Claude Codeで開発見積もりを現実的にする実務ワークフロー

開発見積もりは「何日で終わるかを当てるゲーム」ではありません。実務では、作る範囲、まだ分からないこと、壊したときの影響、レビューや検証にかかる時間を、関係者が同じ絵で見られるようにする作業です。

初心者がつまずきやすいのは、見積もりを実装時間だけで考えることです。たとえば「入力欄を1つ追加するだけ」と見えても、実際にはDBマイグレーション、API型、管理画面、既存テスト、データ移行、権限、通知、ログ、顧客説明まで広がります。ここでいうマイグレーションは、データベースの表や列を変更する作業です。コードと違い、失敗すると元に戻すのが難しいため、見積もりでは特別扱いします。

Claude Codeは、見積もりそのものを魔法のように正解へ近づける道具ではありません。強いのは、リポジトリを読ませて影響範囲を洗い出し、前提と不明点を表にし、リスクを見える形にすることです。Masaが案件相談やClaudeCodeLabの記事改善で使っているのも、「AIに日数を言わせる」ではなく「AIに見落としを減らさせる」使い方です。

公式の考え方とも相性があります。Scrum Guideは経験主義、透明性、検査、適応を重視しています。見積もりも同じで、過去の実績や現在のコードを見ずに作る数字は透明ではありません。タスクの束はGitHub milestonesで追跡できますし、相対見積もりの考え方はAtlassianの見積もりガイドも参考になります。Claude Codeの基本操作は公式overviewとCLI referenceを確認してください。

まず「見積もりの材料」を分ける

実務見積もりは、次の5つに分けると説明しやすくなります。

材料	平易な意味	Claude Codeに任せやすいこと
scope	今回やること、やらないこと	変更ファイル、関連機能、テスト範囲の洗い出し
assumptions	見積もり時点の前提	仕様未確定、既存設計、権限、外部APIの仮置き整理
unknowns	まだ分からないこと	追加調査が必要なファイルや担当者質問の列挙
risk buffer	失敗や手戻りに備える余白	DB、認証、課金、レビュー待ちなどの重み付け
evidence	数字の根拠	過去PR、git履歴、テスト数、変更行数の参照

「2日です」と単発の数字だけを出すと、相手は予定を固定値として受け取ります。おすすめは「最短1.5日、通常3日、リスク込み5日。前提Aが崩れると追加2日」のように幅で出すことです。幅を出すのは弱気ではありません。何を知っていて、何をまだ知らないかを正直に示すための形式です。

flowchart LR
  A["依頼内容"] --> B["repo scan"]
  B --> C["scope分解"]
  C --> D["前提と不明点"]
  D --> E["risk register"]
  E --> F["見積もり幅"]
  F --> G["レビュー"]
  G --> H["顧客向け要約"]

関連して、コードベースを読む順番は大規模コードベース読解ガイドに、曖昧な依頼を直す型はバグレポートテンプレートにまとめています。見積もり後のPR品質はコードレビュー チェックリストと合わせて運用すると崩れにくいです。

実務で使う4つのユースケース

1つ目は、SaaSのプロフィール項目追加です。「電話番号を追加する」だけに見えて、DB、API、フォーム、バリデーション、既存データ、検索、CSVエクスポート、監査ログに波及します。個人情報を扱うなら、ログに出さない、権限を確認する、削除依頼に対応する、といった非機能要件も見積もり対象です。

2つ目は、レガシー画面の不具合修正です。「一覧の絞り込みが効かない」は小さく見えますが、古いクエリ、キャッシュ、URLパラメータ、E2Eテスト、サポート用の再現手順まで触ることがあります。ここでAIに「原因を直して」と頼むより、先に影響範囲と検証方法を出させる方が安全です。

3つ目は、受託開発や社内DXの提案見積もりです。顧客は「管理画面を作りたい」と言いますが、ログイン、ロール、監査、CSV、通知、権限移譲、運用マニュアルまで必要かもしれません。Claude Codeに既存リポジトリやIssueを読ませると、「要件に書かれていないが必要になりそうな作業」を発見しやすくなります。

4つ目は、コンテンツサイトやメディアの改善です。AdSenseやアフィリエイトを考える記事では、表示速度、内部リンク、OGP、構造化データ、翻訳、スクリーンショットまで見積もりに入ります。単にMDXを直すだけなら早いですが、公開品質まで見ると作業は増えます。

失敗しやすい見積もりの落とし穴

一番危険なのは、最初の思いつきをそのまま締切として渡すことです。「多分1日」は、調査前なら願望です。願望が一度共有されると、あとから現実的な数字に直しても「遅延」に見えます。

次に危険なのは、レビューと検証をゼロ扱いすることです。実装が6時間でも、テスト追加、レビュー指摘、修正、ステージング確認、リリース手順でさらに半日から数日かかります。特にGitHub Issuesやmilestonesで複数PRを束ねる場合、レビュー待ちがボトルネックになります。

三つ目は、不明点をバッファに埋めてしまうことです。「なんとなく30%足す」だけでは、何に備えているのか分かりません。外部APIの仕様未確認、DB移行のロールバック未設計、担当者レビュー待ち、テストデータ不足など、不明点は名前を付けて表にします。

四つ目は、AIの出した数字を根拠なしに使うことです。Claude Codeが「3日」と言っても、読ませたファイル、過去PR、テスト、リスクが出ていなければ単なる作文です。AIには「数字」より先に「根拠」を出させます。

もう一つ、初心者ほど見落としやすいのが稼働率です。1日8時間の会社でも、会議、レビュー待ち、問い合わせ対応、CI失敗の再実行、リリース承認を引くと、実装に集中できる時間は6時間前後になることがあります。見積もり表で1日を何時間として扱うかを最初に決めておくと、営業日と実作業時間のズレを説明しやすくなります。

ステップ1: リポジトリの外形を読む

最初の10分は、編集せずにリポジトリの外形を取ります。rgはripgrepという高速検索ツールです。生成物や依存パッケージを除外して、どの領域が大きいかを見ます。

git status --short
git branch --show-current
git rev-parse --show-toplevel

rg --files \
  -g '!*node_modules*' \
  -g '!dist' \
  -g '!build' \
  -g '!coverage' \
  -g '!*.lock' \
  | sort \
  | head -200

find . -maxdepth 3 \( \
  -name package.json -o \
  -name pyproject.toml -o \
  -name go.mod -o \
  -name Cargo.toml -o \
  -name AGENTS.md -o \
  -name CLAUDE.md -o \
  -name README.md \
\) -print

その結果をClaude Codeに渡し、読み取り専用で地図を作らせます。

claude -p "
読み取り専用でrepo scanをしてください。
編集、ファイル作成、依存追加はしないでください。

出力:
1. アプリ/パッケージ/サービス
2. 起動、テスト、ビルドの入口
3. 生成物や読まないフォルダ
4. 今回の見積もりで必ず読むべき10ファイル
5. まだ見積もれない理由
"

この段階では日数を聞きません。日数を先に聞くと、AIは根拠作りを省いてしまいます。

ステップ2: 作業を分解する

次に、依頼を作業単位に分解します。作業単位は「1つのPRにできるか」「レビューできるか」「検証できるか」で切ります。

claude -p "
タスク: ユーザーの電話番号をプロフィールで登録、表示、編集できるようにする。

このタスクを、レビュー可能な作業単位に分解してください。
各行に次を含めてください。
- 作業名
- 触る可能性が高いファイル
- 実装内容
- テスト内容
- 完了条件
- 小/中/大のサイズ

やらないことも明記してください。
推測した仕様は assumption として分けてください。
"

出力が大きすぎる場合は、まずDB、API、UI、テスト、リリースの5分類に絞ります。見積もりは「細かく分ければ正確」ではありません。レビューできる粒度に分けることが大切です。

ステップ3: 前提条件の表を作る

前提は、あとで揉める場所です。仕様、技術、運用、体制に分けて表にします。

| ID | Assumption | Why it matters | Owner | Confirm by |
| --- | --- | --- | --- | --- |
| A1 | Phone number is optional | Required fields change validation and migration | PM | 2026-06-05 |
| A2 | Web only, no mobile app change | Mobile release adds review and store delay | PM | 2026-06-05 |
| A3 | Existing user rows stay null | Backfill work is not included | Tech lead | 2026-06-06 |

Claude Codeには、この表の穴を探させます。

claude -p "
以下のassumptions tableをレビューしてください。
見積もりを壊しそうな前提、確認相手、確認期限の不足を指摘してください。
不明点をrisk registerへ移すべきものも分けてください。
"

ステップ4: リスク台帳を作る

リスク台帳（risk register）は、「何が起きると予定が崩れるか」を並べた表です。難しい言葉に見えますが、中身は単純です。

| Risk | Trigger | Impact | Mitigation | Buffer |
| --- | --- | --- | --- | --- |
| DB rollback is unclear | migration changes existing rows | High | dry-run and rollback plan | 0.5-1 day |
| External CRM also stores phone | CRM field mapping appears | Medium | check integration owner | 0.5 day |
| Review queue is full | no reviewer within 24h | Medium | book review slot early | 1 day |
| Test data is missing | no user with profile edge cases | Medium | create fixtures first | 0.5 day |

バッファは作業者の怠けではありません。未知や待ち時間を計画に入れるための仕組みです。特に認証、課金、個人情報、削除処理、マイグレーションは、低く見積もるほどあとで高くつきます。

ステップ5: 見積もり幅を計算する

見積もりは表計算でもできますが、チームで再利用するなら小さなスクリプトにすると便利です。次の例はそのままコピーして動きます。

// estimate-range.mjs
const tasks = [
  { name: "Repo scan and design check", hours: 2, risk: 1.1 },
  { name: "DB migration and schema", hours: 4, risk: 1.4 },
  { name: "API contract and validation", hours: 5, risk: 1.2 },
  { name: "Profile UI update", hours: 6, risk: 1.2 },
  { name: "Tests and fixtures", hours: 5, risk: 1.3 },
  { name: "Review fixes and release note", hours: 3, risk: 1.2 },
];

const base = tasks.reduce((sum, task) => sum + task.hours, 0);
const likely = tasks.reduce((sum, task) => sum + task.hours * task.risk, 0);
const low = Math.max(base * 0.8, base - 4);
const high = likely * 1.35;

const day = 6;
const format = (hours) => `${hours.toFixed(1)}h / ${(hours / day).toFixed(1)}d`;

console.log(`Low:    ${format(low)}`);
console.log(`Likely: ${format(likely)}`);
console.log(`High:   ${format(high)}`);

node estimate-range.mjs

ここで大切なのは、係数を「真実」と呼ばないことです。risk: 1.4は、DB作業に不確実性があるというメモです。係数を変えたら、なぜ変えたかをPRやIssueに残します。

ステップ6: レビュー用プロンプトで見積もりを批判させる

見積もりを作ったら、Claude Codeに批判的レビューをさせます。自分で作った見積もりは、どうしても楽観寄りになります。

You are a critical project estimation reviewer.

Review this estimate before I share it with a client.
Find:
1. hidden scope
2. weak assumptions
3. missing tests
4. missing rollout or rollback work
5. fake precision
6. tasks that should be split

Return findings first.
Then provide a revised low / likely / high range.
Do not make the estimate look more certain than the evidence supports.

「批判的に」と明示するのがポイントです。通常のプロンプトでは、AIは文章を整える方向に寄りがちです。見積もりレビューでは、きれいな提案書より、危ない抜け漏れの発見が価値です。

ステップ7: 顧客向け要約に変換する

社内メモをそのまま顧客に渡すと、細かすぎて読まれません。最後に、前提、範囲、除外、見積もり幅、次の確認事項だけに絞ります。

# Development Estimate Summary

## Scope
- Add optional phone number to user profile.
- Update DB schema, API validation, profile UI, and tests.
- Include release note and manual verification.

## Not included
- SMS notification.
- Mobile app release.
- Historical data backfill.
- CRM integration changes unless confirmed.

## Estimate
- Low: 3 business days
- Likely: 4-5 business days
- High: 7 business days if CRM or migration rollback work expands

## Assumptions
- Phone number is optional.
- Web only.
- Existing users can keep the value empty.

## Risks
- DB rollback plan must be reviewed before implementation.
- Reviewer availability may add one calendar day.

## Next decision
- Confirm whether CRM and mobile app are in scope by 2026-06-05.

日本語で渡すなら、同じ構成で十分です。「やらないこと」を先に書くと、スコープ追加の会話がしやすくなります。

GitHub Issuesとmilestonesへの落とし込み

見積もりは、Issueに残して初めて運用できます。GitHubのmilestoneは、複数のIssueやPRをまとめて進捗を見るための機能です。小さなチームでも、次のようなIssue本文を使うと、あとで実績比較ができます。

## Estimate
- Low:
- Likely:
- High:
- Confidence: Low / Medium / High

## Scope
- [ ]

## Out of scope
- [ ]

## Assumptions
- [ ]

## Risks
- [ ]

## Verification
- [ ] Unit tests:
- [ ] Integration tests:
- [ ] Manual check:

## Actual result
- Started:
- Merged:
- Extra work found:
- What to adjust next time:

この「Actual result」を残すと、次回の見積もりが急に強くなります。過去の似たPRが平均5営業日だった、レビュー指摘が2回あった、DB作業だけ毎回膨らむ、といったチーム固有の学習が積み上がるからです。

相談・収益化につなげるなら

開発見積もりの記事は、単なるノウハウで終わらせず、相談導線と相性が良いテーマです。読者は「自分の案件ではどう分けるべきか」「顧客へどう説明するか」「Claude Codeをチームに入れて大丈夫か」で困っています。

ClaudeCodeLabでは、見積もりテンプレート、PRレビュー手順、Claude Code導入ルール、社内研修の相談を受けています。自社のリポジトリ、Issue、提案書に合わせて見積もりフローを作りたい場合は、Claude Code研修・相談から現状を送ってください。コードを外部に出せない場合でも、構成、リスク分類、レビュー観点だけで設計できます。

この記事で紹介した内容を実際に試した結果

Masaが小さなプロフィール項目追加をこの手順で見直したところ、最初は「UI修正半日」と見ていた作業が、DB、API、既存CSV、監査ログ、テスト、レビュー待ちを含めて「通常4-5営業日」と説明できる形になりました。数字が大きくなったのではなく、隠れていた作業が見えるようになった感覚です。Claude Codeに任せて良かったのは、日数の断言ではなく、見落としていたファイルと不明点を早い段階で表にできたことでした。