「ソフトウェア企業の競争戦略」読書感想文5
マイクロソフトの開発スタイルの話。カネに飽かせて優秀なプログラマがわんさと集めているマイクロソフト。放っておいても凄いものができるんじゃないの? という人は、少なくともこの記事なんて読まない。良いプログラムは良いプログラマでしか書けないが、良いプログラマさえ集めれば良いプログラムになるとは限らないことを知っているから。ここでの「良い」は各人の好きな内容でどうぞ。
筆者は Windows95/NT/2000 および MS-Office シリーズの開発スタイルを分析し、一つのベスト・プラクティスを導き出している。筆者は「同期安定化プロセス」と名づけている。第4章「開発のベスト・プラクティス」でその詳細な説明があるので、開発手法やマネジメント手法にお悩みの方は読むと得るものがあるかも。
そこで問題。Windows開発プロジェクトチームのうち、最も強い「権力」を持っていたのはどれか?
1.プログラマ
2.テスタ
3.ビルダ
答はマウス反転表示→「3.ビルダ」。「ええっ」と思った方もいるかもしれない(それは私)。モノ作りのメインであるプログラマこそが最も力が強いはずじゃないのか?
プログラマは、同時並行してテストを行うテスタの「相棒」と一対一の組になって開発する。そうした組が3-8人程度で一つのチームを編成し、個々の機能(ユーザが確認できる機能)を作る。それらのチームが、一つの大きな組織のように協同作業する必要が出てくるわけだ。Windows2000 の場合は15-20チームで並行作業していたという。
仕様や設計上の変動要素もある。秒針分歩の技術・ニーズをいつ実装するかという課題もある。そのためWindows の開発では詳細な仕様書を書かなかった。書いてもどうせ変更されるんだ。プログラムの変更に合わせて仕様書との一貫性を保つための作業は、捨てるかもしれない機能のための仕様書を書く作業と同様、リソースを割り当てられることはなかった。
複雑で大規模なプロジェクトを、多くの人員を投入し、同時並行で進める。しかも変更が大いに発生することは予め分かっている。マイクロソフトは同時並行して作業を進めながら、たえず同期を取るプロセスを適用することで、この問題に対処した。そのキモは、
1.完全な製品のビルドを、毎日、決まった時間に実施する
2.ビルドの度にテストを繰り返し実施しデバッグを行う
3.ビルドとデバッグの時間厳守
マイクロソフトの場合は夕方5時がチェックインタイム。この時間までにソースをアップしておくことが絶対条件で、逆にいえば、それさえ守っていれば何をしててもOK。遊んでいようが、夜中だけ働いていようが、部屋から一歩も出てこなくても、何の文句もいわれない。元イスラエル軍戦車部隊の指揮官で、Windows95の品質管理責任者を担当したデーブ・マリッツのコメントを引用する。
プロジェクト・ビルド・マスターはマスター版ソースを用いて毎日「製品」をビルドし、テストする。ビルドもテストもスクリプトによる自動化が図られているため、時間的にはたいしたことはない。ただし、ビルドやテストが通らなかった場合、プログラマは「居残り」となる。イノベーションは任されているし、自由度もある。しかし好き放題にプログラミングしても「製品」は絶対に出来ない。ともすればバラバラになりがちのプロジェクトをデイリービルドで「同期」を取り、その度にテストを実施することで「安定化」を図る。これがマイクロソフトのやりかた[注1]。
マイクロソフトが作っているのは「製品」だ。デイリービルドでは部品ではなく、「製品」を作る。では「製品」とは何か。製品とはビルドとテストが通った機能群のことを指す。どんなに優れたライブラリやクラスでもビルドとテストが通っていないのであれば、それは製品とは呼ばない。それは「在庫」だ。在庫はいくら良質でも、大量にあっても、動かない(動かせない)プログラムだ。酷い言い方をしていいなら、ゴミだ。
「ファクトリー」と銘うたれた日本のソフトウェア企業はこの意識が低い。「製造業」のくせに在庫を「在庫」と思っていない。「製造業」の最たるトヨタを例に挙げる。ジャスト・イン・タイム方式と世間にもてはやされているが、あれは「在庫を道路上に放置プレイ」なんだろ。トヨタに限らず、製造業が蛇蠍のごとく嫌っているのは在庫だ。なぜなら、いかなる在庫であれ、それを保管しておく場所代、管理費(人件費)を要する。そのくせバランスシートでは「資産」として扱われる。一円にもなっていないのに!系列子会社に対し、原材料を工場へ持ち込む時間を細かく指定することで、在庫ゼロを目指しているのだから。トヨタ系列の工場を早朝に訪れてみるとよく分かる。子会社からの原材料を積んだトラックの列が長蛇を成している。それほど「在庫」は悪なのだ。
しかし、ソフトウェアの場合の「在庫」はほとんど意識されない。なにしろ場所代をとらない。コンパイルしてなければ数キロで済むテキストファイルだから。もちろん管理費も取らない。プログラムを書いたらどっかのフォルダに放り込んでおけば一丁あがり。でもやっていることは在庫を量産しているだけなんだ、そいつがビルドとテストを通らない限り。
本書では一言も言ってないが、「製品」を毎日作る同期安定化プロセスは、「在庫」を極力なくそうとするジャスト・イン・タイムにだぶって見える。
また、同期安定化プロセスの説明により、マイクロソフト独自の「それは仕様です」の理由がわかる。仕様書なんて書いていないので、仕様なんてはじめから存在しないのだ。ある操作をすると必ず青画面になったりするのは、開発者が想定していなかった動作であり、そいつは「再現可能な不具合」や「認識された誤動作」と名づけられる。別名「それは仕様です」だ。その「仕様」に対しリソースが割り当てられリリース予定日が決まった時点で初めて「バグ」として認められるのだ、めでたしめでたし…ってザケンナー!
日本(やIBM)を代表とするソフトウェア・ファクトリーでは非常に詳細な仕様書を書く、と筆者は指摘する。それが柔軟な変更や素早い開発(あじゃいる?)を妨げていると断ずる。しかし、できあがったモノに対し「それはおかしい」という指摘の根拠があるわけだ。つまり仕様書にあるから仕様なのであり、無いから仕様ではない、という非常にあたりまえな話ができる。
もちろん「黒は色である」という仕様に対し「白も色である、従って、黒は白である」と展開する顧客もいる。狂っているとしか思えないが「色は黒とする」という仕様は存在する。そして通常、そうした仕様は契約条項として残る。仕様書に書いていないことを要求する理不尽な顧客に対しては「仕様書に無い機能については…」といった免責事項も可能だ。
いずれにせよ、契約による仕事を行う場合の根拠となるのが仕様書だ。これなしでビジネスをするのであれば、契約する相手もいない全く新しいモノに対し仕事をするか、あるいは顧客なんて相手にしない殿様商売の場合に限られる。ま、筆者に言わせるとこのような考え方そのものが「ファクトリー」的な発想なんだろう。はい、分かってます、私は大富豪にはなれませんな(w
(つづく)
--
[注1] このへんの打打発矢は「闘うプログラマー」が面白い。Windows-NTの開発秘話。OSの開発が非常にスリリングに物語られている。ネタとしてはよいが、プロジェクトとしては問題アリだろう。

| 固定リンク
コメント