プロジェクトの炎上原因の多くは、
契約前後の「見積書の認識ズレ」 によって発生します。
・スコープの誤解
・追加作業の無秩序な発生
・金額の根拠が曖昧
・工数の計算方法にズレ
これらはすべて、計画フェーズで必ず問題化します。
この記事では、PMBOKの考え方をベースに見積書トラブルを避けるための実務ポイント をまとめます。
目次
見積書トラブルが起きる根本原因
見積書トラブルは“見積書そのもの”ではなく、
その前後のプロセスの不備 によって発生します。
代表的な原因は以下の通りです：
要件定義が曖昧なまま金額が決まる
「何を作るか」が決まっていないのに金額だけ決めると、
後からスコープが膨らんでトラブルになります。
（→ 要件定義の記事と完全リンク）
スコープの境界が曖昧
・含まれる作業
・含まれない作業
これが明記されていないと、認識ズレが必ず発生します。
見積根拠の提示がない
「一式」「概算」で済ませると、後から必ず揉めます。
変更管理ルールが設定されていない
追加作業の扱いを定義していないため、無料対応が続いて崩壊します。
PMBOKで見る“見積書の位置づけ”
見積書は 計画プロセス群 × コストマネジメント に属します。
つまり、
単なる数字の書類ではなく
プロジェクトの計画と実行を左右する基準（ベースライン） の一部です。
見積書＝コストベースラインの前段
と言い換えられます。
正しい見積書は以下の役割を持ちます：
スコープの明確化
タスクの構造化（WBS）
工数の根拠提示
金額の透明性
変更の基準点
これを理解すると「なぜトラブルが起きるか」が明確になります。
見積書トラブルを防ぐ5つの実務ステップ
① WBSを作った上で見積もる
WBSの粒度が粗いと、
・抜け漏れ
・重複
・工数の過小見積
が発生します。
WBSを作った上で見積ることで、
認識ズレが大幅に減ります。
（→ 本編「計画フェーズの落とし穴」につながるポイント）
“作らないもの（非スコープ）” を明記する
スコープ定義は
「含めるもの」より「含めないもの」が重要 です。
例：Webサイト制作
含める：TOP + 10ページ、フォーム1つ
含めない：記事移行、メール設定、写真素材撮影
これが無いと、無料追加の温床になります。
見積根拠（Assumption）を提示する
見積書に必ず
前提条件（Assumption） をセットで記載します。
例：
・写真素材は支給前提
・文章はクライアント支給
・要件確定後の追加機能は別途見積
これが無い見積書は、プロジェクトが崩壊する典型です。
変更管理フローを明記する
本編「変更管理の流れ」で解説した通り、
変更はプロジェクトの最大リスクです。
最低限、見積書に以下を記載：
仕様追加は別途見積
大幅な要件変更は工数再計算
無償対応範囲
これだけで、トラブルは7〜8割減ります。
コミュニケーション回数・工数を明記
PM・ミーティング工数を軽視すると赤字になります。
例：
週1定例 × 8回
要件定義セッション × 3回
メール/チャット対応時間は合計〇時間まで
プロジェクト管理費と密接に関係する部分です。
（→ 内部リンク「プロジェクト管理費の割合」へ自然につながる）
よくある見積書トラブルと防止策
ケース1：無料で追加対応を求められる
原因：非スコープと前提条件を明確にしていない
対策：
スコープに入っていないことを示す
別途見積ルールに基づき提示
ケース2：納期が延びても追加費用が取れない
原因：変更管理が機能していない
対策：
変更要求をすべて記録
影響分析を行い、承認後に反映
ケース3：見積時点の想定より工数が増える
原因：WBSが粗い
対策：
粒度の細かいWBSを作成
工数の再計算とスコープ見直しを提案
トラブルを減らすための“見積書の必須項目”
- プロジェクト概要
- 作業範囲（スコープ）
- 非スコープ（含まれない作業）
- WBSに基づいた作業一覧
- 工数
- 見積根拠（Assumption）
- 変更管理ルール
- PM・ミーティング工数
- 納期
- 有効期限
これらが揃っていれば、見積トラブルはほぼ起きません。
まとめ：見積書は「数字」ではなく「契約条件」の文書
見積書は
「プロジェクトを成功させるための設計図」
であり、数字だけの紙ではありません。
本編で解説したように、
スコープ
WBS
リスク変更管理
コスト管理
これらが適切に整って初めて、
見積書は“事故らないプロジェクト”の基準点になります。
- → 要件定義の基本
（見積の前に何を固めるべきかが分かります） - → プロジェクト管理費の割合とは？
（PM工数の妥当性を理解するのに必須） - → PMBOKプロセス群を完全整理｜5つのステップと10の知識エリアを図解で理解
（見積書がプロセス群のどこにあるかが理解できます）