見積もりと実装のズレが追加費用を生む理由

見積もりの段階では「この金額なら想定内」と納得して契約したはずなのに、開発が進むにつれて「この機能は見積もりに入っていなかった」「仕様を詰めたら想定より複雑だった」という理由で追加費用の話が出てくる。経理部長や現場責任者の立場からすると、承認した予算の枠を超える説明を経営層にどうするか、その段階で頭を抱えることになります。

この「見積もり時点」と「実装時点」のズレは、担当者の見積もりが甘かったという個人の問題として片付けられがちですが、実はもっと構造的な話です。見積もりという行為そのものが、まだ確定していない情報をもとに金額を出す作業である以上、ズレが生まれる余地は最初から組み込まれています。

この記事では、なぜ見積もり時点と実装時点でズレが起きるのか、その構造を整理したうえで、追加費用そのものを完全になくすのではなく、見通しを持って向き合うためにどこを確認しておけばいいかを見ていきます。

なぜ見積もりと実装の間にズレが生まれるのか

見積もりは、要件定義が終わった時点、あるいは要件定義すら固まりきっていない提案段階で出されることが珍しくありません。つまり見積もりとは「現時点で分かっている範囲の情報」をもとにした予測であり、実装を始めてから初めて見えてくる情報は、原理的に見積もりの時点では反映しようがないのです。

たとえば「既存システムと連携する」という要件が見積もり段階では一行で済んでいても、実装段階になって連携先のデータ形式が想定と違う、認証方式が古い仕様のままだった、といった事情が判明することがあります。これは発注側・開発側どちらかが怠慢だったというより、連携先の詳細な仕様が着手前には十分に開示されていなかった、という情報の非対称性が原因であるケースが多くあります。

要件定義書が「あの人頼み」になる属人化の罠でも触れていますが、要件定義の精度そのものが属人的な事情で左右されやすく、その精度のばらつきがそのまま見積もりの精度のばらつきにつながっているという構造も見逃せません。見積もりの上振れに悩んだときは、金額そのものより先に、要件定義がどこまで具体化されていたかを振り返ってみると、原因の見当がつきやすくなります。ここは、次に見積もりを取るときにそのまま使える視点なので、メモしておくといいところです。

「仕様の揺れ」が追加費用に変わる仕組み

もう一つ見落とされがちなのが、発注側の要望そのものが開発の途中で変化するケースです。「やっぱりこの画面にはこのボタンも欲しい」「この機能も一緒にできないか」という追加の要望は、現場からすれば小さな調整のつもりでも、開発側から見ると設計のやり直しやテスト範囲の拡大を伴うことがあります。

ここで注意したいのは、追加された要望の「見た目の大きさ」と「実際の作業量」が一致するとは限らない、という点です。画面上はボタン一つでも、その裏側でデータベースの構造や他の画面との整合性まで調整が必要になる場合、作業量は見た目以上に膨らみます。追加開発費用が高く感じる理由と相場の考え方でも整理していますが、追加分の単価が初期開発より高く感じられるのは、こうした「調査し直す」「整合性を取り直す」という、作業量に比例しにくいコストが含まれているためです。

構造的なズレを前提にした向き合い方

ズレが起きる構造そのものをゼロにすることは難しいとしても、ズレが起きたときの扱い方をあらかじめ決めておくことで、追加費用への向き合い方は変わってきます。発注後に仕様変更や追加作業が生じた場合の費用の取り扱いについては、下請代金支払遅延等防止法の考え方が参考になります。公正取引委員会は、発注後に発注内容を変更したり、やり直しをさせたりする場合、それによって発注事業者（下請事業者）に生じた費用を発注者側が適切に負担しないことは、同法が禁じる「不当なやり直し」等に該当しうるとの考え方を示しています。これは下請事業者を保護する趣旨の規定ですが、発注する側にとっても、仕様変更が発生した時点で費用の扱いを曖昧にしないことがトラブル予防の基本であると読み取れます。

実務で確認しておきたいのは、次のような点です。

• 見積もりの前提条件が明記されているか：どの要件を前提にその金額になっているか、見積書や提案書に明記されているかを確認する
• 変更が生じた場合の手続きが決まっているか：仕様変更や追加要望が出た場合、どのタイミングで金額の再提示を受けるか、事前にすり合わせておく
• 未確定事項がどこにあるか共有されているか：連携先の仕様や既存データの状態など、着手時点でまだ分かっていない部分がどこにあるかを開発側と共有しておく

この3点は、契約前に一度でも話題に上げておくだけで、後から「聞いていなかった」という食い違いをかなり減らせます。発注する側が意識しておきたいのはここで、金額交渉よりも先に、前提条件のすり合わせに時間を使う方が結果的に総額のブレを抑えやすくなります。

まとめ

• 見積もりは着手前の限られた情報をもとにした予測であり、実装が進むことで見えてくる情報との間にズレが生まれるのは構造上避けにくい
• 仕様の揺れや追加要望は、見た目の規模と実際の作業量が一致しないことがあり、これが追加費用への戸惑いにつながりやすい
• 追加費用そのものをなくすより、見積もりの前提条件と変更時の手続きをあらかじめ確認しておくことで、ズレへの向き合い方を変えられる