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

　このコラムの本題に入る前に，読者の皆様にご協力していただきたいことがあります。現在進行中の「Visual Studio 2005」の開発において，顧客から直接意見を聞いて製品に反映させるという開発アプローチを強化することになりました。

　私たちは日本の顧客の皆様の声を製品に反映させたいと思います。皆様がVisual Studio 2005のベータ1を入手されましたら，ぜひCDまたはDVDの中に収められているreadme.htmをお読みいただき，そこに書いてある要領でベータ版に対するフィードバックをお送りいただきたいのです。よろしくお願いします。

イラスト：岡本 敏

　　　＊　　　＊　　　＊

　さて，本題に入りましょう。今回はVisual Studioの開発の様子を，「プロジェクト管理」というマクロな視点からお話します。それは「プロジェクト・ライフサイクル」と「グループ・マネジメント」という“縦横”の管理手法を駆使したものです。

　Visual Studioの開発プロジェクトは，恐らく現在マイクロソフトに数あるプロジェクトの中でも，屈指の規模ではないかと思います。ソフトウエアの開発としては「巨大プロジェクト」と表現してもよいかもしれません。

　例え話としていうならば，まず広大な大学のキャンパスを想像してみてください。にぎやかにキャンパスを行きかう大半の人は，自分にとってほとんど面識はないはずです。ところが，もしその一人ひとりに尋ねてみるならば，だれもがVisual Studio開発プロジェクトの何かしらの部分を担当している…そのような状況を思い浮かべていただけるとピッタリかもしれません。

　いずれにしろ，革新的な技術の搭載を目標とした製品開発でありながら，また，そうであるがゆえに大量の人員の投入を必要とし，それをなおかつ1つの方向に向かわせて最終製品にまで仕上げるということは，正直いって尋常なことではないのです。

　私はVisual Studio開発プロジェクトにおいて，「プロジェクト マネージメント グループ」という管理専門のチームに所属しています。別の言葉でいえば「現場監督」とでもいいましょうか。そんな立場からお話しようと思います。

この12年で巨大化した開発プロジェクト
　ここでちょっと過去を振り返って見ましょう。今から12年ほど前，マイクロソフトの開発ツール製品群が，Visual Studioとして統合されるずっと以前のことです。「Visual Basic」の最初の日本語版となったバージョン2.0の開発が始まったころ，開発チームの規模は現在とは全く異なっていました。

　当時のVisual Basic開発チームは，製品を開発・出荷するために必要な機能をすべて自前で持っていたにもかかわらず，今と比べてかなりこじんまりした編成で行われていました。その中で実際に働いてみると，少なくともお互いが何をやっているのかよく知らないという状況ではありませんでした。プロジェクト全体のコミュニケーションも，数人ごとに編成された各開発チームのマネージャが，自分のチーム・メンバーを定期的に回って進ちょくを把握するのが中心でした。そして大抵の問題は，数人の必要なマネージャが集まれば解決できたと思います。恐らくプロジェクトが「個人の努力でコントロールできる」規模であったのだと思います。

　その後，製品のバージョンが上がるごとに，プロジェクトに参加する人数は増え続けました。そうすると開発チームの中で，だれかが片手間で何となくやっていた作業が，やがて1人の担当者に専任で割り当てられるようになり，ついには複数の人間が分担するようになって，最後には1つの部署として独立していくというようなことが，日常的に行われてきました。それと同期して，プロジェクトは単に個人の努力でコントロールできる規模ではなくなってきました。

　特にVisual Studio 6.0のプロジェクトが終わって次のプロジェクト，最終的にVisual Studio .NET 2002と呼ばれることになるプロジェクトが本格に始まった1998年秋には，Visual Studio開発プロジェクトは既に「にぎやかなキャンパス」状態になっていました。

製品統合とともに開発チームも統合
　ご存知の方も多いと思いますが，Visual Studio 6.0の中にはそれぞれ異なるIDE（統合開発環境）が3つ共存していました。「Visual Basic 6.0」と「Visual C++ 6.0」があり，「Visual InterDev 6.0」「Visual J++ 6.0」は同じIDEでした。

　これをVisual Studio .NET 2002では，1つのIDEをベースに仕事をすることになって，その開発のために初めてそれぞれのチーム・メンバーが一堂に会することになりました。そのためか，この時期ミーティングに参加すると，まず出席者どうしの自己紹介から始まることが多かったように思います。このように今まで別々に動いていたプロジェクトが統合され，かつその規模が加速度的に拡大する状況にあって，そのプロジェクト管理が並大抵の仕事でないと，想像してもらえるかと思います。

管理手法は，試行錯誤で獲得したノウハウ
　現在のVisual Studio開発チームが採用しているプロジェクト管理手法は，「スパイラル方式」という，何回もリリースしていく手法をベースにしたものです。現在の管理手法に至るまでは，試行錯誤を繰り返しながら，進化してきました。従来製品のプロジェクト管理手法を土台に，部分的にWindows開発プロジェクトやOffice開発プロジェクトから持ってきたアイディアを取り入れたものです。

　マイクロソフト社内のいずれのプロジェクトの管理手法も，細かい部分を除くと体系がそれぞれよく似ています。恐らくマイクロソフト内の各プロジェクトで作り出された様々な手法が，別のプロジェクトに流用され，さらに独自の発達をして，また別のプロジェクトに採用され，というように連鎖的なフィードバックの中で，より利用しやすいように体系化されていったのではないかと思います。そのエッセンスは現在開発中の「Microsoft Visual Studio 2005 Team System」の中にも生かされています。

「巨大化」とはすなわち「複雑化」
　決められたスケジュールに従って，効率よく運営するために大切なことは，変わらないのですが，プロジェクトの規模が大きくなると，達成しなければならない要件がより複雑化していきます。自分たちのチームのコードと，他のチームのコードが互いに影響し合っているためです。

　製品の機能を上げていくための要件自体が大規模化，複雑化していくのはやむをえないとしても，プロジェクトの参加人数が増えることで，おのおのが関連する人たちとの十分なコミュニケーションを維持できないとしたら，それは製品開発上，致命的な問題です。そこでグループ・マネジメントが重要になってきます。

　マイクロソフトの製品開発において，製品の機能改善や新技術導入と同じぐらい重要なのが，プロジェクト管理の効率化です。そのためには，新たな試みを導入するのもいといません。そのため，Visual Studioほどの規模の開発プロジェクトには，私が所属しているようなプロジェクト管理の専門チームが必ず編成されます。

　このチームはその主たる役割として，「開発スケジュールの作成」「それぞれの開発チームが日々生み出すソフトウエア・コンポーネントを“ソフトウエア製品”に統合する作業」「開発プロジェクト全体のリードと進ちょく管理」「ベータ版を含む製品の出荷プロセスの運営」——などがあります。どれも大変に重要な仕事ではありますが，中でも最もこのチームに期待されるのは，このような巨大なプロジェクトを1つにまとめ上げ，適切な方向に全体を導くための役割です。これはあたかも大編成のオーケストラから素晴らしい音楽を生み出す指揮者のような仕事かもしれません。