実は、チームメンバーのパフォーマンスを下げる原因は割り込み作業である。ウォーターフォールでは基本的には仕様変更を想定しておらず、それに対応するための仕組みもない。よって、変更が発生すると、イレギュラー対応になる。本来の作業と並行して対応することになるため、当然のことながらメンバーのパフォーマンスは落ちる。
変更が多いようだと頻繁に発生すると計画のズレが大きくなり、スケジュールを見直すことになる。スケジュールを立て直すのは簡単ではない。変更管理も非常に複雑なものになる。仕様変更による影響を調査して、現在進めている作業と整合を取りながら変更を取り入れることになる。だからこそウォーターフォールにおいて仕様変更は忌み嫌われている。
- TechRepublic Japan関連記事：ハイブリッドクラウド座談会
- 企業ITの行き先を徹底討論する
- エンタープライズ×AWSをさまざまな視点で議論
- SDNやDockerは何を変えるのか
- アーキテクチャを理解しておく必要がある
- IT部門に求められるスキルが変化している
これはウォーターフォールとアジャイルの最大の違いだ。ウォーターフォールはプロジェクトが計画通りに進むことを重視する。一方、アジャイル開発は計画通りにプロジェクトを運営することよりも、開発チームのパフォーマンスを最大化することを重視する。そうすれば得られるバリューも最大にできると考えるからだ。
TOC（Theory Of Constraints）、あるいは制約条件の理論という言葉をご存じだろうか。アウトプットの制約条件を明らかにし、それを緩和することでスループットを最大化するという考え方である。
システム開発では開発チームのパフォーマンスが制約条件となる。アジャイル開発は制約条件である開発チームのパフォーマンスを最大化するものだと言える。それを可能にするのがタイムボックスの本質的な価値といっても過言ではない。
ところでシステム開発の制約条件は開発チームのパフォーマンスだけではなく、もう1つある。それは要件定義である。要件定義がボトルネックになってプロジェクト全体が進捗しないことは珍しくない。次回は「要件定義の扱い」としてこの問題を解説する。
- 吉原庄三郎（よしはら・しょうざぶろう）
- ウルシステムズ 主席コンサルタント、アジャイル推進室
- ウルシステムズでITグランドデザイン、プログラムマネジメント、開発運用プロセスデザイン、上流工程のコンサルティングを提供している。
- 著書に「はじめての設計をやり抜くための本」（翔泳社）がある。
- 若井雅裕（わかい・まさひろ）
- ウルシステムズ シニアコンサルタント、アジャイル推進室
- ウルシステムズで、クライアントの視点、立場に沿ったプロジェクトマネジメントや上流工程のコンサルティングを提供している。
- また、アジャイル推進室の活動を通じて、日々アジャイルの研究と実践に取り組んでいる。
