ガイドライン: Wideband Delphi 手法を使用した作業量の見積もり
Karl Wiegers (www.processimpact.com) による RUP への寄稿、Software Development Magazine の許可を得て転載。Rational Software Corporation によって編集されています。
トピック
概論
このガイドラインでは、ソフトウェア開発作業量の見積もりに使用できる手法について説明します。
Wideband Delphi 見積もり方式は、以下のように要約できます。
- 複数の専門家から成るチームを選抜し、見積もり対象となる問題の記述をそれぞれの専門家に提供します。
- それぞれの専門家に対して、作業量の見積もりを (多くの場合は匿名で) 提供するように依頼します。
この見積もりには、問題を細分化したタスクのリストや各タスクの作業量見積もりが含まれます。
- 専門家は、共同作業を通じてそれぞれの見積もりを繰り返し改訂することにより、最終的に合意に到達します。
Wideband Delphi 方式を使用すると、1 人の個人から見積もりを取得する場合と比較していくつかの利点があります。
最初に、主要なアクティビティーの完全なタスク・リストや作業分解構造を作成するのに役立ちます。
これは、各参加者がタスクのことを考えるからです。
自称専門家や経験の浅い見積もり担当者が見積もりを作成したり、
影響力の大きい個人が明示されていない課題や本来の目的とは無関係な意図に基づいて見積もりを作成したりすることがあります。
合意によるアプローチは、このような見積もりの偏りを排除するのに役立ちます。
多くの人は、他人が作成した見積もりに対してよりも、自分が作成に参加した見積もりに対してより熱心に取り組む傾向があります。
見積もりアクティビティーの参加者の中には「正しい」答えを知っている人はいません。
複数の見積もりを作成することにより、この不確実性を確認します。
最後に、Delphi アプローチのユーザーは、複雑なアクティビティーで反復することの重要性を認識できます。
Wideband Delphi の適用
Wideband Delphi 方式は、ほとんどすべての見積もり対象に適用できます。
たとえば、ある特定のサブシステムの実装に必要な人月数、ある製品全体のコード行数またはクラス数、
Bill Gates の家の改装に必要なペンキのガロン数、ある特定の組織が能力成熟度モデルの
レベル 2 を達成するために必要な作業量などを見積もることができます。
Delphi 方式は、詳細な作業分解構造を作成するのに役立ちます。
詳細な作業分解構造は、ボトムアップでの作業やスケジュールまたはサイズの見積もりの基礎になります。
Delphi セッションの開始点は、開発構想書、見積もり対象の問題の詳細な要求仕様書
または初期の高レベルのアーキテクチャーの記述、プロジェクト・スケジュールなどです。
出力は、詳細なプロジェクト・アクティビティー・リスト、関連品質、プロセス関連、
オーバーヘッド・アクティビティーのリスト、見積もり仮定、アクティビティーおよびプロジェクト全体の見積もりのセットです。
各参加者から 1 つが提供されます。
図 1 は、Wideband Delphi セッションのプロセス・フローを示します。
計画中に、見積もり対象の問題が定義され、参加者が選抜されます。
キックオフ会議では、すべての見積もり担当者が問題に注目します。
次に、各参加者が自分の初期アクティビティー・リストおよび見積もりを個別に準備します。
各参加者は、これらのアイテムを見積もり会議に持参し、
何回かの見積もりサイクルを通じてより包括的なアクティビティー・リストと改訂された見積もりセットを作成します。
次に、収集された見積もり情報を司会者またはプロジェクト管理者がオフラインで整理し、
チームの参加者が見積もり結果をレビューします。
事前に決定された終了基準が満たされると、セッションは完了します。
多くの場合、作成された見積もりの範囲は、個々のどの見積もりよりも現実的な将来の予測になります。
これらのプロセス手順を 1 つずつ順番に見ていきましょう。
Wideband Delphi セッションを計画するときには、問題が定義され、参加者が選抜されます。
キックオフ会議では、すべての見積もり担当者が問題に注目します。
次に、各参加者が初期アクティビティー・リストおよび見積もりを個別に準備します。
見積もり会議では、何回かのサイクルを通じてより包括的なアクティビティー・リストと改訂された見積もりセットを作成します。
次に、情報がオフラインで整理され、チームの参加者が見積もり結果をレビューします。
終了基準が満たされると、セッションは完了します。
計画 
Wideband Delphi セッションは、問題 (開発構想書、ユース・ケース・モデル、
既存のシステム、予備アーキテクチャー) の定義と範囲決定から開始されます。
大きな問題は、より正確に見積もりできるように、管理しやすい複数の部分に分解されます。
各部分を別々のチームが見積もりすることもあります。
見積もりアクティビティーを開始した個人は、
各参加者が十分な情報に基づいて信頼性の高い見積もりを作成できるように、問題仕様書を編成します。
見積もりの参加者には、アクティビティーを計画および調整する司会者、
プロジェクト管理者、2 人から 4 人のほかの見積もり担当者が含まれます。
司会者は、1 人の見積もり担当者として参加できるように十分な情報を得ている必要があります。
しかし、司会者は公平な進行役として振る舞うことを心がけ、
自分の先入観や意見によって結果をゆがめることがないようにします。
問題またはプロジェクトおよびそれに関連する見積もり上の課題を理解している参加者を選抜します。
キックオフ
1 時間以内の初期キックオフ会議によって、すべての参加者に見積もり問題についての予備知識を提供します。
司会者は、Wideband Delphi に詳しくないチーム・メンバーがこの方式を理解できるように説明し、
その他の見積もり担当者に問題仕様書およびすべての仮定とプロジェクト制約を提示します。
司会者は、見積もり担当者が適切に作業できるように十分な情報を提供する一方で、
各自の見積もりに不当な影響を及ぼさないように努力します。
チームの参加者は、見積もりの目的をレビューし、問題およびすべての見積もり上の課題について議論します。
参加者は、使用する見積もり単位 (週、人時、ドル、コード行数など) を承認します。
十分な情報が提供され、すべてのチーム・メンバーが見積もりアクティビティーに
貢献できると司会者が判断した場合は、アクティビティーを開始できます。
上記の条件が整っていないと司会者が判断した場合は、
見積もり対象の問題について参加者により詳細に説明する必要があります。
より正確な見積もりを作成できるほかのメンバーと交代させることもあります。
Wideband Delphi セッションを進める準備ができているかどうかを判断するには、開始基準をチェックします。
開始基準とは、後続のプロセス手順に進むために満たす必要のある前提条件です。
実際の見積もりに取り組む前に、以下の条件が満たされていることを確認してください。
- 適切なチーム・メンバーが選抜された。
- キックオフ会議が開催された。
- 参加者が見積もりの目標と単位を承認した。
- プロジェクト管理者がセッションに参加できる。
- 見積もり担当者が効果的に参加するために必要な情報を持っている。
個別の準備
ある特定のプロジェクトを完了するために必要な作業の合計量 (通常は人時で表されます) を見積もるとします。
各参加者は、見積もりプロセスを個別に開始して、
規定されたプロジェクト目標を達成するために完了する必要のあるタスクの初期リストを作成します。
それには、図 2 に示すようなフォームを使用します。
次に、各参加者は、各タスクで消費される作業量を見積もります。
正確に見積もることができるように、各タスクを複数の小さなアクティビティーに分解します。
アクティビティーを明確に記述します。
これは、すべての参加者のアクティビティー・リストを 1 つの複合リストにマージする必要があるからです。
プロジェクト・タスクごとに作成した見積もりを承認済みの単位を使用して合計することにより、初期合計見積もりを作成します。
各参加者は、見積もりプロセスを個別に開始して、
規定されたプロジェクトを達成するために完了する必要のあるタスクの初期リストを作成します。
それには、このフォームを使用します。
各参加者の見積もりは、プロジェクト管理者またはほかの利害関係者がどのような回答を期待するかとは無関係です。
見積もり結果がスケジュール、作業量、コストの点でプロジェクトの許容可能範囲を超えたり、
交渉が必要な状況が生じたりすることがあります。
また、見積もり結果が範囲の縮小、スケジュールの延長、リソースの調整につながる可能性もあります。
しかし、各参加者が最善を尽くしてプロジェクトの進展を予測した結果が、
外部の圧力によって左右されないようにする必要があります。
プロジェクト・タスクの識別に加えて、
関連アクティビティーまたはサポート・アクティビティーのすべてのタスクを別個に記録します。
最初のサイクルで管理、構成管理、プロセス関連の各アクティビティーを処理するタスクもリストに加えてください。
テストまたは検査のアクティビティーに続く再作業アクティビティーもリストに加える必要があります。
障害を修正するための再作業は実際問題として必要なことなので、計画に含める必要があります。
スケジュールを見積もる場合は、プロジェクトに固有ではないが計画に組み込む必要のある
すべてのオーバーヘッド・アクティビティーも考慮してください。
これには、会議、休暇、トレーニング、ほかのプロジェクトの仕事など、
作業時間を消費するその他さまざまな事柄が含まれます。
基本的な仮定が異なっていると見積もりのばらつきが大きくなることがあるので、
見積もりを準備するときのすべての仮定内容を記録します。
たとえば、特定のコンポーネント・ライブラリーを購入すること
または以前のプロジェクトのコンポーネント・ライブラリーを再利用することを仮定した場合は、それを書き留めておきます。
別の見積もり担当者は、プロジェクト内でそのライブラリーを開発すると仮定する可能性があります。
その場合は、2 つの合計見積もりの間の不一致が発生します。
以下の見積もりガイドラインに留意してください。
- 1 人 (自分) ですべてのタスクを実行すると仮定する。
- すべてのタスクを順番に実行すると仮定する。この時点では、順序や先行タスクについては考慮しません。
- 各タスクの作業に中断なしで専念できると仮定する (これは楽観的すぎるように見えますが、
見積もりプロセスを単純化するためには役立ちます)。
- タスクとタスクの間に発生すると予想されるすべての既知の待ち時間を、所要日数単位で列挙する。
これは、後で作業量見積もりをスケジュール見積もりに変換するときに役立ちます。
見積もり会議 
見積もり会議の最初に、司会者は、参加者の個別見積もりを収集し、図 3 に示すようなチャートを作成します。
各参加者の合計プロジェクト見積もりは、「ラウンド 1」線上の X として示されます。
各見積もり担当者は、自分の初期値が見積もりの分布の中でどの位置にあるかを確認できます。
初期見積もりは、非常に広い範囲にわたって分散する可能性があります。
参加者のうちの 1 人のみに見積もりを依頼し、その結果を使用してプロジェクトを計画したとしたら、
それぞれの結論がどれほど異なるものになっていたかを想像してみてください。
見積もり会議の最初に、司会者は、参加者の個別見積もりを収集し、チャートを作成します。
各参加者の合計プロジェクト見積もりは、「ラウンド 1」線上の X として示されます。
初期見積もりは、非常に広い範囲にわたって分散する可能性があります。
組織によっては、それぞれの見積もりを誰が作成したかを司会者が特定しないことがあります。
その組織では、この匿名性が Delphi 手法の重要な側面の 1 つだと考えるからです。
匿名性が保証されると、積極的に発言する参加者が自分の見方をほかの参加者に押し付けることはできなくなります。
また、個々のチーム・メンバーの分析によって導かれた結論が異なっていた場合に、
最も尊重されている参加者の判断に同調してしまう可能性も低くなります。
しかし、これは必須の要件ではありません。
各見積もり担当者は、自分の初期タスク・リストを読み、すべての仮定を識別し、
すべての質問または課題を提起します。どれが自分の見積もりかは明らかにしません。
実行する必要のあるタスクのリストは、参加者ごとに異なっています。
これらの個別タスク・リストを組み合わせることにより、
どの 1 人の見積もり担当者が作成するリストよりも詳細なリストを作成できます。
このアプローチは、個別タスクが数十個以内の場合に有効です。
それ以上のタスクがある場合は、リストが詳細になり過ぎる可能性があります。
問題をいくつかの二次的な問題に分解して、それぞれを個別に評価できます。
この初期の議論の間に、チーム・メンバーは、問題に関する仮定、見積もり上の課題、質問についても話し合います。
その結果、チームの各メンバーの見積もりは、共有された仮定と共通のタスク・リストに基づいて徐々に収束していきます。
この最終タスク・リストを保管しておくと、類似したプロジェクトを次に見積もる必要がある場合の開始点として使用できます。
この初期の議論の後で、すべての参加者は、会議室内で自分の見積もりを並行して (黙って) 変更します。
議論中に共有した情報に基づいてタスク・リストを改訂することもあります。
また、タスク範囲についての新しい認識や仮定の変更に基づいて個別のタスク見積もりを調整します。
すべての見積もり担当者は、新しいタスクをフォームに追加でき、自分の初期タスク見積もりに対する変更を付記できます。
すべてのタスクに対する変更の総和は、その参加者の合計プロジェクト見積もりでの変更に等しくなります。
司会者は、改訂された合計見積もりを収集し、同じチャートの「ラウンド 2」線上に記入します。
見やすくするために、これをホワイトボード上に示すこともできます。
図 4 が示すように、ラウンド 2 では、ラウンド 1 の平均値よりも高い平均値を中心として、
見積もりの分布範囲がより狭くなる傾向があります。
ラウンドを繰り返すと、分布範囲はさらに狭くなります。
タスク・リストを改訂し、課題と仮定について議論し、新しい見積もりを準備するサイクルは、以下の状態に到達するまで継続します。
- 4 回のラウンドを完了した。
- 見積もりが (事前に定義された) 許容可能な範囲まで収束した。
- 割り当てられた見積もり会議の時間 (通常は 2 時間) が経過した。
- すべての参加者が自分の最新の見積もりを変更することを希望しない。
初期見積もりの議論の後で、すべての参加者は自分の見積もりを変更します。
司会者は、改訂された合計見積もりを収集し、同じチャートの「ラウンド 2」線上に記入します。
後のラウンドでは、ラウンド 1 の平均値よりも高い平均値を中心として、見積もりの分布範囲がより狭くなる傾向があります。
司会者は、散漫な議論が延々と続くことがないように時間を 15 分か 20 分に区切って、チームの議論を誘導します。
司会者は、効果的な会議進行の原則に従う必要があります。
たとえば、予定の時間どおりに開始および終了する、すべての参加者の積極的な関与を促す、
公平な雰囲気を維持して性急な判断は求めない、などの点を心がけます。
最初の数回のラウンドでは、個別見積もりの匿名性を維持することが重要です。
しかし、ある時点を過ぎると、すべての情報を公表して最終結論に向けた議論を公開の形で行うことに
チーム・メンバーが同意する場合もあります。
こうすると、見積もりに大きなばらつきのあるタスクについて議論しやすくなります。
しかし、上記のような場合を除いて、司会者はセッションが完了するまで
それぞれの最終見積もりを作成した個人を特定しないようにします。
タスクの編成 
見積もり会議が終了しても作業は終わりません。
司会者またはプロジェクト管理者のいずれかが、プロジェクト・タスクとその個別見積もりを編成して、
1 つのマスター・タスク・リストを作成します。
この担当者は、仮定、品質関連アクティビティー、プロセス関連アクティビティー、
オーバーヘッド・タスク、待ち時間の個別リストもマージします。
マージ・プロセスには、重複タスクを削除し、個別タスクに対して
異なる見積もりが存在する場合に合理的な解決を見つけることも含まれます。
「合理的」とは、チームの見積もりをプロジェクト管理者が希望する数値に置き換えることではありません。
明らかに類似しているタスクに対して大きな見積もりの差異がある場合は、
そのアクティビティーの解釈が見積もり担当者によって異なっている可能性があります。
たとえば、2 人のメンバーがどちらも「クラスの実装」というアクティビティーを扱っているとします。
しかし、1 人はそのタスクにユニット・テストとコード・レビューを含めているのに対して、
もう 1 人はコーディング作業のみを想定している可能性があります。
すべての見積もり担当者は、自分のアクティビティーを明確に定義して、このマージ手順での混乱を最小限に抑える必要があります。
マージ手順では、各タスクの見積もり範囲が維持されます。
しかし、1 人の見積もり担当者のタスク見積もりがその他の見積もり担当者の見積もりと大幅に異なる場合は、
その見積もりを検討し、場合によっては破棄または変更します。
結果のレビュー 
最終手順では、見積もりチームが要約された結果をレビューし、最終結果についての合意を形成します。
プロジェクト管理者は、全体タスク・リスト、個別見積もり、累積見積もり、
仮定リストなどすべての情報をほかの見積もり担当者に提供します。
30 分から 60 分のレビュー会議を開催して、チームとして見積もりアクティビティー-の最終結論を出します。
この会議は、今回実行した Wideband Delphi プロセスについてチームとして反省し、
将来適用するときにはどのように改善すればよいかを検討する機会でもあります。
各参加者は、最終タスク・リストをできる限り完全なものに近づける必要があります。
見積もり会議以降に考えた追加のタスクがある場合は、この時点でタスク・リストに追加できます。
個別見積もりが大幅に異なっていたタスクが適切な方法でマージされているかどうかをチェックします。
最終的な目的は、見積もり範囲を確定して、プロジェクト管理者および
その他の主要な利害関係者が許容可能な信頼レベルでプロジェクトを計画および実行できるようにすることです。
見積もりの完了 
見積もりプロセスは、指定された終了基準が満たされると完了します。
この時点で成功を宣言し、ほかの仕事に取り組むことができます。
一般的な Wideband Delphi 終了基準は以下のとおりです。
全体タスク・リストが編成された。
見積もり仮定の要約されたリストがある。
個別見積もりを統合して許容可能な範囲にある見積もりセットを作成する方法について、見積もり担当者が合意に到達した。
次に、このデータをどうするかを決定する必要があります。
最終見積もりを単純に平均して、単一の見積もり値を算出することもできます。
多くの場合、見積もりを依頼した人物はこの情報を必要としています。
しかし、単純な平均では簡単すぎるので、見積もり範囲を保持しておくと役立ちます。
見積もりとは将来の予測であり、見積もり範囲は予測という行為に常に伴う不確実性を反映しています。
見積もりの平均 (計画どおりの場合)、最小値 (最善の場合)、最大値 (最悪の場合) の 3 つの数値を提示できます。
また、平均値を名目予測結果として提示し、さらに (最大値-平均値) の値と - (平均値 - 最小値) の値を示すこともできます。
各見積もりには一定の実現可能性があるため、見積もりセットによって確率分布が形成されます。
Watts Humphrey 著、『A Discipline for Software Engineering』 (Addison-Wesley、1995 年) の第 6 章には、
複数の見積もりおよびその不確実性を結合して、合計見積もりと予測区間の上限および下限を算出する精密な数学的方法の説明があります。
もう 1 つの高度なアプローチは、モンテカルロ・シミュレーションを実行して、
最終見積もり値に基づいた予想見積もり結果の確率分布を算出することです。
意思決定権を持つ人々は Delphi セッションの結果には関心を示さないかもしれません。
しかし、この結果は、10% の信頼レベルから 90% の信頼レベルまでのどこでプロジェクトを計画するかを決定するのには役立ちます。
実際のプロジェクト結果と見積もりを比較して、将来の見積もりの正確性を向上させることを忘れないでください。
再実行 (反復) 
この方式の長所の 1 つは、たとえば方向づけフェーズで初期の概算見積もりを実行し、
その後の各フェーズ (または各反復) を通じて見積もりを洗練できるという点です。
同じ見積もり担当者が参加できる場合は、以前の見積もりサイクルを終了したポイントから継続できるので、
プロセスを迅速化できます。
問題についてのより多くの情報が利用でき、いくつかの仮定が変更され、
作業の分解に役立つアーキテクチャーがあらかじめ用意されています。
新しい見積もりの範囲は狭くなるかもしれませんが、以前の範囲内より大きいまたは小さい値になることもあります。
値が大きい場合は、明白なリスクの可能性を意味しているので、プロジェクト管理者はすぐにリスクに対処する必要があります。
Wideband Delphi の評価 
完全な見積もり方式は存在しません。仮に存在したとすれば、それは予知であって見積もりではありません。
しかし、Wideband Delphi 手法には、いくつかの確実性の高い見積もり原則が組み込まれています。
チームによるアプローチは、複数の専門家の観点を結合することを重視しています。
作成された見積もりの範囲は、見積もりプロセスで必ず発生するばらつきを反映しています。
Wideband Delphi 方式には時間がかかり、経験豊富な見積もり担当者のチームが必要です。
しかし、メンバーの力関係によって見積もりに影響が生じるのを防ぎ、極端な初期値を排除できるという利点があります。
|