工数決定
各画面の開発工数を見積もります。
最小〜最大の範囲で指定し、不確実性を明示する2点推定を採用しています。
なぜ範囲で見積もるのか
1点推定の問題点
- • 「5人日」と言い切ると、実際には4〜7人日のばらつきがあっても見えない
- • 不確実性が隠れるため、リスク判断ができない
- • 見積もりが外れたとき「誰の責任か」という不毛な議論になりがち
- • 経験豊富なエンジニアほど「それは条件による」と言いたくなる
2点推定のメリット
- • 不確実性が可視化され、リスクのある見積もりが一目で分かる
- • 「最悪ケースでも〇〇日」という保守的な計画が立てやすい
- • 見積もりに幅があることを発注者と共有でき、期待値調整がしやすい
- • 中央値（期待値）は自動計算されるので入力の手間は変わらない
入力する項目
最小工数（人日）
楽観的なケースでの工数。すべてがうまくいった場合の最短見積もりです。
考え方
- • 要件が明確で変更がない場合
- • 類似実装の経験がある場合
- • 外部連携がスムーズにいく場合
- • レビューが一発で通る場合
最大工数（人日）
悲観的なケースでの工数。予期せぬ問題が発生した場合の最長見積もりです。
考え方
- • 仕様の解釈違いで手戻りが発生する場合
- • 外部APIの仕様が想定と異なる場合
- • パフォーマンス問題でチューニングが必要な場合
- • レビュー指摘で大幅な修正が入る場合
最大工数を大きく見積もる要因
- • 外部システム連携（API、決済、認証）
- • 初めて使う技術・フレームワーク
- • 要件の不確実性が高い
- • レガシーコードへの影響調査が必要
期待値（自動計算）
最小と最大の中央値として自動計算されます。ROI計算にはこの値が使われます。
期待値 = (最小工数 + 最大工数) / 2
メモ（前提・リスク）
見積もりの前提条件やリスク要因を記述します。
記入例
- • 「既存検索APIを使う前提。新規開発なら+3人日」
- • 「デザインデータ確定済みの前提」
- • 「決済連携の仕様書待ち。遅れると最大工数に近づく」
入力例
| 画面 | 最小 | 最大 | 期待値 | メモ |
|---|---|---|---|---|
| トップ | 2人日 | 4人日 | 3人日 | 静的コンテンツ中心 |
| 検索結果 | 4人日 | 8人日 | 6人日 | フィルタ複雑、API待ち |
| カート | 3人日 | 5人日 | 4人日 | 決済連携は別画面 |
Claude Code での操作例
あなた
「toishiの工数見積もりを追加して。 検索結果ページは4〜8人日（フィルタ複雑）。 商品詳細ページは3〜5人日」
AI
工数見積もりを追加しました。
【検索結果ページ】
- 最小: 4人日 / 最大: 8人日
- 期待値: 6人日
- メモ: フィルタ複雑
【商品詳細ページ】
- 最小: 3人日 / 最大: 5人日
- 期待値: 4人日
合計期待値: 10人日（範囲: 7〜13人日）
承認のポイント
承認者はここをチェック
- ✓ 最小と最大の幅が妥当か（差が大きすぎると不確実性が高い）
- ✓ メモに前提条件・リスクが記載されているか
- ✓ 類似画面間で工数のばらつきが説明できるか
- ✓ テスト工数、レビュー工数が含まれているか
- ✓ 不確実性が高い項目は、なぜ高いか説明があるか
ベストプラクティス
幅が大きいときは要因を分解
「2〜10人日」のように幅が大きい場合、不確実性の要因を特定し、 先に調査・検証してから見積もり直すことを検討します。
実績データを蓄積する
プロジェクト終了後に「見積もり vs 実績」を記録し、次回の見積もり精度を上げます。 「いつも最大に近い」なら、最小の見積もりが甘い傾向があります。
発注者には範囲で伝える
「45人日」ではなく「40〜55人日」と伝えることで、期待値調整がしやすくなります。 「最大でも〇〇日」という安心感も提供できます。
エンジニアと一緒に見積もる
PMだけで見積もらず、実装担当エンジニアの意見を聞きます。 「このAPIは癖がある」「ここはライブラリで簡単」など、現場の知見を反映できます。
なぜこの設計なのか
最小〜最大の2点推定 — 「5人日」ではなく「3〜8人日」で不確実性を表現
「5人日」と言い切ると、実際には4〜7人日のばらつきがあっても見えません。 範囲で見積もることで、「最悪ケースでも8人日」という保守的な計画が立てられ、 見積もりが外れたときの「誰の責任か」という不毛な議論を避けられます。
画面単位ではなくユーザーニーズ単位で見積もる — 横断的なロジックの見落とし防止
画面単位で見積もると、「認証基盤」のような複数画面で共有するロジックを 各画面に重複カウントしてしまいます。 ユーザーニーズ単位で見積もることで、共有工数を正しく按分でき、ROI計算の精度が上がります。
根拠を残す — 「なぜ5人日か」が不明だと、スコープ調整時に判断材料がない
「検索画面は5人日」だけでは、予算オーバー時に「どこを削れるか」が分かりません。 「フロント2日、バックエンド2日、テスト1日」のように分解し、 前提条件（「Elasticsearch導入済み」）を記録することで、スコープ調整の判断材料になります。