連載
» 2007年07月24日 12時00分 公開

The Rational Edge:ビルドが全滅する原因/プロジェクトの状態を評価する:パート2(後編)

ビルドの健全性は、プロジェクトのほかの多くの問題を示唆することが多い。チームが安定したビルドを作成できないと、適切な進展が不可能になる。壊れたビルドは、ほかにも致命的な問題が潜んでいることを示す場合が多く、チームのスキル不足であったり、脆弱(ぜいじゃく)なアーキテクチャであったり、作業の分割がうまくできていないこともある(本文から)。

[Kurt Bittner,IBM新技術プログラムディレクター]

構築フェイズにおける評価

 構築フェイズ最大の焦点は、「方向付け」フェイズで概略を用意し、推敲フェイズで「設計」したソリューションの構築をすることだ。要件が残っていればすべて特定し、ソリューションの開発とテストを行っていく。フェイズの最後までには運用可能なシステムができているが、最後にある程度の仕上げが必要な場合もある。

 推敲フェイズで行った評価に加え、以下のような新しい評価値がいくつか加わる。

  • バックログの増加もしくは減少
  • テストの対応範囲
  • ビルドの安定性

プロジェクトのバックログの評価

ALT 本記事は、IBM developerWorksからアットマーク・アイティが許諾を得て翻訳、転載したものです。

 プロジェクトのバックログには、現在取り組んでいないものすべてが含まれる。新たに必要なことが特定されるたびにバックログは増えていき、それらがインプリメントされ、テストされれば減っていく。構築フェイズが来てもその増え方が極めて大きい場合は、何らかの間違いがあることになる。構築フェイズの最後までには、すべてのシナリオを実装し、テストしておく必要がある。つまり、バックログはそのフェイズ全体を通じて減少し、そのフェイズが終わるまでにはゼロ(もしくはそれに非常に近い数字)になる必要がある。

 バックログは、その項目の一部については今後のリリースで実装することにして処理できる。つまり、既存プロジェクトのバックログからは削除し、今後リリースする方のバックログに入れる。それには、利害関係者と何度も話し合う必要がある場合も多いが、これはバックログの管理には通常絶対不可欠だ。

テスト範囲の評価

  進展の評価に関する先の説明では、テストが成功して初めて作業は完成と見なされるという概念が暗示されていた。進展の基準として推奨されるのは完成したシナリオだ。主に人員配備の問題から、完了したすべての作業を徹底的にテストすることは場合によっては難しい。そうなると、評価では以下の2つが問題として見えてくる。1)「テストのバックログ」のようなものがあるため進展が期待値以下で、2)テスト範囲が必要な速さで拡大できない。

 一部のプロジェクトチームは、担当開発者が作業を完了した時点でシナリオを完成と見なす間違いを犯す。このようにすることは、次の複数の理由から誤りである。1)プロジェクトの進展を膨脹し、実際はテストではじかれて改訂が必要であるにもかかわらず、完成と見なしてしまう。2)テストを完成させるために必要な人員がプロジェクトに適切に配備されていない事実を隠してしまう。

 作業を進めながら、単体テストだけでなくシナリオ全体のテストも進める必要がある。進化するソリューションをユーザーにテストしてもらえればなお良い。そこから入手するフィードバックは、極めて貴重なものになる。何かが完成したかどうかを知る手段は、実際のところテストしかない。さらに、テストは完了させる必要のあるものも必ず明らかにするため、テストスケジュールについていけないことはスケジュールの遅れを意味する。テスト結果を評価しながら、進行中の作業品質にも気を配る必要がある。失敗するテストは、思ったほど進展がないことを示唆している。

 進展の評価が絶対に誇張でないようにするためには、テスト範囲を常に把握しておく。これは、完成したすべてのシナリオを100%カバーする必要がある。もしこの範囲にギャップが生じつつある場合は、できる限り早急にこれをゼロに減らす計画的な素早い行動を取る必要がある。

ビルドの安定性の評価

 「ビルド」は、ソリューションのコードをコンパイルし、リンクして実行イメージにしたシステムの成果物だ。効果的なビルドプロセスには、ビルドを自動テストして正しい動作を確認することも含まれる。ビルドと自動テストプロセスの結果は、プロジェクトの健全性を有益に評価するものとなる。

 図7は日別のビルドプロセス結果を示している。

ALT 図7 ビルドステータスの時系列変化(クリックすると拡大

 図7はビルドの完成率および自動テスト合格率を日別で示している。このグラフは、大半の日でビルドが100%成功している一方、ビルドが全滅した日も多く、期間の最後の方では結果がかなり不安定のようだ。これは、チームの多くのメンバーに影響する変更が加えられ、その変更があまりうまく伝わらなかったことを示唆している。これは、まだこの先に問題が潜んでいる可能性を示しており、調査が必要だ。

 ビルドの健全性は、プロジェクトのほかの多くの問題を示唆することが多い。チームが安定したビルドを作成できないと、適切な進展が不可能になる。壊れたビルドは、ほかにも致命的な問題が潜んでいることを示す場合が多く、チームのスキル不足であったり、脆弱(ぜいじゃく)なアーキテクチャであったり、作業の分割がうまくできていないこともある。反復作業中は頻繁にビルドを作成しており、実際に反復作業をしていればビルドも継続的に作成できる。

 継続的なビルドと自動テストプロセスの評価は、プロジェクト全体の進展や健全性に関する貴重な実態を見せてくれる。継続的なビルドプロセスがあれば、テスト対象となる重要な変更があった場合はいつでもビルドすることができ、進展を評価するためのデータを多数入手できる。典型的な4〜6週間の反復期間では、数百のビルドと自動テストが繰り返され、進展と健全性を評価する豊富なデータが提供される。

再度の進展評価

 上述のように、計画された作業はすべて構築フェイズの最後までに完成させる必要がある。プロジェクトの最後となる次のフェイズ、「移行」フェイズでは、本番環境へのソリューション導入に重点を置く。「移行」フェイズをバックログへの対応を継続するための「整理」フェイズにしてはならない。アプリケーションの導入ではやらなくてはならないことがたくさんあり、シナリオの実装を継続するための時間はない。

 構築フェイズで解決しなくてはならない大きな問題の1つが、「フェイズの最後までに必要な作業を全部終わらせることはできるのか?」というものだ。チームの生産性を評価することは重要だ。チームの生産性を定期的に評価するとともに、残りのバックログを評価してそれをゼロまで減らせるかどうか判断する必要がある。主観的だが便利な評価方法が、プロジェクトチームの「速度」だ。これは、開発チームの生産性を測定する手段をうまく言い表したもので、一定時間にどれだけの作業を達成できるかという意味だ。速度は、進展を示す曲線の変化の度合い、もしくはバックログの増減の度合いと考えることもできる。バックログの増減を見れば、チームの生産性を予測し、フェイズの最後までにバックログをゼロに減らせるかどうか予測を立てることができる。もしそれが不可能だと選択肢は限られる。フェイズの期間を延長するか、バックログの範囲を減らす方向で交渉するのだ。


 推敲と構築の両フェイズは、いずれも実行イメージコードの作成に重点を置く点で似通っている。両フェイズの違いは、技術的なリスクとアーキテクチャの問題に対する重点の置き具合にある。進める作業が似通っていることから、作業の管理に利用する評価値も似る傾向にあり、推敲フェイズでは技術的なリスクの方に重点が置かれる。

 構築フェイズまでには技術的なリスクが効果的に緩和され、主な重点は「このフェイズの最後までにすべての作業を完了できるか?」という疑問に置かれることになる。その結果、チームはテスト範囲、生産性、および進展を数値化するための基準に重点を置くことになる。構築フェイズの最後までには、バックログがゼロにまで縮小され、ソリューションが機能的に完成し、初期リリース候補が完成しているはずだ。

 このシリーズの最後となる次回は、ソリューションのリリースに向けた準備に重点を置く「移行」フェイズの評価値について解説する。また、複数のプロジェクトやプログラムで構成されたポートフォリオ管理など、複数のプロジェクトによって構成されるプログラム全体を通じた評価の問題にも目を向ける。

【参考文献】 本稿は「Managing Iterative Software Development Projects」(Kurt BittnerおよびIan Spence共著、2006年Addison-Wesley刊)に当初掲載された資料からの抜粋。


本記事は「The Rational Edge」に掲載された「Measuring Project Health -- Part II」をアットマーク・アイティが翻訳したものです。


「The Rational Edge」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ