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

　今回は，プロジェクト管理のより具体的な事例を取り上げましょう。今夏（2004年8月），「Visual Studio 2005日本語版ベータ1」の提供が開始されました。このベータ版の開発がどう行われ，そしてどのような問題解決のプロセスを経て出荷に至ったのかという話を中心に，開発で実際に遭遇した問題や裏話に触れてみたいと思います。

イラスト：岡本 敏

　Visual Studio 2002と2003に続き，私たちのチームは現在2005年の製品出荷を目指して，Visual Studio 2005の開発を進めています。Visual Studio 2005ではさらなる開発効率の向上に役立つ数々の機能強化や言語仕様の追加を行います。加えて，製品ラインアップを見直して，プログラムの入門レベルの学習者や趣味のプログラマに向けた低価格製品や，アプリケーション開発サイクルの管理を大幅に向上させるツール群を含んだ企業向け製品などを用意することで，より目的に合わせて製品を選択していただけるようにする予定です。また，SQL Server 2000の次期版であるSQL Server 2005との高度な統合を実現しており，ハイエンドなシステムでのソフトウエア開発環境の効率化，パフォーマンスの向上という点で大いに期待していただけるものとなるでしょう。

　私たちは，お客様にとってより価値の高い製品作りを念頭に置いて日々努力を続けています。一方で，このように多くの機能と多様な製品構成を持つプロジェクトを管理して無事に出荷するためには，それ相応の様々な困難が伴います。これは，大規模なソフトウエア開発を経験された方でないと，なかなか想像していただけないことだと思います。ここでは，Visual Studio 2005日本語版ベータ1が，どんなプロジェクト管理の下でプランされ，そしてどのような問題解決のプロセスを経て出荷へ至ったのかをお話したいと思います。

日本語版はローカライズ版の開発におけるパイロット
　今回出荷したベータ1は，Visual Studio 2005の日本語版としては初めての公式なメジャー・マイルストーン・リリースとなります。

　マイクロソフトでは，新しい製品開発プロジェクトが発足すると，通常まず英語版の最終的な製品出荷までのスケジュールがプランされ，その中でアルファ版やベータ版を含むいくつかのメジャー・マイルストーンが設定されます。そして，そこで設けられたマイルストーンを基準に日本語版やドイツ語版などの各ローカライズ版のスケジュールが決定されます。

　しかしながら，ローカライズ版の作成に当たっては，英語版とローカライズ版の両方に共通となるコアのモジュールや英語版自体の開発プラン，ソフトウエア製品としての規模，それにスケジュールや開発段階での品質——など，様々な状況を十分に考慮した上で実現の可能性を見極める必要があります。ローカライズ版をすべて並行して同時に開発する方法は，リソースの有効活用やコストなどの点においてもあまり得策とはいえません。

△　図をクリックすると拡大されます 図1●Visual Studioの場合，日本語版にローカライズ版の開発におけるパイロットの役割を持たせる

　そこで，Visual Studioの場合，日本語版にローカライズ版の開発におけるパイロットの役割を持たせます（図1）。つまり，英語版の開発スケジュールと同期させながら，すべてのローカライズ版の先駆者としてまず日本語版を出荷するのです。そして日本語版の開発から得られたノウハウを生かして，次のメジャー・マイルストーンでその他の各国版（例えば，中国語版やドイツ語版など）の出荷を目指すという手法を取り入れています。

　また，Visual Studioの国際化対応を行う機能の品質に関しても本格的に検証が行われ始めるのはこのベータ1からです。そういう意味でも今回出荷された日本語版ベータ1は，単なるVisual Studio 2005の日本語版であるという位置付けにとどまらず，すべてのローカライズ版のためのパイロット版としての重要な役割を担っています。

日本語ベータ版として何を出荷すべきか徹底議論
　こうしてベータ1としての日本語版の開発が決まると，次に英語版ベータ1でプランされる製品構成のうち，どれを日本語版として出荷すべきか？ということに関して話し合いが行われます。もちろん，Visual Studio 2005の日本語版を，いち早くお客様に評価して多くの貴重なご意見をいただけるように，英語版ベータと全く同じ製品構成で出荷できればベストです。ただし，コア・モジュールや英語版自体の開発スケジュールの遅れなどがあり得ます。そこで，この要因を考慮しつつ日本語版ベータ1として出荷する価値があり，かつ全体として最適な製品構成は何かという点について議論を重ねます。

　この時期に話し合われるもう1つ重要な点は，日本語版ベータ製品として出荷が決まったものに対して，ユーザー・インターフェースやエラー・メッセージ，テンプレートやコマンド・ライン・ツールなどのローカライズの到達レベルに対してどんな優先付けを行うか？ということです。

　たとえメジャー・マイルストーンでのローカライズの目標を100％に設定したとしても，開発途中で予測不可能な問題が発生し得ることが予想されるため，その影響を可能な限り少なくできるようにするのです。あらかじめローカライズの到達レベルの目標をユーザー・インターフェースやエラー・メッセージなどの切り口から適切に設定しておくことで，問題が発生時点で解決のための議論に無駄な時間を費やさずに済むというメリットを考慮しています。

　本来であればメジャー・マイルストーンでのローカライズを100％のレベルで行えればよいのですが，規模の大きなプロジェクトにおいて，完璧なリスク管理を行うことは，やはり限界もあります。そこで私たちは各メジャー・マイルストーンでの集大成として，可能な限りベストに近い日本語版を出荷できるようにプランしながら，日々開発作業を行っています。

　以上が，Visual Studio 2005の日本語版ベータ1として出荷すべき製品構成を決定するためのプロセスになります。

RPMが米国本社側と密接な連携を取りプロジェクトを管理
　次にプロジェクト管理を適切に運営し，製品を無事に出荷するため，私たちが最も重要と考える「米Microsoft本社と日本にそれぞれ分かれて席をおく開発チームが，どのように連携してプロジェクトを進めているか」という点についてお話ししたいと思います。

　現在，Visual Studio 2005日本語版の開発チームは，Visual Studioの機能の核（コア）となるモジュールの開発を受け持つ技術者，ソフトウエア・ユーザー・インターフェースやヘルプ・ドキュメントのローカライズの作業を受け持つ技術者，ソース・コードや翻訳されたリソースなどから実際のセットアップ可能なビルドの生成作業を受け持つ技術者，日本語版のテスト作業を受け持つ技術者（QA），そしてプロジェクト管理を受け持つリリース・プログラム・マネージャ（RPM）——というメンバーで構成されています。地理的優位性を生かして適切に作業を分担し，効率的に開発を進められるように日本と米国のオフィスそれぞれにメンバーが分かれて配置されています。

　そして，日本側でプロジェクト管理を受け持っている私たちRPMは，特に本社側のRPMと密接な連携を取ることによって，日本語版がプランされるところから最終的な製品出荷に至るまでの全体的なプロジェクトの流れを管理しています。

　もちろん，開発中に発生する様々な問題点は少しでも早く解決する必要があり，それには日本側の開発やマーケティング，サポートのメンバー，そして本社側の様々なチームのメンバーとの連携が必須です。とはいえ，製品の開発や出荷スケジュールに大きな影響を及ぼしかねない問題の情報をいち早く共有し，プロジェクト全体として取るアクションを早期に決定するには，本社側のRPMといかに適切に連携を行えるかがプロジェクトの成功にとって非常に重要です。

　今回のベータ1のような1つのメジャー・マイルストーンでの日本側のRPMの役割は，通常次のようなものです。

　まず，プロジェクトの前半から中盤にかけては日本のオフィスで進み具合を注意深く見守りながら，製品のプランニングや問題が発生した場合の早期解決を行うことが中心です。そのため，本社側のRPMやその他の必要なメンバーとは電子メールや電話会議を通しての話し合いが多くなります。

　終盤ではこの様相が変わります。実際のところ，日本とアメリカとの間の時差が問題解決のターンアラウンド・タイムに大きく影響することは紛れもない事実です。またVisual Studioのように規模が大きいと，RPMがカバーすべき範囲は非常に多岐にわたります。そのため，マイルストーンの終盤（エンド・ゲーム）の時期になると，私たちは可能な限りリアルタイムに問題解決を行えるように，日本から米本社へ数週間から1カ月間ほど出張し，本社側の開発チーム・メンバーとさらに密に連携して作業を行います。