第7章 見積りとベロシティ

本章では、プロダクト開発における永遠の課題である「いつできるのか？」「コストはいくらかかるのか？」という問いに対し、スクラムがどのようにアプローチしているのか（見積りとベロシティの概念）を解説します。

7.1 概要

スクラムでは、「いつできるか」に答えるために、まず作ろうとしているものの「サイズ（規模）」を見積もる必要があります。

• そのサイズの総量を、チームがスプリントで消化できる量（ベロシティ）で割ることで、おおよその期間やコストを算出します。
• 例: 全体のサイズが200ポイントで、チームの平均ベロシティが20ポイント/スプリントであれば、およそ10スプリント（約10〜20週間）で完了すると予測できます。

7.2 いつ何を見積もるのか

見積もりは、バックログのレベルに応じてタイミングと詳細度が異なります。

• ポートフォリオバックログの見積もり: まだプロダクトとして承認される前の段階で行う、大まかな見積もりです。
• プロダクトバックログの見積もり: スプリントに投入する前に、PBI（プロダクトバックログアイテム）をグルーミングするタイミングで継続的に行われます。PBIのサイズが見積もり可能なほど小さくなければ、分割して再見積もりします。
• タスクの見積もり: 最も細かいレベルの見積もりです。スプリントプランニングにおいて、チームがPBIを具体的な技術的タスクに分解した際に、理想時間（時間単位）で見積もります。

7.3 PBIの見積もりの考え方

PBIのサイズを見積もる際、スクラムではいくつかの重要な原則に従います。

チームで見積もる

• マネージャーや一部の専門家が単独で見積もるのではなく、実際に作業を行う開発チーム全員で見積もります。
• プロダクトオーナーは質問に答えたり要件を明確にしたりするために参加しますが、見積もりの数値自体はチームが決定します。

見積もりはコミットメントではない

• 「これくらいでできそう」という見積もりと、「必ず終わらせる」というコミットメント（確約）は別物です。これらを混同すると、チームは保身のために見積もりを大きく水増しするようになり、健全な議論が失われます。

正確性か精度か

• スクラムの見積もりでは、過度な「精度（細かさ）」よりも「正確性（だいたい合っていること）」を重視します。不確実な未来に対して、細かすぎる見積もりを出しても意味がなく、単なる時間のムダです。

相対サイズの見積もり（重要）

• 人間は絶対的なサイズ（これは何メートルか？）を見積もるのは苦手ですが、相対的なサイズ（AとBのどちらが大きいか？）を比較するのは非常に得意です。
• そのため、PBIの見積もりには絶対値（時間や日数）ではなく、相対的なサイズ（あの機能と比べて2倍くらい大変そう、など）を用います。

7.4 PBIの見積もりの単位

相対サイズを見積もるための単位として、主に以下の2つがよく使われます。

ストーリーポイント

• PBIの大きさを測るための最も一般的な相対指標です。
• 複雑性や物理的な規模など、作業の完了に必要なすべての要素を統合して1つの「ポイント」として表します。
• 時間（工数）とは切り離された純粋な「規模」の指標です。

理想日

• 「もし他の作業や割り込みが一切なく、その作業だけに専念できたらかかるであろう日数」を表す指標です。
• 導入時は直感的に理解しやすい反面、人によってスキルの差があるため「誰にとっての理想日か？」がブレやすく、後々ストーリーポイントよりも扱いが難しくなる弱点があります。

7.5 プランニングポーカー

プランニングポーカーは、メンバーの同意ベースで見積もりを行う効果的なテクニックです。チーム全体が参加して議論を深め、見積もりの精度を高めます。

見積もりの尺度

• 数値の尺度には、フィボナッチ数列を少し変形した 1, 2, 3, 5, 8, 13, 20, 40, 100 といったパターンがよく使われます。
• 小さめのサイズは細かく刻まれていますが、大きくなるにつれて間隔が広がります。これは、PBIのサイズが大きくなるほど、見積もりの不確実性も増すという現実を反映しています。
• 数値以外にも「∞（無限大）」「?（疑問符）」などのカードも含まれます。

やってみよう（ルールと手順）

プランニングポーカーは以下のステップで進行します。

1. プロダクトオーナーがPBIをひとつ選び、内容をチームに説明する。
2. 開発チームが質問し、要件の詳細を明確にする。
3. 開発チームの各メンバーが、自分の見積もりを表すカードを裏向きで選ぶ。
4. 全員が同時にカードを公開する。
5. 全員の数字が一致すれば、それがそのPBIの見積もりとなる。
6. 数字がばらけた場合、メンバー（特に最大と最小の数字を出した人）がその理由を説明し合い、見解の相違を解消したうえで、再度カードを選び直す。

メリット

• 会話を通じてチーム全員がタスクへの理解を深めることができます。
• 一斉にカードを出すことで、声の大きい人や権威のある人の意見に流される（アンカリング効果）のを防ぐことができます。

7.6 ベロシティとは

ベロシティとは、各スプリントで完成させた仕事量のことです。

• スプリントの最後に、「完成の定義」を完全に満たしたPBIのサイズ（ストーリーポイントなど）の合計値として算出されます。未完成のアイテムは一切カウントされません。

7.7 ベロシティの幅の算出

ベロシティは単一の絶対的な数字ではなく、幅を持って表現するのが現実的です。

• 例：「このチームは通常、スプリントあたり25ポイントから30ポイントを完成させる」といった表現になります。
• 直近の数スプリント（例：過去3スプリント）の平均から算出するのが一般的です。

7.8 ベロシティの予想

新しいチームや新しいプロダクトなど、過去の実績がない場合は、最初のスプリントのベロシティを予想する必要があります。

• 予想値は、スプリントが進行して実際の実績データが得られ次第、すばやく調整（キャリブレーション）していくべきです。

7.9 ベロシティへの影響

ベロシティは様々な要因で変動します。

• チームの変化: メンバーの入れ替わりや、新しいツールの導入、トレーニングなどはベロシティに影響を与えます。
• 持続不可能なペース: 納期に間に合わせるために残業を増やすと、一時的にベロシティは上がるかもしれませんが、品質の低下（技術的負債の蓄積）や疲労を招き、長期的には必ずベロシティが低下します。

7.10 ベロシティの誤用（重要）

ベロシティは計画のための強力なツールですが、使い方を誤るとチームを破壊します。

• パフォーマンスの指標にしてはならない: ベロシティをチームの評価基準にしてはいけません。
• チーム間の比較に使ってはいけない: 見積もりの基準（1ポイントの重み）はチームごとに異なります。チームAの50ポイントとチームBの20ポイントを比較して「チームAのほうが優秀だ」と判断するのは全くの無意味です。
• ポイントのインフレ: ベロシティを評価に使ったり、経営陣が無理な数字を要求したりすると、チームは「手抜きをして完成とする」か「見積もりの数字を水増しする（インフレさせる）」ようになります。結果として、予測ツールとしてのベロシティの価値は完全に失われます。

7.11 終わりに

本章では、相対的なサイズ見積もりとベロシティに基づいた、健全な計画と予測の手法について学びました。次章では、持続可能なベロシティを阻害する最大の要因である「技術的負債」について詳しく掘り下げます。

---

エンジニアリングへの適用メモ

• 見積りの共通言語化: 見積もりを「時間」で行おうとすると、シニアとジュニアで想定時間がズレてしまい議論が紛糾しがちです。「ストーリーポイント」という抽象的な概念を導入することで、時間ではなく「作業の複雑さや規模」で合意形成できるようになり、チームの計画づくりが劇的にスムーズになります。
• グッドハートの法則: 「測定される指標が目標にされたとき、それはもはや良い指標ではなくなる」という法則があります。開発現場で「ベロシティを毎スプリント10%上げろ」といった目標を設定すると、エンジニアはコードの品質を犠牲にしてポイントを稼ぐようになり、確実にシステムは崩壊します。ベロシティはあくまで「体重計（現状の把握）」であり、「ダイエットの目標値」として使わないことが肝心です。