見積もりは「予言」ではない：不確実性と向き合うシステム開発の値付け

なぜ見積もりは、こんなにも当たらないのか

「この開発、いくらで、いつまでにできますか？」——プロジェクトの初期に必ず飛んでくるこの問いは、実は非常に答えにくい。まだ要件が固まっていない段階で、正確な金額と納期を約束しろと言われているに等しいからだ。見積もりが外れるのは、担当者の腕が悪いからではない。多くの場合、そもそも「まだ分からないこと」を無理に数字にしているからだ。ここを発注側と共有できるかどうかが、プロジェクトの明暗を分ける。

「不確実性コーン」を前提に置く

ソフトウェア開発には「不確実性コーン」という有名な考え方がある。プロジェクトの初期ほど見積もりの誤差は大きく、実際の幅は数倍にも及ぶ。要件定義や設計を経て情報が増えるにつれ、この幅は徐々に狭まり、精度が上がっていく。つまり、企画段階の見積もりと、要件確定後の見積もりは、まったく別物だ。私たちは、この段階の違いを明示しないまま一つの数字を独り歩きさせることを、最も危険な行為だと考えている。

概算見積もりと確定見積もりを分ける

だからこそ、見積もりは段階を分けて出す。初期段階では、あくまで予算感をつかむための「概算見積もり」であることを明言し、幅を持たせて提示する。要件が固まってから「確定見積もり」を出す。この二段構えを最初に合意しておくだけで、「最初に言った金額と違う」という不毛な衝突の多くは避けられる。

バッファは「サボり」ではなく「保険」だ

見積もりにバッファ（余裕）を積むと、発注側から「水増しでは」と疑われることがある。しかしバッファは、想定外のトラブルや仕様の解釈違いに備えるための保険だ。問題は、その中身が見えないことにある。私たちは、リスクの高い箇所（外部連携、未経験の技術、要件が曖昧な機能）を具体的に挙げ、なぜそこに余裕が必要なのかを説明するようにしている。根拠を示したバッファは、値引き交渉の対象ではなく、合意すべき前提になる。

曖昧な要件は、正直に「曖昧」と言う

見積もりを難しくする最大の要因は、要件の曖昧さだ。「いい感じの管理画面」「よくある検索機能」といった言葉は、人によってイメージが何倍も違う。ここを分かったふりで数字にすると、後で必ず食い違う。私たちは、曖昧な部分を曖昧なまま見積もらず、「この機能はこう解釈して見積もった」という前提を書き添える。前提が違えば金額も変わる、という当たり前を可視化しておくのだ。

発注側と「握るべき前提」を言葉にする

結局のところ、良い見積もりとは金額の正確さではなく、前提の共有度で決まる。何が含まれ、何が含まれないのか。どこまでが今回のスコープで、どこからが追加なのか。誰が何を用意する責任を持つのか。これらを発注側と明文化して握ることが、後々のトラブルを防ぐ何よりの防波堤になる。見積書は値段表ではなく、お互いの認識をすり合わせるためのコミュニケーションツールなのだ。