フレームワーク活用ガイドひとことで言うと#
開発タスクの大きさを**「何時間かかるか」ではなく「他のタスクと比べてどれくらい大きいか」**で相対的に見積もる手法。フィボナッチ数列（1, 2, 3, 5, 8, 13, 21…）を使い、チーム全員で見積もることで精度と共通認識を高める。
押さえておきたい用語#
- フィボナッチ数列（Fibonacci Sequence）
- 1, 2, 3, 5, 8, 13, 21…という数字が大きくなるほど間隔が広がる数列のこと。不確実性が高いタスクほど細かい区分が不要であることを反映している。
- プランニングポーカー（Planning Poker）
- チーム全員が同時にポイントを提示し、議論を通じて合意する見積もり手法のこと。アンカリング効果を防ぐために同時出しが鉄則。
- ベロシティ（Velocity）
- 1スプリントで消化したストーリーポイントの合計値で計るチームの開発速度のこと。過去3〜5スプリントの平均で次の計画を立てる。
- 基準タスク（Reference Story）
- チーム全員が認識を共有できる中規模タスクで、他のタスクとの比較基準となるタスクのこと。通常3または5ポイントと定義する。
ストーリーポイントの全体像#
こんな悩みに効く#
- 「3日で終わる」と言った作業が1週間かかることが頻発する
- メンバーごとに見積もりの基準がバラバラ
- 「今スプリントでどれくらい消化できるか」が予測できない
基本の使い方#
まずチーム全員が共通認識を持てる基準タスクを1つ選ぶ。
手順:
- 過去に完了した中規模のタスクを1つ選ぶ
- そのタスクを3ポイント（または5ポイント）と定義する
- 他のタスクはこの基準と比較して「大きいか小さいか」で見積もる
例:
- 基準タスク: 「ユーザープロフィール画面の作成」= 3ポイント
- 「ログインボタンの色変更」= 1ポイント（基準よりかなり小さい）
- 「決済機能の実装」= 13ポイント（基準の4倍以上複雑）
使うスケール: フィボナッチ数列（1, 2, 3, 5, 8, 13, 21）。数字が大きくなるほど不確実性が増すため、細かい区分は不要。
チーム全員で同時に見積もりを出す「プランニングポーカー」を実施。
手順:
- PMまたはスクラムマスターがユーザーストーリーを説明
- 不明点があれば質問タイム
- 全員が同時にカード（数字）を出す
- 数字が揃えばその値を採用
- 大きくズレた場合は、最大と最小を出した人が理由を説明
- 議論後に再投票
同時に出す理由: 先に誰かが「3かな」と言うと、他の人が引っ張られる（アンカリング効果）。全員が独立して判断することで精度が上がる。
13以上のタスクは分割を検討する。大きすぎるタスクは不確実性が高く、見積もり精度が落ちる。
スプリントごとに**消化したストーリーポイントの合計（ベロシティ）**を記録する。
ベロシティの使い方:
- 最初の3スプリントはデータ収集期間。安定するまで無理に使わない
- 4スプリント目以降、過去3〜5スプリントの平均ベロシティで計画を立てる
- 例: 平均ベロシティが30ポイント/スプリント → 次も30ポイント分を計画
注意: ベロシティはチーム固有の数値。他チームと比較してはいけない。「AチームのベロシティはBチームの2倍」→ 見積もり基準が違うだけで、生産性の比較にはならない。
ベロシティとバックログの合計ポイントから、リリース時期を予測する。
計算例:
- 残りバックログ: 120ポイント
- 平均ベロシティ: 30ポイント/スプリント（2週間）
- 予測: 120 ÷ 30 = 4スプリント（約8週間）
幅を持たせる: 最小ベロシティ（25）〜最大ベロシティ（35）でレンジを出す。「6〜10週間」のように幅で伝えるほうが誠実。
注意: ベロシティを「上げる」ことを目標にしない。ポイントのインフレ（同じ作業に高いポイントを付ける）が起こるだけ。
具体例#
5人の開発チームがストーリーポイントを導入してスプリント計画を改善した事例。
Before（時間見積もり）:
- 「このタスクは16時間」→ 実際は40時間かかった
- スプリントの達成率: 平均55%（半分しか終わらない）
- メンバーの発言: 「見積もりが外れるのが怖くて控えめに言ってしまう」
導入プロセス:
- 基準タスク「APIエンドポイント1つの追加」= 3ポイント
- 最初のスプリントはプランニングポーカーに1時間かかった
- 3スプリント目からは30分で見積もりが完了するように
ベロシティの推移:
| Sprint | 消化ポイント | 達成率 |
|---|---|---|
| Sprint 1 | 22pt | 65% |
| Sprint 2 | 28pt | 72% |
| Sprint 3 | 32pt | 80% |
| Sprint 4-6 | 30pt前後 | 85% |
結果: スプリント達成率が55%→85%に改善。リリース時期の予測精度が±3週間→±1週間に向上。「自分は13だと思うけど他の人は3だった」という認識のズレが早期に発見されるようになった。
8人の開発チーム（フロント3名、バック3名、QA2名）。大型機能のリリース時期を経営陣に約束する必要があった。
ベロシティデータ（直近5スプリント）:
| Sprint | ベロシティ |
|---|---|
| Sprint 8 | 45pt |
| Sprint 9 | 38pt |
| Sprint 10 | 42pt |
| Sprint 11 | 50pt |
| Sprint 12 | 40pt |
平均ベロシティ: 43pt/スプリント（最小38、最大50）
新機能の見積もり結果: 合計180ポイント
リリース予測:
- 楽観的: 180 ÷ 50 = 3.6スプリント（約7週間）
- 現実的: 180 ÷ 43 = 4.2スプリント（約8.5週間）
- 悲観的: 180 ÷ 38 = 4.7スプリント（約10週間）
経営陣への報告: 「8〜10週間で完了予定。最も可能性が高いのは9週間前後」
結果: 実際のリリースは9.5週間後。経営陣が「当初の約束通り」と評価。時間見積もりでは不可能だった精度のリリース予測がベロシティで実現した。
従業員8名の受託開発会社。クライアントへの見積もり提出時に「見積もりと実績が乖離する」クレームが頻発。
Before:
- 人月ベースの見積もり: 「この機能は3人月です」
- 実際の工期: 見積もりの1.5〜2倍になることが常態化
- クライアントの不信感が蓄積
ストーリーポイント導入の工夫:
- クライアント向け: 人月で見積もりを提出（従来通り）
- 社内向け: ストーリーポイントで見積もり、ベロシティから人月に変換
変換ルール: 平均ベロシティ25pt/2週スプリント → 1人月 ≒ 50pt
案件A（EC サイト構築）の例:
| 機能 | ストーリーポイント | 変換後の人月 |
|---|---|---|
| 商品一覧・検索 | 40pt | 0.8人月 |
| カート・決済 | 65pt | 1.3人月 |
| マイページ | 30pt | 0.6人月 |
| 管理画面 | 55pt | 1.1人月 |
| 合計 | 190pt | 3.8人月 |
結果: 見積もりと実績の乖離が平均40%→12%に改善。クライアントからの信頼が回復し、リピート受注率が50%→78%に上昇した。
やりがちな失敗パターン#
- ストーリーポイントを時間に換算しようとする — 「1ポイント = 4時間」と固定すると、相対見積もりの利点が失われる。ポイントはあくまで相対的な大きさであり、時間ではない
- ベロシティをチーム間で比較する — 見積もり基準がチームごとに違うので、数字の比較は無意味。同じチームの過去のベロシティとの比較だけが意味を持つ
- ベロシティ向上をKPIにする — 「今期はベロシティを50%上げろ」と言うと、インフレが起こるか品質が下がる。ベロシティは予測のためのツールであり、パフォーマンス指標ではない
- プランニングポーカーで議論せずに多数決で決める — ポーカーの本質は「ズレた理由を議論する」こと。最大と最小を出した人の意見を聞かずに中間値で妥協すると、認識の不一致が見過ごされ、スプリント中に問題が顕在化する
まとめ#
ストーリーポイントは「何時間かかるか」の呪縛から解放し、「どれくらいの大きさか」で計画を立てる手法。プランニングポーカーでチームの認識を合わせ、ベロシティで将来を予測する。時間見積もりより精度が高く、チームのコミュニケーションも改善される。まずは基準タスクを1つ決めて、次のスプリントから試してみよう。