ビッグピクチャー
From The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳
2007年1月21日 日曜
以下はスコット・ローゼンバーグのDreaming in Code(コードで見る夢)のレビューだ。
目というのはページフォルトの機構を使っている。これはあまりにうまく機能しているため、あなたがそれに気付くことはない。
目が高解像度で見ることのできる範囲というのはごく小さい。おまけに真ん中あたりに大きな盲点がある。それでもあなたは自分の回りの超高解像度パノラマイメージを持っているつもりで歩き回っている。どうしてそんなことが可能なのか? 目はすごく速く動き回っており、通常の状況においては、目はどこであれ、あなたが見たいと思った方へと即座に向きを変えることができる。そして頭は実に完成度の高い抽象化を提供しており、ごく小さな高解像度イメージと、広範囲だがはなはだ解像度の低いイメージと、見たいと思った部分をすぐにページインできる能力によって、完全な視覚の幻想を作り出し、一日中歩き回っているあなたに、全体像が頭の中の小さな劇場に投影されていると思わせている。
これはとても有用であり、その他のいろいろな感覚もまたこのような働き方をしている。耳は会話の重要な部分だけ拾い上げることができる。指は必要なものを探ってまわり、それが上質のメリノウールのセーターなのか、自分の鼻の穴の中なのかについて、あらゆる部分の感触の全体像を与える。夢を見ている時にも、あなたの心は普段のように感覚に対して様々な問い合わせをする(それは何? あっちの方を見たい!)。しかし感覚は一時的に切られており(なにしろ眠っているわけだから)、感覚は一種ランダムな答えを返す。あなたの頭はそれらを組み合わせて夢と呼ばれるおかしなストーリーを作り出す。そして朝になってあなたがその夢をボーイフレンドに話して聞かせようとすると、それにはまったく完全な現実感があるにもかかわらず、実際何が起こったのかわからないことに急に気づいて途方にくれることになる。あなたが1分か2分眠っていたなら、あなたの脳は感覚に対して、バラの茂みの中で自分と一緒に泳いでいる動物が何かと聞いていたかもしれない。そしてとんちんかんでランダムな答えが返ってきたことだろう(カモノハシだよ!)。しかし目を覚ましてその話を誰かにしようとするまでは、聞く人に筋が通るようにするにはバラの茂みで一緒に泳いでいた動物が何か知る必要があるということにすら気づかない。首尾一貫した話には決してならないのだ。だからあなたの見た夢について教えてくれようとしないでいいよ。
これの具合の悪い副作用の1つは、心がものごとをどれほどはっきり理解しているかについて過大評価しがちだということだ。心はいつでも「ビッグピクチャー」を持っているつもりでいる。たとえそうでないときであっても。
このことはソフトウェア開発においてはとりわけ危険な罠となる。やりたいことの大まかなアイデアが頭の中にできると、それはまったく明快で何かをデザインする必要があるとさえ思われない。すぐに飛び込んでビジョンの実装に取りかかれると感じる。
たとえばあなたのビジョンは古いDOSのスケジュール管理ソフトの再構築だったとしよう。それは大変結構なのだけど、ぜんぜんお勧めできない。それは簡単なことのように見える。それがどう機能するかは明らかなように思える。あなたは何かをデザインしようとさえしない･･･そして一団のプログラマを雇って、コードをバリバリ書き始める。
ここであなたは2つの間違いを犯している。
第一に、心の自信過剰のトリックに引っかかっている。「ああ、これのやり方ならよくわかっている! まったく分かり切ったことだ。仕様を詰める必要もない。ただコードを書きゃいいんだ」
第二に、デザインする前にプログラマを雇ってしまっている。それがまずいのは、ソフトウェアをデザインしようとするのより難しい唯一のことは、チームでソフトウェアをデザインすることだからだ。
他の1人か2人のプログラマとミーティングし、プログラムがどう動くべきか決めようとして、そしてどこにもたどり着かないという経験をしたことは数え切れないくらいある。それで私は自分のオフィスに引っ込んで、紙切れを引っ張り出し、考え始める。別な人とやり取りするというまさにそのことが、機能をデザインするときに必要となる集中を妨げるのだ。
私が辟易するのは、何かがうまくいくか見極める必要が出るたびにミーティングを開くという悪習を持ったチームだ。会議して詩を書こうとなんてするか? それは太った大工の一団がソファに座ってベイウォッチを見ながらオペラを書こうとするみたいなものだ。ソファに太った大工を追加するほど、オペラが出来上がる可能性は低くなる。
せめてテレビは消しなよ!
Chandlerのチームで何が起きたのか推測しようとするのは思い上がりだろう。彼らが今いる地点にたどり着くために、なぜ何百万ドルも使い、何年もかける必要があったのか。それはすごいバグだらけで不完全なカレンダープログラムで、去年現れたそのほかの58のWeb 2.0カレンダーと比べてもあまりパッとしない。そういったプログラムはみんな2人の大学生が暇な時間に作ったもので、しかも2人のうちの一方は大方マスコットを描いただけなのだ
Chandlerにはマスコットさえない!
前に言ったとおり、私は彼らの何がまずかったのか知っているわけではない。もしかすると何も悪くなかったのかもしれない。彼らは順調に進んでいるつもりでいるのかも。スコット・ローゼンバーグのすばらしい新刊は、今時の最高にホットなスタートアップを舞台とした「超マシン誕生」になるべきものだったが、スコットの話は途中で途切れている。Chandler 1.0が近いうちには現れそうにないためだ。(それがリリースされる頃には本なんてなくなっているかもしれないというリスクをローゼンバーグは犯せなかったのだろう。きっと知識は錠剤にして飲むようになっている。)
それでも、この本はある種のソフトウェアプロジェクトについて書かれたすばらしい本だ。そのプロジェクトとは、回りに回り続けて、そしてどこにもたどり着かないプロジェクトだ。あまりに壮大なビジョンを持ち、詳細がちょっとばかり欠けているのだ。私に言える限りでは、Chandlerの元々のビジョンは「革新的なもの」というだけだったのではないかと思う。あなたはどうかしらないが、少なくとも私は「革新的」だけじゃコードを書けない。もっと具体的なことが必要だ。仕様書が製品を形容詞ばかりで記述(「これはすごくクールなものになる」)していて、具体性(「磨き上げられたアルミのようなタイトルバーを持ち、アイコンはすべて光沢感があって、グランドピアノの上に置いたかのよう」)を欠いているなら、トラブルに見舞われる。
ローゼンバーグの本から読み取れるChandlerの具体的なデザインのアイデアは、「ピアツーピア」「サイロだらけにしない」「自然言語の日付を解釈する」ということだけだ。この本に書かれていないというだけなのかもしれないが、製品の初期のデザインがごく曖昧なものだったのに違いない。
「ピアツーピア」はChandlerのそもそもの存在意義だった･･･どうしてスケジュールを調整するだけのためにMicrosoft Exchange Serverを買わなきゃいけないんだ? 結局どうなったかというと、ピアツーピアによる同期化が非常に難しかったか何かのため、この機能はカットされた。今ではCosmoと呼ばれるサーバーを使うようになっている。
「サイロだらけにしない」というのが意味するのは、メールはあるサイロに、カレンダーは別なサイロに、リマインダーはさらにまた別なサイロに、という具合になっているのでなく、すべてを保持する統合された１つのサイロがあるということだ。
「サイロだらけにしない」ことについて疑問をあげ始めるとすぐ、それがうまく機能しそうにないことに気付くだろう。メールをカレンダーに置くの? カレンダーのどこに? 受け取った日? それで金曜日のマスにはバイアグラの広告が200通入っていて、非常に重要な株主とのミーティングを隠してしまうことになる。
結局「サイロだらけにしない」というのは「切手」というアイデアに組み込まれることになった。ドキュメントやメモやカレンダーの項目にはemail切手を貼ることができ、それを誰にでもメールできるようになる。それってどう思う? この機能はMicrosoft Officeが90年代にすでにやったことだ。そしてOffice 2007になってようやく取り除かれることになった。誰も使いやしないからだ。何かを人にメールする簡単な方法なら十分たくさんある。
実際、「サイロだらけにしない」というアイデアは、アーキテクチャ宇宙飛行士たちに最もアピールするだろうと思う。彼らはサブクラスと抽象ベースクラスを見出し、アーキテクチャ的美観以外には大した理由もなく機能をサブクラスからベースクラスに移して喜んでいる。これは通常ユーザインタフェースをデザインする方法としてはひどいものになる。ユーザにプログラムモデルを理解させることができるのはメタファーだ。現実のものと見た目や、感じや、とくに振る舞い方が合っているとき、ユーザはプログラムをもっともよく理解し、それによってアプリケーションは使いやすいものとなる。現実において極端に違った2つのもの(メールと予定)を組み合わせて同じユーザインタフェースに押し込めるなら、もはや現実世界のメタファーは機能しなくなり、ユーザビリティが損なわれるのだ。
ケーパーが聞いてくれる人に誰彼なく話しているその他のクールなところとしては、予定表に「次の火曜」と打ち込むと、魔法のように予定が次の火曜に設定されるというのがある。これはまあ気が利いていると思うが、そこそこまともなカレンダープログラムであれば、みんな90年代に実現している。革新的ではない。
Chandlerチームはまた、ボランティアの協力を過大評価していた。オープンソースというのはそんな風に機能するものではない。モノマネ機能の実装には非常に向いているが、それは仕様がすでにあるからだ。コピーしようとする実装がそうだ。「かゆみを取る機能」にもすごくいい。プログラムの入力に使うEBCDICのコマンドライン引数がほしいというような。しかしそのアプリケーションがまだ何もしていないなら、かゆみを感じる人もいない。誰もそれを使っていないからだ。そのためボランティアも集まらない。Chandler開発チームのほとんどすべてが雇われた開発者だろうと思う。
ローゼンバーグが何か見誤っていたり、本当は前進しているのに間違った印象を与えているなら、そして私の(デザインの失敗によるこういった惨事を批難しがちな)悪い癖が出ているなら、そのことをChandlerチームに謝らなければならない。
その上で、このプロジェクトは確かに１ついいものを生み出している。収束することに失敗したソフトウェア開発プロジェクトについて、「超マシン誕生：コンピュータ野郎たちの540日」や「闘うプログラマー」のスタイルで書かれたすばらしい本だ。この本を強くお勧めする。
(オリジナル: The Big Picture)
