超概算とは、要件が固まる前に、予算枠と案件を進めるかを判断するための幅を持った見積もりです。提案比較に使う概算、契約と実行計画に使う詳細見積へ進むほど、分かっている情報と金額の用途が変わります。見るべきは最安値ではなく、どの段階の見積もりか、何を仮定し、何を含めていないかです。
同じ「受注管理を作りたい」という相談でも、FAXを一覧へ転記するだけなのか、得意先品番を商品マスタへ照合し、在庫を確認して販売管理へ登録するのかで作業は変わります。月末の締め処理、旧データの移行、承認者不在時の扱いまで聞く前に、一つの確定金額を求めるほうが無理があります。
業務システムの見積もりは、なぜ会社ごとに幅が出るのか？
対象範囲、調査済みの情報、含める工程、リスクの置き方が会社ごとに違い、幅が生まれます。
300万〜500万円と答える会社と、800万円と答える会社があっても、前者が安いとは限りません。前者は確認画面まで、後者は基幹連携、データ移行、操作教育、切り替え立会いまで含めているかもしれません。
金額を横に並べる前に、次を同じ列で比べます。
| 比較する項目 | 見積書で確かめること |
|---|---|
| 対象業務 | どの部署の、どの開始点から終了点までか |
| データ | 現行データの調査、整形、移行、照合を含むか |
| 外部連携 | API、CSV、手動連携のどれを前提にしたか |
| 非機能 | 権限、監視、バックアップ、停止時間を含むか |
| テスト | 開発会社のテストと自社の受入支援を分けたか |
| 運用準備 | マニュアル、教育、問い合わせ対応を含むか |
| 対象外 | 誰が別途行い、いつ金額へ入れるか |
| 再見積条件 | 何が判明した時点で金額を見直すか |
IPAのCoBRA法に基づく見積り支援ツールは、規模だけでなく、プロジェクトごとの工数変動要因を洗い出し、その影響を見積もりへ反映する考え方を示しています。連携仕様が未開示、現行データの欠損が不明、担当者が繁忙期に参加できない、といった条件も金額の幅を作ります。
超概算・概算・詳細見積は、何が違うのか？
超概算は予算枠、概算は提案比較、詳細見積は契約と実行計画の基準として明確に使い分けます。
JUASの2025年度 システム開発・保守QCDs研究会成果物は、三つの見積もりを目的、入力情報、手法、出力で分けています。
| 段階 | 主な用途 | 入力する情報 | 受け取るもの |
|---|---|---|---|
| 超概算 | 進めるか、予算枠を取るか | 業務の目的、仮の機能数、画面・帳票・連携の規模 | 金額レンジ、主要な仮定、対象外、次段階の条件 |
| 概算 | 複数提案を比べ、予算を確保する | 上位要件、主要機能、非機能、外部連携 | 工程別の費用、体制、スケジュール、リスク |
| 詳細見積 | 契約し、実行計画の基準にする | 要件定義成果物、詳細なWBS、制約、受入条件 | 契約金額、作業計画、変更管理基準 |
同資料が示す精度目安は、超概算がマイナス50%〜プラス100%、概算がマイナス25%〜プラス75%、詳細見積がマイナス5%〜プラス15%です。これはJUAS研究会の確認シートに置かれた段階差の目安であり、個別案件の価格を保証する幅ではありません。
初回相談で「400万円」と一点だけ出されても、超概算なら400万円の前提と上下幅を聞きます。反対に、要件定義後の詳細見積で大きな幅が残るなら、未確定の連携、データ、役割分担を確認します。
超概算では、何を決めてから相談すればよいか？
困っている業務、処理件数、利用者、連携先、期限、予算幅を仮置きして具体的に伝えます。
完成した要件書は要りません。ただし「受注業務を変えたい」だけでは規模を測れません。営業事務が平日30〜40枚のFAXを処理する、得意先品番を販売管理の商品コードへ読み替える、15時までの注文は当日出荷する、と現場の手順を伝えます。
画面数が分からなくても、入力、確認、承認、出力の場面は数えられます。要件書がなくてもシステム開発を相談できるか？で整理した7項目を使い、分からない箇所は「未確認」と書きます。
超概算で受け取るのは、契約金額ではなく経営判断の材料です。予算枠に合わなければ対象部署を一つに絞る、基幹への自動登録を後回しにする、または開発せず既存SaaSを試す判断に使います。
概算では、見積書のどこを比べればよいか？
工程別費用、前提、対象外、体制、再見積条件をそろえ、同じ範囲へ直してから比べます。
見積書Aは「開発一式500万円」、見積書Bは要件確認、設計、実装、テスト、移行、運用準備に分かれているとします。Bの合計が高くても、Aに移行と受入支援が入っていなければ比較は終わっていません。
各社へ同じ表を返し、空欄を埋めてもらいます。特に外部システムのAPI利用料、既存ベンダの調査費、データの手直し、社内担当者の作業は、開発会社の金額から外れやすい項目です。
短納期案を選ぶ場合も、人数を増やせば必ず短くなるわけではありません。承認待ち、外部ベンダの回答、データ照合など、並行できない作業を工程表で確認します。
詳細見積まで進めば、金額は確定したと考えてよいか？
契約の基準にはできますが、合意した変更管理の外で金額が動かない保証ではありません。
詳細見積では、誰が何を作るかをWBSへ分け、担当、工数、順序、外部費用を積み上げます。要件定義書、基本設計、非機能要件、受入条件が入力になります。データ移行や切り替え、運用手順まで作業として載っているか確認してください。
変更が出たときの手続も見積もりの一部です。新しい帳票を追加する、連携先の仕様が変わる、移行対象年数を延ばす。そのたびに、費用と納期への影響を出し、誰が承認するかを契約前に決めます。
IPAの情報システム・モデル取引・契約書（第二版）は、開発段階ごとの責務や複数契約の関係を整理しています。見積もりの数字だけでなく、要件定義、開発、保守を誰が担い、成果物をどう確認するかを契約へつなげます。
見積もりで抜けやすい作業は、どこにあるのか？
データ移行、外部連携、受入テスト、切り替え、運用準備が一式表記の外へ漏れやすくなります。
画面を作る費用は見えやすく、使い始めるための作業は隠れやすいものです。たとえば月末の請求締めを新システムへ移すなら、旧システムをどの時点で止めるか、新旧の合計を誰が照合するか、差が出たらどちらへ戻すかが必要です。
「現行同等」という言葉にも注意します。現行画面を写すだけでなく、Excelマクロ、担当者の手作業、夜間バッチ、取引先ごとの例外を調べなければ、同等の範囲を決められません。IPAのモデル契約資料も、再構築では要件定義前の現行システム調査に専門的な技術、費用、時間が必要だと注意を促しています。
社内では、見積もりを受け取る前に何を決めるべきか？
予算幅、優先業務、後回しにできる範囲、判断者、比較基準を社内で先に明確に決めます。
安い提案を探す前に、予算を超えたら何を削るかを決めます。確認画面までを第1段階にする、過去データは直近2年分に絞る、自動登録は受入後に追加する、と優先順位を置きます。
比較する担当者と決裁者も分けます。現場は手順と例外を確認し、経営者は予算、期限、残すリスクを判断する。同じ会議で両方を曖昧にすると、金額だけが先に決まります。
開発会社へは、見積もりのために何を渡せばよいか？
現場の実物、処理件数、例外、連携先、停止時間、予算幅、未決事項を一組で渡します。
匿名化したFAX、Excel、メール、現在の画面、出力帳票を数件用意します。正常な一件だけでなく、手書き修正、空欄、差し戻し、月末だけの処理も含めます。
依頼時には「詳細見積をください」ではなく、「いまは予算枠を判断する超概算が必要」「3社を同じ範囲で比べる概算が必要」と用途を伝えます。そのうえで、前提、対象外、再見積の時期を見積書へ書いてもらいます。
関連記事と相談先は、どこから確認できるか？
発注前の材料は要件整理、依頼先の違いは開発体制の記事から続けて確認してください。
Heygoodへの初回相談では、いきなり確定金額を置きません。現場の帳票と手順を見て、いま出せるのが超概算か概算かを分け、幅が生まれる未確認事項を残します。予算に合わなければ、作る範囲を絞るか、作らない選択も一緒に検討します。