2009年06月

Wordpress2.8がリリースされたので、自動アップデート対象になった。颯爽とインストールする。Header Cleaner導入で劇的に軽くなったけど、より軽くなった気はしない。

相当量のChangeLogを読み解きつつ「あー、これうれしいのはないな」と思いつつ、ユーザとはそんなものだよな、と自戒した。

帝国の中心で自由主義を夢見る先に - 雑種路線でいこう.

に大変な感銘を受けたので、いろいろ考えたが、エントリを起こすことにする。これに限らず、この一週間ほど梅田望夫氏の「日本のWebは残念」発言が話題になっている。

まあ個人的には、このインタビューそのものはほうっておいて良いと思っている。というのも、もはや彼は別に日本のWebをどうこうする存在ではない。その資格は、彼がはてぶのコメントには、バカなものが本当に多すぎると発言した時点で失ってしまった。すくなくともL.starの心の中では、彼の発言は「自分が誰に向かって話をしているかまったくわかっていない」ということを自白した以上でも以下でもない。

梅田氏はあの発言時点で日本のWeb2.0をリードしていくこと(と梅田氏が信じることをすること)を「投げた」んだとは思う。「日本の%nは残念」というのが結構な%nにおいて成り立つのは、むしろおおむね同意するところである。ただ一点、投げないなら彼はそれをああいう形で批判すべきではなかった。それだけである。その後の行動見ると「投げた」んだろうし、先のインタビューもその延長線上に過ぎない。L.starも同様の投げ方は何度もやったことがあるので良くわかる(ぉぃ

だから、こう問いかけたい。「あなたは日本のWebが残念だというが、残念でないWebとはどのようなものですか。残念じゃない日本ってどんなものですか」と。梅田氏の著作等々をしっかり読み込んだわけではないが、彼がこれに正しく答えたかというと疑わしい。私が見たのは「シリコンバレーはすばらしい。然るに日本はどうか」という、とある具体例ばかりであり、この2つの本当の本質的な差、そして日本を残念でない世界にするための方法論という部分には行き着かなかった。

翻って、楠氏のエントリはおおむね日本ムラ社会に対する恨みつらみで進行していく。まあL.starの経験から鑑みて、事実無根ではないし、それよりもどす黒そうな話まで出てくるので、恨みつらみというより分析といってよい。そして結果として楠氏の希求するものへとすべてつながっていく。これを読んだ人の感想は大きく二通りに分かれるだろう。NPS(No Problem Syndorome)を発症して現状の日本に苦言を呈する氏を攻撃するか、彼の指し示そうとする道に興奮するか。L.starはもちろん後者なのだが、しかし指し示す道はあいまいかなと感じる。すばらしい道に興奮しながらも、正しく指し示されていないために非常にもどかしいものになってしまっている。いや、楠氏は言葉にこそしていないが、氏がその道を理解していることは想像に難くない。梅田氏も同様に理解しているであろう。なぜ指し示せないのかと思ったが、それは単に攻めている方向が違うんじゃないか、という結論に達した。

正直、日本が物理的に残念だと思ったことはない。企業が腐敗し、政府が馬鹿でも、根源的な問題をいっぱい、それでもいまだに最高の国家のひとつである。というかほかの国家も同様にレベルが低いというべきなのであろうが。そんな最高の国家がシリコンバレーに勝てないのは唯一、心構えではないか。みなぎる自信ではないか。成功するために必要な「空気」とは何か、ということを知ることではないか。

これは、シリコンバレーではなく、バブル前の日本の大企業社会にもおそらくあったと思う。ただ、人間は本質的に自信がない生き物だから、どうしてもその成功を自分自身の行動に結び付けたがるから、その何かあいまいなものだけを抽出して語ることができないだろう。

結局のところ、ムラ社会的な行動力学は、たいていは自信の欠如から生じている、とL.starは考えている。自分に自信があるなら、無駄に他人を攻撃する必要も、利益誘導する理由も、感情論で相手を否定する必然性もないのだ。日本人の根源的な自信の欠如を補うことこそが、残念じゃない日本への一番の近道ではなかろうか。

であればこそ、知っておかなければいけない大変重要なことがある。これは(日本スポーツにおけるメンタルトレーニングの権威である)福島大学の白石豊先生が講演でおっしゃっていたことなのだが、自信とは実績より前に醸成できるものだし、そうすべきである。階級が上がれば行動も自然についてくるというが、それもその証拠のひとつでもあろう。だから、まず自信を持つことができる。必要なのは自信を一方的に打ち砕くような、日本的理不尽さを無視することである。

自信を得るためのもうひとつの方法は宗教であろうが、宗教には救済と再生いう側面がある。罪を赦され、新しい一歩を踏み出す。今の日本に必要なのは、この救済と再生ではなかろうか。攻撃するわけでなく今までの悪い習慣を赦し、新しい方向を定義してそこに向かう力にできる。L.starを含めた多くの人間にとって、自分の過去というのは自分の過去であるということだけで正しいものであるはずだ。それを改めて見つめなおし、良い方向に向かうためには、まず自分を赦さないといけない。社会を見つめなおすなら、社会を赦さないといけない。

あらためて「救済」と「再生」というキーワードから総括に向かうと、梅田氏も楠氏も「再生」については強くメッセージを発している。でも、彼らの言葉に「救済」はないのではないか。「救済」なくしては本当の再生には向かわない。灰にしてしまわない限りはね。だから彼らのメッセージからは(まあL.starのメッセージからもそうなのだろうが)「社会を灰にしてしまわないと」と思ってしまう何かを持っている。だから灰にされると困る人には伝わらない。意見は割れる。そういうことだ。

いやなんでL.starがそんなキーワードにこだわるかというと最近ミュンヘンでワーグナーの「パルジファル」を見て、彼の何かにいろいろと感化されたからなんでしょうけどね。こういう言葉を抑えつつ、世俗的な意味での宗教的なものとは一線をおいて、純粋に何かを語っていきたいな、というのが最近のテーマだったりする。

昔、clockload名義でRoundtableというチャットクライアントを作っていた。clockloadの閉鎖とともに配布終了していたが、最後にコードを書いたのは 2002年のことだと思う。7年前のことだ。これはJavaを使って、チャットなど、一つのワークスペースを共有するもので、かなり柔軟なモジュラー形式にしていたことが自慢であった。もっとも、その柔軟性を使うことはほぼなかったため、無駄といえば無駄だったが。

ところが最近Google Waveという同様のツールが出てきて世間をにぎわせている。触ったこともなければちゃんとデモも見ていたわけではないので正確なことはいえない。が、幾多のちがいはもちろんあれど、大筋で似たようなことをやっているなと感じた。Roundtable自体、せいぜい10000行にも満たないJavaアプリケーション、実質1ヶ月ぐらいで書いたもので、特にWaveletが多数動作している部分の設計は似ているだろうと想像に難くなく、新ためて自分の設計の正しさを思い知ったしだいである。

一方で、RoundtableはGoogle Waveになれなかった。あれで1ヶ月なら、1年まじめにやれば近い部分までたどり着くことは可能だったかもしれない。今日はなぜたどり着けなかったか考察しつつ、自戒としたい。

-同じだったもの

クライアントサーバ型であるとか、データ差分を利用することとかが非常によく似ている。またXMPPをベースにしたWaveのプロトコルは、実際にかなりRoundtableのプロトコルと似ている。waveのほうがシンプルに絞り込まれていること、RoundtableはSerializationに頼りっきりな100%Java依存なところとかがまあ違いである。

どちらも基本的にデータは差分であり、差分から全体を構成するところもそっくりである。そのようにすることで、ヒストリーの保存や再生もかなり簡単に可能である。

プロトコルの構成から見て、コアとWaveletの関係もたぶん予想の範疇である。これだとWaveletは通信をあまり意識せずに書け、しかも依存性も低いだろう。

- 異なる競合性解決

この種のアプリケーションで面倒なのは、同時に同じ部分を編集しようとしたりしたときの解釈である。Roundtableでは、これは解決していなかった:) なにしろ、同時にいじる人数は少ないので、さほど工夫をする必要もないのである。それゆえデータはすべてのクライアントノードでばらばらに持っていた。これは比ゆ的にいうと、SQLデータベースにおけるクエリベースのレプリケーションに似ている。ただし、この場合はSQLよりもずっと競合は少ない点は救いか。その先として考えていたのは、各アクションに対して必要なだけpessimistic lockをとらせ、取れた後行動可能にさせるというものだ。今考えると、デッドロック時の挙動が怖い。そして、作ったときには考えていなかったが、クエリベースの不安定さというのは、2004年ごろから強く身にしみて学ぶことになる。

次にWaveだが、InfoQの記事のGoogle Wave アーキテクチャに詳しい。Waveの核はOperation Transformationというものであるらしい。これは単一のエンティティをサーバ上に用意する共有型である。こいつのなにがすごいかというと、UIのような高速さが要求される部分に対して、すばやく文字単位で更新を受け入れつつ、しかも最終的につじつまを合わせられるようなトランザクションモデルを提供していることだ。

一連の動作に対して、まずxidをすばやく取得に走る。取得は非同期で、運よく受け入れたれた場合はその更新をサーバに伝え、さらにその間の更新についても再び同じように問い合わせる。最後にサーバから最終バージョンへの差分が投げられて、これでクライアント間の整合性もばっちりだ。

これに二年かかったというのもうなずける。リカバリーだのなんだのを含めると、このすばやく反応可能な、完全なトランザクションモデルを実現できるサーバプロトコルは、ちょっとやそっとのしろものではない。データモデルこそ単純だが、BigTableよりも高度なことをやっているのではないかと思ってしまう。

- 洗練されたUIと機能

そしてもちろんGoogleの18番、きっちりと機能とUIを作りこんでいるところである。RoundtableはL.starの知りうるSwingテクニックを全部盛り込んだ野心作であったといえるが、一方でGoogleのUI作りこみはそんなL.starのプライドなどゴミくずにしか見えないようなクールなのを作っているので定評がある。サーバに盛り込める機能といい、それに対するチューニングといい、彼らのほうが数十段よい仕事をしているのは間違いないだろう。

こんなところだろうか。もちろん知名度とかそういうのは、正直言ってもともと天と地の差があるので、同じように作れたとしても有名になったとは思えない。しかし、それ以前にやはり大きな差もまた感じてしまった。L.starはいったい8年間、どれだけ時間をどぶに捨ててきたのか考えてしまう。

というか、まさか自分が昔やったトランザクション技術と、UI技術がこんなところで融合されうるとは、到底考え付かなかった時点で負けなのだろう。素直にあらためてRoundtableを引っ張り出して、Operational Transformationもどきを実装するとか、そういう勉強から復帰すべきだろう。

↑このページのトップヘ