Visual Studioの開発現場から（第5回）p3

禁断の「仕様の変更」
　製品仕様そのものも，実装およびテストが進行するうちに変更の必要に迫られることがあります。そのような仕様変更のリクエストも，手続き上はバグと同じように処理し，データベースに登録します。リクエストは開発のリーダーたちによって，承認か却下かが決定され，データベース上の承認結果が更新されます。正式に仕様変更が承認されれば，その「バグ」レコードがコード担当者に割り当てられます。実装が終了したら，今度はテスト担当者がその部分のテスト項目を自分の作業に追加します。

　とにかくこの時期は，バグ件数のグラフの推移がプロジェクトの進行の大半の部分を語っているといえます。日々1件でも多くバグを解決して，バグ0件を目指すのが最優先事項です。繰り返しになりますが，バグの修正とその確認のためには，新しいビルドを日々出し続けることが絶対条件となります。

「バグをクリアする」とは
　首尾よくバグの件数の減少が確実になったら，そろそろ出荷のための準備をする必要があります。バグが減ってきているのだから，ここから先は楽ではないかと思われるかもしれませんが，実は案外そうでもありません。

　私は，エンド・ゲームは「飛行機の着陸」と共通点が多いと思っています。飛行機の場合も，もう飛行場はそこに見えているのだから，着陸は簡単なように思えます。実はパイロットにとって離着陸の瞬間が一番難しい——と聞いたことがあります。プロジェクトのエンド・ゲームにも同様のことが言えます。どちらも「動から静」へ物事を強制的に切り替えていかなければいけませんから，細心の注意が必要なのは同じです。

　本格的にエンド・ゲームに突入する前に，まずやっておかなければいけないことがあります。それは，データベース上のバグ件数を十分なレベルまで減らすことです。飛行機も安定した着陸を得るためには，最もよい方角と角度で滑走路に入る必要があります。そのためには不安要素は極力排除する必要があります。

　Visual Studioプロジェクトの工夫としては，ある日を境に「過去2日内に登録されたバグ以外はすべてクリアする」というルールがあります。これを超えると，やっとバグの総数が落ち着いた感触を得られます。その日まではとにかくバグを1件でも減らすことが，最優先事項となります。

△　図をクリックすると拡大されます 図3●エンド・ゲームに突入するとビルドは2つに分かれる

「本流ビルド」と「ベータ・ビルド」に分ける
　そして，いよいよエンド・ゲームに突入します。「ベータ版出荷」というメジャー・マイルストーンの場合，まずベータ専用のビルド・プロセスを構築します。言い換えると今まで使っていた「本流ビルド」と「ベータ・ビルド」の2つのビルド・プロセスを持つこととなります（図3）。「本流ビルド」はベータの作業とは離れて，次のベータや最終製品版を作るためのビルドです。「ベータ・ビルド」は間近に迫っているベータ版を作るためのビルドです。

　このような体制にする理由は，「ベータには必要だが，ベータが終わったら不要なコード」があるからです。エンド・ゲームでは，出荷が最優先になるため，ベータの場合は特定の問題に対して一時的な回避コードを埋め込むことがあります。「本流ビルド」と分けておくことにより，安全にソース・コードを管理できます。また，ベータの作業と並行して，本流ビルドを使い，次のメジャー・マイルストーンのための作業を並行して行えます。

　場合によっては，ビルドを分けたあとに「ベータ・ビルド」と「本流ビルド」の両方にコード修正をしなければならないこともあります。そのときは両方のビルドに同じコードを入れます。これはビルドを分けたことによる副作用で，2重作業となってしまいます。そのような期間を不必要に長く取っては，効率が落ちますので，状況から期間を見極めます。

　プロジェクトがエンド・ゲームに入ると，この時点でビルドの品質はかなり安定してきているはずです。そうなるとエンド・ゲームの最重要課題は，その「安定を維持しつつ残った問題を速やかに解決する」ということになります。ですから，この時期のプロジェクト管理はかなり物事を保守的に考えるように切り替わらなければいけません。

　もし，この時期にだれかのひらめきがあって，画期的な機能を思いついたとしても，絶対にその実装は許可されません。コードに大きな変更を入れることにより，製品の安定性が損なわれるからです。少しでも製品の安定性に影響が出ると，確実に出荷の遅れにつながります。ビルド内の変更は，本当に必要な重大な問題に絞られ，かつ変更量が最小限ですむように少しずつ制限されていきます。

ビルドの変更点を毎日の全体会議で共有
　ある時期から，各開発チームの代表者がプロジェクト全体の状況を，毎日把握する必要があります。そのための進ちょく確認ミーティングが毎夕開かれます。代表者だけでも相当な人数なので，ミーティングとしてはかなり大きい方でしょう。

　発表内容は，その日ビルドに加えた変更，つまりバグ修正済みの項目についてです。バグ・データベースを基に各チームが順次発表します。発表を聞いているチームは，その変更が自分のチームへ影響がないかを考えています。その場で質疑応答も行われます。

バグ修正にも認承が必要になる
　そういう時期がしばらく続くと，さらに制限がきつくなります。今度は，ビルドへの変更を許可なく行うことが禁じられます。すべての変更は，進ちょく確認ミーティングで担当者が情報を提出し，承認を受けて初めて変更できます。

　承認の判断基準は，基本的に変わりませんが，より厳しくなります。また，バグ修正の候補を持ち込む人は，あらかじめ自分で「プライベート・ビルド」と言うものを作成して，自分が入れようとしているコードが基本的に問題を引き起こさないことを実機動作で確認する義務があります。この時期になると，承認される修正バグは1日およそ数件にまで絞り込まれます。

　しかし，Visual Studioは巨大な製品ですから，この時期になってはじめて，スケジュールに影響を与えそうな重大な問題が発覚することもあります。その場合は「スケジュールを遅らせても修正コードを入れるか」「涙を飲んでその部分の修正をあきらめ，予定通りの出荷を目指すか」の決断をしなければいけません。そのための準備として，
・修正しない場合の回避策の有無の確認
・修正個所の把握とプライベート・ビルドによる実機確認
・該当部分の影響範囲の分析
があります。

　まずは回避策の確認をします。特にベータ版出荷の場合は，回避策があればそれをリリース・ノート（readme.htm）に記載することで，コード修正不要と判断することがあります。そうでない場合は，次に修正候補コードの実機確認をして，修正作業に必要な技術的問題をクリアにしておきます。さらに，現状でそのバグが，視覚的なエラーを起こすか，他機能へ影響があるか，それともエラー表示もなく単にその機能が使えなくなっただけなのか——などを判断材料にします。もちろん，その機能自体の重要性も考えなければいけません。ただし，Visual Studioのようなプロジェクトには，それぞれ個人的な思い入れもあり，冷静な判断が難しいこともしばしばです。

　それでも「安全に着陸すること」が最優先には違いありません。多少飛行機の翼が揺れても着陸した方が，よい結果的になる場合もあるでしょう。予定到着地に何らかのトラブルが発生して着陸できないときは，やむを得ず予定を変更して他の着陸地を探さざるを得ない場合もあるでしょう。

　これはプロジェクト管理責任者にも，ほぼ同様のことがいえます。すなわち，スケジュールを可能な限り守りつつ，製品の品質が顧客の要求するレベルに達しているかを総合的に判断し，出荷を決定するということです。それは顧客に対して，最終的な品質管理の責任を持つということでもあります。もちろん，そこに至るまでには，品質管理についてはテスト担当者の貢献によるところが大きいわけですが，最後の判断はプロジェクト管理責任者の仕事です。

　最終的にリリース候補版ビルドが出ると，テスト担当者がすべてのテストをします。そして出荷基準を満たしていることが確認できたら，ようやく全員の合意の下，プロジェクト管理責任者が，ビルドの出荷を決断します。そうなると，マスターCDは製造工程に回され，同時にMSDN（マイクロソフト・デベロッパー・ネットワーク）会員向けのWebダウンロードの担当者に送られます。

メジャー・マイルストーンごとに反省会を開く
　こうして1つのメジャー・マイルストーンが終了すると，チームごとにいわゆる反省会を開きます。そこで過去を振り返って，どこがうまくいって，どこがまずかったかを明確にしていきます。実際に実行してきたこと，発生した問題などをプロジェクトの初期から思い出します。それらが当初のプランに対して，どのような結果に終わったか，全員で分析します。

　「ここは目論見通りうまくいったから，継続しよう」とか，「あそこは予想に対して期待した効果が得られなかったので，別のプランを考えよう」，または「結果として問題はあったが，基本的なアイディアに間違いはなかったことが確認できたので，現状を踏襲しつつ反省点を改善しよう」——などというように，それらを次のメジャー・マイルストーンのためのアクション・プランに落とし込みます。

　ここで重要なのは，反省会は個人の責任追及の場ではないということです。もしそうなると，皆思っていることが言えなくなり，反省会をする意味が失われてしまいます。この場では，例え自分自身が関与する問題であっても，冷静に客観的に意見として述べる態度が望まれます。

最後に
　ここに説明した以外に，実際にはプロジェクト管理として，リスク管理やローカリゼーション製品のプロジェクト管理，ベータ・プログラムの運営など，様々な側面があるのですが，今回はプロジェクト管理の基本概要だけにとどめさせていただきました。

　次回は「Visual Studioにおけるソフトウエア・ローカライズ手法の概要」についてご紹介する予定です。