見積もりが二転三転する不安、その正体を整理する

最初にもらった見積もりと、実際に請求される金額が違う。しかも「追加開発費」「仕様変更対応費」といった項目が後から増えていく。経理部長や情報システム担当として発注側に立ったことがある人なら、一度はこの「聞いていた話と違う」というモヤモヤを味わったことがあるのではないでしょうか。契約書にサインした後になって金額が動くと、自分の見積もりの読み方が甘かったのではないかと不安になったり、社内から「なぜ最初の金額と違うのか」と詰められて板挟みになったりすることもあります。

実はこの不安、開発会社の見積もりが雑だから、あるいは自社が交渉下手だから、という単純な話ではないことが多いです。システム開発という商品の性質上、契約時点では「何を作るか」が完全には確定していないという構造的な事情が背景にあります。

この記事では、見積もりが後から膨らんでいく理由と、その裏にある不安の正体を整理したうえで、発注する側として持っておきたい考え方を紹介します。

なぜ見積もりは「最初の金額」で終わらないのか

システム開発の見積もりは、家や車を買うときの見積もりとは性質が異なります。家であれば図面が固まってから金額が出ますが、システム開発の場合、契約前の段階では「要件定義」と呼ばれる作業――何を作るか、何ができればゴールなのかを言葉に落とし込む工程――がまだ途中であることが多いのです。

つまり、見積もりの元になっている情報自体が、まだ確定していない状態で金額が算出されているということです。ここは実務上のポイントで、見積もりを「確定額」として受け取るのではなく「現時点で把握できている範囲の概算」として受け取る心構えが必要になります。

さらに、発注側の社内でも「経理は締め処理を自動化したい」「営業は顧客管理と連携したい」など、部門ごとに期待していることが異なる場合があります。これが要件定義の段階ですり合わされないまま契約に進むと、後になって「これも入っていると思っていた」という食い違いが表面化し、追加費用として跳ね返ってくる構造があります。

二重コスト構造という落とし穴

見積もりが膨らむ理由をもう一つ挙げると、「二重コスト構造」と呼べる状態があります。これは、要件が曖昧なまま開発が始まり、途中で仕様変更が入ることで、一度作った部分を作り直す手戻り作業が発生する状態を指します。

作り直しは、単純に「もう一回作業する」というだけでなく、すでに投入した工数が無駄になる分も含めてコストとして二重に発生します。見えないコストが二重に発生しているのに、発注側からは「なぜこんなに追加費用がかかるのか」としか見えない、というのがこの構造のやっかいなところです。

この見えにくさが、実は不安の正体をさらにこじらせます。追加費用の明細を見ても、それが「もともと必要だった作業」なのか「作り直しによる二重発生分」なのかが判別しにくいため、発注側は「本当にこの金額は妥当なのか」という見積もりそのものへの不信感を抱きやすくなります。加えて、社内では経営層から「なぜ予算内に収まらないのか」と問われ、開発会社からは「仕様変更があったので当然の費用です」と説明され、現場責任者がその間で説明に窮する、という板挟みの構図も生まれやすいところです。

こうした二重コスト構造が起きやすいかどうかは、契約前の要件定義がどれだけ丁寧に行われたかにかなり左右されるとされています。ここは、次に開発会社と話す機会があったときに、そのまま確認材料として使える視点なので、メモしておくといいところです。

発注する側が持っておきたい考え方

構造的な理由と、そこから生じる不安の輪郭が見えてきたところで、発注側としてどう向き合えばいいかを整理しておきます。ここで大事なのは、具体的な手順を完璧にこなすことよりも、見積もりや要件定義に対する捉え方そのものを少し変えてみることです。

まず、見積もりが動くこと自体を「異常事態」として身構えるのではなく、「契約時点でどこまで確定していて、どこから先が未確定なのか」を区別して見る視点を持つことです。金額が変わったこと自体よりも、変わった部分が「もともと未確定だった範囲」なのか「合意していたはずの範囲」なのかを見分けられれば、不信感の性質もだいぶ変わってきます。

次に、社内の板挟みを減らすためには、要件定義の段階で各部門の要望をすり合わせる作業を「開発会社に任せる工程」ではなく「自社内で合意形成をしておくべき工程」として捉え直すことが助けになります。発注する側が意識しておきたいのはここで、経営層への説明も、現場からの要望整理も、契約前にある程度言葉にしておくほど、後から板挟みになる場面は減らしやすくなります。

そして、社内だけで要件を詰め切るのが難しいと感じたときは、担当者一人で抱え込まず、社内の別部門やこれまで類似のプロジェクトに関わったベテラン担当者に相談してみるのも一つの視点です。外部に丸ごと任せる前に、まず社内でどこまで言葉にできているかを一度棚卸ししてみることが、不安を整理する最初の一歩になります。

まとめ

• 見積もりが後から膨らむのは、契約時点で要件が完全には確定していないというシステム開発特有の構造が背景にあることが多いです。
• 要件が曖昧なまま開発が進むと仕様変更による作り直しが発生し、二重にコストがかかる「二重コスト構造」が起きやすくなります。この見えにくさが、見積もりへの不信感や社内での板挟みという心理的な負担につながります。
• 発注側としては、見積もりの「確定部分」と「未確定部分」を区別して見る視点を持ち、要件定義を社内の合意形成の工程として捉え直すことが、不安の正体を整理する手がかりになります。