「たぶん1日」で爆死した僕の、開発見積もりタスク分解術

「電話番号を入力できるようにするだけだよね。たぶん1日かな」

会議でそう口走った僕は、その瞬間、自分の首をしめていました。1日と言った作業は、最終的に5営業日かかりました。DBの列を増やし、API側の型を直し、フォームのバリデーションを足し、既存ユーザーの空データをどう扱うか悩み、CSVエクスポートに列を追加し、監査ログに個人情報が漏れないか確認し、テストを書き、レビュー待ちで丸一日溶かした。「入力欄1つ」のはずが、気づけば8ファイルを触っていました。

つらいのは、遅れたこと自体じゃありません。最初に「1日」と言ってしまったせいで、4日分の正当な仕事が全部「遅延」に見えたことです。

見積もりって、未来を当てるゲームじゃないんですよね。「何を分かっていて、何をまだ知らないか」を相手と共有する作業なんです。今日はその話を、僕の失敗込みで書きます。Claude Codeを「日数を言わせる道具」じゃなく「抜けを洗い出す壁打ち相手」として使う手順も、コピペで動くコードつきで紹介します。

この記事の要点

• 見積もりは日数当てではなく、「範囲・前提・不明点・リスク・根拠」を相手と共有する作業。
• 単発の「2日」ではなく、最短／通常／リスク込みの3つの幅で出す。それだけで会話が変わる。
• タスク分解は「細かさ」より**「1つのPRにできてレビューできて検証できる」粒度**で切る。
• 過小評価の正体は「実装時間しか数えていない」こと。レビュー・検証・待ち時間が抜け落ちる。
• Claude Codeには数字を言わせず、先にコードを読ませて影響範囲と不明点を表にさせる。

なぜ見積もりは決まって低く出るのか

人は、頭に浮かんだ「うまくいったときの絵」を見積もります。電話番号の例なら、「カラム足してフォーム直して、はい完成」という最短ルートだけが見える。これは計画錯誤（planning fallacy）と呼ばれる、人間の標準装備みたいなクセです。

僕の実感だと、低く出る原因はだいたいこの4つに集約されます。

• 実装時間しか数えていない。コードを書く時間は氷山の一角。
• レビューと検証をゼロ扱い。実装6時間でも、テスト・指摘修正・ステージング確認で半日〜数日乗る。
• 待ち時間を計画に入れていない。レビュー待ち、仕様確認の返信待ち、CIの再実行。
• 不明点を「気合い」で埋めている。「なんとなく3割増し」では、何に備えているか自分でも説明できない。

この記事のゴールは、この4つを潰す型を手に入れることです。

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

いきなり日数を出そうとするから事故ります。先に材料を5つに仕分けると、見積もりが一気に説明可能になります。

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

ここでマイグレーションという言葉だけ補足します。データベースの表や列を変える作業のことで、コードと違って失敗すると元に戻すのが難しい。だから見積もりでは特別扱いします。後述しますが、僕がいちばん痛い目を見るのは毎回ここです。

タスク分解は「PR1個」の粒度で切る

分解というと「細かく刻むほど正確」と思いがちですが、逆です。細かすぎると管理コストで溺れます。僕の基準はシンプルで、**「1つのPRにできるか／レビューできるか／検証できるか」**の3つで切る。これに当てはまらない塊は、大きすぎるか小さすぎます。

電話番号追加なら、こう割ります。

作業単位	触る可能性が高い場所	サイズ	検証
repo scan・設計確認	（読むだけ・編集なし）	小	影響範囲メモ
DBマイグレーション	schema、migration	中	dry-run + ロールバック確認
API契約・バリデーション	endpoint、validator	中	単体テスト
プロフィールUI更新	form、component	中	表示・編集の手動確認
テストとフィクスチャ	test、fixtures	中	CI green
レビュー指摘修正・リリースノート	全体	小	レビュー承認

ポイントは、最初の「repo scan」を独立した作業として置くこと。ここを省くと、後ろの全部が憶測になります。それと「やらないこと」を必ず一行書く。SMS通知はやらない、モバイルアプリは触らない、過去データの埋め戻しはしない——これを先に宣言しておくと、後からの「ついでにこれも」を冷静に追加見積もりへ回せます。

不確実性コーンを思い出す

ここで頭に入れておきたいのが、不確実性コーン（cone of uncertainty）という考え方です。プロジェクトの初期、つまり情報がいちばん少ない段階では、見積もりは現実の数倍ブレてもおかしくない。調査が進むにつれて、その振れ幅がコーン（円すい）状にすぼまっていく、というモデルです。

何が言いたいかというと、調査ゼロの段階で出した「1日」は、振れ幅の真ん中ですらないということ。コーンがいちばん開いている地点で、しかも楽観側の端っこを口にしているわけです。僕の「たぶん1日」は、まさにこれでした。

だから初期見積もりは点ではなく幅で出す。そして調査が進んだら遠慮なく更新する。これは「前言撤回」ではなく、コーンがすぼまった結果の自然な精緻化です。Atlassianの見積もりガイドも、相対見積もりと再見積もりを前提に話を組み立てています。

3点見積もりとバッファの現実的な置き方

幅で出すと言っても、適当に「3割増し」では根拠になりません。僕が使っているのは3点見積もり（three-point estimate）です。各タスクに「うまくいくと（O）／普通だと（M）／こじれると（P）」の3つを置いて、ざっくり (O + 4M + P) / 6 で期待値を出す。PERTと呼ばれる古典的な手法ですが、難しく考えなくていいです。要は楽観と悲観の両方を口に出させるのが狙いです。

バッファについて、ひとつ強調したいことがあります。バッファは作業者の怠けでも保険でもなく、未知と待ち時間を計画に入れる正規の枠です。罪悪感で削らないでください。特にこの5つは、低く見積もるほど後で高くつきます。

• 認証・権限まわり（壊すと全ユーザーに影響）
• 課金・決済（お金が絡むとロールバックが地獄）
• 個人情報・削除処理（法対応がついてくる）
• DBマイグレーション（戻せない）
• 外部APIとの連携（相手の都合に振り回される）

逆に、ボタンの色を変える、文言を直す、といった「壊しても戻せる」作業はバッファを薄くしていい。重みをメリハリつけて配るのがコツです。

コピペで動く：3点見積もりを計算するスクリプト

表計算でもできますが、チームで使い回すなら小さなスクリプトが楽です。次のコードはそのままコピーして動きます。各タスクに楽観・通常・悲観の時間とリスク係数を持たせ、最短／通常／リスク込みの幅を出します。

// estimate-range.mjs
// 各タスク: o=楽観, m=通常, p=悲観 (時間), risk=不確実性の重み(1.0=確実)
const tasks = [
  { name: "repo scan・設計確認", o: 1, m: 2, p: 4, risk: 1.1 },
  { name: "DBマイグレーション",   o: 3, m: 4, p: 9, risk: 1.4 },
  { name: "API契約・バリデーション", o: 4, m: 5, p: 8, risk: 1.2 },
  { name: "プロフィールUI更新",   o: 4, m: 6, p: 9, risk: 1.2 },
  { name: "テストとフィクスチャ", o: 4, m: 5, p: 8, risk: 1.3 },
  { name: "レビュー指摘・リリースノート", o: 2, m: 3, p: 6, risk: 1.2 },
];

// PERT期待値: (楽観 + 4*通常 + 悲観) / 6
const pert = (t) => (t.o + 4 * t.m + t.p) / 6;

const likely = tasks.reduce((s, t) => s + pert(t) * t.risk, 0);
const low = tasks.reduce((s, t) => s + t.o, 0);          // 全部うまくいった世界
const high = tasks.reduce((s, t) => s + t.p * t.risk, 0); // 全部こじれた世界

const HOURS_PER_DAY = 6; // 会議や待ちを引いた「実作業」時間
const fmt = (h) => `${h.toFixed(1)}h（${(h / HOURS_PER_DAY).toFixed(1)}営業日）`;

console.log("--- 開発見積もり ---");
for (const t of tasks) {
  console.log(`  ${t.name.padEnd(22)} 期待値 ${pert(t).toFixed(1)}h`);
}
console.log("-------------------");
console.log(`最短     : ${fmt(low)}`);
console.log(`通常     : ${fmt(likely)}`);
console.log(`リスク込み: ${fmt(high)}`);

実行はこれだけです。

node estimate-range.mjs

大事なのは、係数を「真実」と呼ばないこと。risk: 1.4 は「DB作業は不確実だよ」というメモにすぎません。1日を6時間で計算しているのも意図的で、会議・レビュー待ち・問い合わせ対応・CI再実行を引くと、実装に集中できる時間は8時間の会社でも6時間前後に落ちるからです。係数や時間配分を変えたら、なぜ変えたかをPRやIssueに残す。そうやって数字に履歴を持たせると、次回から見積もりが急に強くなります。

Claude Codeは「数字」より先に「根拠」を出させる

ここからが本題のClaude Code活用です。やってはいけないのは、いきなり「これ何日かかる？」と聞くこと。AIは聞かれた質問に答えようとするので、根拠作りをすっ飛ばしてもっともらしい日数を作文します。

正しい順番は、先にコードを読ませて影響範囲と不明点を出させ、日数は最後です。最初の10分は編集させず、読み取り専用で地図を作らせます。

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

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

この段階では日数を答えないでください。
"

地図ができたら、依頼を作業単位に分解させます。

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

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

やらないことも明記してください。
推測した仕様は assumption(前提) として別枠に分けてください。
"

最後に、できた見積もりをわざと批判させます。自分で作った見積もりは必ず楽観に寄るので、ここで叩いておく。

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 a revised low / likely / high range.
Do not make the estimate look more certain than the evidence supports.

「critical（批判的に）」と明示するのが効きます。普通に頼むと、AIは提案書を綺麗に整える方向へ寄る。見積もりレビューで価値があるのは、整った文章ではなく、危ない抜け漏れの指摘です。

コードを読ませる順番に自信がなければ大規模コードベース読解ガイドを、曖昧な依頼を直す型はバグレポートテンプレートにまとめてあります。見積もり後のPR品質はコードレビュー チェックリストと合わせると崩れにくいです。Claude Code自体の基本操作は公式overviewを見てください。

前提とリスクは「名前を付けて表」にする

不明点をバッファに溶かして「30%増し」で済ませると、後で必ず揉めます。代わりに、前提もリスクも一つずつ名前を付けて表に書き出す。揉める場所を先に可視化しておくわけです。

前提の表はこんな形です。

| ID | 前提 | なぜ効くか | 確認相手 | 期限 |
| --- | --- | --- | --- | --- |
| A1 | 電話番号は任意入力 | 必須にするとバリデーションと移行が増える | PM | 2026-06-09 |
| A2 | Webのみ、モバイル改修なし | モバイルは審査・ストア反映の遅延が乗る | PM | 2026-06-09 |
| A3 | 既存ユーザーはnullのまま | 埋め戻し作業は今回含めない | Tech lead | 2026-06-10 |

リスクの表（リスク台帳）は「何が起きると予定が崩れるか」を並べたものです。難しそうな名前ですが中身は単純です。

| リスク | 引き金 | 影響 | 対策 | バッファ |
| --- | --- | --- | --- | --- |
| DBの切り戻し手順が不明 | 既存行を変えるマイグレーション | 大 | dry-runと切り戻し計画 | 0.5〜1日 |
| 外部CRMも電話番号を持つ | 連携の項目マッピングが発覚 | 中 | 連携担当に確認 | 0.5日 |
| レビュー待ちが詰まる | 24時間以内に空きなし | 中 | レビュー枠を早めに予約 | 1日 |
| テストデータ不足 | 端値ケースのユーザーがいない | 中 | 先にフィクスチャ作成 | 0.5日 |

この表があると、顧客への説明が「なんか膨らみました」から「この前提が崩れると2日増えます」に変わります。説得力がまるで違う。

顧客向けには「やらないこと」を先に書く

社内メモをそのまま客に渡すと、細かすぎて読まれません。最後に、前提・範囲・除外・見積もり幅・次の確認事項だけに絞ります。順番が肝で、「やらないこと」を範囲の直後に置くと、後からのスコープ追加の会話が驚くほど楽になります。

# 開発見積もりサマリ

## やること
- ユーザープロフィールに任意の電話番号を追加
- DBスキーマ・APIバリデーション・UI・テストを更新
- リリースノートと手動確認まで含む

## やらないこと
- SMS通知 / モバイルアプリのリリース
- 既存データの埋め戻し / CRM連携の変更（要確認）

## 見積もり
- 最短: 3営業日
- 通常: 4〜5営業日
- リスク込み: 7営業日（CRMかマイグレーション切り戻しが膨らんだ場合）

## 前提
- 電話番号は任意 / Webのみ / 既存ユーザーは空のままでよい

## 次に決めること
- CRMとモバイルが範囲かを 2026-06-09 までに確定

そして、この見積もりはIssueに残して初めて運用に乗ります。GitHubのmilestonesは複数IssueやPRをまとめて進捗を見る機能です。見積もり後の実績をmilestoneで追うなら、GitHub milestonesが手堅い。Issue本文に「Actual result（実績）」欄を一行足して、開始日・マージ日・追加で見つかった作業を書き残す。これだけで「DB作業だけ毎回1.5倍に膨らむ」みたいなチーム固有のクセが蓄積されて、次の見積もりが鋭くなります。

考え方の土台としてはScrum Guideの経験主義（過去の実績で調整する）が効きます。過去の実績も現在のコードも見ずに出した数字は、結局ただの願望ですから。

よくある質問

Q. 見積もりを幅で出すと「で、結局いつ終わるの？」と詰められます。 通常値（3点見積もりの期待値）を「お約束ライン」として提示しつつ、「ただし前提Aが崩れると最大7日です」と幅もセットで伝えます。一点だけ言うと固定値として独り歩きするので、必ず「何が起きたら延びるか」をワンセットにするのがコツです。

Q. タスクはどこまで細かく分ければいいですか？ 「1つのPRにできて、レビューできて、検証できる」が上限の目安です。30分で終わる作業まで刻むと管理コストで赤字になります。逆に「3日かかる1タスク」は中身が見えていない証拠なので、分割します。

Q. Claude Codeの出した日数は信じていいですか？ 日数そのものは信じません。読ませたファイル・過去PR・テスト・リスクが添えられていなければ、それはただの作文です。AIには「数字」より先に「根拠（影響範囲と不明点）」を出させて、日数は人間が最後に決めるのが安全です。

Q. バッファを乗せると「サボる気か」と思われそうで削ってしまいます。 バッファは余白ではなく、未知と待ち時間という現実を計画に入れた結果です。リスク台帳で「何に対する何日か」を名前付きで示せば、サボりではなく備えだと伝わります。むしろ削るほど、後で「遅延」として倍返しされます。

Q. 小さな修正でも毎回この手順を踏むんですか？ 踏みません。文言修正やCSSの微調整など「壊しても戻せる」作業は、幅もバッファも薄くていい。この手順をフルで使うのは、DB・認証・課金・個人情報・外部連携が絡むときだけで十分です。

実際に試した結果

冒頭の「たぶん1日」事件のあと、僕は同じプロフィール項目追加をこの手順で組み直してみました。結果は「通常4〜5営業日」。数字が4倍に膨らんだように見えますが、感覚はまったく逆でした。膨らんだのではなく、最初から隠れていた作業がやっと見えただけです。DB、API、既存CSV、監査ログ、テスト、レビュー待ち——全部、初日から表に載っていれば「遅延」になりようがなかったものでした。

Claude Codeに任せて一番よかったのは、日数を断言させたことではありません。僕が見落としていたファイルと不明点を、コードを読んで早い段階で表にしてくれたことです。賢いAIに正解の日数を当てさせるより、抜けを先に潰すほうが、見積もりはずっと当たる。これが今の僕の結論です。

見積もりは技術というより、誠実さの形式だと思っています。自分の案件でどう範囲を切るか、顧客へどう説明するかで詰まったら、Claude Code研修・相談から現状を送ってください。コードを外に出せなくても、構成とリスク分類とレビュー観点だけで設計できます。