「マイクロソフトにおけるアジャイル開発はこんな風に進められている」という記事が公開されているので紹介します。
http://www.publickey1.jp/blog/10/post_107.html
以下、上記URL内の本文から内容を引用してご紹介します。
マイクロソフトの代表的なソフトウェアは、数千人を超える開発者、数十万のソースコードファイル、数千回ものビルドを繰り返して開発される大規模なものだといわれています。
マイクロソフトのエバンジェリスト長沢智治氏は、こうした大規模な開発プロジェクトがマイクロソフト社内でどのように行われているのか、プロジェクトチームの組成から実施計画、進捗管理、バグレポートなど、その裏側を紹介するセッションをいくつかのイベントで行っています。
そこで明かされている内容は、パッケージソフトの開発だけでなく、SIerでの開発プロジェクトでも参考になる部分が多いと思われ、いつかレポート記事として紹介したいと思っていました。
今回、以前に行われたセッションビデオの存在を長沢氏ご本人から教えていただいたので、開発プロセスに関する部分にフォーカスした記事としてまとめました。
記事での内容は主に、「Microsoft Tech·Ed Japan 2009」で行われたセッション「マイクロソフトにおけるアジリティを向上させる開発プロセスへの試み」を基に構成しました（ただし記事として分かりやすいように一部を割愛したり、説明の順序を入れ替えたりしています）。
マイクロソフトにおける開発プロセス
いくつかの統計によると、ITプロジェクトの成功率は3割程度しかない。ITのプロジェクトには、もっと成熟すべき部分がある。
プロジェクトが追求するのは、よりよいものをより短い期間で、安く作るということ。いわゆるQCD（Quality、Cost、Delivery）の3要素。マイクロソフト社内でも、QCDについてさまざまなイニシアチブで取り組んでいる。
マイクロソフトにも苦い経験がある。Visual Studio 2005の開発時には、当初24カ月で開発を終えようと計画していた。しかし途中でバグの発生などがあり、対策に時間がかかった結果15カ月も遅延し、39カ月もかかってしまった。
このやり方では開発者のニーズに対応できないと考え、次のVisual Studio 2008の開発に入る前に新規開発をやめ、4カ月ほど既存バグの根絶と、バグのない状態を保てるような開発プロセスの見直しをした。バグが出ないように、あるいはバグが出てもすぐに対応できるようなアジリティのある体制にすることを目指した。
つまり対症療法ではなく、原因療法への切り替えだ。
アジリティの向上をトップダウンでやるべきか、ボトムアップでやるべきか。どちらかでやるという考え方はやめる。どちらも必要。
トップダウンやボトムアップではなく、「バリューアップ」の価値観で統一する。そして、コードをコンプリートさせるのではなく、フィーチャーをコンプリートさせる、という考え方にシフトする。
これはタスクの達成率などで進捗を計るのではなく、どれだけバリューをアップさせたかで計る。バリューを基準にした組織運営に変えていく。
マイクロソフトはどのような開発プロセスにしたのか。開発プロセスの階層化を意識して作り込んだ。
まずビジネスの価値や目的ありきで考え、それをブレークダウンしていく。SIでいえば、お客様のビジネス目標があり、それをITで実現するための要件をブレークダウンしていくのと同じ。
Visual Studio 2008では、おおよそ9つのビジネス目標があり、それを100のバリュープロポジションに分解、それを実現する300のフィーチャーグループ（ユーザー経験）に落とし込み、最終的に1200のフィーチャー（機能）を開発することとした。
これを実現する社内の組織構造はどうしたか。社内の物理的な組織は、PMグループ、開発グループ、テストグループなどの役割別に縦割りになっている（図の緑色の帯）。しかしフィーチャーを実際に開発するチーム「Feature Crew」は、この組織を横串で横断するバーチャルチームとして構成した。各チームはおおよそ10人以下の規模感である。
このチームごとに「プロジェクト」となり、実際の開発方法はチームに任せられる。XPでもスクラムでもいいし、ウォーターフォールでもいい。チームにあった方法でいい。
ただしチームは3つの鉄則を守らなければならない。
- 報告義務をおろそかにしない。嘘をつかない
- フィーチャーの完了前に「クオリティゲート」を通過しなければならない
- 「クオリティゲート」を通過したもの以外、アクティブなブランチに統合してはならない
クオリティゲートはフィーチャーごとに設けられる品質チェックの工程。フィーチャーの完成には3～6週間を想定しており、短期のゴールを確実にクリアすることがプロジェクトごとに繰り返される。
クオリティゲートには17項目ほどのチェック項目があり、これによって品質を共有していく。
実行計画について。チームはフィーチャーごとの開発工数を見積もり、管理ツールに入力する。また、フィーチャーは重要度ごとにランク付けされる。
マイクロソフトのTeam Foundation Serverでは、フィーチャーごとに見積もった工数を全部集計しExcelで出力する機能がある。このシートでは、重要度ごとにソートされており、工数を積算して出荷予定日に間に合いそうにないものが黄色と赤で表示される。
これを見ればマネージャは、納期までにどのフィーチャーが間に合うのか、あるいはどの時期までに重要なフィーチャーが揃い、出荷可能になるのかのカットラインを判断できるようになる。また、重要なフィーチャーは重要度を上げ納期内に間に合わせ（その代わりほかのものを落とす）といった操作もできる。
これを「Yellow/Red Game」と呼んでいる。
進捗管理について。フィーチャーごとのプロジェクトには、進捗のためのチェックポイントが2つある。1つは実施計画レビュー（CP1：チェックポイント1）、もう1つは実施内容レビュー（CP2：チェックポイント2）。そのあとにクオリティゲートをクリアすれば、フィーチャーが完成する。
各チームは毎週プロジェクトの進捗を入力していくが、プロジェクト開始時にフィーチャーの完成をの日付をコミットするわけではない。プロジェクト開始時にはCP1の日付をコミットし、その先については予想日付とする。
CP1の時点でCP2の日付をコミットし、CP2の時点で完成の日付をコミットする。このように順次日付をコミットしていく。
こうすることで、マネージャはYellow/Red Gameで詳細な情報を基にした意志決定ができる。また、チームにとっては報告義務がシンプルになる。シンプルだから継続的に実行できる。
進捗として入力された情報は、ExcelのシートだけでなくProjectでガントチャートとして見ることなど柔軟なビューが用意されている。これもTeam Foundation Serverの機能。
バグの状況は、フィーチャーに関連付けて報告を行うことで、どのフィーチャーにどれくらい問題が発生しているのかを把握することができる。バグの解消状況もグラフで把握することができ、状況に応じた対応が可能に。
マイクロソフト社内でこうした開発プロセスを取り入れた結果、Visual Studio 2005（Whidbey）開発時と比べて、Visual Studio 2008（Orcas）の開発では最初からバグの発生を抑えることができ、バグが発生しても早く収束するという効果がでた。
