「概算 300 万円」と「本見積 620 万円」は同じ案件でも矛盾していない
システム開発の初期相談で受け取った「概算 300 万円」と、後日改めて出てきた「本見積 620 万円」——この 2 つが同じ案件のものだと知って戸惑った経験はないでしょうか。金額差は、開発会社が嘘をついているわけでも、途中で吹っかけているわけでもありません。両者はそもそも別の目的で作られる見積であり、精度も前提も違います。
この違いを理解しないまま概算をもとに稟議を進めてしまうと、後で予算を組み直す羽目になり、社内の信用も失いかねません。この記事では、発注担当者向けに概算見積と本見積の違い、フェーズごとの精度の目安、そして各段階で発注側が確認すべきポイントを整理します。
1. 概算・本・確定——3 種類の見積の定義と精度
まず言葉の整理から始めます。開発現場で使われる「見積」には、実は複数の段階があります。
| 見積の種類 | 提示タイミング | 精度の目安 | 使い道 |
|---|---|---|---|
| 概算見積 (ラフ見積) | 相談〜初回ヒアリング直後 | ±30〜50% | 予算感の確認、社内の企画通し |
| 本見積 | 要件定義完了後 | ±10〜15% | 契約金額の根拠、正式な稟議 |
| 確定見積 | 契約締結時 / 着手直前 | ±5% 以内 | 実際の契約金額として確定 |
概算見積はレンジで捉えるもの
概算見積は、要件がほとんど固まっていない段階で提示されます。開発会社はヒアリングで得た情報から近い過去案件を参照し、大まかな工数を見立てて金額に落とします。数字は 1 点ではなく「300〜500 万円」のような幅で提示されるのが本来の形です。単一の数字で示されていても、実際には ±30〜50% のレンジを内包していると考えるのが妥当です。
本見積は要件定義後の金額
本見積は、要件定義工程が終わり、実装対象が画面・機能・非機能要件レベルで具体化された段階で提示されます。ここまで来ると、開発会社は工数を積み上げ方式で算出でき、精度は概算より格段に上がります。契約書に添付されるのは通常この本見積です。相場感そのものを押さえたい方は システム開発の見積相場 を先に参照してください。
確定見積は契約直前の最終版
確定見積は、契約締結の直前に、本見積のうち軽微な差分 (体制の微調整、開始日、外部サービスの選定など) を反映した最終版です。ここでの変動幅は通常 5% 以内に収まります。
2. 相談から契約までの見積フェーズ
システム開発の見積は、次のような流れで少しずつ精度が上がっていきます。
- 相談・初回ヒアリング。目的・課題・想定利用者・大枠のスコープを共有します
- 概算見積の提示。ヒアリング内容をもとに開発会社がレンジで提示します
- 要件定義 (有償 / 無償)。機能一覧・画面遷移・データ構造・非機能要件を固めます
- 本見積の提示。要件定義書に基づく積み上げ計算で提示されます
- 契約締結・確定見積。契約書の別紙として最終金額を確定します
要件定義は、規模によっては別契約 (要件定義フェーズだけを準委任契約で発注) になることもあります。この場合、要件定義自体に数十万〜数百万円がかかりますが、そこで得た成果物が本見積の精度を担保します。
なぜ概算だけで契約はできないのか
概算の段階では、開発会社はまだ工数を根拠つきで説明できません。契約書に金額を書くには、その金額の根拠が必要です。要件定義を飛ばして概算のまま契約すると、後日「想定と違った」を理由に何度も追加見積が発生し、結果的に総額が読めない案件になります。
3. 各フェーズで発注側が確認すべきこと
見積を受け取ったら、フェーズごとに確認すべきポイントが異なります。
概算見積を受け取ったとき
概算では、数字が「レンジ」で提示されているか (1 点数字なら振れ幅を聞く)、前提条件が明記されているか (対応 OS、想定ユーザー数、機能の粒度など)、何が含まれ何が含まれないかが分けて書かれているか、概算の根拠として類似案件の実績が示されているか——この 4 点を確認します。
本見積を受け取ったとき
本見積では、工数の内訳 (画面ごと・機能ごと・工程ごと) が読めるか、非機能要件 (性能・セキュリティ・可用性) が反映されているか、諸経費・管理費・予備費の割合が妥当か、前提条件・免責事項が現実的か——を確認します。読み方の詳細は 開発の見積書の見方 で解説しています。
契約締結の直前
確定見積が本見積からどれだけ変わったか、変わった理由は説明できるかを確認します。あわせて、支払条件 (着手金 / 中間 / 検収) が資金繰り上問題ないか、仕様変更が発生したときの追加見積プロセスが明記されているかを、契約締結前に必ず突き合わせます。
4. 概算見積を精緻化するために揃える情報
概算見積のレンジは、発注側が提供する情報量によって狭められます。最初のヒアリングで次の情報を渡せると、レンジが ±50% から ±20% 程度に絞れることも珍しくありません。
- 利用者像とユースケース。誰が、どのシーンで、何のために使うか
- 業務フローの概要。現状の運用を図または箇条書きで
- 想定画面一覧。Excel レベルの粗さでよいので画面名と役割
- 連携する外部システムの有無。SaaS、社内基幹、決済など
- 非機能要件の希望値。同時利用者数、稼働率、レスポンスの目安
- 予算枠と希望リリース時期。どちらか一方でも構わない
これらは要件定義工程を待たなくても、発注前に社内で整理できる範囲です。準備の全体像は 発注前に整理すべきこと にまとめています。
5. 「概算で意思決定」の罠
現場でよく見かける失敗が、概算見積の数字をそのまま社内稟議に持ち込むケースです。稟議上限を概算の中央値で通してしまうと、本見積で金額が上振れたときに再稟議が必要になり、プロジェクトそのものが失速します。
FIXIT概算 300 万円って言われたし、そのまま稟議通しちゃえばいいよね？
Tsukasa結論から言うと危険です。概算は ±30〜50% の幅を持つ数字で、本見積で上振れると再稟議になります。
FIXITTsukasa概算の上限値に 10〜15% のバッファを足した金額です。稟議書には本見積で確定させる旨を明記します。
FIXITTsukasa逆に言えば、上限枠を先に共有する方が、開発会社もその枠でスコープを設計してくれます。
罠を避ける実践パターン
稟議上限を、概算の中央値ではなく上限値 + バッファ 10〜15% で通しておきます。稟議書には「本見積で確定させる」旨を明記し、金額が精緻化される前提を社内で共有します。加えて、概算段階で予算枠の天井を開発会社に共有し、その中で機能を絞る前提のレンジをもらうこと、大型案件なら要件定義工程だけを先に発注し、本見積で改めて社内承認を取ることが有効です。
特に最後のパターンは、大型案件で有効です。要件定義に数十万〜数百万円かけることで、数千万円規模の本開発の見積精度が担保されます。要件定義の投資対効果は、本開発の金額が大きくなるほど高くなります。
6. 概算と本見積で金額が動く理由と、許容すべき目安
概算から本見積で金額が動く原因は、多くの場合次の 5 つに集約されます。
- 要件の具体化に伴う工数の再算定です。画面数や分岐の実数が判明することで積み上げが変わります
- 非機能要件の追加です。性能・監査ログ・バックアップなど、後から必要と分かる要件が積まれます
- 既存システム連携の詳細判明です。API 仕様や運用制約が見えて工数が増えます
- デザインの作り込みレベルの決定です。テンプレート流用か独自設計かで UI 工数が変わります
- 体制・スケジュール要件の変化です。開始時期のずれや体制強化の要否が反映されます
差の許容ラインの目安
概算から本見積の変動が ±30% 以内なら、正常な精緻化の範囲です。30〜50% の変動があるなら、概算時のヒアリング不足、または要件の追加があった可能性があります。50% を超える差が出た場合は、概算の前提そのものが崩れている可能性が高く、概算時に何を含み何を除外していたのか、開発会社に差分の内訳を必ず開示してもらってください。差の原因が発注側の追加要望であれば追加は妥当ですが、開発会社の見立て違いであれば説明責任があります。
金額を左右する要因の詳細は 開発見積が高くなる / 安くなる要因 を参照してください。
コツ
概算はレンジで捉える数字、本見積は要件定義後の積み上げで確定させる金額。稟議は概算の上限値
- バッファ 10〜15% で通し、稟議書に「本見積で確定させる」旨を明記しておくと、金額の精緻化を社内合意ごと折り込めます。
まとめ
概算見積は精度 ±30〜50%、本見積は ±10〜15%、確定見積は ±5% 以内が目安です。概算はレンジで捉える数字、本見積は要件定義後の積み上げで確定させる金額であり、両者を混同すると稟議が破綻します。発注側が事前に情報を整理するほど概算のレンジは狭くなり、概算から本見積で ±30% 以内なら正常な精緻化、50% を超えるなら前提の齟齬を疑うのが実務的な物差しです。
AI 駆動開発のクリエイティブスタジオである FIXIT では、初回のヒアリング後にレンジ提示型の概算と、予算枠から逆算した機能スコープ案を並べてお出ししています。予算感の相談段階からご一緒できますので、無料相談 からお気軽にご連絡ください。進め方の全体像は AI 駆動開発サービス もあわせてご覧ください。