Rogue Engineer's Diary / やさぐれ日記

■ [やさぐれ読書録] "Competing on Internet Time"読了

6月12日から読んでいた"Competing on Internet Time: Lessons From Netscape and Its Battle with Microsoft"(Michael A. Cusumano and David B. Yoffie)を読了。日本語版は「食うか食われるか ネットスケープvs.マイクロソフト」（すごいタイトル、というか、いくらなんでもコレはあんまりだと思うよ…）以下、まとめ。

■ Netscape

これは「クスマノ・シリーズ」（と僕が勝手に呼ぶ）4冊セットの2冊目に当たる本。「クスマノ・シリーズ」の本来の目的はMicrosoftの開発の様子と僕らの開発の姿を比較していく、という点にあるのだが、この本の主役はNetscapeなのでまずはそこから話を始める。まず印象深かったのが、Netscapeの関係者がCMMI的な考え方を真っ向から否定する姿。CMMIの段階表現モデルにおいてはソフトウェア開発組織の成熟度を、最低レベルの1から最高レベルの5までに分類し、ソフトウェア開発を「特定の個人の力量に依存しない」、「予測可能な」プロセスにすることを実現するための道筋を示している。

成熟度レベル1では、通常、プロセスは場当たり的で無秩序である。（中略）成熟度レベル1の組織での成功は、（中略）組織に属する人員の力量や英雄的行為に依存している。
（能力成熟度モデル統合(CMMI), 1.1 版、段階表現 p.11）

（CMMIの）成熟度レベル4では、プロセスの実績は、統計的技法およびその他の定量的技法を使用して制御され、定量的に予測可能である。
（能力成熟度モデル統合(CMMI), 1.1 版、段階表現 p.13）

Netscape関係者の発言を拾い上げてみると、上記のような考え方の正反対を主張している様子が浮かび上がる。まずは1995年にBorlandからNetscapeに移った、シニアデベロッパのLloyd Tabbの言葉：

「本当に素晴らしいソフトウェアはヒーローたちの手から生まれる」
（"Competing on Internet Time" p.235、やさぐれ訳）

そしてNetscape社、クライアントプロダクトのリリースマネージャであったMichael Toy（ちなみにこのヒト、何とRogueの作者でもあったらしい）の言葉：

「コントロールは悪だ。過剰なコントロールからは、予測可能な結果しか得られない。わずかにコントロール不能な状態にしてやるほうがはるかに良い。こうすれば予測不能な大成功を手に入れることが出来る」
（"Competing on Internet Time" p.222、やさぐれ訳）

「予測不可能な大成功を手に入れる」とは魅力的なフレーズだし、ここまではっきりと言い切ってくれるとなかなか痛快だ。ところが、Netscapeの中心的開発者の一人、Jamie Zawinskiの言葉をこれらに重ね合わせてみると、その印象は少々変化する：

ぼくたちは、新しいコミュニケーションのメディアの先鞭を切ったのだ。ぼくたちは世界を変えた。
でも、それをやったのは 1994〜1995 年のことだった。1996 年から1999年にやったことは、以前にやったことから生じた波に乗り、惰性で進んできただけだ。
なぜか？　会社がイノベーションを止めてしまったからだ。
（Jamie Zawinski 「辞職そして追悼。」）

さすがのNetscapeも「予測不能な大成功」を何度も繰り返すことは出来なかった、というのが現実のようだ。イノベーションというのは、つくづく厄介な代物であると改めて思う。

■ Microsoft

続いてMicrosoft。彼らの開発の姿を追うという、「クスマノ・シリーズ」本来の目的に沿って、関係者の言葉を拾う。まずAlex Edelsteinの言葉：

「マイクロソフトでは、ちゃんとしたドキュメント無しには、APIをデベロッパやパートナーに公開しないというのが常識だった。ドキュメントはドラフト版であることもあったが、すくなくとも存在はしていた」
（"Competing on Internet Time" p.82、やさぐれ訳）

4月のRHG読書会で行われたartonさんの講演「COM―古きを訪ねて新しきを知る」の中では、『"The Component Object Model Specification"というドキュメントが、Microsoftが出しているCOMの仕様書だ。でもDraft Versionの0.9が公開されたっきりで、その後正式版が出た、という話は聞かないけどね』という話があった。上の「ドキュメントはドラフト版であることもあったが、すくなくとも存在はしていた」っていう話と確かに一致する。ちなみに"The Component Object Model Specification"は現在は（辛うじて？）ここで参照できるようだ。

次はMicrosoftでのコードレビューの話。

Slivkaによれば、IE 1.0, 2.0,そして3.0にかけて、Microsoftの開発者たちは全てのチェックインに対してコードレビューを行い、（自分のコードが直ちに他の人の目に触れることから）良いコードを書くように動機付けるとともに、コードベースやコーディングスタイルといった一般的テクニックに関する知識を広めることに努めていた。
（"Competing on Internet Time"p.244、やさぐれ訳）

コードレビューをやっていたとは、ちょっと意外。「その割にはあの当時のIEの出来はどうにもイマイチだったな」と思ったのだが、しばらく経った後に、通常はコードだけではなく仕様書もレビューの対象にするはずだが、そこがどうなっているかが本書には書かれていない、ということに気が付いた。実情はどうなのか、次に読む予定の"Microsoft Secrets"に手がかりがあることを期待しておく。

■ そしてコンポーネントモデル

最後に、この本のもう一つ大きなトピックである、コンポーネント化に関する議論についても書いておく。

1990年代初めから中ごろにかけ、MicrosoftはComponent Object Model(COM)を設計し、それに合わせ、Word、Excel、PowerPoint、およびWindowsとWindows NTのアーキテクチャとコードベースを再設計するという作業にかなりの時間を費やしていた。この再設計はコンポーネントの共有を目的としたものである。例えば、Wordのプロダクトユニットはテキスト処理モジュールや印刷モジュールをビルドするが、これはWordだけでなくExcelや他のOffice製品、さらにはテキスト処理やプリントを行うほかのいくつものアプリケーションでも使われることとなる。
（"Competing on Internet Time"p.201、やさぐれ訳）

コンポーネント化を実現する方法にはいくつかあるが、一つ有力なアプローチとしては、成功したアプリケーションを解体し、組み合わせ可能な部品の集まりとして再構築するという方法がある。IE3.0のコンポーネント化に携わったBen Slivcaの言葉から：

「我々にはCOM、すなわちコンポーネント・オブジェクト・モデルを理解する人間がおり、ソフトウェアのコンポーネント化を正しく行った場合、それがどのような価値を生み出すかについても理解しているという強みがあったが…それでも我々は95年の秋にコンポーネント化を進めるかについて、厳しい判断を迫られていた。これは「行くか、戻るか」迷っていた時期とも言える。別の言い方をすれば、『我々はこの子（ソフトウェア）をバラバラに解体すべきか、それともそのままにしておくべきか?』という悩みであった」
（"Competing on Internet Time" p.184、やさぐれ訳）

90年代中盤はあちこちでコンポーネント化が熱心に進められた時期とも言える。NetscapeはCommunicator Version 6でブラウザのコンポーネント化を目論んでいたし、ジャストシステムも1995年に「一太郎7」で、「JUSTSYSTEM Open Component Architecture JOCA）」という名前のコンポーネント技術を立ち上げようとしていた。だがコンポーネント化というのは半端で無いほどの開発資源の投資を伴う割に、かなり後にならないとその効果が目に見えないという点で、非常に大きなリスクを伴う、一種のギャンブルであるとも言える…と書き始めたところで、このまま進むと収拾がつかなくなるほど奥の深いトピックであることに気が付く。コンポーネント技術については別の機会に書くことにしよう。