showさんのblogより。

野口悠紀雄のトンデモIT論その３

どうやら野口悠紀雄の週刊ダイアモンドのIT論がトンデモだという文脈での話らしい。池田信夫と言い野口悠紀雄と言い、なぜ「経済」の人達はよくわかりもしないのにITを論じるのか。

かつての日本のキャプテンシステムとフランスのミニテルは失敗した。なぜなら、クローズドなネットワークだったからという論を述べているが、キャプテンは普及しなかったけど、ミニテルは当時世界中がああなればいいとうらやむようなサービス基盤を作り、日常生活に深く溶け込んだんですよ。それのどこが失敗なのか。

まぁミニテルが失敗だという認識は確かにトンデモ。

でも、キャプテンの失敗も別にネットワークのせいではないよ。

キャプテンについては、前にも何度か書いている。テレビ局に勤めた14年間のうち、8年くらいはローカルキャプテン会社に出向していた。かなり黒歴史ではあるけど、いろんなことをが学べたし、フリーソフトウェアに深く関わる元になった場所でもあるし、ネット人脈を育てた場所でもある。という自分語りはいいとして。

失敗の原因の一つが「セットトップボックス」であることは、前に書いた。

また端末ソフトウェアのライセンスの問題だったということも、前に書いている。

前に書いてないものとしては、プロトコルの限界というものがある。プロトコルの設計が古いのはしょうがないとしても、その頃にその頃の技術の範囲でガチガチの設計にしたものだから、いろいろな拡張性を放棄してしまうことになっていた。正確に言えば、拡張性がかなりある基本設計の上にガチガチの制約を載せてしまったものだから、基本設計はそんなに悪くないのに、拡張が出来なくなってしまっているのだ。この根本原因は、プロトコルを設計したエンジニアの

想像力の欠如

の結果だろう。プロトコルの寿命は、自分たちの目の前にある技術そのものの寿命よりも、かなり長い。もっと一般的に言えば、

成功した(すべき)システムの寿命は設計者の想定より長い

ということだ。自分がこれから作ろうとしているシステムが成功して欲しいと願うなら、そのシステムの寿命は自分の想像を超えてしまうことを考慮しなければならない。もちろん成功しなければ想像よりも短いことになってしまうのだが、間違って成功することも含めたら、少なくとも設計する時には、

システムの寿命は設計者の想定よりも長い

ということを考えておかなければならない。もちろんその時に考えるべき「未来」は、設計者の想像を超えているかも知れない。であるなら、未知のものに謙虚になって、「未来の人に託す」ことを考えるべきだ。つまり、本来未知であるものに対して、勝手に「現実的」な制約を課すということはするべきではない。

CAPTAIN-PLPSの例で言えば、「画面の大きさ」に対する仮定が入っていて、それ前提のプロトコルになってしまっているのだ。ところが、ほとんどのプロトコル要素ではそんなものは意識する必要がない設計になっているので、逆に「そんなものはいくらでも変化しうる」ということにしてしまっていても、何ら問題はなかったはずなのだ。そうすれば、画面解像度が上げられる時代になっても生き残ることは可能だったろうし、もっと汎用性を持たせることも出来たはずだ。だから、技術者の想像力の欠如によって、プロトコルの寿命を不当に縮めてしまったわけだ。

今から結果論で言えば、あれが長持ちしたところで何のプラスにもならなかったと言えなくもないが、当時プロトコルをいじっていた私にしてみると、「ここに一工夫あるだけでもっと応用範囲が拡がっただろうに」と思ったものだ。と同時に

想像力の欠如した技術者は罪

とも思ったものだった。