禁断の「仕様の変更」 とにかくこの時期は,バグ件数のグラフの推移がプロジェクトの進行の大半の部分を語っているといえます。日々1件でも多くバグを解決して,バグ0件を目指すのが最優先事項です。繰り返しになりますが,バグの修正とその確認のためには,新しいビルドを日々出し続けることが絶対条件となります。
「バグをクリアする」とは 私は,エンド・ゲームは「飛行機の着陸」と共通点が多いと思っています。飛行機の場合も,もう飛行場はそこに見えているのだから,着陸は簡単なように思えます。実はパイロットにとって離着陸の瞬間が一番難しい——と聞いたことがあります。プロジェクトのエンド・ゲームにも同様のことが言えます。どちらも「動から静」へ物事を強制的に切り替えていかなければいけませんから,細心の注意が必要なのは同じです。 本格的にエンド・ゲームに突入する前に,まずやっておかなければいけないことがあります。それは,データベース上のバグ件数を十分なレベルまで減らすことです。飛行機も安定した着陸を得るためには,最もよい方角と角度で滑走路に入る必要があります。そのためには不安要素は極力排除する必要があります。 Visual Studioプロジェクトの工夫としては,ある日を境に「過去2日内に登録されたバグ以外はすべてクリアする」というルールがあります。これを超えると,やっとバグの総数が落ち着いた感触を得られます。その日まではとにかくバグを1件でも減らすことが,最優先事項となります。
「本流ビルド」と「ベータ・ビルド」に分ける このような体制にする理由は,「ベータには必要だが,ベータが終わったら不要なコード」があるからです。エンド・ゲームでは,出荷が最優先になるため,ベータの場合は特定の問題に対して一時的な回避コードを埋め込むことがあります。「本流ビルド」と分けておくことにより,安全にソース・コードを管理できます。また,ベータの作業と並行して,本流ビルドを使い,次のメジャー・マイルストーンのための作業を並行して行えます。 場合によっては,ビルドを分けたあとに「ベータ・ビルド」と「本流ビルド」の両方にコード修正をしなければならないこともあります。そのときは両方のビルドに同じコードを入れます。これはビルドを分けたことによる副作用で,2重作業となってしまいます。そのような期間を不必要に長く取っては,効率が落ちますので,状況から期間を見極めます。 プロジェクトがエンド・ゲームに入ると,この時点でビルドの品質はかなり安定してきているはずです。そうなるとエンド・ゲームの最重要課題は,その「安定を維持しつつ残った問題を速やかに解決する」ということになります。ですから,この時期のプロジェクト管理はかなり物事を保守的に考えるように切り替わらなければいけません。 もし,この時期にだれかのひらめきがあって,画期的な機能を思いついたとしても,絶対にその実装は許可されません。コードに大きな変更を入れることにより,製品の安定性が損なわれるからです。少しでも製品の安定性に影響が出ると,確実に出荷の遅れにつながります。ビルド内の変更は,本当に必要な重大な問題に絞られ,かつ変更量が最小限ですむように少しずつ制限されていきます。
ビルドの変更点を毎日の全体会議で共有 発表内容は,その日ビルドに加えた変更,つまりバグ修正済みの項目についてです。バグ・データベースを基に各チームが順次発表します。発表を聞いているチームは,その変更が自分のチームへ影響がないかを考えています。その場で質疑応答も行われます。
バグ修正にも認承が必要になる 承認の判断基準は,基本的に変わりませんが,より厳しくなります。また,バグ修正の候補を持ち込む人は,あらかじめ自分で「プライベート・ビルド」と言うものを作成して,自分が入れようとしているコードが基本的に問題を引き起こさないことを実機動作で確認する義務があります。この時期になると,承認される修正バグは1日およそ数件にまで絞り込まれます。
しかし,Visual Studioは巨大な製品ですから,この時期になってはじめて,スケジュールに影響を与えそうな重大な問題が発覚することもあります。その場合は「スケジュールを遅らせても修正コードを入れるか」「涙を飲んでその部分の修正をあきらめ,予定通りの出荷を目指すか」の決断をしなければいけません。そのための準備として, まずは回避策の確認をします。特にベータ版出荷の場合は,回避策があればそれをリリース・ノート(readme.htm)に記載することで,コード修正不要と判断することがあります。そうでない場合は,次に修正候補コードの実機確認をして,修正作業に必要な技術的問題をクリアにしておきます。さらに,現状でそのバグが,視覚的なエラーを起こすか,他機能へ影響があるか,それともエラー表示もなく単にその機能が使えなくなっただけなのか——などを判断材料にします。もちろん,その機能自体の重要性も考えなければいけません。ただし,Visual Studioのようなプロジェクトには,それぞれ個人的な思い入れもあり,冷静な判断が難しいこともしばしばです。 それでも「安全に着陸すること」が最優先には違いありません。多少飛行機の翼が揺れても着陸した方が,よい結果的になる場合もあるでしょう。予定到着地に何らかのトラブルが発生して着陸できないときは,やむを得ず予定を変更して他の着陸地を探さざるを得ない場合もあるでしょう。 これはプロジェクト管理責任者にも,ほぼ同様のことがいえます。すなわち,スケジュールを可能な限り守りつつ,製品の品質が顧客の要求するレベルに達しているかを総合的に判断し,出荷を決定するということです。それは顧客に対して,最終的な品質管理の責任を持つということでもあります。もちろん,そこに至るまでには,品質管理についてはテスト担当者の貢献によるところが大きいわけですが,最後の判断はプロジェクト管理責任者の仕事です。 最終的にリリース候補版ビルドが出ると,テスト担当者がすべてのテストをします。そして出荷基準を満たしていることが確認できたら,ようやく全員の合意の下,プロジェクト管理責任者が,ビルドの出荷を決断します。そうなると,マスターCDは製造工程に回され,同時にMSDN(マイクロソフト・デベロッパー・ネットワーク)会員向けのWebダウンロードの担当者に送られます。
メジャー・マイルストーンごとに反省会を開く 「ここは目論見通りうまくいったから,継続しよう」とか,「あそこは予想に対して期待した効果が得られなかったので,別のプランを考えよう」,または「結果として問題はあったが,基本的なアイディアに間違いはなかったことが確認できたので,現状を踏襲しつつ反省点を改善しよう」——などというように,それらを次のメジャー・マイルストーンのためのアクション・プランに落とし込みます。 ここで重要なのは,反省会は個人の責任追及の場ではないということです。もしそうなると,皆思っていることが言えなくなり,反省会をする意味が失われてしまいます。この場では,例え自分自身が関与する問題であっても,冷静に客観的に意見として述べる態度が望まれます。
最後に 次回は「Visual Studioにおけるソフトウエア・ローカライズ手法の概要」についてご紹介する予定です。 |
Visual Studioの開発現場から(第5回)p3
あなたにお薦め
注目のイベント
日経クロステック Special
What's New
経営
- 平等より特別の方がビジネスに有利な理由は
- 「データのサイロ化」の原因とその解決法
- ものづくりと経営をデータでつなぐ試みとは
- 深い業務理解で顧客を支援≫キヤノンMJ
- 全方位DXを推進する意義。カバー範囲は
- DXを内製で実現する「3ステップ」
- 中小企業がDXで効果を上げるには?
- 企業をまたいでERPを連携? 何が起こる
- 製造業DXを成功に導くための3つの勘所
- 少量の学習データでもAI活用が可能に!?
- コロナ禍のデジタル活用=DXではない理由
- 経営層に求められるDXの船“進水”のコツ
- 富士通と日本IBMがローカル5Gで協業
- つなぐポイントシステムが地域を盛り上げる
- DX先進企業は何を考えているか?
- “音の出る歯ブラシ”はなぜ生まれた?
- IT人財の真価を発揮する人を軸とした戦略
- 顧客の再来店と常連化を実現した施策を探る
- IBM、ビジネスパートナー14社を表彰