ソフトウェアの突然変異：ミッシングリンクを予見する（前編） - (page 2)

データが重要

　Jeff Atwoodは最近、Joel Spolskyはやりすぎだという記事を投稿した。投稿には怪しい部分もあったものの、Joelはこれまで相当な量のエッセイを書いてきた。わたしが特に興味を引かれた、「Excel」の成功の転換点は「Lotus 123」のデータを読み書きできたことだったということを説明するエントリもそのひとつだ。

　直接的なゴールは、アプリケーションが市場シェアを競争相手から奪い取るべく障害を取り除くことだ。しかし、実際の教訓はもっと大きい。どの表計算アプリケーションでも他の表計算アプリケーションのデータを読み書きできれば、ソフトウェアは製品を取り巻く生態系の大きさではなく、どのくらいうまく動くかで評価されるようになる。企業はシェアに安住してそれを守るのではなく、常に製品を改良し続けなくてはならなくなる。ユーザーは何を食べ、どこで買い物をし、どんな車を運転するかを選べる。表計算ソフト、スケジュール管理、オンライン状態通知などのアプリケーションについても、ユーザーが同じことを望むのは当然のことだ。ユーザーにとっては、ソフトウェアのコードが自分のものでなくてもいい。しかし、自分が作成して編集し、蓄積したデータは自分のものだ。

マーケットの問題

　オープンソースは、多くの優秀なプログラマーの注意と時間を捉えてきた。そしてその結果、オープンソースで何ができるかを示してきた。しかし、オープンソース運動が必要としているのは、むしろ多くの優秀なマーケティング専門家がオープンソースの重要性を示すことに費やす注意と時間なのだ。典型的なエンジニアのやり方では、マーケティングは後付けになる。しかし、OSを書くのと同じ努力がデータ標準のマーケティングに使われれば、理想主義者たちは自分たちの理想の世界に一歩近づけるだろう。

　直言すれば、夢想的なオープンソースの（非）ビジネスモデルは過去のものだ。Linux、Apache、Mozillaなどの目立ったオープンソースプロジェクトには、背後に十分な資金力を持つスポンサーが付いている（IBMでありGoogleだ）。Firefoxのマーケティングがこれほどうまく行ったのは、偶然ではない。夢物語よりも、損益を見張るスポンサーの方が必要なのだ。必要なのは新しい触媒だ。

モバイルデバイス

　モバイルデバイスの売上高がパソコンの売上高を抜き去ったことは人々の注目を集めた。このことはどういう結果を生んだだろう。パソコンは複雑なソフトウェアによって動く汎用機器であり、何でもこなせるように作られているのに対して、モバイルデバイスは簡単なソフトウェアを実行するように設計されている。絞り込まれた要素を対象とし、限られたことを上手にこなすように作られている。

　現在のデスクトップコンピュータやラップトップコンピュータは、リーンな体というよりはステロイド剤を使っているスポーツ選手に近い状態だ。前述したわたしの親戚が最近買った新しいコンピュータは250Gバイトのハードディスクを搭載している。この容量を子どもの写真で埋めるのは大変だ。毎週、100キロバイトのサイズの写真を100枚撮るとすると、このハードディスクが埋まる頃には子どもは480歳になっているだろう。

クリーンコンピューティング

　モバイルデバイスはこの点では弱い。モバイルデバイスの場合、持ち運べるだけ軽く、ポケットに入るだけ小さくなくてはならず、スリムなデザインでなければならない。もちろん、iPodのような目的が1つのモバイルデバイスが、大容量ドライブの機能も持っている場合もある。しかし、プログラマーはむしろ、無線インターネット接続、より多くのガジェットやウィジェット、それから開発プラットフォームを求めるのだ。その結果出てきたものは、デスクトップコンピューティングの初期、必要な最大メモリが640キロバイトだったころのものに似たものだ。モバイルデバイスは、デスクトップやラップトップ上のデータでは多くの場合うまく動かないが、これは単にそれらのデータが大きすぎるからだ。

　モバイルデバイスでは、データの大きさは必要最低限にすべきだ。別の言い方をすれば、正しい動作をするのに、完全なデータセットは必要ないということだ。一意の識別子さえあれば十分なはずだ。これは、データをよりモバイル向きにできるというだけでなく、データのやり取りを改良したり特殊化したりするのにも役に立つ。

目を覚ませ、データに着目せよ

　iCalendarの例に戻って、WiMAXを備えていて、丸くて頭に2つのベルが付いている、時間を告げるモバイルデバイスを想像してみよう。これを、ここではiAlarmClockと呼ぶことにする。iCalendarの仕様は完全なので、時間が関係する大抵のイベントについて役に立つが、これと連動するiAlarmClockについては問題が1つある。アラームをいつ消せばいいかということだ。正しいフォーマットのiCalendarのエントリは、UML4ページ分ほどの情報を持っているものとしよう。ここで、iAlarmClockはその4ページ目に掲載されているAlarm Component Propertiesの情報を必要とするとしよう。さらに、もしiAlarmClockの後ろについている丸いつまみを使って手動でオーバーライドすれば、アラーム時間を修正できるのならば、iCalendarのエントリも、同じ情報源に基づくほかのデバイスも、このデータの断片に基づいて魔法のように自動的に更新されれば便利だ。そうすれば、わたしがどこで昼寝をしても、わたしの全てのiAlarmClockを利用できる。

　われわれプログラマーは、データ全体ではなく断片を扱える必要がある。全体像が見えなくても問題ない場合もあり、その場合には手元のタスクに必要なものだけを使う。目的はデータの完全さではなく、アラーム時計や冷蔵庫、掃除機や洗濯機などのつまらないものを機能させるのに十分なだけ、データが役に立つかどうかだ。

　パート2では、Web 2.0と社会的つながりのミッシングリンクに関する記事をお届けする。