時代に咲いた徒花: 『プログラマのジレンマ 夢と現実の狭間』
同僚に教えてもらって読んだのだが、とても良かった。プログラマは必読だが、それ以外の人にもおすすめしたい。
Chandlerという鳴り物入りで始まったオープンソースプロジェクトについて、およそ3年にわたって追いかけた失敗の記録。といって「ああ、デスマの本ですか」と一括りにしてしまうともったいない。確かにソフトウェアプロジェクトの失敗の話なんてありふれているし、デスマーチの本なんて他にいくらでもある。この本が面白いのはたぶん、そういうありがちな問題がまるでないプロジェクトだったにもかかわらず失敗する、ということを報告しているからだ。
デスマーチはない。納期に追われて徹夜するやつはいない。勤務時間は自由であり、オフィスには愛犬を連れてきてもいいし、在宅勤務もオーケー。資金的にも問題ない。スポンサーが変なことを言い出して仕様変更になったりしない。リーダーはロックスター級の人物で、他にも超大物で有能な人物がどんどん参加する。しかも、リーダーは壮大で理想的な目標を掲げ、みんなその理想に共鳴して参加する。ビジョンは共有されている。
にもかかわらず、プロジェクトは進まず、失速する。なぜか?
その問いには簡単には答えられないが、ひとくちで言うなら、目的が壮大過ぎ、かつはじめから高い完成度を追い求め過ぎたことかと思う。Chandlerは凡百のツールとは違う。メールのやり取りができ、予定の管理ができ、メモを書き留めることができ、ドキュメントやTODO管理ができ、しかもそれらのデータは相互に変化させることができる(受け取ったメールからカレンダーの予定やTODOを作ったりできる)。さらにデータの同期までできるが、データの同期はP2Pで中央のサーバを必要としない。
壮大すぎるし柔軟すぎる。案の定、開発者たちは議論だけの無為な時間を過ごす。メールはアイテムなのか、スレッドはどうなるか。くり返しの予定はどういう風に保存されるべきか。ドキュメントの集合はドキュメントとして管理されるのか、違うのか。議論は長引き、会議は踊る。どうでもいい技術が導入される。
けっきょく、機能を限った小さなプロトタイプから始めてドッグフードしつつ完成度を高めていくのが一番だと思うけど、チームはなかなかその結論に至らない。データは、ユーザからはどれも等価に扱えるべきだけど、内部的には階層的な意味論で管理されるべきだ、という提案を受け入れづらい。P2Pは将来の目標ということで棚上げしてしまえば楽だけど、なかなかそういう道に進めない。エンジニアは斧を研ぎたがるという話がこの本に出てくる。その時点では必要ないかもしれないけど、将来必要となった時のために考えておくべき拡張性や新機能を斧になぞらえているわけだ。ゲームを作るのにまずメモリマネージャを作り始めるというネタも近いものがありそうな気がする――何故かそこから始めてしまい、それ自体は高機能だが、いつまでたっても所望のものが出てこない。
開発プロセスもなかった。オープンソースというと、いろんな人達がよって集って作り上げていくから開発プロセスも無きに等しいと思いがちだけど、それは違う。個人プロジェクトならそうだけど、これほどの大規模プロジェクトではそれじゃ無理が出てくる。普通の会社とは違うかもしれないけれど、何らかのプロセスなしには進めなくなる。どういうスケジュールで、どの段階までに何が必要で、それにはどれだけ時間がかかるか。次のバージョンではどのバグを直し、どの機能を入れるのか。やり方はなんでもいいのだけど、そういうことをなにもしないとプロジェクトは迷走する。
……ここであげるれた問題は、よくあるデスマの愚痴とは違う。違うがゆえにソフトウェア開発でおこる問題が浮き彫りになる。プロジェクトが失敗するのは、技術のことをわかっていない客が余計な口出しをするからではないし、無茶なスケジュールが組まれるからでもない。プログラマが無能だからでもない。そういうことではない。なのに、いつまでたっても具体的な問題に落とし込まれず、動くものも出来ず、プロジェクト自体が泥沼にはまってしまう。
ただ、こういう問題は、あげつらうと大したことのない話に見えるので、あとから振り返ってみたり傍から見れば「それはこうしたらいいに決まっているじゃん」と思いがちなんだけど、読むと結構ぐさぐさくる。人間、そう簡単に地雷を避けることはできない。
—
テクニカルに面白いのは、採用する技術のことごとくで地雷を踏んでいることかも。当初からマルチプラットフォームを考えていたので、Python。これはいいけど、GUIにはwxPython。ウェブは使わない。何故ならUIがイケテナイから。データの意味論にはRDFを採用。というか全面的にXMLっぽい。RDF「トリプル」とか、久々に目にしましたよ……。ストレージはP2Pでの同期を想定し、ローカルにはZopeのオブジェクト指向DB、ZODBを採用(のちにBerkeley-DBを直に叩くように書きなおし)。迷走の数年を経て最終的にはP2Pは諦め、webDAVを使った同期を採用。
いちおう弁護しておくと、プロジェクトの構想は2001年頃、実際に始動したのは2002年ぐらい。プロジェクトが迷走している間の2004年にgmailが登場し、ajaxがバズワードとして急速に広まっていくが、まともなウェブアプリをデスクトップアプリと比較するのはありえないという時代だった。
そういえば、本も終盤になったところで、とあるPythonハッカーがこのプロジェクトに参加することになって、そのコードを読んだのをもとにして「PythonはJavaじゃない」という記事を書いて揶揄したというくだりがある。著者はその中身までは紹介してなかったが、好奇心から読んでみたらおもしろかった。技術的に詳細すぎるとして著者が省いた論旨の中には、たとえばXMLの多用がある。JavaではXMLはいいものだとされている。柔軟さにかけるコードに動的な機能を与えるツールとしては便利だ。だけどPythonならコードははじめから柔軟なんだから、XMLを使う意味はない。XMLを手書きするより、Pythonのコードの書いたほうがシンプルでわかりやすい。まあ、ある程度の経験がある人なら「そりゃそうだ」と思うような話だよね。それで思い出したんだけど、本の半ばぐらいに「レイアウト情報もデータの形でストレージに入っているから、コードは何も変えなくてもデータを変えるだけでレイアウトを変更できる」技術が成果の扱いで紹介されてたんだよね。そうか、XMLか……とちと感慨にふける。
全般的に「そういう時代だった」としか言いようのないテクノロジーの組み合わせなのかもしれない。XMLとセマンティックウェブの夢。ああいう壮大で理想主義的で、確かに実現したらすごいかもしれないけど現実的の細々とした問題に目がいかない。そういう時代だったし、そういうビジョンだったのかも。
今は、壮大で巨大なプロジェクトというのが成り立ちづらくなっている時代なのかもしれない。これは野望そのものの壮大さとは関係ない。「世界を変える」のが野望だとして、そこに至るのは「なんでもできるすごいヤツ」ではなくて、むしろ「メールサービス」「TODO管理」「メモの記録」そういった小粋でニッチを埋めるようなツールなのかもしれない。小さなツールから出発し、それをうまくやりながら広がっていくパターンこそが成功の道。そういう、時代の境目に咲いた徒花のような視点で本書を読むこともできる。かも。
—
翻訳は微妙な気分になる。訳者の伊豆原弓さんは『イノベーションのジレンマ』の人でキャリアもあり、訳自体はこなれている。だけど、エンジニア以外の人が読んで楽しめる本という原書の目的に追随するために(たぶん)、中の用語は可能な限りカタカナに訳すというポリシーが採用されている。その結果、ゾープとかルシーンとか、ウェブDAVとかwxウィジェッツとかJavaスクリプトとか、思わずのけぞるような訳語が結構ある。この辺は頑張って読んでくださいとしか言いようがない感じ。
—
本書の終わりは、一応の希望を感じさせる終わり方になっている。時間はかかったし、機能もまだ素晴らしいとは言いがたいが、開発プロセスは手に入れた。ドックフードもしている。最新版のリリースにひどい遅れはなかった。プロジェクトリーダーは、色々あったけどプロジェクトには関わり続ける。資金もある。オープンソースプロジェクトには明確な完成がないことも多い。著者の取材は終わるが、プロジェクトは続いていく。
……んだけど、オリジナル版の2年後に出たペーパーバック版にたされたあとがきと、訳者あとがきで語られるプロジェクトのその後で何もかも台なしな感じ。プロジェクトは続いていくことに変わりはないけれど、戦いは終わった。勝ち負けで言えば、Chandlerは負けた。そういう時代なのかもねえ。