マイクロソフト シークレット （下）

マイケル・A・クスマノ/ルチャード・W・セルビー

山岡洋一 訳

日本経済新聞社(1995)
★★★★★

下巻からの抜粋です。

製品の開発と出荷のための５つの戦略
(1) いくつかのチームに分かれ､同時並行して仕事を進める。ただし、毎日｢同期｣をとり、デバッグを行う。
(2) 主要なプラットフォーム、主要な市場の全てに対応した各バージョンの製品を、理論的には常に出荷できる状態で用意しておく。
(3) 開発は一つの場所で行い､共通の言語を使用する。
(4) ビルド（ファイル化）のたびに、絶えず繰り返しテストを行う。
(5) 中間目標の達成､製品の出荷といった重要な決定を下す際に､数量データを利用する。

毎日のビルド―――チームの調整を保つ厳しいルール
毎日のビルドによって､プロジェクトがどのように進んでいるかを迅速に､チームにフィードバックできる。ウインドウズＮＴのソフト工学責任者、ロウ・ペラゾーリは、毎日のビルドを「苦労を伴うが実りも多いもの」と、とらえている。「毎日のビルドほどつらいものはない。しかし、これほど偉大なものもない。このため、すぐにフィードバックができるのだから。」。マイクロソフトには規則らしい規則はごくわずかしかないが、頻繁にビルドを行う規則は厳密に守っているプロジェクトが多い。

進捗状況を把握する

「仕様書作成、コーディング、テスト、保守」という局面を順次進めていく古い考え方では、完成までどれぐらいの段階にあるのかの判断が非常に難しくなる。プロジェクトの期間の80パーセントが、進捗度を80パーセントから100パーセントに引き上げるのにつかわれるケースが多いそこで、これとは違う中間目標プロセスを開発した。達成が少々難しい作業をいくつか選んで、それを中間目標までに100パーセント完成させる。この段階で、プロジェクトの進捗状況を見直す。…中間目標には、その段階で開発した機能だけで製品を出荷すると想定した場合、…製品として出荷するのに必要なこと全てをやる。…このプロセスを使っていれば、製品を完成させてから、出荷するまでの期間は極めて短くなる。…これで、すれジュールがはるかに立て易くなる。問題が起こった時は、プロセスの早い段階にわかる。…進捗状況をしっかりつかめる。

コードの半減期は短い

開発チームは常にソフトを書き直しており、一つのコードにこだわりすぎることはない。デーブ・ムーアによると、マイクロソフトでは、ソフトのコードの「半減期」は18ヶ月ほどだ。つまり、わづか18ヶ月ほどで、コードの半分が変更されたり、他と置き換えられたりしている。…クリス・ピーターズによると、再利用できるようにコードを書くことには余り重点を置いていない。コードがすぐに時代遅れになることがその理由だ。「再利用できるコードにするために時間を使っても、2年もすれば古くなっている。変化がそこまで早く、めまぐるしい世界で、どんなコードを再利用しようというのだ」

機能を変更するのは、2倍よくなる時

「ＯＳ／２は、何もかも変更しようとした。…１０パーセントの改良のために、コードを完全に書き換えたが、１０パーセントの改良ではユーザーは喜ばない。今では、製品の整合性を大切にする場合、２倍は改良されていなければ、違いは出てこないというのが、経験則になっている」クリス・ピーターズ

２０パーセントの税金としてのコードの書き直し

製品を出荷できる状態にしておくことの別の面として、次のバージョンの発売までの間に、コードの書き直しに投資している（他の祖父と開発会社で行われている「保守」、「リエンジニアリング」の作業に似ているが、マイクロソフトで箱の作業のために独立したグループは作っていない）。開発責任者は、開発時間の２０パーセントを製品の弱い部分を作り直すために当てるようにするべきだとされている。バージョン後とに確実にこれを実行していけば、製品の質は確実によくなっていく。

ビルドのたびに、絶えず繰り返してテストを行う

マイクロソフトのテストの方針を決める原則はいくつかあるが､いずれも､チームが開発と並行して絶えずテストを進められるようにするものだ。このように､開発と同時並行で絶えずテストを行う考え方は､マイクロソフト独自のものだ。ソフト会社の殆どは､開発サイクルの最後に集中してテストを行っているが､この時期にバグを処理するのは極めて難しく､時間がかかる。また､同社は製品のテストに当たって､幅広い視点を取るようになっている。
　　例えば､自動テスト・ツールを作成し､開発者はこれを使って､各自のコードを毎日テストできるほか､マスター・ソース・コードへの変更をチェックインする前には､必ずテストしなければならない。このテスト・ツールは､各製品のマクロ言語を使うか､キー入力を再現して自動的にテストをする。開発者は､バグを検出したり､特殊な条件をチェックするための特別なルーチンを入れた｢デバッグ版｣を作成し、更にコードをレビューして､コードを読むことによってエラーを探し出す。ユーザビリティ・テストでは､一般の消費者に依頼し､専用ラボで機能の使いやすさを評価する。また開発者とテスト担当者が一人づつ組むようにする（同社では､開発者一人に対して､ほぼ一人の割合でテスト担当者がいる）。テスト担当者は､まず仕様書を読み､早い段階でテスト・ケースとテスト戦略を準備する。…
　　テスト担当者が使う方法はいくつかある。一つは､体系化されたテスト・スクリプトを使う方法だ（「シナリオに基づくテスト」と呼ぶ）。スクリプトに従わず､製品を｢壊す｣ために考えられる限りの操作を試す｢ゴリラ・テスト｣もある。また､様々な人が参加してバグを探す｢バグ・パーティ｣を開く。更に､開発中の製品を自分たちで使い､初期バージョンを社内に配布し､数千本のベータ版を主なユーザに送る。これらは全て､製品を発売する前にバグを発見するためだ。

開発者中の製品の品質や効率を高めるために、開発者がデバッグコードを使う例は多い。小さな製品でも､合計で一万行のデバッグ・コードを組み込む場合がある。中でも重要なのは､メモリーとデータ構造のチェック､アサーション､検査版だ。

メモリーとデータ構造のチェック

「メモリーもチェック」ではプログラムが使用するか割り当てるメモリーを全て計算する。例えば､メモリーの自動検査でエラーが発生すると｢MIF｣(メモリーの完全性のエラー)というメッセージが表示される。これに煮た｢データ構造のチェック｣では､特別なルーチンを使って､製品のほぼあらゆるデータ構造の一貫性を確認する。これによって､プログラムがデータを正しく保存し､取り出しているかどうかを確認できる。

アサーション

きわめて一般的なデバッグ・コードに､｢アサーション｣がある。これは､ユーザーが入力するデータに関係なく､必ず結果が真になるはずの「if〜then」文を実行するテストだ。…「アサーションが極めて重要なのは､…コードを書く時に､グローバル状態を理解していなかったり､グローバル状態に関して何らかの想定があることが､バグのおおきな原因の一つになっているためだ。…グローバル状態について何かを想定する場合には､コードにアサーションを組み込む習慣をつけるようにしている。…アサーションを十分に使えば､バグをすぐに見つけられるようになる。」

ベータテスト

　　ウインドウズ3.1のデータは､ベータ・テストがいかに効果的であるかを示している。最終ベータによって､発売前に発見された全てのバグのうち､22パーセントが見つかっている。

数量データに基づく機能と製品の完成のチェックリスト

マイクロソフトのプロジェクトでは､数量データに基づくチェックリストを作成し､機能と製品が完成したかどうかを決定するために使っている。

エクセル5.0の数量的データに基づき出荷準備の完了を判断するチェックリスト
Ａ．テストの完了
(1) 自動テストでエラーが発見されなかった。
(2) 手動でテストケースを実行した。
(3) マスター・ワークシート[製品の機能の概要がかかれている]できめられたテスト分野が、いづれも「完了した」とされている。
(4) 二人のテスト担当者による各分野の特別テストが完了している。
(5) すべてのバグを回帰テストし（2回以上の再テスト）､終了した。
(6) 最新の200個の重要度1と2のバグについて､再度回帰テストを行った。
(7) 製造部門に引き渡す出荷日の1ヶ月前に､セットアップと全てのコンポーネント(EXCEL.EXEを除く)が確定している。
(8) 評価の高い｢ガッツ・フィール｣調査の結果､テスト・グループは､出荷準備ができたと考えている。
Ｂ．バグの発見・処理データ
(1) バグ発見のペースが､ゼロ・バグ版（ＺＢＲ）まで鈍化傾向になり、ＺＢＲ以降は横ばいである。
(2) バグの重要度の分布が変化し､重要度3と4のバグの割合が増え､重要度1と2のバグの報告が減少し続けている。
(3) 最初のリリース候補（ＲＣ１）の「決定会議」（報告のあったバグを､現在のリリースで処理するか､次のリリースに持ち越すかについて､「処理」、「持ち越し」、「未定」に分類する会議）の後で、すべてのバグが報告され、バグが解決された際、バグの回帰テストで参考にする様々なコメントを、バグ・レポートに追加している。
(4) 製造開始日までの１週間に、テストを続けているが、「必ず処理しなければならない」バグが報告されていない。

事後分析

1980年代後半以降、マイクロソフトのプロジェクトのうち、半分から3分の2が事後分析レポートを書いており､レポートを書かなかったプロジェクトも､殆どが事後分析のための会議を開いている。事後分析レポートでは､驚くほど率直に自分たちの動きが批判されており､経営陣にまで配布されるレポートであることを考えると、なおさらそのその率直さに驚かされる。ビル・ゲイツすら､ワード､エクセルなどの大型の製品と、マルチメディアなどの新しい分野では、事後分析レポートを熱心に読んでいる。
「プロジェクトのスケジュールが不適切で､現実性を欠くスケジュールを守ろうとして圧力がかかったため、テスト過程の統一性が保てなくなった。スケジュールが非現実的であったため､出荷モードのテストが始まったのは11月であった。これが4月半ばまで続いた。つまり、テストに使った時間の40パーセントが出荷モード（6ヶ月）に費やされたことになる。疲労困憊したこの過程で、生産性が落ちたことに気づいた。…コード変更､コード1000行当たりのバグ数､コードの複雑さを示す数値等を現実的に見積もってスケジュールを立てていれば､出荷モードに移る前に､出荷モードに移る前に､後3ヶ月､組織立った徹底したテストを行えただろう。」マック・ワード4.0プロジェクトの事後分析より。

製品ではなく､プロセスに焦点を当てた事後分析

事後分析レポートは､問題を列挙していく点ではすばらしい成果を挙げてきたが、問題が起こった理由を分析し､どのような解決策がありうるかを考える点では､不十分なケースが少なくなかった。その上､同じグループで将来､同じ間違いを繰り返さないようにする方法も､別のプロジェクトの経験を組織的に学ぶ方法も確立されていなかった。ウイリアムズによれば､例えば､どのグループでも毎回のように､チームのメンバーが機能を次々の増やしていったために、スケジュールが管理できなくなったと事後分析レポートで指摘しているという。…私は、「測定していないものは管理できない」（デマルコ）という言葉が大好きだ。数量データばかりにこだわることはないし､あらゆる物を測定するべきだとも思わないが、これまで、様々な点を一貫して測定する点では、あまりいい仕事をしてこなかったように思う。例えば、開発者の1週間当たりのバグ数といったデータだ。…今、追及しているものの一つに、見積もりと現実の差の検討が甘すぎた点が挙げられる。特にスケジュールの遅れに甘すぎた。例えば、開発者が「多分、3週間でできる」といったとする。4週間半たって、「まだ終わっていないのか」と聞くと、「もう終わるところだ」という答えが返ってくる。そして、仕事が終わると、皆でその開発者のところへ行って、「よくやった」という。「3週間のはずが4週間半かかった。どうしてなんだ。何処に問題があったんだ。どんな問題にぶつかったんだ」とは、誰も聞かない。