業務システムの見積もりに幅があるのは、金額を出せないからではありません。発注判断に使う超概算、提案比較に使う概算、契約と実行計画に使う詳細見積では、分かっている情報と金額の用途が違うからです。見るべきは最安値ではなく、どの段階の見積もりか、何を仮定し、何を含めていないかです。
同じ「受注管理を作りたい」という相談でも、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への初回相談では、いきなり確定金額を置きません。現場の帳票と手順を見て、いま出せるのが超概算か概算かを分け、幅が生まれる未確認事項を残します。予算に合わなければ、作る範囲を絞るか、作らない選択も一緒に検討します。