追加改修を頼んだら、最初に「概算で◯◯万円くらいです」と言われた。ところが、あとから届いた確定見積もりは、その金額を上回っていた。こうした経験をして、「最初に言われた金額は何だったのか」と戸惑う発注者の方は少なくありません。
「追加改修の概算見積もりが出たが、確定見積もりになったら金額が上がった。概算の金額は守ってもらえないのか」
先に結論をお伝えします。概算見積もりは、多くの場合「確定した金額の約束」ではなく、「いまわかっている範囲での目安」です。ただし、金額が上がったからといって、そのまま受け入れる必要はありません。「何が変わって上がったのか」を、前提条件の差として説明してもらい、納得できてから進めることができます。
この記事では、概算見積もりと確定見積もりの違い、金額が変わる主な理由、そして次の打ち合わせでそのまま使える確認事項と質問例を整理します。契約や法律の個別の判断ではなく、一般的な考え方の紹介です。
概算見積もりと確定見積もりは何が違うのか
まず、2つの見積もりの役割を整理します。呼び方は会社によって違いますが、考え方は共通しています。
| 概算見積もり | 確定見積もり | |
|---|---|---|
| 出るタイミング | 相談の初期・内容が固まる前 | 要望の内容と条件が固まったあと |
| 根拠 | 過去の似た案件や経験からの目安 | 作業内容を洗い出した積み上げ |
| 金額の幅 | 広い（上下することを前提にしている） | 狭い（契約の金額になる） |
| 発注者の使い方 | 予算を考える材料・やるかどうかの判断材料 | 発注するかどうかを決める材料 |
つまり、概算見積もりは「天気予報」のようなものです。大まかな見通しとしては役に立ちますが、「その金額で必ず作る」という約束とは性質が違います。
ここで大切なのは、言葉の呼び方より、見積書やメールにどう書いてあるかです。「概算」「目安」「◯◯を前提とした金額」といった書き方があれば、確定ではないという意味を含んでいる可能性が高いといえます。
概算より確定が高くなる主な4つの理由
開発会社が意図的に金額を上げているとは限りません。多くの場合、次のような理由で金額が変わります。
理由1：要望の中身が、概算のあとで具体的になった
概算のときは「ログイン後の画面に検索を足したい」程度だった要望が、詳しく聞くうちに「項目ごとの絞り込み」「CSVでの出力」「権限ごとの表示の切り替え」まで広がることがあります。作業が増えれば、金額も増えます。
理由2：既存のシステムを調べたら、想定と違っていた
追加改修は、すでにあるシステムを触る作業です。実際にコードを見てみると、「ほかの機能と密接につながっていて、直すと影響が広い」ことが分かる場合があります。影響を確かめる作業（影響調査）やテストが増えるため、金額に反映されます。
理由3：概算に「含まれていないもの」があった
テスト、データの移行、画面の確認、リリース作業、ドキュメントの更新などは、概算の段階では含めず、確定見積もりで初めて入ることがあります。概算の金額が「開発作業だけ」の目安だったのかどうかを確認しないと、比べようがありません。
理由4：前提条件が、途中で変わっていた
「既存の画面をそのまま使う」という前提で出した概算が、画面のデザインも直すことになった、というような変化です。前提が変われば、金額が変わるのは自然なことです。
「概算を出す時点では、まだ分からないことが多いんです。『この条件なら、このくらい』という前提つきの数字だと思っていただけると、あとの話がしやすくなります。」
金額が上がったときに確認する5つのこと
金額が上がっていても、まず落ち着いて、次の順に確認していきます。
1. 概算見積もりに、前提条件が書いてあったか
概算の見積書やメールを見直します。「◯◯を前提とする」「詳細確認後に変動する可能性があります」といった文言があるかどうかで、話の進め方が変わります。前提が書かれていた場合は、その前提と今回の状況の差を比べます。
2. 概算と確定で、作業の範囲がどう違うのか
金額の差ではなく、作業の内容の差を見ます。概算にはなかった項目が増えたのか、同じ項目の作業量が増えたのか、新しく含まれた作業（テストなど）なのかを、項目ごとに並べてもらいます。
3. 上がった理由が「要望の変更」か「前提の誤り」か
ここは話し合いの大きな分かれ目になります。
- 発注者側の要望が途中で増えた → 作業が増えた分は、金額に反映されるのが一般的です
- 開発会社が概算のときに見落としていた → どちらの負担にするかは、概算の位置づけや契約内容によります。話し合いで決める部分です
どちらか一方だけが悪いと決めつけず、事実を並べて整理することが近道です。
4. 金額を下げられる選択肢があるか
金額が合わない場合は、やめるか受け入れるかの二択ではありません。次のような調整が考えられます。
- 要望の一部を次回に回し、今回は優先度の高いものに絞る
- 画面や機能を簡素にして、作業量を減らす
- 作業を段階に分けて、最初の段階だけ発注する
5. 発注の前に、書面で条件を確認する
口頭の説明だけで進めず、確定見積もりに「含まれるもの」「含まれないもの」「前提条件」「金額が変わる条件」を書いてもらいます。あとから「言った・言わない」にならないための、いちばん確実な方法です。
契約の形（請負か準委任か）によっても、金額の考え方は変わります。契約や費用の負担について迷うときは、IPAが公開している契約書のひな形と解説が参考になります。
📰 出典：IPA（情報処理推進機構）「情報システム・モデル取引・契約書」
IPAは、システム開発の取引で、契約の前に決めておくべきことや、契約の形ごとの考え方をひな形と解説で公開しています。見積もりの前提条件をどう書面に残すかを考える際の、一般的な参考資料になります。個別の契約の判断については、弁護士などの専門家に確認してください。
概算見積もりのときに、やっておくと防げること
金額のずれは、起きてから直すより、概算を受け取る時点で防ぐほうが楽です。
- 概算を依頼するときに、「確定のときにずれる可能性がある条件」を聞いておく：「どんな場合に金額が変わりますか」と先に聞いておくと、あとの話が早くなります
- 概算の幅を聞く：「◯◯万円」だけでなく、「◯◯〜◯◯万円」の範囲で出してもらうと、予算を立てやすくなります
- いつ確定になるのかを決めておく：「どこまで要望が固まったら確定見積もりを出すのか」の目安を共有しておきます
- 要望を、できるだけ文章で残しておく：口頭だけだと、聞き手によって解釈がずれやすくなります
やりがちな失敗
- 概算の金額だけを社内の予算に確定として書いてしまう
- 概算の前提条件を読まずに、金額だけを比べる
- 上がった理由を聞かずに、「高い」と感じたまま話を止めてしまう
- 逆に、理由を聞かないまま「仕方ない」と受け入れてしまう
- 条件を口頭で済ませて、書面に残さない
発注者がやること チェックリスト
- ☐ 概算見積もりの書面に、前提条件や「変動する可能性」の記載があるか確認した
- ☐ 概算と確定の違いを、作業の項目ごとに並べて説明してもらった
- ☐ 上がった理由が、要望の変更によるものか、前提の差によるものかを整理した
- ☐ 金額を調整する選択肢（範囲を絞る・段階に分ける）を相談した
- ☐ 確定見積もりに、含まれるもの・含まれないもの・金額が変わる条件を書いてもらった
- ☐ 次回以降の概算では、金額の幅と変動の条件を最初に聞くことにした
開発会社への質問例
- 「概算の金額は、どんな前提で出した数字でしたか。その前提と今回の状況で、変わった点を教えてください」
- 「概算と確定見積もりで、項目ごとにどこが増えたのか、一覧で見せていただけますか」
- 「今回の差額は、要望が増えた分と、調査して分かった分と、どちらがどのくらいでしょうか」
- 「金額を抑えるために、今回は範囲を絞る場合、どの機能を後回しにできますか」
- 「確定見積もりの金額が、さらに変わる可能性があるのはどんなときですか。書面に残していただけますか」
まとめ
概算見積もりは、確定した金額の約束ではなく、前提つきの目安であることが多いものです。だからこそ、金額が上がったときは、金額そのものではなく、前提と作業内容の差を一緒に確認することが大切です。
- 概算と確定は役割が違う（目安と、契約の金額）
- 上がる理由は、要望の具体化・既存システムの状況・含まれる作業・前提の変化のどれかであることが多い
- 理由を項目ごとに並べて、書面で確認してから進める
なお、概算が届いた段階での金額の見方については、こちらの記事で詳しく解説しています。
あわせて読みたい関連記事
