アジャイル計画|アイネット

　　ウォーターフォールでは、顧客の要求は、事前に詳細に明確になるという前提のもとに、時間をかけてスコープを詳細に定義し、それをベースにしてＷＢＳ（ワーク・ブレークダウン・ストラクチャ）を作り、スケジュール、コストなどの実行計画を詳細なプロジェクトマネジメント計画書として作り、それをもとに実行します。実行の際には、顧客の要求変更を統制し、計画したコスト、スケジュールを死守しようとします。しかし、この方法では、顧客価値実現のための要求変更が多く発生した場合、顧客価値の実現が不可となるリスクを持っており、過去多くの失敗プロジェクトが生じています。

　一方、アジャイルは、顧客の要求は事前にはすべての要求が詳細にならないこと、プロジェクト開始後も環境の変化や顧客の気づきなどで、要求は変更されることを前提にした反復漸進開発方法で、リリース計画、反復計画、毎日の計画の３つのレベルの計画を立てることにより、要求変更に対応して顧客価値実現を目指します。図１．はアジャイルプロセスを表します。

　

　リリース計画では、優先順位の高い要求から順次開発工数の見積をし、リスクや開発チームの能力（ベロシティ）などを考慮して、どの要求をどの反復サイクルで開発していくかを、リリース計画ミーティングで、概略計画として作成します。このミーティングでは、プロダクト・オーナー（顧客）が主管し、アジャイル・プロジェクト・マネジャー、開発チーム、その他の主なステークホルダーも参加して計画内容を決めます。

　次に、リリース計画に基づいて、当該反復サイクルの反復計画を反復計画ミーティングで、詳細計画として作ります。このミーティングでは、プロダクト・オーナー、アジャイル・プロジェクト・マネジャー、開発チーム、その他の主なステークホルダーが参加しますが、開発チームが自らの計画として当該反復サイクルに開発する要求を優先順位の高い要求からタスクに要素分解し、反復計画を作ります。開発チームは、自ら決定した反復計画をプロダクト・オーナーにコミットし、合意を取り付け、実行していきます。なお反復計画は、当該反復サイクルの詳細計画であり、実行の途中での変更はできませんが、要求変更が発生した場合、次以降の反復サイクルの反復計画で反映します。

　開発チームは反復計画をベースに、毎日１回、まずデイリー・スタンドアップといわれる15分以内の短いミーティングを実施したあと、設計・コーディング・テストなどの作業を実行していきます。このミーティングでは、開発チームの各メンバーが、昨日行ったこと、今日何をやるか（毎日の計画）、プロジェクト進捗上の課題の３つの内容を説明し、全員でこれらの情報を共有します。そして、当該反復サイクルの最終日には、顧客に対して完成した成果物のデモを行い、顧客のレビューを受け、要求変更があれば、次以降の反復サイクルの反復計画に反映し、要求変更に対応していきます。

　以上のようにアジャイル計画では、ウォーターフォールのように事前にすべて詳細な計画を立てるのではなく、まず概略計画としてリリース計画を作り、次に反復作業を開始する前にそれをベースに詳細な実行計画として反復計画を作ります。反復期間はタイムボックス化され、優先順位の高い要求変更がきたら低い優先順位の要求を外すという方法で対応して反復計画を作るため、スコープクリープを防ぐことができます。また、実行するタスクは、アジャイル・プロジェクト・マネジャーが決定してチームメンバーに割り当てるのでなく、開発チームが自ら決定するため、日々の仕事にやらされ感はなく高いモチベーションで仕事に取り組めることも、顧客価値実現への変更対応が可能なことに加えてアジャイルの大きな利点といえます。

以上