|
プロジェクトを支える管理手法
プロジェクトの推進役「ビルド」 現在開発が完了しているVisual Studio 2005日本語版ベータ1の場合，Visual Studio自身のソース・コードのコンパイルから始まって，最終的にセットアップ可能な「ビルド」を得るまでのビルド・プロセスに，最新のサーバー・マシンを使ってもおよそ半日ほどかかります。Visual Studioを使って自分のプログラムの「ビルド」を実行してみた経験のある人には，これがどれだけ大きなビルド・プロセスであるかが想像していただけるのではないでしょうか？ Visual Studio以外のマイクロソフト製品も，かなり初期の段階から「ビルド」を作ります。初期の「ビルド」は，まだ機能がそろっていなかったり，動作が不安定であったりします。それでも，セットアップ用のプログラムが組み込まれていることは，「ビルド」の必須条件です。それぞれの「ビルド」には，通常特定のビルド番号が付けられます。そしてプロジェクト・チーム内では，「明日何番のビルドが出ます」などというコミュニケーションが日常的に行われます。 プロジェクト終了までの長い期間，マイクロソフト社内では無数の「ビルド」が作られてテストに回され，その結果バグが報告され，それらのバグに対処した次の「ビルド」が作られ，またテストされ，というサイクルを繰り返して製品の品質を高めていきます。そして最後に「出荷可能な品質」であると全員が判断したビルドが，製品版またはベータ版という形で出荷されます。もし，ビルドが予定通り出て来ないと，その後の作業がすべて止まってしまうという最悪の状況になります。 Visual Studioほどの複雑な製品のビルドを行うためのファイル管理は，簡単ではありません。特にプロジェクト後期に入るまでは，日々のソース・コードやビルド自体の構成の変更も大きく，セットアップ可能なビルドを定期的に出すことは，それだけで大変な作業です。「ビルド」環境は大変デリケートで，例えば膨大なソース・コードの中の1つがコンパイル・エラーになっただけで，全体が止まってしまいます。コード開発者としては，最低コンパイル・エラーにならないことを自分のところで確認した上で「ビルド」環境に入れているはずですが，同じ日の他の部分の変更が影響することもあり，どのようなエラーが出るか，実際に「ビルド・プロセス」を起動して「ビルド」作成作業を開始するまで全く予測はできません。ソース・コードが安定する時期が来るまでは，この「ビルド」の担当チームが，全開発チーム内で最も神経をすり減らすチームかもしれません。 考えようによっては，ビルドはプロジェクトのリスク要因といえるかもしれません。それでも，多数の開発チームが同期しながら作業を進めるためには，「ビルド」を中心とするのが最良であるというのが，現時点でのマイクロソフト社内の大方の認識だと思います。
初めに遠い先までスケジュールが決められる それでもあえて日付を確定させる理由は，各チームが同期しながら作業を進めるための時期的な目印が必要であるのと同時に，プロジェクト全体を通した作業量と作業目標をある程度明確にすることで，逆に今から3カ月とか半年という直近の時期に，消化するべき作業が見えてくるためです。遠い日付も近付いてくるに従って再設定され，日付の精度も上がって行くのは，いうまでもありません。 様々な要因で，具体的な日付は変更される可能性がありますが，経験上，最終製品の出荷前の中間的なゴールなど，プロジェクト上の大まかな段取りは，一度設定されるとその後大胆に変更されることは少ないようです。プロジェクト上に設定される中間的なゴールのことを，私たちは「マイルストーン」（「里程標」の意味）と呼んでいます。ベータ版や最終製品版の出荷のような「メジャー・マイルストーン」があって，その間にはもう少し細かい「マイルストーン」があります。小さな「マイルストーン」を適切に達成することによって，「メジャー・マイルストーン」に到達できるのです。 また「メジャー・マイルストーン」は，その到達目標を明確にすることが重要です。特にベータ版の場合は，もとから最終的な仕様を満たしていないわけですから，何を持ってベータ版のゴールと見なすかを，あらかじめ決めておくことは重要になります。それらについては，メジャー・マイルストーンの変わり目の時期がきたら細かく設定します。例えば，ベータ1が終わった直後は，ベータ2の到達目標について話し合うちょうどよい時期になります。
プロジェクト・ライフサイクルをマイルストーンの流れに置く これを「メジャー・マイルストーン」ごとにほぼ同じように繰り返します。言い換えると，マイルストーンをパターン化しています。こうしておくと，プロジェクトにかかわる者にとって，現状が把握しやすくなります。つまり，過去に一度でもプロジェクトを経験したものにとっては，全体の流れのパターンが分かっているわけです。ですから次のプロジェクトもパターンが同じなら，前の経験をもとに今後の見通しを容易にかつ適切に把握できるようになります。これがプロジェクト・ライフサイクルです。 これは巨大プロジェクトの参加者に，現状に対する共有感を醸成するのにも役立ちます。この共有感の醸成は，プロジェクトの規模が大きくなるほど重要なポイントになってくると思います。 また共有感の醸成のためにはメールの活用も有効です。マイクロソフトの場合，プロジェクトの運営責任者が週に一度，あるいは重大な局面においては毎日，プロジェクトの参加者全員に投げてきます。内容はプロジェクトの現状，直近の問題点と目標，現在の最優先事項などです。このようなメールにより，プロジェクトの参加者全員が，自分たちが今やっていることは正しいと信じることができたり，問題があれば，一時的に特定の部分に高い優先度をつけて作業したりということを柔軟に判断できるようになります。しかもチームの垣根を越えて行いやすくなります。 大規模プロジェクトにおいては，まずプロジェクトの運営責任者のメッセージが，間違いなくプロジェクト全員に理解されなければいけません。次に，それが組織的に各チームの作業目標や優先度に適切に反映され，うまく同期して作業が進まなければなりません。このような状況を実現するには，パターン化したマイルストーンの設定が不可欠だと思います。 仮にプロジェクトの運営責任者が，マイルストーンを独自の定義で勝手に決めていたら，恐らくチームのどこかで混乱は免れないでしょう。同様に個々のグループや担当者が，マイルストーンの意味を勝手に解釈してちぐはぐな作業を行っていたら，結局統合するときになって問題続出は免れないでしょう。 マイルストーンのパターン化，標準化は大規模プロジェクトの運営には必須であると思います。ただし，それはパターンをかたくなに守るという意味ではなく，それぞれのマイルストーンの目的を正しく把握して，それを現場の状況に柔軟に当てはめることが重要です。
「バグ」を巡る攻防戦 各ビルドを使ってテストした結果，見つかった問題点は，すべてそのプロジェクト専用のバグ・データベースに登録して，プロジェクト全体で共有します。データベース上，見つかったバグ1件は，レコード1件として登録されます。代表的な登録情報としては，下記の項目があります。
・バグの詳しい内容 社内のルールとして，データベース上で特定のバグの担当者に指名されたら，その人は責任を持って問題を解決する義務があります。少なくとも調査を行って，結果的に自分の担当でなかった場合でも，データベース上で速やかに担当者を元の人に再設定するか，新たな担当者に設定します。もし，担当しているバグの解決のペースが遅いと，まもなく上司に一喝されてしまいます。
通常，最新ビルドに内在するバグの数は，テスト作業の進行に伴ってどんどん上昇を続けます（図2）。これは「順調にバグが見つかっている」状態です。ただし，見つかったバグについては，それぞれの担当者が随時解決しますので，プロジェクトがある時期まで来ると，その日に見つかったバグと解決したバグの総数が均衡し，理想的に言うとその後バグ総数は下降し始めます。なんらかの事情で再びバグの数が上昇し，グラフ上の「小山」を作ることもありますが，全般的には収束に向かうのが正しいというか，期待される状態です。特にメジャー・マイルストーンに対応するテスト項目が出尽くしていれば，基本的にバグの件数はその時点からは大きく伸びません。そのため先ほども述べました通り，ベータ出荷などでは，その到達ゴールを細かく設定し，どこまでテストする必要があるかについて明確にしておく必要があります。 ここから先は，スケジュールに合わせてすべてのバグが解決するように，それぞれのチームが「週に何件のバグを解決する」などのノルマを立てて，ひたすらバグ修正と格闘することになります。この間もテスト担当者は，製品の品質向上のために各ビルドに対して過酷なテストを課し続け，最新のビルドに残っている問題を表に引きずり出そうと奮闘します。 そのとき，もしバグ件数の上昇がある時期を過ぎても止まる気配を見せないとしたら，それは非常によくないサインです。ここからはさらに必死で修正作業を続けて，何とかバグ件数を抑え込むか，さもなければスケジュールの変更を検討しなければいけません。いずれにしてもこの時期は1つの正念場となります。 |
