闘うプログラマー ― 2009/08/14 01:16
闘うプログラマー[新装版] ビル・ゲイツの野望を担った男達 (単行本（ソフトカバー）)
G・パスカル・ザカリー (著), 山岡 洋一 (翻訳)
Windows 7のリリースにあわせてなのか、再版されていた。おもしろいセンテンスだけ抜き出した読書メモ。
1990年1月の時点ではNTはモノにならないだろうと考えられていたらしい。
マリッツは、NTについて、「技術革新の練習であって製品ではなく、しかも「ろくにコーディネートされていない練習だ」と判断した。ウィトマーのグラフィック・チーム、ルビンのネットワーク・チーム、NTチームがすべてカトラーの指揮下で一つのチームになれば、状況は良くなるだろうと考えた。そうしないかぎり、NTは商品にならないだろう。
開発の初期の段階で、グラフィック・チームのひとりである、ムーアは精神的に病み、仕事ができなくなってしまった。
「どうせチャック（ウィトマー）が変えてしまうのに、決める必要がどこにあるんだ。何を考えようと関係無い。これはチャックの製品だ。すべてはあいつが決める。オレは奴隷のように、それを実現すればいいだけだ」
ムーアは、「破滅的な悪循環」に陥っているとも思っていた。この７年間、マイクロソフトで１日１２時間も過ごしてきた。友人はしだいに遠ざかり、真綿で首を絞めるようにじわじわと孤独感が襲ってきた。こんなことになるとは思わなかった。「懸命に働いていて、知り合いはいないし、何人かの友人は、みな忙しい。それなら、もうすこし働こうと考える。働き続けて、知り合いがもっと減っていき、やりたいことも減っていく。しばらくすると、仕事以外なにも残らなくなる」。そうなると、仕事まで中身のないつまらないものに思えてくる。必死に逃げようとしても、追われているような気がしてくる。
プログラム管理者：ユーザーがよろこんだり、満足するような機能や改良を提案するのが仕事。
マイクロソフトのプログラム管理者は、コードを書かないが、製品の仕様を決める作業を支援する。その影響力は大きく、プログラミング責任者以上の力を持つこともある。しかし、意見を通すには、相手を説得するしかない。プログラマーに直接、自分のアイデアを実現するように命じる権限はない。しかし、プログラマーに拒否された場合、希望するコードを外注する権限を持っている。
カトラーのプログラム管理者へ対する評価
自分やチームに口出ししようとするプログラム管理者は、みんなくそくらえだ。
・・・
「わたしはいつも闘っている。連中がもっとまともなら、いつもこれほどピリピリせずに済むだろう。わたしのような人間は、めったにいない。正しいことなら、何だって取り入れる。昼も夜も懸命に働く。しかし、難しい仕事をやると決めた後で、とやかく口を出すな」
マリッツが1990年の春から夏にかけて、ゲイツとバルマーを説得してOS/2から開発リソースをNTに移すように進言。
NTは「本当に真剣に取り組まなければ」完成しない。ところが、マイクロソフトには「NTを製品として仕上げるために必要な資源さえない」。OS/2に時間と資金をつぎ込みすぎているからだ。
マリッツは２人に、このままでは自分はOS/2の責任者として失敗するのは間違いないと言った。「戦略を変えなければ、自分の人生を無駄にしていると感じる。勝てる見込みのない戦略をとっているのに、緊張やストレスに耐えようとする者がいるだろうか」
マイクロソフトのスタイル
「コードにあれこれ注文は出さない。注文はたった一つ、動くものを作ってくれということだけだ」とルコフスキーに言った。
カトラーの指示は、プログラマーに自由にやらせるというマイクロソフトの伝統にのっとっている。「社員のほとんどは、やる気をおこさせないといけないタイプではなく、やる気がありすぎて抑えるのに苦労するタイプだ」とあるベテランは語る。
マイクロソフトでは管理者もコードを書くのが原則だ。ゲイツは、まともなコードが書けるプログラマーだけが管理者になるべきで、管理者になってからもコードを書き続けるべきだと考えている。これはソフトウェア会社が陥りやすい問題を見事に解決する方法だ。ソフトウェア会社では、管理者はプログラマーのいいなりになりやすい。スケジュールは守られず、製品は失敗に終わり、予算は膨れあがる。すべては、現代の魔術師がしていることを、トップの人間が理解できないからだ。最初は成功したソフトウェア会社が、コードを知らない管理者の失敗で急激に転落した例はいくつもある。
マイクロソフトは、十分な研修をしないことで有名だ。「泳げないヤツは沈めばいい」というのが、新人のルールだった。
自分で作ったドッグフードを食え、とは？
カトラーは、半分は男らしさを見せるために、半分は常識的は判断から、「ドッグフード」を食べることを重視していた。つまり、「自分で作ったプログラムを使う」べきなのだ。ドッグフードを食べていれば、NTの欠陥や不十分さから目を背けることができなくなる。
・・・
当初は、ドッグフード程度の味しかしないのであれば、ますますこれを食べるべきだ。プログラマーは、早急に品質を上げなければならないと実感し、すぐにコードのエラーを修正し、もっと信頼性の高いコードを書くようになるだろう。
MSのマニュアル整備に対する姿勢
マニュアルは冗談のタネにされることが多いが、聖書を読むように熱心に読めば、いくつもの秘密があきらかになる。マニュアルが良ければ、ソフトをもっと使いこなせるようになる。マニュアルのほとんどは悲惨なもので、良いものをつくれば目立つことになる。ユーザーは普通、マニュアルの出来にはほとんど関心を持たない。ソフトを使いこなそうとするときにも、マニュアルは避けている。しかし、プログラミングの専門家は、すみからすみまで、必死になって読む。オペレーティング・システムではとくにそうだ。
チームでのソフトウェア開発
理想のソフト開発チームは、人数がひとりのチームだと、カトラーが皮肉ったことがある。
クリフ・バン・ダイク（セキュリティ機能担当のプログラマー）
プログラミングの能力には限度があり、休みをとって充電しなければ、能力がすぐにつきてしまうと考えている。
不思議なもので、「勤務時間を長くすると、正しい答えを見つけ出すまでにかかる時間も多くなる」。
「マイクロソフトでは、注意していないと、いくらでも自分の時間を食われてしまう」。だから、自分を守るために、「オフィスからはなれるべきだ。１日の仕事が終わったら、家に帰るべきだ」と言う。
理想やスタイルは想像力の源泉である
プログラマーはコードの設計にあたって、論理や数学に頼っているので、技術的な判断では個性は重要ではないと考えている。しかし、過去に偉大な発見や工夫がいくつもあるのだから、どう判断すべきかは決まっていると考えるのは幻想にすぎない。ほぼおなじ目的を達成するための方法は、技術的にみていくつもある。
NT開発がマラソンといえるほどになって、緊張をほぐす遊びと、単なる時間の区別をする必要がでてきた。
ある日、カトラーはNTチーム全員が共有している電子掲示板、NTDevで、関係代名詞の正しい使い方について、熱心な議論が戦わされていることに気がついた。
・・・
この時期に熱心に議論するような問題なのか。文法についての議論はやめろ、とカトラーは命令した。「これをNTDevから削除しろ。今度おなじものがあったら、てめえらのオフィスの壁をぶちやぶって話をつけにいく」。
レジストリーはセキュリティについでの大論争の結果、つくられたものだ。セキュリティ機能の一部として、ネットワークに接続している個々のパソコンをユーザーにあわせて、簡単にカスタマイズできるようにすることが、最大の目的だ。
1992年12月16日のビル・ゲイツによる出荷の可否を判断するためのレビュー
ゲイツは会議に出るにあたって、腹を決めていた。「こいつを出荷する」つもりだった。
・・・
コンピューターの新しい時代を切り開くためには、妥協すべき点は妥協するつもりだった。たとえば、8MBのメモリーのパソコンでNTを使えるようにするという希望はもうあきらめていた。NTがまともに動作するには、最低１６メガバイトのメモリーが必要になりそうな形勢だ。
・・・
しかし、パフォーマンスではそうはいかない。この点では妥協できない。ここで妥協すれば、ユーザーに見向きもされなくなるだけだ。
・・・
ゲイツにも頭が上がらない相手がいるとすれば、その名はスピードだ。ウィンドウズのアプリケーション・ソフトがNTでそこそこ速く動かないのであれば、ユーザーはNTのすばらしい機能を無視して、おなじウィンドウズのソフトをDOSで使い続けるだろう。ひょっとすれば、最大のライバル、IBMが売っているOS/2を選ぶかもしれない。人気の高いソフトはどれもOS/2には対応していないが、IBMは死んだも同然のこのプラットフォームを生き返らせるうまい方法を考えついている。今後のバージョンでは、ウィンドウズのソフトが、DOSと変わらぬスピードで（ひょっとしたら、DOSより速いスピードで）うごくようにする計画なのだ。
結局この会議ではパフォーマンス上の疑問から、会議は大荒れし、ビルgの決定は保留され、６週間後にもう一度会議を設定
1993年2月1日のゲイツとNTチームの会議で、マリッツはNTが「ようやく最終コーナーをまわった」と感じた。ウィンドウズのアプリケーションを実行したときの速度は、まだDOSより遅かったが、違いは小さくなり、ゲイツも満足した。
バグをとれ、ということ。
どういう欠陥があって、周囲の人たちを傷つけることがあるにしろ、普通の生活のなかで仕事への集中を妨げるものを片っ端から封じこめられるからこそ、すばらしい仕事ができる。普通の人たちに偉大な仕事ができないのは、めったにない仕事に取り組んでいるときですら、日常の習慣にとらわれているからである。月並みな仕事しかできないのは、才能がないからではない。意志に問題があるからだ。カトラーはそう考えている。この段階にきて、カトラーはチームの全員がたったひとつのことに注意を集中するようもとめていた。たったひとつのこと、それはバグである。
どのバグを処理するのか？
最悪のバグは「ショーストッパー」と呼ばれるようになった。ショーを止めるようなバグ、つまり、リリースを遅らせるしかなくなるバグである。次に重要なバグは、「プライオリティ１」と呼ばれた。NTのサンプル版にはファースト・クラスのバグが数百あった。もっと軽度のバグは「プライオリティ２」であり、数千にものぼることがあった。
しかし、どのバグがどこまで重要なのかが、いつもはっきりしているはけではない。もちろんNTがクラッシュするようなバグは取り除かなければならない。しかし、ショーストッパーとファースト・クラスのバグのほとんどは、ここまで悪質なものではなかった。
・・・
マーク・ルコフスキーがずばり真実をつく才能を活かして、こう語っている。「処理しているものは、問題なのだろうか。予定を遅らせているものは、問題なのだろうか。必死になっているものは、本当に問題なのだろうか」
なにが悲惨な結果をもたらすのかは、だれにもわからない。だから、プログラマーは、ひとつの失敗で、すぐにではなくても、いつか、取り返しのつかない事態になりうると考えて、仕事に取り組まなければならない。ここまで厳しい態度を取っておくべきなのだ。バグとの戦いは凄惨だ。パフォーマンスの改善なら、遠くからの急所攻撃で一気にカタがつく。しかし、バグ取りはそうはいかない。言ってみれば、血まみれの接近戦に似ている。
欠陥があることは避けられない
NTのコードは５６０万行にもおよび、３５００ページの大辞典よりもテキスト量が多いのだ。これだけのソフトが完璧になることはない。十分に良くなることがあるだけだ。
ダリル・ヘブンズは、チーム発足当時からのメンバーだが、フィアンセと別れることになったのはプロジェクトのためだと考えている。
しかし、苦痛に満ちた今回の経験で、自分の仕事量をもっと抑える必要があると痛感する必要になった。NTの完成に向けて無理を重ねた結果、チームの多くのメンバーが、疑問も持たずに長時間勤務をうけいれる純真さを失ったとヘブンズは見ている。
リーダシップがしっかりしていることは重要だが、それだけでプロジェクトが進むわけではない。チームワークが効率的なことも大切だ。
しかし、チームワークといっても、普通に考えられるようなものではない。普通、チームワークといえば、個々人のばらばらな言動を抑えることを意味する。こうしたチームはフットボール・チームや軍隊には適しているだろうが、想像力がもとめられる世界では、個々人は強烈な個性を持っている。通常のチームワークでは、グループの目標に向けて、全員が協力し、順応し、妥協することが不可欠であり、創造的な仕事とは真っ向から対立する。
・・・
実際、技術チームと文字を持たない種族とには、よく似た点が多い。今日では、技術の進歩はきわめて早く、印刷された情報はおどろくほどの短い時間に時代遅れになる。技術分野はきわめて細かくわかれているし、たえず変化しているため、技術の核心については、マニュアルもなければ、教科書もない。技術者は担当する分野に習熟し、知識を吸収するために、チームメイトに頼るしかない。
・・・
技術チームの多くは、チーム内の対立を奨励していても、官僚制度を生み出していく。決定を間違えるのを恐れて、重要な問題を検討する委員会をつくる。委員会には小委員会がつくられ、すぐに、単純明快な提案でも、実際の仕事にはたずさわっていない人たちが延々と検討を重ねるようになる。NTチームはこのワナには陥らなかった。
・・・
技術面での重要な決定のほとんどは、形式ばらない方法で下され、プログラマーが担当する部分について決定権を持つのが通常であった。チーム以外による検討は、ごくまれにあったにすぎない。
