違法ダウンロードの刑罰化

いよいよ明日（10月1日）より、違法ダウンロードの刑罰化を盛りこんだ著作権法が施行されます。

迫る違法DL刑罰化にネット民不安

さて、それではどんなものが違法ダウンロードになるのでしょうか。
以下、上記のリンク先の記事からの抜粋です。

• “有料著作物等”とは、有償で提供されている著作物のこと。音楽CD、映画やアニメのDVD、さらにネット上で有料配信されている音楽・映像が当てはまる。しかし、ソフト化される予定のないテレビ番組などは“有料著作物”には当たらない
• 違法にアップされた動画をYouTubeなどで閲覧するだけなら違法にならないが、それをファイルとしてダウンロードすると違法となる。動画再生時のキャッシュは違法ではない
• メールに添付された違法複製ファイルをダウンロードしても違法ではない
• 画像ファイルのダウンロード、テキストデータのコピー＆ペーストは“録音・録画”に当てはならないので刑罰の対象とはならない

なんとなく理解はできるのですが、リンク先の記事にもあるように、何をすれば法に触れるのかがいまいちあいまいです。

たとえば、パソコンに取り込まなくてもDropboxやSkyDriveのようなクラウドサービスにコンテンツを保存するのは違法なのか合法なのか。
クラウドサービスにファイルを保存することはダウンロードとはいいませんが、この法律が制定された目的を考えると、違法になってしまうかもしれません。

また、「録音・録画」されるコンテンツのみが対象となるので、画像ファイルとして端末に取り込まれるマンガは違法にならないようです。
海外サイトには、多くのマンガが無料でダウンロードできる状態になっているにも関わらず、です。

さらに1つ疑問なのが、どうやってそれらの違法ダウンロードを検知するのでしょうか。
違法ダウンロードが可能なサイト（違法サイト）へのアクセス履歴を調べ、有償コンテンツをダウンロードした閲覧者を摘発するのでしょうか。
本来なら、違法サイトの存在自体が問題のはずです。
違法サイトの多くが海外にあることを考えると、サイトを閉鎖させたり有償コンテンツを削除させたりするのが難しいのかもしれませんが。

それと、「いつ、どこで、誰が、どんなサイトをみていたか」というアクセス解析データを、犯罪防止の目的で収集されてしまうというのは、あまり気持ちのいいものではありませんね。

五十嵐貴之

電子書籍の妥当な価格

先日（9/24）、私が著させていただいた書籍の1つが電子書籍として販売開始となりました。

「いちばんやさしいデータベースの本」（技評SE選書 シリーズ）

（この書籍の紙版は、2010年8月より発刊されています）

電子版の価格は、紙版と変わらず1,680円（税別）です。
ただし、電子版の場合は価格が変動する可能性もあります。
（紙版はどの書店でも必ず同じ価格で販売されますが、電子版は販売サイトによって価格が違う場合があります）

ところで、同じ書籍なら紙版と電子版で同じ価格という考え方について、読者はどう感じているのでしょうか。

出版デジタル機構「パブリッジ」のスキームを考える

上記のサイトに掲載されている、ジャストシステムが3月7日に公表したアンケート調査結果によると、多くの読者が紙版よりも電子版の価格は安くあるべきだと考えているようです。
しかも、紙版の半額以下が妥当だと考える割合が、4割にも達しているようです。

実際、電子版は紙版と違い用紙代もかかりませんし、書店に並べてもらう必要もありません。在庫管理も不要です。
そのため、販売するために必要となるコストが紙版と比較して安くなるであろうことは容易に想像できますし、そのために電子版は紙版よりも安くあるべきだと考えてしまうのは当然かもしれません。

しかし、それだけで電子書籍の妥当な価格を判断するべきではありません。
これから、書籍の電子化はいよいよ本格化されることになるでしょう。
ヘビーな読書家は、旅行先へ大量の書籍をスーツケースに入れておく必要がなくなります。
今後は自分のお気に入りの電子ブックを1つ、ポケットのなかにいれておくだけです。
自宅の本棚にあふれかえるほどの書籍を抱え込むこともなくなります。
それでも電子版と紙版が同じ価格で販売されていたら電子版は損した気持ちになるからやはり紙版を購入する、といったことになるでしょうか。

書籍のコストから価格の妥当性を考えるより、その時々に応じてどちらを購入したほうが自分にとってよりよいかを考えることになりそうです。

五十嵐貴之

バーチャルとリアルの狭間

2012.09.22付の日本経済新聞Web版に、次のような記事が掲載されていました。

ゲームショウの伏兵、エンタメの未来映すソニーの実験 - 「現実と録画を混同させる」、ＨＭＤ試作機で実現

この記事では、Sonyが開発した頭部に装着することによってプレイするゲーム用専用の液晶ディスプレイについて紹介しています。

Sonyは、この液晶ディスプレイをとおしてみた空間がバーチャル（仮想）空間なのかリアル（現実）空間なのか、体験者には判別できないほどリアルに近いバーチャルを作り出すことに成功したようです。

「そんなリアルっぽいゲームなんて気持ち悪くてやれないよ」

なんて意見もあるかもしれませんが、おそらくは単なるゲーム機のためのディスプレイとして利用されるだけではないでしょう。

自宅にいながら世界旅行に出かけたり、大好きな片思いの異性とデートしたり、限りなくリアルに近いそんなバーチャルを楽しむことができるようになるかもしれませんね。

しかし、2009年に発刊された芦崎治氏の「ネトゲ廃人」に出てくる1ゲーマーのように、リアルな生活をバーチャルな世界でリセットしたつもりになる人も大勢出てくるかもしれません。

リアルとバーチャルの区別がつかなくなったことに起因する犯罪も増えるかもしれません。

これらの心配事は、やはり誰もが抱かずにはいられないでしょう。

五十嵐貴之

Facebookの終焉?!

「フェイスブックが幕を閉じる日が近づいている」

2012.09.18付でJapan Business Pressに掲載されていた記事のタイトルです。
記事の内容は、こちらです。

http://www.blogger.com/blogger.g?blogID=5593071713677772050#editor/target=post;postID=5635781477897299878

私もFacebookを利用していますが、正直いってかなり飽きてきています。

私がFacebookを利用し始めた理由は、ikachi Softwareのサイトのアクセス数を増やすためです。
Facebookでikachi Softwareのサイトを宣伝し、誘導することが目的だったのですが、ほとんど効果がありませんでした。
もちろん、宣伝の仕方がよくなかったのでしょうが、私はあまりマメな性格ではないので、Facebookにそれほど多くの時間を割く気になれません。
このような姿勢でFacebookを利用していたため、宣伝効果が得られなかったと知ったときにやる気がうせてしまったのです。

「中国、インド、Facebook」などと、Facebook人口は中国とインドに次いで第3位とも揶揄されるほどの爆発的な人気を誇ったSNSでしたが、今、Facebookの発祥国である米国ではその熱が急激に冷めてきているようですね。

実際、Facebook上に掲載した記事を多くの方に読んでもらうには、まずは多くの（Facebook上の）友達を作らなければなりません。
リアルな世界での友達だけでは友達同士のコミュニケーションツールとしての役割だけでしかなく、それだけではFacebookを利用する利点は少ないでしょう。
Facebook上の友達はリアルな世界の友達だけではない方の方が、おそらく多いのではないでしょうか。

自分が掲載した記事をFacebook上のみでの友達に読んでもらうには、それらの友達の記事の「いいね！」ボタンを押すことでしょう。
本当にその記事を読んだかどうかに関わらず、です。

「この人、よく知らないけどいつも私の記事に「いいね！」をしてくれるので、私も今日はこの人の記事に「いいね！」をしておこう」

より多くの人にそう思わせることが、より多くの方に自分の書いた記事を読んでもらうために必要なことなのです。
（いや、「いいね！」をしてもらっただけかもしれません、読んでもらってないかもしれません）

現在では、ikachi SoftwareのFacebookファンページに「いいね！」をしていただいた方は10人を超えることができました。
しかし、このほとんどはFacebook上でikachi Softwareを宣伝したことによって「いいね！」をしていただいた方ではなく、逆にikachi SoftwareのサイトからFacebookaのファンページを見つけて「いいね！」をしてくださった方の方が多いようです。
本末転倒ですね（笑）

五十嵐貴之

TwitterのCEO、APIについて語る

先日、このブログでも書きましたが、Twitter APIの変更によって関連アプリのほとんどが使えなくなってしまう可能性があります。

Twitter API ver.1.1 バージョンアップについて

これに関し、Twitter社のCEO、Dick Costolo氏からのコメントがありました。
Yahoo!ニュースの記事に掲載されています。

TwitterのCEO、「真のプラットフォーム」の構築を強調--開発者の怒りの声を無視

CEOのいう「真のプラットフォーム」を構築することによって、全世界のツイートにアクセスするためにはTwitter社が提供するUIに絞られてしまいます。
これにより、Twitter社の広告収入は「複数のプラットフォーム」が存在していたときよりも多く得られることになるでしょう。

しかし、今までTwtterの発展に貢献してきた「複数のプラットフォーム」をかんたんに切り捨ててしまうことは、やはり「プラットフォーム」の開発者にとってはかなりの痛手であり、ひどい仕打ちであると私は思います。

共に闘ってきた盟友の手柄を恨んで後ろから刺し殺す。

そのくらい、ひどい話しです。

五十嵐貴之

Twitter API ver.1.1 バージョンアップについて

2012年9月5日、Twitter API のバージョンが1.0から1.1へとアップしました。
メジャーバージョン（整数部のバージョン番号）ではなく、マイナーバージョン（小数第1位のバージョン番号）の変更です。

通常、マイナーバージョンの変更は修正規模がそれほど大きくないものですが、今回のTwitter APIのマイナーバージョンアップは、Twitter APIを利用したアプリの開発者が強いショックを受けるほどかなり大きな変更となりました。
詳しくは、以下のリンクをご覧ください。
ITに詳しい方でないと、聞いたこともない横文字だらけで読みづらいと思います

TwitterからのRSS取得が2013年3月5日で打ち切りへ（GIGAZINE）

上記のリンク先の記事をかなりかんたんにいってしまえば、

• 今まで使用していたTwitter関連アプリが使用できなくなる可能性が大いにある
• 使えたとしてもツイートが1時間に60ツイートしか表示されない

の2つが重要でしょうか。
1回でTwitterとFacebookの2箇所へ記事を投稿できるようなアプリについては、今後一切使えなくなるようです。
移行期間が来年の3月15日まであるとはいえ、Twitter関連アプリの開発者は今回のバージョンアップにかなり嫌気がさしているようですね。

さて、上記のGIGAZINEのサイトからもリンクされている江添亮氏の「本の虫」ブログでは、これをTwitter社の"邪悪な囲いこみ"と表現しています。

Twitter API 1.1により、Twitterは終了する（本の虫）

今までは、Twitter関連アプリを開発する開発者によって様々な便利アプリが市場に出回っていました。
Twitterがこれほど普及した要因の1つとして、これらの便利アプリの存在もきっとあることでしょう。
これらの便利アプリがTwtter社からツイートを取得するたびに、おそらくはTwitter社のサーバーに大きく負荷がかかったことでしょう。
そのため、長時間ツイートを取得できなくなり、何度もフェイルホエール（Twitterが何らかの理由によってエラーが発生した場合に出現するくじら）の画像を表示するはめになったかもしれません。
しかしながら、ここでいきなり手のひらを返し、ここまでTwitterとともに成長してきた関連アプリの存在を切り捨てることが許されるでしょうか。

同じアプリ開発者として、今回のTwitter社のやり方には個人的に非常に不愉快です。

五十嵐貴之

ジョエルテスト④

３．デイリービルドしてる？

デイリービルドを行う目的としては、常に正常にビルド可能なソースコードをプロジェクト内で共有するためです。
そして、そのためにはジョエルテストのいちばんめの項目であるソースコード管理が必要となってきます。

個人で開発する小さなシステムならともかく、複数人で開発する大きなシステムの場合、1つのモジュールを複数人で手を加える場合が多々あります。
そのとき、ある人の環境では自分が修正したモジュールをつかってビルドがうまくいったのに、また別の人の環境ではビルドに失敗した、などという場合も往々にしてあります。
それは、一部のモジュールの最新を環境に取り込んでいなかったり、また別の外部的な何かが要因となることもあります。

デイリービルドを習慣づけた場合、誰かが壊してしまってビルドできなくなったとき（修正したはずのモジュールを使うとビルドできなくなった状態）、それに気づくのは最長でも24時間以内です。
しかしデイリービルドが行われていない場合、どのモジュールを直せばビルドは正常に動くようになるのか、またそのモジュールを修正して今度はビルドがうまくいったとしても、そのモジュールに本来行われるはずだった修正はきちんと反映されているままなのか、それが出荷の直前だったとしたら、プロジェクトは大慌てすることになるでしょう。

五十嵐貴之

ジョエルテスト③

２．ワンステップでビルドできる？

Joel Spolsky氏は、

良いチームでは、ひとつのスクリプトを実行するだけで、そのスクリプトがスクラッチから全ソースをチェックアウトし、すべてのコードをリビルドし、すべてのバージョンと言語と#ifdefの組み合わせについてEXEを作り、インストールパッケージを作り、そしてCD-ROM形式であれWebサイト用のダウンロード版であれ、最終的なメディアを作る

とあります。
ソフトウェアの規模が大きくなればなるほど、上記のすべてを実現するのはなかなか難しいものですが、しかしソフトウェアの規模が大きければ大きいほど、非常に重要なことです。

私が以前勤めていた会社では、あるパッケージソフトのインストーラーを作成できる者はたったの1人でした。開発は10人程度で行っていたのにです。
もし、その社員が何の引き継ぎもせずに突然退職してしまったら、今までどおりのインストーラーを作成することはできず、別の方法を模索することになったでしょう。そしてそれにどれだけの工数をかけることになるか、想像できません。

Joel Spolsky氏が述べたインストールパッケージを作るスクリプトに関しても、そのスクリプトを作った者以外は誰も理解できないといったことがないようにしなければなりません。

五十嵐貴之

ジョエルテスト②

１．ソース管理してる？

私が今までに携わったことがあるいくつかのプロジェクトのなかで、ソースコード管理システムを使用していたチームはほとんどありませんでした。
なかには、ユーザーに出荷する際にバージョンを管理する必要がある中規模ソフトウェアでもソースコード管理システムを使用していない例がありました。
おそらく、今までにソースコード管理システムを利用したことがないため、そのメリットがわからないからでしょう。

ソースコード管理システムのメリットは、ソフトウェアの規模が大きくなればなるほど実感することができます。
また、たとえ単発で終わる小規模ソフトウェアの開発であっても、ソースコード管理システムにソースコードを保管しておくことでソースコードを紛失する危険性を回避することができます。
それ以外にも、

• 以前のバージョンに戻ってモジュールをコンパイルしたい
• いつ誰がどのような修正をどのモジュールに対しておこなったかを知りたい

などの悩みは、ソースコード管理システムを利用することで解消されます。

とにかく、ソースコード管理システムを使わないメリットはないといっても過言ではありません。

五十嵐貴之