Claude Codeで開発見積もりの精度を3倍にする7つの実践テクニック

「3日でできます」と言ったタスクが2週間かかる——プロジェクト管理あるある現象です。原因は 見積もり時にコードを読んでいない こと。Claude Code に既存コードを読ませて見積もりすれば、精度が3倍に跳ね上がります。

1. 影響範囲を読んで見積もる

タスクを受けたら、まず触る範囲を Claude Code に調査させます。

claude -p "
タスク: ユーザーテーブルに 'phone_number' カラムを追加し、
プロフィール画面で表示・編集できるようにする。

このタスクで触る必要があるファイルを全て列挙:

1. データベース層（マイグレーション、スキーマ）
2. API 層（リクエスト/レスポンス型）
3. UI 層（フォーム、表示）
4. テスト（既存 + 新規）
5. ドキュメント

各ファイルの変更行数の見積もりも出してください。
"

「3ファイル変更」と思っていたタスクが「14ファイル + 6テスト」と判明することは日常茶飯事。

2. 過去類似タスクの所要時間を参照

Git 履歴から類似タスクの実績を抜き出します。

claude -p "
過去6ヶ月で、ユーザーテーブルにカラムを追加した PR を全て探して:

1. PR タイトルと番号
2. 着手から merge までの日数
3. 変更ファイル数
4. レビュー往復回数
5. 本番反映後のバグ件数

git log --grep='add.*column' --since='6 months ago' で検索。
平均と中央値を出して、今回の見積もりに使える基準値を提案。
"

「過去の類似PRは平均5営業日」というデータがあれば、根拠ある見積もりが出せます。

3. 隠れた依存関係を洗い出す

「想定外」が膨らみの最大の原因。

claude -p "
'phone_number' カラム追加で、以下の隠れた影響を調査:

1. 既存の検索/フィルタ機能で対応が必要か
2. 通知機能（SMS など）への影響
3. 外部API連携（CRM、メール送信）への影響
4. 個人情報保護（GDPR / 改正個人情報保護法）の対応必要性
5. 既存の analytics / event tracking への影響
6. mobile アプリ側の対応

各項目の対応コストを高/中/低で評価。
"

GDPR や mobile アプリの対応が後から発覚すると、見積もりが数倍に膨らみます。

4. リスクバッファを自動算出

不確実性を数値化します。

claude -p "
今回のタスクのリスク要因と、それぞれのバッファ係数を算出:

評価項目:
- 関連コードの理解度（高/中/低）
- 関連テストのカバレッジ
- 触る箇所の凝集度
- 過去のバグ多発エリアか
- 外部依存の数
- レビュアーの稼働状況

それぞれ 1.0 〜 2.0 のバッファ係数を割り当て、
最終的な見積もり時間 = 純粋実装時間 × 係数の積 で出してください。
"

「実装3日 × 係数1.8 = 5.4日」と機械的に算出できます。

5. 見積もり根拠ドキュメントを生成

ステークホルダー向けに説明可能な形に。

claude -p "
今回のタスクの見積もり根拠を docs/estimates/{task-id}.md に出力:

## タスク概要
## 影響範囲（Claude調査結果）
## 過去類似タスクの実績
## リスク要因とバッファ係数
## 最終見積もり（楽観/標準/悲観の3シナリオ）
## 前提条件と除外スコープ

PMが読んで判断できる粒度で。
"

「3日です」だけだと根拠を聞かれた時に説明できません。根拠ドキュメントが説得力を生む わけです。

6. 定期的な見積もり vs 実績の差分分析

精度を継続的に改善するためのふりかえり。

claude -p "
直近1ヶ月で完了したタスクについて:

1. 当初見積もりと実績の差分を集計
2. 精度の高かったタスク / 低かったタスクの傾向
3. 見積もりが甘かった原因の分類
4. 次回から取り入れるべき改善点

docs/estimates/retrospective-$(date +%Y-%m).md に出力。
チームの月次レトロで使える形式で。
"

「いつもDB周りで2倍になる」のような 個人/チーム固有のバイアス が可視化できます。

7. 大規模タスクは段階見積もりする

大きいタスクは一発見積もりせず、段階的に。

claude -p "
タスク 'チェックアウトフロー全面リニューアル' を段階見積もりで分解:

Phase 1: 調査（既存コード分析、要件定義）→ X日
Phase 2: 設計（テクニカルデザインドキュメント）→ Y日
Phase 3: PoC（最小実装）→ Z日

Phase 1完了後に Phase 2-3 の見積もりを精緻化する前提で、
まず Phase 1 のみ詳細見積もりを出す。

これを 'Rolling Wave Planning' と呼びます。
"

不確実性の高い大規模タスクは、段階見積もり で進めるのが鉄則。一発見積もりは大幅な乖離の原因になります。

CLAUDE.md に見積もりルールを書く

チーム全体で使う基準を明文化。

## 見積もりルール

### 必須プロセス
- 1日以上のタスクは Claude Code で影響範囲調査をしてから見積もる
- 3日以上のタスクはリスクバッファを明示
- 5日以上のタスクは段階見積もりを採用

### バッファ係数の基準
- 触ったことのないコード: 1.5x
- カバレッジ50%未満エリア: 1.3x
- 外部API連携あり: 1.4x
- レガシーコード: 1.8x

### コミュニケーション
- 「楽観/標準/悲観」の3シナリオで提示
- 想定外が出たら24時間以内にエスカレーション

やってはいけないこと

❌ 経験と勘だけで見積もる

人間の見積もりはほぼ確実に楽観バイアスがかかります。Claude Code でコードを読ませて補正。

❌ バッファをゼロにする

「ジャストで見積もる」は失敗の元。最低でも 1.3x のバッファを入れる。

❌ 見積もりを後から正当化しない

実績との差分は隠さず、レトロで分析。次回の精度向上につなげる。

❌ 段階見積もりを諦める

「全工程の見積もりが今欲しい」と言われても、不確実な段階で確約しない。Rolling Wave Planning を提案。

まとめ

• 影響範囲を Claude Code に調査させて見積もる
• 過去類似タスクの実績を引用
• 隠れた依存関係を網羅
• リスクバッファを数値化
• 見積もり根拠ドキュメントを生成
• 月次の見積もり精度ふりかえり
• 大規模タスクは段階見積もり
• CLAUDE.md でチームのルール統一

見積もり精度が上がると、チームの信頼性も上がります。「言ったことを期日に終わらせる」が当たり前になれば、より大きなタスクを任せてもらえる好循環が生まれます。

関連記事: チーム開発ガイド / PR品質を10倍にする / 新人オンボーディング

公式ドキュメント: Anthropic Claude Code / Rolling Wave Planning (PMI)