Estimation

見積もり

目的

開発工数と期間を根拠のある数字で提示し、プロジェクト計画の意思決定を支援する。 数字の正確さより「前提と不確実性を明示した納得感のある見積もり」を最優先とする。

使うタイミング

• 要件定義後、開発着手前に計画を立てるとき
• ステークホルダーへの予算・スケジュール提案が必要なとき
• フェーズ境界(設計完了後、実装完了後)で再見積もりするとき
• スコープ変更が発生し、影響評価が求められるとき

進め方

1. 前提条件の文書化 見積もり開始前に「何を含み何を含まないか」「依存する外部要因」を箇条書きで確定する。 前提が崩れた時点で再見積もりする契約を関係者と共有する。

2. タスク分解 [[task-breakdown]] と連携し、見積もり単位を1〜3人日以下に細分化する。 大きいまま見積もると必ず楽観に倒れる。分解してから見積もるが第一原則。

3. 三点見積もりの適用 各タスクに楽観値(O)・最頻値(M)・悲観値(P)を設定する。 期待値 E = (O + 4M + P) / 6 標準偏差 σ = (P - O) / 6 で不確実性を定量化する。

4. 実装以外の工数を明示計上 テスト・レビュー・修正・環境構築・ドキュメント・コミュニケーションは 実装工数の1.5〜2倍になる。個別に行として見積もりシートに記載する。

5. 相対見積もりと絶対見積もりの使い分け

   • ストーリーポイント(相対): スプリント計画、優先順位比較、チームのベロシティ管理
   • 人日(絶対): 契約・予算提示、外部との調整、ガントチャート作成 チーム内ではストーリーポイントで議論し、対外発表時に人日へ換算する。

6. AI時代の多視点見積もり(見積もりポーカー的手法) 複数のエージェントに独立して見積もらせ、乖離箇所を議論する。

   • Sonnet にタスク分解の下書きと初回見積もりを作成させる
   • Opus に技術的難易度・未知領域のリスクを独立評価させる
   • 乖離が30%超のタスクは根拠を掘り下げ、前提の違いを特定する

7. 全体バッファの設定 個別タスクに隠しバッファを積まない。全体合計に対してリスクバッファをまとめて置く。 バッファの消費状況を週次で可視化し、燃焼率を管理する。 目安: リスクが低いプロジェクト10〜15%、中程度20〜25%、高リスク30〜40%。

8. 不確実性コーンによる精度レンジの提示 要件定義前: ±4倍のぶれを想定し、数字より「レンジ」で提示する。 基本設計完了後: ±2倍、詳細設計完了後: ±1.25倍が目安。 フェーズごとに再見積もりする前提を計画に組み込む。

9. 見積もりレビューと合意 数字を単独で出さず、前提条件・精度レンジ・主要リスクをセットで提示する。 関係者が前提を確認・承認した記録を残す。

成果物テンプレート

# 見積もりシート: [プロジェクト名]
作成日: YYYY-MM-DD  作成者: [名前]  バージョン: 1.0

## 前提条件
- 含む: [例] フロントエンド実装、単体テスト、結合テスト、デプロイ手順書
- 含まない: [例] インフラ構築、負荷テスト、運用保守
- 外部依存: [例] デザインカンプ納品: MM-DD、外部API仕様確定: MM-DD
- チーム構成: [例] フロントエンド2名、バックエンド1名
- 精度レンジ: [例] 詳細設計完了前のため ±50% (不確実性コーン)

## タスク別見積もり

| # | タスク               | O(楽観) | M(最頻) | P(悲観) | E(期待値) | σ   | 前提・リスク                     |
|---|----------------------|---------|---------|---------|-----------|-----|----------------------------------|
| 1 | 要件定義             | 1.0     | 2.0     | 4.0     | 2.2       | 0.5 | 関係者の合意取得に時間がかかる可能性 |
| 2 | 基本設計             | 2.0     | 3.0     | 6.0     | 3.3       | 0.7 | 外部API仕様が未確定              |
| 3 | 詳細設計             | 1.0     | 2.0     | 3.0     | 2.0       | 0.3 |                                  |
| 4 | フロントエンド実装   | 5.0     | 8.0     | 15.0    | 8.7       | 1.7 | デザインカンプの品質に依存        |
| 5 | バックエンド実装     | 3.0     | 5.0     | 10.0    | 5.5       | 1.2 | 外部API連携の複雑度次第           |
| 6 | 単体テスト           | 2.0     | 3.0     | 5.0     | 3.2       | 0.5 |                                  |
| 7 | 結合テスト・修正     | 2.0     | 4.0     | 8.0     | 4.3       | 1.0 |                                  |
| 8 | コードレビュー       | 1.0     | 2.0     | 3.0     | 2.0       | 0.3 |                                  |
| 9 | 環境構築・CI設定     | 1.0     | 2.0     | 4.0     | 2.2       | 0.5 |                                  |
|10 | ドキュメント・引き継ぎ| 1.0    | 1.5     | 3.0     | 1.7       | 0.3 |                                  |
|   | **小計**             |         |         |         | **35.1**  |     |                                  |

## バッファ計画

| 区分               | 工数(人日) | 備考                              |
|--------------------|------------|-----------------------------------|
| タスク合計(期待値) | 35.1       |                                   |
| リスクバッファ(20%)| 7.0        | 週次で消費状況を可視化             |
| **総計**           | **42.1**   | 約 **42人日**                     |

## カレンダー換算
- チーム有効稼働: 2.5名 × 稼働率80% = 2.0人/日
- 所要日数: 42.1 ÷ 2.0 ≒ 21営業日(約1ヶ月)
- 推奨期間レンジ: 1.0〜1.5ヶ月(精度レンジ ±50% 反映)

## バッファ消費ログ
| 日付       | 消費(人日) | 累計消費 | 残バッファ | 理由              |
|------------|------------|----------|------------|-------------------|
| YYYY-MM-DD | 0.5        | 0.5      | 6.5        | 外部API仕様変更対応|

チェックリスト

• 前提条件(スコープイン/アウト・外部依存)を文書化した
• タスクを1〜3人日以下に分解した
• 三点見積もり(楽観/最頻/悲観)を全タスクに適用した
• テスト・レビュー・環境構築・ドキュメントを個別計上した
• 実装工数に対して非実装工数が1.5倍以上になっているか確認した
• 個別タスクに隠しバッファを積んでいないか確認した
• 全体リスクバッファをまとめて計上した
• 精度レンジ(不確実性コーン)を添えて提示した
• 関係者が前提条件を承認した記録がある
• 次の再見積もりタイミングをスケジュールに入れた

アンチパターン

• 希望納期からの逆算: 「3ヶ月でやれ」→「3ヶ月で収まる見積もり」は見積もりではなく服従。
• 一発見積もりを最後まで使い続ける: フェーズが進んでも初回見積もりのまま運用し、遅延が「突然」発生する。
• テスト・レビュー工数の計上漏れ: 「実装が終わったのに完成しない」の主因。非実装工数は実装の1.5〜2倍。
• 前提を書かずに数字だけ出す: 数字が独り歩きし、スコープ追加が「無料」と誤解される。
• 個別タスクへの隠しバッファ: パーキンソンの法則が働き、バッファが全て消費される。可視化できないため管理不能になる。
• 全タスクを楽観値で合算する: 楽観値の合計は必ず外れる。期待値ベースで集計する。
• 見積もりポーカーを省略して一人の数字を採用: 複数視点の欠如は大きな見落としにつながる。

モデル委譲ガイド

共通原則は [[orchestration]] を参照。

役割	担当モデル	理由
前提設定・リスク係数の判断・最終見積もり承認	司令塔	プロジェクト全体の文脈把握と意思決定が必要
技術的難易度の評価・未知領域のリスク分析	Opus	深い技術知識と多角的なリスク推論が必要
タスク分解の下書き・類似実績の調査・三点見積もりの集計	Sonnet	繰り返し処理と情報収集・整理に適している
コードベース規模の計測・LOCカウント・ファイル数集計	Haiku	高速・低コストな定量計測タスク

関連スキル

• [[task-breakdown]] — 見積もりの前提となるタスク分解
• [[requirements-definition]] — スコープ確定のための要件定義
• [[project-management]] — バッファ消費の追跡と進捗管理
• [[orchestration]] — マルチエージェント委譲の共通原則
• [[architecture-design]] — 技術的不確実性の評価に必要なアーキテクチャ把握
• [[mvp-development]] — スコープを絞ってリスクを下げる開発戦略