株式会社renue
AI導入・DXの悩みをプロに相談してみませんか?
AIやDXに関する悩みがありましたら、お気軽にrenueの無料相談をご利用ください。 renueのAI支援実績、コンサルティングの方針や進め方をご紹介します。
エンジニアの見積もりが外れる構造的な理由
「2日で終わると思ったら1週間かかった」——エンジニアの見積もりが外れるのは、能力の問題ではなく構造の問題です。人間は楽観バイアスを持ち、「最良のシナリオ」で見積もる傾向があります。さらにAI開発では、非決定性・API障害・データ品質問題という従来にない不確実性が加わります。
本記事では、AI開発プロジェクトの工数見積もりを精度よく行うための3層分解法とバッファ設計を解説します。
見積もりの3層分解法
第1層:WBS(作業分解構造)
大きなタスクを最大4時間単位まで分解します。分解の粒度が細かいほど見積もり精度が上がります。
❌ 粗い見積もり 「認証機能の実装:3日」 ✅ 3層分解 認証機能の実装 ├ JWT発行ロジック:4h ├ ミドルウェア作成:3h ├ ロール別権限チェック:4h ├ テスト作成:3h ├ CLAUDE.mdセキュリティセクション更新:1h └ PRレビュー対応:2h 合計:17h(≒2.5日)+ バッファ20% = 3日
第2層:依存関係の特定
タスク間の依存を明示し、クリティカルパスを特定します。
JWT発行 → ミドルウェア → ロール権限チェック(直列・クリティカルパス) テスト作成 → PRレビュー(並列可能)
第3層:リスクベースのバッファ
| リスクレベル | バッファ | 適用場面 |
|---|---|---|
| 低リスク(経験あり) | +10% | 同じ技術スタックの類似実装 |
| 中リスク(一部不確実) | +20% | 新しいライブラリ・API使用 |
| 高リスク(未知要素多い) | +30-50% | 初めての技術スタック・AI精度チューニング |
AI開発特有の見積もり難易度
なぜAI開発の見積もりは特に難しいか
| 従来の開発 | AI開発 | 見積もりへの影響 |
|---|---|---|
| 入力→決定的な出力 | 入力→確率的な出力 | テストの合否判定が曖昧 |
| ビルド成功=完成 | 精度目標達成=完成 | 「いつ精度が出るか」が予測困難 |
| 自社環境で完結 | 外部API依存 | レート制限・障害で遅延 |
| 仕様通り作れば動く | データ品質で精度が変わる | データ受領後に再見積もりが必要 |
AI開発で追加すべき見積もり項目
- データクレンジング工数:顧客データの品質に依存(受領前は概算のみ)
- プロンプトチューニング:精度目標達成まで反復回数が読めない
- API障害対応:プロバイダー側の障害で開発が止まるリスク
- セキュリティ審査待ち:顧客側の承認プロセスに数ヶ月かかる場合あり
- 閉域環境デプロイ:DNS/ディスク/プラットフォーム問題の切り分け
見積もり精度を上げる5つのテクニック
1. 過去の実績から逆算する
「前回の類似タスクは見積もり3日→実績5日だった」——この見積もり倍率(実績/見積もり)を記録し、次の見積もりに反映します。
2. 3点見積もり法
最楽観値(O):全てうまくいった場合 = 2日 最可能値(M):普通にやった場合 = 4日 最悲観値(P):問題が発生した場合 = 8日 期待値 = (O + 4M + P) / 6 = (2 + 16 + 8) / 6 = 4.3日
3. AIにWBS初稿を生成させる
「この機能を実装するために必要なタスクを、4時間以下の粒度で分解してください」——AIが過去のプロジェクトパターンからWBSの初稿を生成します。人間はそれをレビューし、抜け漏れを追加します。
4. スパイク(事前調査)を見積もりに含める
不確実性が高い部分は、本実装前に「調査タスク」を別途見積もります。調査完了後に本実装の見積もりを確定させる2段階アプローチです。
5. チェックポイントで再見積もりする
プロジェクトの中間地点で、残作業を再見積もりします。「当初見積もり」に固執せず、現在の情報で最も正確な見積もりを出し直します。
見積もりのアンチパターン
| アンチパターン | 問題 | 対策 |
|---|---|---|
| 「すぐできます」 | 楽観バイアスで過小見積もり | 必ずWBSに分解してから回答 |
| バッファなしの見積もり | 想定外の問題でスケジュール崩壊 | リスクレベルに応じたバッファを加算 |
| 見積もり=コミットメント | 見積もりを変更できない空気 | 見積もりは予測であり確約ではないと共有 |
| 全体を一括見積もり | 大きな塊は精度が低い | 4時間以下に分解 |
| 依存関係の無視 | 並列できないタスクを並列前提で計算 | クリティカルパスを明示 |
見積もりの報告テンプレート
【見積もり報告】
■ 対象タスク:○○機能の実装
■ 見積もり工数:4.5日(バッファ20%込み)
- 内訳:
- 設計:4h
- 実装:12h
- テスト:6h
- レビュー対応:4h
- バッファ(中リスク×20%):5h
■ 依存関係:△△のマージが前提
■ リスク:
- API精度が目標未達の場合、追加チューニング+2日
- 顧客データ品質が低い場合、クレンジング+1日
■ 完了見込み:2026-04-18(金)
まとめ:見積もりチェックリスト
| ステップ | チェック項目 |
|---|---|
| 分解 | 全タスクが4時間以下に分解されているか |
| 依存 | タスク間の依存関係とクリティカルパスが明示されているか |
| バッファ | リスクレベルに応じたバッファ(10-50%)が加算されているか |
| AI固有 | データクレンジング・プロンプトチューニング・API障害の工数が含まれているか |
| 報告 | 見積もりの内訳・依存・リスク・完了見込みが明記されているか |
| 再見積もり | 中間チェックポイントで再見積もりするタイミングが設定されているか |
見積もりは「当てるもの」ではなく「管理するもの」です。3層分解で精度を上げ、バッファでリスクを吸収し、中間チェックで軌道修正する——この3ステップで、見積もりの信頼性を高めてください。
関連記事
ビジネススキル研修のご相談はrenueまで。

