良い見積もり手法
見積もり手法とアプローチは、Waterfall や V-Model のような従来のプロセスフレームワークと Agile を分かつ重要な領域の 1 つです。
混乱を招きがちなのは、ストーリーポイント、エスティメーションポーカー、T シャツサイジング、ベロシティといった Agile の用語と、それらがより良くより精度の高い見積もりにどう関係するかです。
この簡単なハウツーガイドでは、チームが開発工数をより良く、より信頼性高く見積もるために Agile が取り組む主要な課題を素早くまとめます。
注意: 見積もり手法の適用は、2 か月以上の期間のプロジェクトに対してのみ推奨します。
GitLab Professional Services プロジェクトの見積もり
GitLab および顧客プロジェクトチームが GitLab Issue にウェイトを付与する方針に進む場合、以下の T シャツサイジング見積もりを推奨します。
- Sm - 1 (0-2 時間)
- Med - 2 (2-5 時間)
- Large -3 (5-10 時間)
- 10 時間を超えるものは、より小さなタスクに分割すべきです
見積もりの不確実性
「estimate（見積もる）」という言葉の意味には次のようなものがあります。
- 何かの値、数、量、程度を概算で計算したり判断したりすること [動詞]
- 何かの値、数、量、程度を概算で計算したり判断した結果 [名詞]
類義語: 概算する、近似する、おおよその推測 — そこから「guestimate（推測 + 見積もり）」というスラング、すなわち推測と計算が混ざった言葉が生まれました。
ドワイト・D・アイゼンハワーは有名な言葉を残しています: 「計画は無価値だが、計画立案こそがすべてである。両者には大きな違いがある。なぜなら、緊急事態に備えて計画する場合、まず次の 1 点から始めなければならない: 「緊急事態」とはまさに予想外のものであるため、計画通りには起こらないということだ。」1
ポイントは、見積もりは決して正確ではないということですが、プロジェクト管理 — 特にソフトウェア／IT のプロジェクト管理 — では、見積もりが日常的にベースライン化され、石板に刻まれ、追跡され、結果として「最初に工数を見積もった人たちが完全に間違えた」と認識されて、政治的な問題を多く引き起こします。
彼らは間違えたわけではありません。当時はそれだけの情報しか持っていなかっただけです。
Cone of Uncertainty（不確実性の円錐）
Cone of Uncertainty は、プロジェクト管理用語で、プロジェクトのさまざまな段階で存在する不確実性のレベルを表すものです。
工数を一番初めに見積もるとき、たとえばアイデアのコンセプト段階では、精度の点で桁違いに外れる可能性が高いです。これは私たちの Engagement Manager がスコープ情報を提供する時点です！ 交渉段階で行われます。
異なるプロジェクトフェーズを進み、実際の作業や関わる課題についてより多くを学ぶにつれ、見積もりは（実際の作業工数により近づくという意味で）より良くなっていきます。
要するに、見積もる対象についてより多く学ぶにつれ、見積もりに対してより確信を持てるようになります。
プロジェクト完了に近づくほど、見積もりのばらつきは減少します。
唯一の例外は、100% 理解されているプロセスを扱う場合です。生産ラインが良い例で、各工程をピースが移動する正確な時間がわかっており、製品 1 個を完成させるのにどれだけかかるかを正確に見積もれます。
生産ラインは通常、多くの実証的な時間計測を経て最適化されており、各製造ステップがスムーズに進むようになっています。PS のエンゲージメントは本質的に異なります。
不確実性、創造性、これまで存在しなかった何かを伴う作業を行っている場合、Cone of Uncertainty が当てはまります。これはほとんどのソフトウェア開発や IT プロジェクトに当てはまります。
サーバーアップグレードのような通常の IT タスクでさえ、頻繁に予想より時間がかかります。システム管理者がディスク容量不足になったり、予想外の停電でアップグレードが破損したり、その他「緊急事態」が発生したりするからです。
プロセスを自動化してより予測可能にすることはできます。たとえば Amazon Web Services のクラウドにおける自動化されたサーバー要求などですが、通常はプロセスの標準化が必要となり、それはつまり不確実性、創造性、未経験のものを含まない、何千回も実行されてよく知られ十分に理解されているもの、ということになります。
長期および短期の計画ホライズン
したがって、見積もりのばらつきの低減は計画ホライズンに依存します。
今日の予定を立てるなら、自分の 1 日がどう進むかをよく理解しているはずなので、午後 5:00 のアポイントメントに間に合うことを高い確率で（つまり低い見積もりのばらつきで）見積もることができます。
一方、5 か月先の予定を立てようとする場合、できることはせいぜいリマインダーを置く程度です。予定を変える予期せぬ出来事が起こる可能性は高いです。病気になるかもしれませんし、予期しない出張で外出するかもしれませんし、両親の世話をしなければならないかもしれません。
ソフトウェアプロジェクトの見積もりにおいて、これは伝統的な「Planning Onion」として表現されます。
この「Planning Onion」は基本的に外側から内側に向かって、段階的に詳細度を増していきます。これは Cone of Uncertainty で示された概念と密接に関連しています。
タイミングの側面と見積もりの詳細度を反映させると、「Planning Onion」を次のように考えられます。
最後に、Agile / Scrum の見積もりの時間ホライズンに関しては、長期と短期の計画ホライズンを次のように考えられます。
ビジョンとロードマップの計画は長期ホライズンの活動であり、スプリント計画は短期ホライズンの活動に分類されます。
Waterfall と Agile における計画と見積もりの違い
では、Waterfall と Agile の実際の計画・見積もりの違いは何でしょうか？
見積もり手法の観点からは、T シャツサイジングやエスティメーションポーカーをどちらの手法でも使えない理由はありません。
Waterfall の主な問題は、プロジェクト全体を最初に見積もろうとし、スコープを明確に理解しないまま、早い段階で非現実的なタイムラインに対してプロジェクトをコミットしてしまうことです。
次の図は、3 つの架空の（しかし私の経験ではよくある）「中断」を含む、伝統的な Waterfall プロセスを示しています。これらの中断は基本的にプロジェクトを最初に戻してしまいます。
- 要件変更 — 主要な要件が変更され、チームを Analysis のドローイングボードに戻すことを強制される
- 顧客マネジメントの交代 — 顧客／クライアントのマネジメントや主要ステークホルダーが交代し、「新しいチーム」がプロジェクトに対して入力（読み: 新しい方向性）を提供したいと考え、リセットを引き起こす
- テクノロジーイノベーション — 新しいテクノロジーがプロジェクトを提供する良い方法を可能にし、チームに既存の Analysis、Design、Code を再評価して最初からやり直すことを強制する
Waterfall プロジェクトでは、これが常に起きます。価値を提供せずにリセットしてしまうのです。
一方 Agile を使用すると、小さなプロダクトインクリメントを迅速に提供できます。計画ホライズンは短く、Agile チームは基本的に各スプリントの終わりに動作するインクリメントを提供することにコミットします。
スプリントの途中で要件が変更されても、そのスプリント終了時のプロダクトインクリメントは提供されます。新しい要件はプロダクトバックログに登録され、後のスプリントで優先順位付けされます。
顧客／クライアントマネジメントやステークホルダーが交代しても、Agile / Scrum ではプロジェクトチームが各スプリント終了時に動作するソフトウェアをデモすることができ、多くの場合、「方向転換」したいという欲求が弱まります（だってすでに動いているのですから！）。要請された変更は追加要件としてプロダクトバックログに記録され、後のスプリントで優先順位付けされます。
最後に、テクノロジーイノベーションさえも、プロダクトバックログに含めて後のスプリントで優先順位付けすることで対応できます。
ここで重要なのは、Agile では、中断、予期せぬ展開、「緊急事態」があっても、チームは各スプリント終了時にプロダクトインクリメントの形で動作するソフトウェアを提供し続け、実際の有形の価値を提供できるということです。
これを Waterfall 手法と対比してください。Waterfall ではしばしば、生み出される唯一の価値はチームが更新を維持するのに苦労する大量のドキュメントだけです。
動作するソフトウェアを提供することで、チームが単にドキュメントを生成しただけの場合よりも、無視したり議論したりしにくい「現場の事実」が作られます。
一般的な見積もりアプローチ
一般的な見積もりアプローチにはどのようなものがあり、どう機能するのでしょうか？
絶対見積もりと相対見積もり
頭に入れておくべき重要なことは、Agile / Scrum チームは相対見積もりを使うということです。これはチームに対して相対的だからです。それはどういう意味でしょうか？ 本質的には、タスクに対して合意された測定単位／粒度は、それを見積もる開発チームに固有のものということです。チーム A は 8 ストーリーポイントと見積もるかもしれませんし、チーム B は 5 ストーリーポイントと見積もるかもしれません。それはチームに対して相対的であり、相対見積もりは絶対的な測定によって 100% の精度を目指すものではありません。
次の図は違いを明確にしようとしています。
ここでの 絶対的 な指標はミリリットル (ml) で、これは国際単位系の液体の指標です。意味の解釈の余地はありません。絶対的です。ワインボトルはこれに従って分類されます。
相対的 な指標は、T シャツサイジングで使われる small、medium、large の分類や、エスティメーションポーカーで使われる 3, 5, 8 のフィボナッチ数列のストーリーポイントなどです（エスティメーションポーカーについては次のセクションで詳しく説明します）。
次の表は、絶対見積もりと相対見積もりの比較を示しています。
{width=“544” height=“380”}
エスティメーションポーカー
{width=“523” height=“285”}
前述のとおり、エスティメーションポーカーは、精密さよりも正確さを重視する相対見積もり手法です。一般にフィボナッチ数列 (1, 2, 3, 5, 8, 13, 21, 34, 55, …) を使用します 2。
作業を行う実装チームのメンバーが見積もりを行う必要があります。これは重要です。実装チーム以外の人に作業を見積もらせてはいけません。これはアカウンタビリティを生み、実装チームが見積もりに完全にコミットするために重要です。
エスティメーションポーカーはチームの特性に対して自己補正されます。つまり、2 つのチームが同じ作業を見積もって異なる見積もりを出す可能性があるということで、これは特定のチームの構成やスキルセットが異なるためです。
以下の 8 ステップで基本的なエスティメーションポーカーのプロセスを説明します。
STEP 1
「アンカーストーリー」を特定します — 全員が合意できる最もよく理解されているストーリーで、サイズ／工数の参照として機能します
STEP 2
プロダクトオーナーがストーリーを説明します
STEP 3
各開発チームメンバーが（秘密裏に）カードを選びます
STEP 4
開発チームメンバー全員が一緒にカードを公開します
STEP 5
カードが異なる場合、最高と最低の見積もり者が自分の選択と前提を簡潔に説明します
STEP 6
プロダクトオーナーが必要に応じて追加情報を提供します
STEP 7
開発チームは合意に達するまで、最大 3 回プロセスを繰り返します
STEP 8
アンカーストーリーを常に念頭に置きながら、見積もりが必要な全ストーリーに対して繰り返します
よくある課題は、7（±2）人の実装チームでは意見の相違が発生することです。あるユーザーストーリーを 5 と主張する人もいれば、13 だと言う人もいるでしょう。では、どうすればよいのでしょうか？
よくある解決アプローチ
見積もりプロセス中の意見の相違を解決する方法は基本的に 4 つあります。
- 外れ値の見積もり者に主張を述べてもらい、他の開発チームメンバーを説得しようと試みる。基本的にはコンセンサスに達するまで前後に交渉する形です。このようなオープンな議論は、対等にバランスの取れたチームメンバーではうまく機能しますが、強い、Type A の人格の人物や、3 人の非常に強力な技術エンジニアと 4 人のエントリーレベルのエンジニアからなるアンバランスなチームでは難しい場合があります
- 無記名投票や「Fist of Five」コンセンサスモデルを行う
- 多数決は対立を避けられるため人気がありますが、責任を感じる人がいないコミッティ決定を生み出すリスクがあります — アカウンタビリティが必要なので、これは良いアプローチではありません
- 最高見積もりを選ぶこともできますが、見積もりの肥大化のリスクが生じます
意見の相違を解決する最良の方法は、議論を行い、すべてのチームメンバーが見積もりに合意することです。
見積もりはチーム固有であり、見積もりは基本的にこの見積もりに基づいて納品するという実装チームのコミットメントであることを忘れないでください。だからこそコンセンサスが重要なのです。
「一人はみんなのために、みんなは一人のために！」
T シャツサイジングと Affinity Estimation
{width=“521” height=“326”}
T シャツサイジング（別名 Affinity Estimation）は、通常必要となるすべての詳細を持たずに素早く何かを見積もる必要性に基づいています。T シャツサイジングが使える例をいくつか示します。
- 予算策定の目的 — ビジョンとロードマップが議論されている際、経験豊富な開発者にハイレベルな依頼内容を見てもらい、適切にサイズ化することで T シャツサイジングが役立ちます。同じことが人員計画にも当てはまります（来年は何人の PSE を採用する必要があるか？）
- ユーザーストーリーが利用できないとき — Program Manager / Project Manager は、自分のエンゲージメントが詳細に何をするべきかを知っている詳細レベルのドメインエキスパートです。エスティメーションポーカー中、Program Manager は各ユーザーストーリーを説明、議論、明確化します。しかし現実には、完全に肉付けされたユーザーストーリーがまだ利用できない場合や、Program Manager が潜在的なスプリントの 6 か月前に何が必ず開発される必要があるかを知らないこともよくあります。とはいえ、見積もりたい各ユーザーストーリーには少なくともプレースホルダーの件名行があるべきで、たとえば「HP OfficeJet 9800 をサポート」のように — 少なくとも開発者は正確な詳細を知らなくても、より大きな文脈で何が必要かを素早く把握できます
- ユーザーストーリーが 2,986 個あるとき — 生産性の高い Program Manager / Project Manager が、詳細レベルのばらつきがあるユーザーストーリーを何百、何千と量産することは珍しくありません。完全に肉付けされたものもあれば、件名のみのものもあります。すると課題は、すべてのストーリーを見積もるのにかかる過度な時間です。エスティメーションポーカーで見積もりを生成するためだけに、開発作業を 6 週間止めますか？
これらの見積もりの課題に対する答えは、T シャツサイジングを使うことです。エスティメーションポーカーと T シャツサイジングの間にいくらか比較可能な体系を持たせるために、以下の数値化体系の使用が推奨されます。
- XS = 1 ストーリーポイント
- Small = 2 ストーリーポイント
- Medium = 3 ストーリーポイント
- Large = 5 ストーリーポイント
- XL = 8 ストーリーポイント
- XXL = 13 ストーリーポイント
- EPIC = Program Manager / Project Manager が Epic をより詳細なユーザーストーリーに分解する必要があります（たとえば EPIC が「国際化サポート」のようなものを示すかもしれません。これは「英国英語のサポートを提供」「スペイン語のサポートを提供」のような、より詳細なユーザーストーリーに分解する必要があります）
そして、次の 4 つの簡単なステップに従います。
STEP 1
1 分かけて、開発チームに 1 つの「small」ユーザーストーリーで合意してもらいます。XS、medium、large、XL、XXL、EPIC のサイズのストーリーで繰り返します
STEP 2
10 〜 30 分かけて、開発チームに残りのすべてのユーザーストーリーを XS、small、medium、XL、XXL、EPIC のカテゴリに分類してもらいます
STEP 3
さらに 10 〜 30 分かけて、開発チームに必要に応じてユーザーストーリーの分類をレビューして調整してもらいます — 完了！
STEP 4
プロダクトオーナーに分類をレビューしてもらいます
この 4 ステップのプロセスにより、開発チームは何百ものユーザーストーリーを素早く扱えます。
エスティメーションポーカーを使っているか、T シャツサイジングを使っているかにかかわらず、Cone of Uncertainty は依然として適用されます。プロセスの早い段階で T シャツサイジングを使うと、ばらつきの大きな見積もりが生じることに注意してください。
見積もる対象に応じて、適切な見積もり方法を選択してください。
- ロードマップ計画 => T シャツサイジングを使用
- リリース計画 => ユーザーストーリーの数に応じて T シャツサイジングまたはエスティメーションポーカーを使用
- スプリント計画 => エスティメーションポーカーを使用
見積もりチームのサイズ
見積もりチームのサイズは、Agile 実装チームのサイズによって決まり、これは 7（±2）であるべきです。
作業を行う人々が、それを見積もる人でなければなりません。
組織は時々、見積もりに人を増やせば見積もりが良くなると考えますが、これは一般に受け入れられている誤解です。チームが大きいほど良い見積もりを生み出すわけではありません。
{width=“600” height=“377”}
見積もり精度は、チームサイズが大きくなるにつれて実際には低下します。
チームサイズに関する考察は広範に研究されており、最適なチームサイズは 5 〜 8 人の間のどこかであることが一般に認められています。最大 12 人のチームメンバーで良好に機能するチームもあります。コロケーション、オフショアリング、パートナーシップ、スタッフの資格はすべて見積もりの効率に影響します。
スポーツのチームがこのサイズで構成されているのは指摘に値します（サッカー: 11 人、バスケットボール: 5 人、野球: 9 人、フットボール: 11 人）。例外はラグビーで、15 人です。軍隊の分隊もこのサイズで構成されています。
見積もりの効率と同様にチームのダイナミクスでも重要なのは、以下のことを理解することです。
チームが大きくなるほど、効果的にコミュニケーションし、見積もり、コンセンサスに達するのが難しくなります。チームが大きくなるほど、誤コミュニケーションによって何かが見落とされる可能性が高まります。私たちの PS エンゲージメントのほとんどはリモートで実施されるため、この問題はさらに増幅されます。
大きなチームでコミュニケーションパスが増え続けるこの課題は、有名な「ダンバー数」とも幾分か関連しています。これは安定した社会的関係を維持できる人数（〜 150）に認知的限界があることを示唆しています。
ベロシティとは何か？
ベロシティとは、開発チームが信頼できる形でストーリーポイントを納品できるレートです（通常はタイムボックスされたスプリントにパッケージされ、動作するプロダクトインクリメントとなります）。
見積もりは自己補正する
エスティメーションポーカーを使うと、通常最初の 4 〜 6 スプリントの過程で見積もりのばらつきが減少します。安定したチームが 5 〜 6 スプリント一緒に働いた後にかなり正確な見積もりを達成できなかったケースは、私はほとんど見たことがありません。
ここで「安定したチーム」がキーであることに注意してください。チームは安定している必要があり、チームメンバーは互いを知り、共に働き、チームを成功裏に形成している必要があります。これは、1965 年に Bruce Tuckman が最初に提案した 標準的な「forming–storming–norming–performing」グループ発達モデルに従います。
これらのフェーズはすべて、チームが成長し、課題に立ち向かい、問題に取り組み、解決策を見つけ、作業を計画し、結果を出すために必要かつ不可避なものです。私たちの大規模な PS エンゲージメントのほとんどは、顧客の開発チームとの広範なクロスチームコミュニケーションとコラボレーションを必要とするため、顧客側のチームダイナミクスを理解し、認識することも必要です。
時間経過に伴う見積もり精度とベロシティ
実装チームが「forming–storming–norming–performing」プロセスを経ると、チームのベロシティが確立されます。見積もり精度と予測可能なベロシティにより、より長期の予測が可能になります。
簡単に言えば、プロダクトバックログに 2,400 ストーリーポイントを表す 450 のユーザーストーリーがあり、開発チームが 2 週間スプリントごとに 60 ストーリーポイントの安定したベロシティで納品しているなら、プロジェクトの残りはあと 40 スプリント、つまり 80 週間、おおよそ 1 年半かかると予測できます。
2,400 / 60 = 40 スプリント
40 スプリント × 2 週間スプリント期間 = 80 週間
80 週間 / 1 年あたり 52 週間 = 1.54 年
それに従い、バーンレートの計算も簡単な作業になります。労務コストとオーバーヘッドに期間を掛けるだけです。たとえば 7 名の開発チームが年間 1,529,500 ドル（給与 805,000 ドル、オーバーヘッド／福利厚生など 724,500 ドル）かかるとわかれば、スプリントあたりのコスト (1,529,500 / 26 = 58,827 ドル) を簡単に計算できます。
予測可能性と予測精度はこれ以上良くなりません。
まとめ
エスティメーションポーカーを用いた Agile / Scrum 見積もりは、ユーザーストーリーが完全に定義されている短期ソフトウェア見積もりに対する経験的、自己補正的なアプローチです。
経験的なプロジェクト計画アプローチであるため、いつでもプロジェクトが正確にどこにあるかを把握できます。
T シャツサイジング（Affinity Estimation）は、すべてのユーザーストーリーが詳細に定義されておらず、今後の作業の素早いアセスメントが必要な、予算策定、人員配置、その他の長期計画活動に必要なハイレベルな見積もりに使用されます。
ワシントン D.C. での National Defense Executive Reserve Conference でのスピーチから (1957 年 11 月 14 日); Public Papers of the Presidents of the United States, Dwight D. Eisenhower, 1957, National Archives and Records Service, Government Printing Office, p. 818 : ISBN 0160588510, 9780160588518 ↩︎
定義により、フィボナッチ数列の最初の 2 つの数字は 0 と 1 であり、後続の各数字は前の 2 つの合計です ↩︎
