LESSON 30分

見積もりの技術

ストーリー

「見積もりが苦手で......。聞かれるたびに不安になります」

渡辺マネージャーが頷いた。

「見積もりは『正確に当てること』が目的じゃない。 チームが計画を立てるための『共通の物差し』を持つことが目的だ。 絶対時間ではなく、相対的な見積もり手法を覚えよう」

ストーリーポイントとは

ストーリーポイント（SP）は、タスクの「相対的な大きさ」を表す数値です。時間ではなく、複雑さ・作業量・不確実性を総合的に評価します。

時間見積もりとの違い

項目時間見積もりストーリーポイント
単位時間、日ポイント（1, 2, 3, 5, 8, 13...）
基準個人の能力に依存チーム共通の基準
目的いつ終わるかの予測タスク間の相対比較
プレッシャー「3時間で終わらせなきゃ」「これは5ポイントの大きさ」

フィボナッチ数列を使う理由

ストーリーポイントにはフィボナッチ数列（1, 2, 3, 5, 8, 13, 21）を使います。

なぜフィボナッチ？

  1 vs 2  → 違いがわかる（2倍）
  2 vs 3  → 違いがわかる（1.5倍）
  5 vs 8  → 違いがわかる（1.6倍）
  13 vs 21 → 違いがわかる（1.6倍）

  → 大きくなるほど粒度が粗くなる
  → 大きなタスクの細かい差は意味がないため
  → 「13か14か」を議論するより「13か21か」の方が有意義

基準タスクの設定

チームで「基準タスク」を決め、それを基に相対的にポイントを割り当てます。

基準タスク例（あるWebアプリチームの場合）:

  1 SP: 既存APIのパラメータ追加（テスト含む）
  2 SP: 新しいCRUD APIエンドポイント1つ（テスト含む）
  3 SP: 新しい画面のUI実装（既存コンポーネントの組み合わせ）
  5 SP: 新しい機能のバックエンド＋フロントエンド実装
  8 SP: 外部API連携を含む機能実装
  13 SP: 新しいサブシステムの設計＋実装
  21 SP: 大きすぎ。分解が必要

Tシャツサイズ見積もり

ストーリーポイントよりもさらに簡易な見積もり手法です。初期段階のざっくりとした見積もりに適しています。

サイズ定義

サイズ意味SP換算目安作業日数目安
XS軽微な変更1 SP半日以下
S小さなタスク2-3 SP1日
M標準的なタスク5 SP2-3日
L大きなタスク8 SP1週間
XLとても大きい（分解推奨）13+ SP1週間以上

使いどころ

Tシャツサイズが適する場面:
  ✓ バックログリファインメントの初期段階
  ✓ ロードマップの大まかな計画
  ✓ 非エンジニアとの見積もり共有
  ✓ 素早く大量のタスクを分類したい時

ストーリーポイントが適する場面:
  ✓ スプリントプランニング
  ✓ ベロシティの計測
  ✓ より正確なスプリント容量の計算

プランニングポーカー

チーム全員で見積もりを行う手法です。各メンバーが独立して見積もり、結果を一斉に公開します。

進め方

1. プロダクトオーナーがタスクを説明（3分）

2. チームメンバーが質問（5分）
   「このAPIは認証が必要ですか？」
   「既存のライブラリを使えますか？」

3. 各メンバーがカードを選ぶ（一斉公開）
   田中: 5  佐藤: 8  鈴木: 5  高橋: 13

4. 最大と最小の人が理由を説明
   高橋「外部APIの仕様が不明確なので、調査が必要」
   田中「既存の類似実装があるので流用できる」

5. 再投票
   田中: 5  佐藤: 8  鈴木: 8  高橋: 8

6. 合意形成 → 8 SP に決定

プランニングポーカーのルール

ルール理由
一斉に公開する他人の意見に引きずられないため
最大・最小の人が説明する見落としや過剰評価を発見するため
2回まで再投票議論を長引かせないため
合意できない場合は大きい方を採用楽観バイアスを防ぐため

ベロシティの活用

ベロシティとは、チームが1スプリントで完了できるストーリーポイントの合計です。

ベロシティの計測

スプリント1:  計画 30 SP → 完了 25 SP
スプリント2:  計画 28 SP → 完了 27 SP
スプリント3:  計画 27 SP → 完了 30 SP
スプリント4:  計画 30 SP → 完了 28 SP

平均ベロシティ = (25 + 27 + 30 + 28) / 4 = 27.5 SP

ベロシティの活用方法

活用場面方法
スプリント計画平均ベロシティ分のタスクをスプリントに入れる
リリース予測残りSP / 平均ベロシティ = 必要スプリント数
キャパシティ超過の検知計画SPが平均ベロシティの120%を超えたら警告

ベロシティの注意点

やってはいけないこと理由
チーム間でベロシティを比較する基準が異なるため比較は無意味
ベロシティを増やすよう圧力をかけるポイントのインフレが起きるだけ
個人のベロシティを測定するチームの指標であり、個人評価に使うべきでない

見積もりの改善サイクル

見積もり vs 実績の記録

スプリント終了時に、見積もりと実績を比較して改善します。

タスク: ユーザー検索API実装
  見積もり: 5 SP（約2日）
  実績: 4日

振り返り:
  乖離の原因:
    - DBのインデックス設計に想定外の時間がかかった
    - コードレビューの指摘対応が多かった
  次回への教訓:
    - DB周りの作業は+2 SPのバッファを追加
    - レビュー対応も見積もりに含める

見積もり精度の向上パターン

経験が浅い時:  見積もり x 2〜3 = 実績
  ↓
半年後:        見積もり x 1.5 = 実績
  ↓
1年後:         見積もり x 1.0〜1.2 = 実績

まとめ

ポイント内容
ストーリーポイント相対的な大きさ。フィボナッチ数列を使用
Tシャツサイズざっくりした初期見積もり。XS〜XL
プランニングポーカーチーム全員で見積もる手法。一斉公開がポイント
ベロシティチームの消化速度。スプリント計画の根拠になる
改善見積もり vs 実績を記録し、精度を向上させる

チェックリスト

  • ストーリーポイントと時間見積もりの違いを説明できる
  • フィボナッチ数列を使う理由を理解した
  • プランニングポーカーの進め方を知っている
  • ベロシティの計測と活用方法を理解した

次のステップへ

次のセクションでは、「マルチタスクの罠」について学びます。同時に複数のタスクを進めることが、なぜ生産性を下げるのかを理解し、対策を身につけましょう。

推定読了時間: 30分