見積時点で赤字案件を生まないためのチェックポイント｜楽観見積と前提抜けを潰す10項目

「実行フェーズで止血する」より、「見積で勝負を決める」ほうが圧倒的に楽です。
赤字案件のうちかなりの割合は、見積時点で構造的に赤字が確定しています。実行で巻き返せるのはせいぜい5〜10%程度の振れ幅で、それを超える赤字は見積時点の選択ミスです。

本記事では、受託開発の見積で赤字を生まないための10項目のチェックポイントを、実務目線で整理します。

見積で赤字を生まないための10項目

見積担当者がフィットする顧客・案件ほど楽観的な数字を出します。これを「個人の問題」にせず、上長レビュー・3点見積・過去類似案件比較で補正する仕組みを置きます。

「あの案件は何人月で着地したか」を見ずに作る見積は、ほぼ机上計算です。実績DBがなければ、Excel1枚でもいいので過去5案件の実工数を並べて見てください。

「ヒアリング前提」「サーバ要件は別途」「テスト環境は顧客提供」など、前提を口頭で済ませた案件は、後から必ず争点になります。前提条件は見積書 or SOWに必ず明記します。

含まれているものよりも、含まれていないものを書く方が重要です。データ移行・性能試験・顧客側ユーザー教育・運用設計など、よく抜けるところを定型化しておきます。

顧客側のレビュー期限、確認体制、検証担当の確保、データ提供期限――これらが定義されていない見積は、後から確実に揉めます。

バッファを「適当に1.2倍」で乗せると、上長レビューで削られて終わります。
「未確定要件◯件×平均◯日」「新規技術領域分の◯%」のように、項目に分解した根拠を持たせてください。

検収条件のない見積は、検収条件が「顧客の満足」になります。受入条件・テスト範囲・確認方法・期限を明文化します。

「変更があれば再見積」のひとことではなく、「軽微変更の定義」「変更要請から見積回答までの期限」「変更未決時の影響範囲」を見積段階で握っておきます。

PM単独で出して提案する見積は、楽観・前提抜け・除外漏れの3つが必ず混ざります。最低でも別PMまたは上長のレビューを通します。

営業が「顧客の希望価格」を持ち帰った段階で、開発側が見積根拠を保てなくなる会社はとても多いです。営業見積と開発見積を分けて出す運用にすると、根拠が崩れにくくなります。

10項目のうち、自社では何項目が「仕組み」になっていて、何項目が「担当者の頑張り」に依存しているでしょうか。
ここが半分以下なら、見積精度の問題ではなく、見積運用の仕組みの問題です。

「うちの会社の見積レビュー・変更管理・赤字検知は、仕組みになっているのか担当者依存なのか」を点検したい場合は、PM組織健康診断を使ってください。
PM個人ではなく、受託案件運営の仕組みを点検する診断です。経営層・開発責任者が次の一手を決める材料に使えます。