システム開発の見積もりはなぜずれる？内訳・比較・失敗を防ぐ依頼方法

CONTENTS / ARTICLE MAP目次25項目

システム開発の見積もりがずれる主因は、目的・利用者・データ・例外・外部連携・非機能要件・移行・運用・変更手続きの9項目が、概算時点で十分に決まっていないことです。見積額だけをそろえるより、前提と未確定事項をそろえる方が差を説明できます。

見積もりがずれる9つの原因と防ぎ方

ずれる原因	見積もり前に決めること
目的・利用者	解決する業務、対象者、成功条件
データ	件数、品質、保持、移行、削除
例外	失敗、取消、重複、途中再開
外部連携	相手、認証、上限、停止時の動き
非機能要件	性能、可用性、セキュリティ、監査
移行	切替、並行運用、戻し方
運用	問い合わせ、監視、更新、障害
変更手続き	追加判断、費用、納期、承認者

見積もりは精度の段階を分ける

段階	分かっていること	使い方
超概算	目的、対象業務、規模感	実施可否、予算枠、調査範囲
概算	主要機能、方式、外部連携、品質条件	候補比較、優先順位、要件定義計画
確定に近い見積もり	要件、画面、データ、例外、受入条件	契約、工程、変更管理の基準

IPAの「ソフトウェア見積り」解説は、初期には情報が一部しかなく、要件が明確になるにつれて見積もりが変わる構造を説明しています。類推、専門家判断、トップダウン、ボトムアップ、パラメトリック等の方法を挙げ、売れる価格へ合わせるだけのPrice to Winを不適切としています。資料は2004〜2008年度事業のアーカイブですが、見積もり方法の基礎として参照できます。

見積もりがずれる9つの原因

1. 目的が機能名だけ
   誰の何を改善するかが曖昧。
2. 現行業務を未確認
   例外、手作業、承認、繁忙期が後から判明。
3. データが見えていない
   形式、件数、品質、移行、保持、削除が未定。
4. 外部連携の前提不足
   仕様、契約、権限、制限、障害対応が不明。
5. 非機能要件が後回し
   性能、可用性、安全、監査、バックアップが未定。
6. 管理画面・運用を忘れる
   登録、承認、検索、出力、問い合わせが必要。
7. テスト条件がない
   対象環境、データ、合格条件、担当者が不明。
8. 確認待ちを見込まない
   社内判断、素材、外部審査が工程へ影響。
9. 変更管理がない
   修正と仕様変更の境界、再見積もり方法がない。

見積書の内訳で確認すること

項目	確認
調査・要件	現状、業務、利用者、データ、未決事項の成果物
設計	画面、処理、データ、権限、例外、外部連携
開発	対象機能、方式、環境、レビュー、管理画面
テスト	単体、結合、総合、受入、性能、安全、移行
導入	データ移行、教育、切替、バックアップ、切戻し
管理	計画、進捗、課題、品質、会議、変更、報告
運用	監視、問い合わせ、障害、更新、改善、終了

GeNEEの2026年7月更新記事も、概算と確定、工数、要件粒度、類推・トップダウン・WBS積み上げ等の算出方法、PM、調査、要件、設計、実装、テスト、導入、保守を説明しています。同記事の規模別価格は同社の目安であるため、本記事では一般的な平均には使用しません。

相見積もりを同じ条件へそろえる

• 対象業務、利用者、主要機能
• 含む・含まない範囲
• 見積もり時点の前提と未決事項
• データ、外部連携、移行
• 性能、安全、可用性、監査
• テスト、受入、公開、切戻し
• 変更・再見積もりの手順
• 運用・保守、ソース・データ・文書の引き継ぎ

契約形態は仕事の不確実性に合わせる

完成物と受入条件を明確にできる範囲と、調査・改善を繰り返す範囲では、適した契約・管理方法が異なります。名称だけでなく、成果、作業、責任、変更、報告、支払いを契約書で確認します。フリーランス法の対象となる取引では、条件明示や支払期日等の公式案内を公正取引委員会で確認してください。

AIで見積もり精度は上がるか

AIは要件候補、WBS、リスク、テスト観点、コードの初案を速めますが、現行業務、データ品質、例外、外部制約、責任、受入条件を自動で確定できません。AIで作った機能一覧を確定仕様とせず、現場確認と判断記録を行います。

見積もりの幅は不誠実ではなく未確定情報の表現になる

初期見積もりに幅があること自体は失敗ではありません。まだ利用者、業務例外、データ、連携、品質条件が決まっていない段階で一点の金額を確約する方が、前提抜けを隠すことがあります。重要なのは、幅の理由、金額を動かす項目、追加調査、次の更新時点を説明できることです。

不確実性	例	見積もりでの扱い
事業・価値	誰が使うか、課題が本当にあるか、優先機能	調査・試作で検証し、本開発を分ける
業務・要件	例外、承認、権限、手作業、法的条件	主要フローと例外を整理し、未決事項を残す
技術	既存連携、性能、端末、データ品質、古い環境	技術検証やサンプル移行を行う
外部	API、審査、他社、法令、料金、納期	責任分界、代替、余裕、変更条件を置く
組織	決裁、素材、担当者、レビュー、繁忙期	承認者と回答期限、遅延時の影響を決める

超概算では、類似案件や大きな機能群から幅を置き、投資判断に使います。概算では主要フロー、方式、データ、連携、品質を整理します。確定見積では、対象、前提、成果物、検収、スケジュール、変更条件を具体化します。名称は会社によって違うため、「この見積もりで何が確定し、何が未確定か」を確認してください。

古いIPA資料は、見積手法として類推、専門家判断、トップダウン、ボトムアップ、パラメトリック等を整理し、開発が進むほど情報が増え見積もりが変わることを扱っています。資料の年代は古いものの、「初期情報が少ないほど精度に限界がある」という考え方は、現在のクラウド・SaaS・AI開発でも前提として確認できます。

見積書はWBSだけでなく前提・除外・完了条件まで読む

工数の一覧だけでは、同じ完成状態を想定しているか分かりません。機能・工程の内訳に加えて、前提条件、対象外、発注者作業、外部費用、品質、検収、変更、運用を読みます。

見積欄	具体的に確認すること
成果物	画面、機能、管理、データ、設計、ソース、手順、テスト記録
前提	利用者数、データ量、外部仕様、素材、対応端末、稼働時間
除外	移行、原稿、外部契約、審査、運用、教育、セキュリティ診断
発注者作業	要件回答、データ整備、アカウント、法務確認、受入テスト
品質	対象OS・ブラウザ、性能、可用性、安全、アクセシビリティ
検収	正常・例外、テストデータ、合格基準、不具合と追加要望の境界
変更	依頼、影響分析、見積、承認、優先順位、納期更新
運用	監視、障害、問い合わせ、バックアップ、更新、終了時移行

「設計一式」「テスト一式」とまとめられている場合、工程名を細かくすることが目的ではありません。必要な責任が含まれるかを確認します。たとえばテストなら、開発者の単体確認、連携、システム、性能、安全、受入のどこまでか、誰がテストデータを用意し、どこで行うかを聞きます。

発注者作業を無料と考えないでください。現場ヒアリング、資料、データ整形、承認、受入、教育には社内時間が必要です。制作会社の見積が安くても、発注者へ多くの作業が移っている場合があります。外注費と社内投入時間を一つの工程表にします。

相見積もりは機能名でなく利用シナリオへそろえる

「会員管理」「予約」「請求」といった機能名は会社ごとに解釈が違います。利用者・条件・操作・結果・失敗時を含むシナリオへ変えて渡します。たとえば「担当者が空き枠を登録し、利用者が予約し、重複時は確定せず案内され、双方へ通知され、管理者が取消と履歴を確認できる」と書きます。

比較軸	A社・B社でそろえる内容	差として評価する内容
初回範囲	同じ主要シナリオ、権限、データ、端末	後回し提案、代替、過剰機能の指摘
方式	必要な品質・連携・運用条件	採用理由、制約、移行、保守性
品質	性能、安全、可用性、対象環境	試験方法、記録、リスクの説明
未決事項	同じ質問と回答、決定期限	調査計画、幅の示し方、優先順位
12か月運用	同じ利用量・外部費用シナリオ	監視、障害、改善、引き継ぎ体制

提案内容が違う場合、総額をそのまま順位付けしません。A社は初回へ10機能を入れ、B社は3機能で検証してから拡張するかもしれません。どちらが安いかではなく、最初の投資で何を学び、どのリスクを減らし、次の費用がいつ発生するかを比べます。

各社から質問を受けたら、共通Q&Aへ回答を追記します。一社だけが重要な制約を発見した場合、他社にも同じ情報を伝えます。それでも提案が変わる部分が会社の判断差です。情報差を価格差と誤認しないよう、版と更新日を管理します。

固定価格・準委任・段階契約を不確実性に合わせる

契約形態は安さではなく、仕事の不確実性と成果の定義に合わせます。要件が明確な移行や定型実装は成果物・検収を固定しやすく、利用者検証や継続改善は優先順位を見直しながら進める方法が合う場合があります。

進め方	向きやすい作業	必要な管理
成果物・固定範囲	仕様と合格条件を定めやすい実装・移行	前提、除外、検収、変更見積、納期
時間・体制型	調査、改善、要件が変わる開発	予算上限、優先順位、実績報告、成果レビュー
段階契約	調査→試作→本開発→運用を分けたい	各段階の成果、継続判断、資料の利用権
混合	確定部分と探索部分が同居する	どの範囲がどの契約・責任かを明記

どの形でも、報告と承認が必要です。時間型だから成果が不要なのではなく、調査結果、設計、動く機能、テスト、未決事項等を定期レビューします。固定価格だから変更を一切できないのではなく、影響を見積もり、範囲・費用・納期を合意して変更します。

段階契約では、調査成果物を発注者が保有し、別会社にも説明できるか確認します。先行会社へ本開発を依頼する利点はありますが、調査結果が同社内にしか残らないと比較や引き継ぎが難しくなります。契約終了時の資料、データ、アカウント、作業途中成果も決めます。

変更管理は追加費を防ぐ仕組みではなく判断を残す仕組み

開発中に変更が出ること自体は自然です。現場理解が進み、外部仕様や事業条件が変わるためです。問題は、変更が口頭・チャットへ散らばり、費用・納期・他機能への影響を確認せず積み上がることです。

1. 変更理由を記録
   不具合、要件漏れ、事業変更、改善案のどれかを分けます。
2. 影響を確認
   設計、データ、画面、テスト、外部連携、運用、納期を見ます。
3. 選択肢を出す
   今入れる、代替する、後回し、採用しないを比較します。
4. 承認する
   決裁者が費用・納期・範囲を確認し、最新版へ反映します。
5. 完了を検証
   変更部分と関連機能を確認し、記録を閉じます。

不具合修正と追加要望の境界も検収条件で決めます。合意した結果と違うなら不具合、合意後に新しい結果を求めるなら変更という基本はありますが、要件文が曖昧なら争いになります。利用シナリオ、画面、データ、例外、合格基準を承認時に残します。

AIで見積もりは速くなるが、未知と責任は消えない

AIは、要件の抜け候補、WBS、類似機能、テスト観点、議事録、コード試作を速められます。しかし、現場で例外が何件あるか、既存データがどれほど壊れているか、外部システムが仕様どおりか、利用者が価値を感じるかは、実際の調査と検証が必要です。

AIに入力した前提が誤っていれば、詳細に見える誤見積もりができます。見積もりの根拠としてAI出力を使う場合も、情報源、対象版、仮定、除外、担当者レビューを残します。顧客の機密資料や個人情報を外部サービスへ入力する場合は、契約とデータ取扱いを確認します。

コード生成で実装時間が減る部分があっても、要件、レビュー、統合、テスト、安全、運用、保守が残ります。大量のコードを短時間で作るほど、変更量、依存、検証範囲が増える場合もあります。「AI利用で何割安い」と一律に置かず、短縮した作業と新しく必要になった検証を工程ごとに見積もります。

4つの案件ケースで見積もりの進め方を変える

新規事業で要件が固まっていない

最初から全開発の確定見積を求めず、利用者調査、UI試作、技術検証、初回範囲を先に行います。先行工程の費用、期間、成果物、継続判断を契約します。市場や価値の不確実性を、機能一覧の詳細化だけで解消しようとしません。

概算は、初回検証版、想定本番版、上振れ条件に分けます。検証で仮説が成立しなければ、本開発へ進まない停止条件を置きます。調査成果を別会社にも説明できる形で受け取り、継続発注を自動的な義務にしない方法もあります。

古い業務システムを置き換える

画面数より、現行業務、例外、データ品質、外部連携、並行稼働、教育が費用を動かします。代表データで移行を試し、エラー率と手修正を確認して全件見積を更新します。旧システムの仕様書があっても、実運用と一致するか現場へ確認します。

切替日に全機能を同時移行する案と、部門・機能ごとの段階案を比較します。二重入力やデータ同期が増える場合もあるため、段階移行が常に安いとは限りません。停止時間、切戻し、旧データ参照、監査を含めます。

外部API・SaaS連携が多い

連携先ごとに、契約、担当、仕様、検証環境、料金、件数、認証、正本、障害、再送、終了を確認します。相手の仕様が不明なら、接続試験を先行工程へ分けます。APIがあることと、必要業務を安全に完了できることは同じではありません。

外部障害や仕様変更は開発会社だけで防げません。検知、暫定運用、利用者表示、再処理、追加費用の責任分界を契約します。将来料金が変わる可能性があるため、利用量の開始・想定・上振れを置きます。

法令・契約で期限が動かせない

期限内に必要な最低業務と、後から追加できる機能を分けます。既製サービス、手動運用、暫定画面を組み合わせる案も比較します。ただし安全、個人情報、会計、法的表示等の必須条件を「暫定だから」と省きません。

工程表には、発注者の回答、アカウント、法務確認、データ、教育、受入も入れます。確認遅延時に何を後回しにするかを先に決めます。短納期を約束するだけの会社より、範囲・品質・リスクの調整を説明できる会社を選びます。

発注者が毎月確認する見積もり健全性

契約後も見積もりは管理資料として更新します。予算消化だけでなく、完成した価値、残作業、未決事項、変更、リスク、予測完了を確認します。初期見積との差が出たら、誰の責任かを先に争うのではなく、前提が変わった理由と今後の選択肢を整理します。

月次確認	問い
範囲	初回公開に必要な範囲は変わったか。削れるものは何か
実績	動く成果とテストで何を確認できたか
未決	誰がいつ決め、遅れると何へ影響するか
変更	理由、費用、納期、品質、優先順位を承認したか
予測	残作業、外部待ち、リスクを含む最新予測はいくらか
運用	公開後12か月費用と体制に新しい前提がないか

進捗率だけでは判断しません。簡単な画面が多数終わり、難しい連携・データ移行・性能が残っていれば、90%完成とはいえません。難所を早く試し、残リスクを減らす順序にします。

追加要望は一件ずつ影響を見るだけでなく、累積を確認します。小さな変更が多数あると、設計・テスト・運用が複雑になります。一定期間ごとに、まとめて後続版へ回す、既存機能をやめる、標準へ戻す判断をします。

予算上限に近づいたら、品質確認を削る前に範囲を削ります。初回利用者、対象部門、データ件数、外部連携、レポート等を段階化します。安全・個人情報・復元・主要業務の完了条件は残します。

最終的に、見積もりの成功は初期金額と一致することだけではありません。前提と変更が記録され、重要な判断を早く行い、価値の低い開発を止め、公開後に運用できる範囲へ投資を収めることです。

システム開発見積もりの最終チェックリスト

• 超概算・概算・確定のどの段階で、何が未確定か分かる
• 不確実性を事業、業務、技術、外部、組織へ分けた
• 成果物、前提、除外、発注者作業、品質、検収、変更、運用がある
• 複数社へ同じ利用シナリオとQ&Aを渡した
• 難所の調査・技術検証・代表データ移行を早い段階へ置いた
• 契約方式が確定作業と探索作業の性質に合っている
• 変更の理由、影響、選択肢、承認、検証を記録する
• 初期費と12か月運用、社内時間、終了時引き継ぎを比較した

一点の金額より、判断が変わる条件と更新方法を確認します。幅がある見積もりでも、理由と減らす手順が明確なら実務で使えます。

予算超過時は品質・安全・復元を削らず、初回利用者、対象部門、機能、連携を段階化します。価値の低い開発を止められることも、良い見積もり管理の成果です。

見積差が大きい場合は、単価の違いと範囲の違いを分けます。同じ作業でも経験・体制・品質条件で単価は変わりますが、移行、管理画面、例外、テスト、運用が抜けた提案は単価比較以前の問題です。各社に差の理由を説明してもらい、必要なら初回範囲を共通化して再見積を取ります。最安額を選ぶ前に、未決事項が解消したときの上振れ、追加承認、契約終了時の費用まで確認してください。

プロジェクト終了時には、最終請求だけでなく、未完了、既知の不具合、運用課題、外部契約、権限、データ保持、バックアップを確認します。開発会社へ残るアカウントと秘密情報を削除し、発注者側で更新します。終了後の問い合わせ窓口や保証期間がある場合は期限を記録します。完成した機能だけでなく、運用者が説明を受け、障害時に必要資料へ到達できることを検収に含めてください。

最新予測を更新するときは、楽観・想定・悲観の三つを置き、各差を生む条件を示します。一つの「残予算」だけより、経営側が範囲削減、追加投資、延期、中止を判断しやすくなります。確率を根拠なく精密に見せず、確認できた事実と仮定を分けます。

判断会議では最新見積の版と基準日を確認し、古い数字を混ぜません。

よくある質問

システム開発の見積もりはいつ確定しますか？

要件、データ、連携、品質、受入条件が明確になるほど精度は上がります。初期は幅を持つ概算とし、要件定義後に確定範囲と残る不確実性を更新します。

会社ごとに金額が違うのはなぜですか？

想定範囲、方式、担当者、品質、リスク、除外、運用が違うためです。同じ依頼資料を渡し、範囲・前提・未決・品質・変更条件で比較します。

追加費用を完全になくせますか？

未知を完全になくすことは困難ですが、調査、段階見積もり、優先順位、変更管理、予備費、停止条件で予測可能性を高められます。追加の原因と承認手順を事前に決めます。