開発の終盤に入る直前に何が何でも未解決バグをいったんゼロに エンド・ゲームの期間に入ると新たに発生した問題は，個人やおのおのの開発チームの判断だけで勝手に解決することは許されません。特に重大な問題に関しては各チームの代表者を中心としたメンバーで構成されるミーティングの場で，一つひとつその重大性や優先性に応じた解決策が話し合われます。 ところで，エンド・ゲームで新たに見つかった問題点を一つひとつ注意深く吟味するということは，逆にいえばそれだけ多くの時間やコストが消費されることになります。もし，この時期にバグ件数が右肩上がりに伸びていくことがあるとエンド・ゲームとして全く意味をなさなくなります。 マイクロソフトの開発プロセスの中では，エンド・ゲームに入る直前に何が何でも未解決バグ件数をいったんゼロにするというマイルストーンが設定されることについては先ほどお話をしました。実は，これはエンド・ゲームの中で一つひとつのバグに対して十分に話し合いの時間を持つことができるように，エンド・ゲームに入る直前までに製品の品質をある一定のレベルに到達させ，安定化を図ることを最大の目的としています。 ですので，エンド・ゲームでの議論を適切なものとし，安定した品質の製品をスケジュール通りに出荷するためには，「未解決バグ件数ゼロ」というマイルストーンをきちんと乗り越えることが私たちの製品開発においてとても大きな意味を持つと言えます。 もちろん，メジャー・マイルストーンとはいえ，開発の途中で未解決バグ件数をいったんゼロにできるものなのか？と思われる方もいらっしゃるかと思います。確かに，この期間デベロッパー（Dev）は，自分に割り当てられた山のような問題を解決するために，毎日必死でそれに取り組みます。一方，QAチームによるテストも容赦なく続けられるので，当然品質がある程度安定するまで，未解決バグ発生件数の収束率は低い状態が続きます。 しかし，未解決バグ件数ゼロの目標時期に近づくほど，Devは毎日毎晩エンジン全開でバグを解決し続け，やがて未解決バグの発生件数が大きく収束し始めます。そして，そのころを目安に，Devに最後のチャンスとなる「48時間」という時間が与えられるのです。その時間に発見された未解決バグに関しては，未解決バグ件数ゼロというマイルストーンの中ではカウントされず，すべてエンド・ゲームへ持ち越されます。このようなルールが決められているので，Devは最後の48時間にラスト・スパートをかけて，残ったバグをすべてつぶしにかかります。このとてもハードでエキサイティングな時間を経て，ようやく未解決バグ件数ゼロの日を迎えられるというわけです。
終盤では本社側と同じ目的のミーティングを定期的に開催 一方，日本のオフィスにいる開発チームでも本社側と歩調を合わせて同じ目的を持ったミーティングが定期的に開催されました。ここで日本とアメリカの時差が影響してきます。本来はあらかじめ出席者全員がその日に話し合われる問題を把握した上で同じ時間帯に電話会議やビデオ会議を行うというのが理想です。しかし，時差のため，本社メンバーと毎日いっしょにミーティングを行うのが難しく，日本にいるメンバーだけで行われました。
ここで大切だった点があります。1つは本社と日本とでそれぞれが同じ問題を議論できるように，バグを管理するシステムからその日に話し合うべき問題を抽出する共通のクエリーを用意したことでした。もう1つは，米本社のミーティングで話されたことを日本のミーティングに生かせるようにしつつ，逆に日本のミーティングで話されたことを次の日の本社のミーティングで生かせるように，私がそのパイプ役を努めることでした（ 図3）。 本社での私の作業は次のようなものでした。日中は本社のメンバーと個々に問題解決のための作業を行い，夕方ころから各チームの代表者を中心とした全体でのミーティングに参加します。さらに日本の開発チームのメンバーとの電話や電子メールによるやりとりが深夜の2時過ぎころまで続きました。このようなサイクルの繰り返しでしたので，体力的にも精神的にもかなりハードでした。 とはいえ，このとき得られた私の経験は貴重でした。パイプ役として必要な情報を適切なタイミングで双方のチームに伝えるには，製品の仕様に対する（たとえ浅くても）広範な知識が必要ですし，もちろん問題の本質をちゃんと理解することが大切です。加えて本社とのコミュニケーションはすべて英語（しかもいろいろな国のなまりが入った英語）なので，必要な情報を得ることも伝えることも，常に工夫と努力と熱意を持つことがとても重要であると実感しました。
プラン段階で顕在化しにくかった問題が後で表面化 そうしたこともあり，プラン中心の作業を行っていたマイルストーンの前半では顕在化しにくかった問題が，後で表面化するという局面もありました。後半で日本語版開発のための実作業が本格化し，終盤になって安定してきた日本語ビルドが社内のより多くの人たちによってテストされるようになったことがきっかけです。 問題にはそもそもの開発プランや仕様の曖昧（あいまい）さに起因するものも多く，特にエンド・ゲームで見つかった問題のいくつかは出荷スケジュールに大きく影響を及ぼしかねない状況でした。 例えば，日本語ベータ1としてお客様に評価していただくための重要な新機能に，致命的な不具合が生じたものがあります。開発段階でのビルドの品質の向上のために行われたシステムの大幅な変更によって，日本語版ベータ1のコンポーネントとしてビルドを継続するのが非常に困難になったものもありました。 このように日本語版の出荷に影響を与えるような重大な問題は，米本社のミーティングで話し合われるだけでは適切な解決策があまり見つかりません。そんなときは，パイプ役の私が問題を預かってその日の夜の間（日本の昼間）に日本の開発チームやマーケティング，サポートのメンバーと大急ぎで話し合いを持ちます。そこで日本語ベータ1のあるべき姿に照らし合わせて，可能な限り適切な解決策を導き出し，その翌日の本社でのミーティングで合意が得られた後，その問題に対する相応の修正や変更が加えられるというサイクルで日々問題解決が行われました。 こうして，英語版ベータ1の公開から大幅に遅れることなく，私たちは今年の夏にVisual Studio 2005日本語ベータ1を何とか無事に出荷することができました。
終わりに 私たちRPMには，ベータ版出荷の後もそれをお客様に評価していただいてご意見をいただき，次のマイルストーンや最終製品，そして将来の製品へとつなげて行くためのベータ・プログラムの運営という重要な仕事があります。紙面の都合上，今回はそこまで触れておりません。またいつかこのような場でお話できればと思います。 Visual Studio 2005では，これまでの製品ラインに加えて，ソフトウエア開発という舞台でより気軽にVisual Studioを体感していただくためにExpress製品（VB，VC#，VC++，VJ#，VWD）の開発も行われており，現在ベータ1がマイクロソフトのWebサイト（該当サイト）からダウンロード可能です。なにぶんベータ製品のため，完成度という点からは期待されるレベルに到達できていませんが，Visual Studioを通してまずは身近な小さなソフトウエアによって，ものづくりの楽しさを少しでも体験していただけたら幸いです。 次回は「Visual Studio 2005 Team Systemによる新しい開発スタイル」についてご紹介する予定です。 |
◆会社紹介◆
|
「マイクロソフト プロダクト ディベロップメント リミテッド」は，日本のマイクロソフトの中で研究開発を担当する会社。日本のマイクロソフトの組織は，2つの会社で成り立っており，ほかにマーケティング，製品の流通，サポート業務を担当している「マイクロソフト株式会社」がある。
