|
マイクロソフト プロダクト ディベロップメントリミテッド
ディベロッパー製品開発統括部
プロジェクトマネージメントグループ
プログラム マネージャ
小松 誠
入社以来，サポート，マーケティング，製品開発部と部署移動しても常に担当製品はVisual Studio。実家は祖父の代から大工道具屋，3代続いてディベロッパツール屋。
|
現行バージョンの「Visual Studio .NET 2003」では，「Visual Studio .NET Enterprise Architect 2003」が最上位版です。これは開発者向け「Visual Studio .NET Enterprise Developer 2003」に，開発上流工程を支援する「Office Visio 2003」を追加したものです。これにより，アプリケーションのアーキテクチャと機能を，設計・指定・伝達できるようになっています。 これらは主に，アプリケーションArchitect（以下アーキテクト）のための機能です。この製品によりVisual Studioは，プロジェクト開発におけるアーキテクトと開発者（主にプログラマー）を支援できるツールとなりました。
ところが，今までの連載でも書いてきましたように，アーキテクトと開発者だけではプロジェクトを成功させることはできません。プロジェクトを成功させるには，そのプロジェクトに対する品質/納期/予算をすべて予定内に収めなければなりません。そのため，品質を向上させるためテストを行う“QA”と，予定通りの納期と予算でプロジェクトが進んでいるかを常に監視している“プロジェクト管理者”が必要です。 VSTSは，今までのVSのようにアーキテクトと開発者だけのツールではなく，QAやプロジェクト管理者も含めて，開発プロジェクトのすべての参加者を支援するツールとして登場しました（図1）。
大規模プロジェクトになるほど必要とされる「プロセス」とは 大規模プロジェクトを成功させるためには，「ルール」すなわち「プロセス」が必要です。プロセスは開発を進める上で非常に重要なものです。われわれVisual Studio開発チームも常にプロセスを守り開発を進めています。鉄の掟といっても過言ではないでしょう。 そのことは，私が他部署から移ってきた時に強く感じました。Visual Studio .NET 2003の開発が終盤に差し掛かったころでした。Visual Studio .NET 2003日本語版のために新たな作業が必要になりました。それは大きな作業ではなくエンジニアが1人で2時間くらい作業すれば終わるような小さなものでした。しかし，われわれはすぐにその作業は行わず，まず，最初に関係者が数名集まり2時間くらいでその作業のプロセスを作りました。そして，その作られたプロセスを基に作業を行いました。そして，製品版リリース後に，これらプロセスがうまくいったかどうかを，時間をかけて見直しまいた。 たった2時間で終わるような作業に，これほど時間をかけるのは一見無駄なように思われますが，一度作成し（うまくいった）プロセスは，中国版や韓国版など他の翻訳版にも利用できます。また，次のバージョンであるVisual Studio 2005で同じ作業が発生した場合にも，再利用できるのです。われわれのチームでは，このように作業のノウハウを個人にではなくプロセスとして蓄積していきます。このような過去からのプロセスの蓄積により，Visual Studioが開発されているのです。
マイクロソフトのノウハウを集約した「MSF」と「MOF」
MSFの歴史は意外と古く，MSFの最初のバージョンが発表されたのは1994年です。MSFも他の製品と同じようにバージョンアップを重ね，現在はバージョン3.1がリリースされています。これら内容としては，現在日本語のWeb （該当サイト） で「Microsoft Solutions Framework3.0の概要」と「MSFチームモデルv.3.1」として公開されています。ご興味がある方はぜひご覧ください。なおVSTSがリリースされる際には，MSFも3.1から新しいバージョンにアップされる予定です。 開発工程をサポートするMSFとは別に，プロジェクトの運営環境のプロセスを集めて研究し，まとめたものを，「Microsoft Operations Framework（MOF）」として発表しています。MSFとMOFを相互利用することにより，プロジェクトの全体をカバーできます（図2）。 |
