Insider's Eye マイクロソフトが提供する開発指針「MSF」とは何か？ ―― 翔泳社デブサミ2005 セッション・レポート ―― デジタルアドバンテージ　一色 政彦 2005/02/09

Page1 Page2

2. MSFチーム・モデル

　MSFチーム・モデルでは、次の表にある6つのチーム構成要素を定義する。

チーム（構成要素）	説明責任（＝役割分担）	職能領域（＝具体的な役割）
プロダクト・マネジメント	高い顧客満足の実現	ビジネス上の価値評価、マーケティング、顧客代弁、製品計画
プログラム・マネジメント	プロジェクトに対する制約条件をクリアしたうえでのITソリューションの提供	プロジェクト・マネジメント、ソリューション・アーキテクチャ、プロセス保証、管理サービス
開発	製品仕様を満たすITソリューションの構築	技術コンサルティング、実装アーキテクチャと設計、アプリケーション開発、インフラストラクチャ開発
テスト	すべての品質問題（バグなど）の検出。またそれに対処した後のリリース承認	テスト計画、テスト・エンジニアリング、テスト報告
ユーザー・エクスペリエンス	ユーザーにとっての高い利便性・使用性の実現	アクセシビリティ、国際化、ユーザー代弁、教育／サポート・マテリアル、使用性調査とテスト、ユーザー・インターフェイス設計
リリース・マネジメント	スムーズな展開。およびシームレスな運用	インフラストラクチャ、サポート、運用、ロジスティクス、商用リリース・マネジメント
MSFチーム・モデルにおけるチーム構成要素

　プロジェクトを上記表にある6つのチームに分割して、それぞれのチームに明確な説明責任（＝役割分担）を与えることで、チーム間で、下図のような（階層的ではない）ネットワーク的なコミュニケーションを促進させることができる。つまりこのような構成にすることで、それぞれのチームは、その説明責任を果たすために、必要ならば適切なチームとのコミュニケーションを図るようになるわけである（もしこれが階層的に構成されたチームならば、その階層をたどらなければならないなど、コミュニケーションに支障が出てくる可能性がある）。

MSFチーム・モデルにおけるチーム間の関係

●大規模プロジェクト／小さなプロジェクトでのチーム構成の方法

　大規模なプロジェクトで6つのチームに分割する方法には、「職能チーム構成」と「製品機能チーム構成」の2種類がある。職能チーム構成は、6つのチームを作成し、上記のチーム構成要素の分類に従って、そのそれぞれのチームに構成員を割り当てる方法である。一方、製品機能チーム構成は、それぞれの製品機能ごとに（例えば、デスクトップ製品機能、ファイルとプリント製品機能、メッセージング製品機能ごとに）分野を分割し、それぞれの分野の中に6つのチームを作成する方法である。これらのチーム構成方法は、かかわるプロジェクトや状況に合わせて最適なものをその度に選ぶことになるだろう（小泉氏のセッションでは、その選択基準について詳しくは言及されなかった）。

　しかし、チーム構成員が少ない小規模なプロジェクトの場合、そのように1つのプロジェクトを6つのチームに分割できないかもしれない。そのような場合には、（あまり望ましいことではないが）チーム（＝説明責任）を兼務するしかない。ただしその役割兼務の組み合わせについては注意が必要となる。その組み合わせ方によっては、何らかのリスクが生じる可能性があるからだ。

　例えば、プロダクト・マネジメントが顧客寄りの意志決定をするチームであるのに対し、プログラム・マネジメントは開発者寄りの意志決定をするチームである。そのため、この両者を1チームが兼任してしまうと、（人間は完ぺきではないので）顧客か開発者かのどちらかに偏りが生じやすい。このような偏向のリスクがあるので、プロダクト・マネジメントとプログラム・マネジメントを兼務することは避けなければならない。

　そのようなチーム（＝説明責任）の組み合わせ内容における判断基準（可能／普通はしない／避けるべき）を次の表にまとめた。

	プロダクト・マネジメント	プログラム・マネジメント	開発	テスト	ユーザー・エクスペリエンス	リリース・マネジメント
プロダクト・マネジメント	-	N	N	P	P	U
プログラム・マネジメント	N	-	N	U	U	P
開発	N	N	-	N	N	N
テスト	P	U	N	-	P	P
ユーザー・エクスペリエンス	P	U	N	P	-	U
リリース・マネジメント	U	P	N	P	U	-
小さなプロジェクトでの役割兼務の組み合わせに関する判断基準
P（Possible：可能）、U（Unlikely：普通はしない）、N（Not Recommended：避けるべき）。

　上記表で特に注意すべきところは、前述のプロダクト・マネジメントとプログラム・マネジメントが兼務できないという点に加えて、開発はどの役割とも兼務できないということである。注意してほしい。

3. MSFプロセス・モデル

　MSFプロセス・モデルでは、イテレーティブ型（＝繰り返し型）のプロセス・モデルを規定している。このイテレーティブ・モデルでは以下の図表にある5つのフェイズ（過程）が1回の開発サイクルとなる。

フェイズ マイルストーン 主導チーム ビジョン化 ビジョン／スコープ（＝製品機能）の合意 プロダクト・マネジメント 計画（＝設計） プロジェクト計画の合意 プログラム・マネジメント 開発 スコープ完成 開発、ユーザー・エクスペリエンス 安定化（＝テスト） リリース準備の合意 テスト、リリース・マネジメント 展開 展開完了 リリース・マネジメント

MSFプロセス・モデルの各フェイズ（1サイクル）

図中のひし形（四角）は、マイルストーン（＝各フェーズのゴール地点）を表す。

　上記図表の1サイクルを、次の図のように何度も繰り返し、バージョンを更新しながら、製品を最終的な状態にまで完成させていく。

イテレーティブ型MSFプロセス・モデルの概念図

　MSFプロセス・モデルによる開発プロセスを実行する際には、長大なプロジェクトを細かいバージョンに分割したり、内部リリースやデイリー・ビルド（＝毎日ビルドしてバージョンを上げること）を採用したりして、サイクルを小さく回すことが推奨される。このようにすることで、計画フェイズや開発フェイズと、安定化フェイズの間隔が短くなって、比較的早期に問題を解決できる可能性が高まる。つまり、そうすることが開発プロジェクト全体のリスク軽減につながるのだ（例えば、2〜3カ月前の昔のバグの修正は困難だが、2〜3日前の早期に発見されたバグの修正なら比較的容易なことが多いだろう）。

4. MSFの規範

　前述したように、MSFでは、チーム・モデルおよびプロセス・モデルを確実に実施していくために、プロジェクト・マネジメント規範／リスク・マネジメント規範／レディネス・マネジメント規範といった3つのプラクティス（＝判断・行動のルール）が提供されている。

●プロジェクト・マネジメント規範

　プロジェクト・マネジメント規範では、プロジェクトを効果的に管理できるように、一般的なプロジェクト・マネジメント標準（例えばその世界では非常に有名な「PMBOK：The Project Management Body of Knowledge」など）を取り込んで活用できるようにしている。つまり、広く用いられているPMBOKの手法をそのまま使って、MSFのプロジェクト管理が行えるわけである。

●リスク・マネジメント規範

　リスク・マネジメント規範では、リスク（＝問題発生の危険性）に対してリアクティブ（＝事後）に対応するのではなく、リスクをプロアクティブ（＝事前）に識別して分析し、さらにそれに対処するための規範が提示されている。具体的には例えば、以下の表にあるような規範に従って、リスク・マネジメントを行うことが求められる。

プロアクティブなリスク管理	リアクティブなリスク管理（非推奨）
問題を予測する	問題が発生してから対応する
根本原因に対処する	起こった表面的事象に対処する
軽減策によりリスクを予防または極小化する	結果に反応する
結果に対する準備により影響を極小化する	危機に反応する
既知の構造化されたプロセスを使用する	その場しのぎのプロセスを使用する
MSFリスク・マネジメント規範

●レディネス・マネジメント規範

　レディネス・マネジメント規範では、ソリューション開発に必要なチーム構成員の知識／スキル／能力をその場しのぎで身に付けるのではなく、それがプロアクティブに備わるように管理すること、いわゆるレディネス・マネジメントが求められる。このレディネス・マネジメント規範には、例えば以下の表のようなものがある。

レディネス管理	リアクティブな対処（非推奨）
レディネス計画を前向き的なものとして扱う	知識。スキル、能力の不足に反応する
既知の構造化されたプロセスを使う	場当たり的なプロセスを使うか、何もしない
レディネスの必要性を予期し、スケジュールに組み込む	ギャップが顕在化してからトレーニングを行ったり、ギャップを埋める
ナレッジ・マネジメント・システムを開発し使用する	知識資産が個人に埋没する
MSFレディネス・マネジメント規範

■

　以上が、小泉氏のMSFのセッションで語られた内容の要約である（筆者なりにまとめなおしたため、完全には一致しない部分もあるかもしれない）。筆者はこのセッションの中で、特にチーム構成の分け方やそこでの役割兼務の話はとても面白いと思った。読者諸氏も本稿のセッション・レポートによってMSFに何らかの興味を持っていただけたならば幸いである。もしMSFに興味を持ったなら、ぜひ次のマイクロソフトのサイトを訪れてより詳しい情報を入手してほしい。

• Microsoft Solutions Framework (MSF) プロセス

　なお、MSFプロセスは次期開発ツールであるVisual Studio 2005 Team Systemの1機能としても搭載される予定である。もちろんMSFはすでにドキュメントがそろっているのでいますぐに活用することもできるが、Visual Studio 2005 Team Systemでは、その統合開発環境からMSFを基盤とした開発プロセスの導入、活用、管理が行えるようになる。先進の次期開発ツールを使いこなすためにも、MSFはいまから学んでおくべきものだろう。

INDEX
	Insider's Eye
	マイクロソフトが提供する開発指針「MSF」とは何か？
	1．MSFの概要
	2．MSFのモデルと規範

　

Insider's Eye

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）