はじめに
ソフトウェア開発における「見積もり」は、プロジェクトの成否を大きく左右する重要な要素です。しかし、当初の見積もりと最終的なコスト・工数が大きく乖離し、**「予想以上に工数がかさんだ…」**という問題に直面するプロジェクトは少なくありません。
本記事では、ソフトウェア開発の見積もりが増加する主な理由を整理するとともに、不確実性コーン（Cone of Uncertainty）や三点見積もり（PERT 見積もり）といったアプローチを活用して、不確実性と見積もり誤差をどのようにマネジメントすればよいかを考察します。
1. なぜ見積もりが当初より増えてしまうのか & ソフトウェア開発の成功率は3割程度
1.1 なぜ見積もりが当初より増えてしまうのか
| 理由 | 詳細 |
|---|---|
| 1. 開発が進むにつれて解像度が高まる | - 初期要件の曖昧さ：要件や技術スタックが明確でないため、後から想定外の仕様追加や見落としが発覚しやすい - リワーク（手戻り）の増加：途中段階で仕様を修正するほど、過去の実装とテストをやり直す必要があり、工数が跳ね上がる |
| 2. 技術的負債（テクニカルデット）の積み重ね | - 応急処置的な実装：短納期を優先して「とりあえず動く」コードを増やすと、後々のメンテナンスが複雑化 - 生産性の低下：コードのスパゲッティ化により、バグ修正や機能追加の工数が雪だるま式に膨らむ |
| 3. メンバーのスキルセットを考慮しない | - チームの熟練度不足：過去プロジェクトの実績が、今回のメンバー構成やスキルレベルと合わないと、学習コストや試行錯誤が増える - 外部ベンダーや新規メンバーの連携：オンボーディング不足で、連絡ロスや仕様理解のズレが発生 |
| 4. スコープ変更（追加要件）の発生 | - 顧客側の要望追加：プロジェクト途中で「新機能」や「仕様変更」を依頼されると、追加工数が直撃 - 市場・ビジネス要件の変化：競合の動向や組織方針の変化に合わせてスコープを再検討する必要があり、当初見積もりと大きく乖離 |
| 5. 予期せぬ技術的・外的リスク | - 新技術の学習コスト：未経験のフレームワークやライブラリを導入する場合、検証やドキュメント調査に想定以上の時間がかかる - 外部システム連携の不具合：API仕様の更新やドキュメント不足が原因で、調整対応やテスト工数が急増 |
| 6. コミュニケーション不足 | - ステークホルダー間のズレ：要件定義や仕様の解釈が食い違ったまま進むと、後半で大幅な手戻りが必要 - 問題発覚の遅れ：定例ミーティングやチャットツールを活用せず、進捗報告が滞るほど、潜在問題が大きくなってから表面化し、結果的に工数増加 |
1.2 ソフトウェア開発の成功率は3割程度
こうした見積もり超過の背景は、そもそもソフトウェア開発プロジェクトの成功率が低いことにも表れています。情報処理推進機構（IPA）などの調査によると、**「品質・納期・コストなど総合的に見て成功といえるプロジェクトは約3割程度」**との報告があります。
-
大規模プロジェクトほど失敗リスクUP
規模拡大とともに利害関係者や連携先が増え、コミュニケーションコスト・調整難易度が跳ね上がるため、当初見積もりとの乖離が生じやすくなります。 -
要件定義やコミュニケーションの不備が主因
日産の大規模リコール事例や、海外のセキュリティ欠陥事例など、手戻りを繰り返した結果、当初想定の数倍のコストがかかったケースは枚挙にいとまがありません。
ポイント：
**「見積もりどおりにピッタリ終わるほうがむしろレア」**という認識を共有し、不確実性に備えることが大切です。
2. 不確実性コーン（Cone of Uncertainty）の考え方
「なぜ当初見積もりと最終コストが大きくズレるのか？」――その本質には、開発初期の不確実性が大きく影響しています。ここでよく参照されるのが、**不確実性コーン（Cone of Uncertainty）**というモデルです。
不確実性コーン：
開発初期は要件や技術が固まっておらず、最大で 4 倍ほどの誤差が生じる可能性がある。しかし、要件定義・設計・実装とフェーズを進めるにつれ、未知数が減って見積もり誤差が徐々に収束していく、という考え方。
2.1 フェーズごとのバッファ設定例
不確実性コーンを踏まえ、各フェーズに応じてどの程度バッファ（余裕工数）を見込むべきかの一例を表にまとめます。
| フェーズ | 不確実性の大きさ | 推奨バッファ率（例） | 補足 |
|---|---|---|---|
| 概念策定 / 要件検討 📝 | 最も不確定要素が多い | 30〜50% (場合によってはそれ以上) | - 要件変更や仕様膨張が顕著な段階 - **PoC（概念実証）**などを駆使して未知数を減らす取り組みが必要 |
| 設計完了 ✍️ | 技術的リスクの一部が解消 | 20〜30% | - 主要技術の選定が終わり、要件も固まり始める - ただし外部システムや他部署との連携リスクはまだ残る |
| 実装完了 💻 | 実際の作業実績が把握できる | 10〜20% | - コードベースが見えてきて、残課題や技術的負債の規模もある程度分かる - テスト段階での追加改修に備え、余裕を確保 |
| テスト完了 / リリース 🚀 | 不確実性が最も低い | 5〜10% | - 終盤でクリティカルなバグが出る可能性もあるが、フェーズが進むほどリスクは狭まる - リリース後の保守フェーズに移行する前の最終調整 |
ポイント：
大規模プロジェクトほど、初期段階で多めのバッファを持たせないと、後半で手痛いリスク増に直面しやすいです。
3. 三点見積もり（PERT見積もり）で不確実性を数値化する
「不確実性コーン」の概念は理解できても、具体的にどのくらいブレる可能性があるかは見えづらいもの。そこで役立つのが三点見積もり（PERT見積もり）です。各タスクについて以下の3値を見積もり、期待値と標準偏差を導き出すことで、ブレ幅を定量的に把握できます。
| 項目 | 内容 |
|---|---|
| 楽観値 (Best case) 🌈 | 最短で終わる場合（何も問題が起きない理想パターン） |
| 最可能値 (Most likely) ⚖️ | 最も現実的と考えられるパターン（一般的な遅れ・不具合などは織り込み済み） |
| 悲観値 (Worst case) ⚠️ | 最悪のケース（大きなリスクが顕在化した場合の上限値） |
3.1 計算例
たとえば、ある機能Aの実装にかかる工数を見積もる場合:
| 項目 | 時間(h) |
|---|---|
| 楽観値（Best） | 10h |
| 最可能値（Most） | 15h |
| 悲観値（Worst） | 28h |
-
期待値 (E)
-
標準偏差 (σ)
結果として、「約16時間 ±3時間程度ブレる可能性がある」 と定量化できます。このように各タスクで三点見積もりを行い、期待値と標準偏差を合算すればプロジェクト全体の工数レンジをおおまかに把握できます。
メリット
- 客観的な数値を用いて、ステークホルダーに最悪パターンを含めたレンジを説明しやすい
- 楽観・悲観の両端を設定することで、**「何が最悪のシナリオなのか」**をチームで認識し、リスク対策を立てやすい
注意点
- 初期段階は悲観値が極端に大きく出ることが多く、誤差が非常に幅広くなる
- 過去プロジェクトの実績やチームスキルを無視すると、あまり現実的でない見積もりになり得る
TIP：
三点見積もりをアジャイル開発のスプリント計画などでも活用すれば、実際のベロシティ（チームの開発速度）との擦り合わせもやりやすくなります。
4. バッファ（余裕工数）の考え方
4.1 初期フェーズほどバッファ多めに 🛡️
- 不確実性コーンが最も広い要件定義段階や設計初期では、30〜50％程度のバッファを検討することも珍しくありません
- ビジネス要件が流動的（スタートアップ等）な現場だと、それ以上の余裕を確保する場合も
4.2 フェーズ移行時にバッファを再設定 🔄
- 設計終了・実装終了などのマイルストーン到達時に、残リスクや実績データを踏まえてバッファを見直す
- 過剰なバッファはリソースの無駄になり、逆に不足すればリスク高騰に直面するため、都度微調整が不可欠
4.3 多段階契約やスプリント手法でリスク分散 💡
- 大規模プロジェクトの場合、最初から全範囲を一括で見積もり契約するより、要件定義フェーズ・プロトタイプフェーズ・本開発フェーズなどに段階的に契約を締結するとリスクを抑えやすい
- アジャイルであれば、短いスプリントごとに工数実績（ベロシティ）を可視化し、次スプリントの見積もり・バッファを修正できる
5. まとめ
5.1 見積もりが増える理由を理解する
- 開発が進むほど要件や技術的リスクが露呈し、追加工数やリワークが必要
- ソフトウェア開発の成功率は約3割という現実から、初期見積もりが大幅に外れるプロジェクトが多い
5.2 不確実性コーンと三点見積もりの組み合わせ
- 不確実性コーン：工程が進むほど誤差が狭まるため、初期段階は大きめのブレを前提に計画を立てる
- 三点見積もり：楽観・最可能・悲観の3値から期待値と標準偏差を算出し、具体的なブレ幅を数値化
5.3 適切なバッファ設定＆プロジェクト管理でリスクを抑える
- フェーズごとにバッファを再計算し、都度最適化する（過剰・不足両面のリスクを回避）
- 多段階契約やアジャイルのスプリント計画を導入し、リスク分散しながら進める
⚙️ ワンポイント：
**「完璧な見積もり」**というものは存在しません。不確実性コーンや三点見積もり、そして各フェーズに合ったバッファ調整を組み合わせることで、見積もり誤差をある程度コントロールすることが可能になります。変化の激しいソフトウェア開発においては、不確実性を前提とした計画こそがプロジェクト成功の鍵になるでしょう。
参考文献
-
情報処理推進機構（IPA）
- 「組込みソフトウェア開発データ白書 2019」など
-
Software Estimation: Demystifying the Black Art (Steve McConnell)
- 不確実性コーンや三点見積もりなど、さまざまな見積もり手法が紹介された名著
-
Why small projects succeed and big ones don't | Bigger Impact - Boost
- 小規模・大規模プロジェクトの成功率比較など、統計的視点を交えた分析
最後に
本記事では、ソフトウェア開発の見積もりが当初より増えてしまう理由を深堀りし、不確実性コーンや三点見積もり、バッファ運用などの具体的対策を紹介しました。
実際の開発現場では、チームスキルや技術トレンド、ビジネス要件の変動など、刻一刻と状況が変わります。定期的な見積もりの見直しとリスク管理を怠らずに続けることで、プロジェクト成功率を高めることができるはずです。
💡「不確実性」と上手に付き合うことが、エンジニア・プロジェクトマネージャーの必須スキルともいえます。今回の内容を参考に、ぜひ自社の開発プロセスに活かしてみてください。