システム開発の見積もりの取り方と内訳｜妥当性の判断基準

システム開発の見積もりを取るときは、同じ依頼資料を複数の開発会社へ渡し、機能に加えて利用者、データ、外部連携、品質条件、納品物、発注側の担当範囲まで示します。届いた見積書は、「何を作り、どこまで確認し、何を含まないか」が工程別に説明されているかで比べるのが基本です。

見積額の差は、要件定義やテスト、リリース支援を含む範囲の違いからも生じます。高い見積もりを過剰、安い見積もりを効率的と金額だけで評価するのは早計です。前提が違う総額を並べても、妥当性は判断できません。

では、まだ仕様を固め切れない小規模開発では、どこまで揃えれば比較できるのでしょうか。答えは、未確定事項を隠さず、確定する工程と再見積もりの条件まで見積書に含めることです。

AI機能を含む場合は、モデルやAPIの実装費だけでなく、評価、ガードレール、人手確認、監視も条件へ加えます。AIシステム開発費の内訳と再見積もり条件も併せて確認してください。

システム開発の見積もりは「同じ条件」で取る

開発会社へ最初に渡す資料は、詳細な仕様書でなくても構いません。ただし、会社ごとに口頭で異なる説明をすると、提案の前提がずれます。少なくとも次の内容を一つの依頼資料にまとめます。

• 解決したい業務課題と、開発後に実現したい状態
• 主な利用者、利用場面、想定する権限の違い
• 必要な機能と、今回は作らない機能
• 扱うデータ、その入手元、移行の有無
• 会計、決済、認証など外部サービスとの連携
• セキュリティ、性能、可用性、対応端末などの非機能要件
• 希望時期、予算上限、優先順位
• 発注側が用意する素材、確認担当者、意思決定の方法
• 希望する納品物と、公開後の運用・保守の範囲

資料の厚さよりも、見積もりに影響する条件を各社へ同じように伝えることが比較の精度を左右します。不明な項目は「未定」としたうえで、開発会社が置いた仮定と金額への影響を記載してもらいます。

独立行政法人情報処理推進機構（IPA）の「ITユーザとベンダのための定量的見積りの勧め」も、見積もり対象の機能・非機能要件、開発条件、ライフサイクル全体、発注者と開発会社の役割分担を明確にする必要性を示しています。古い資料ではありますが、スコープと根拠を双方で共有するという判断軸は、小規模開発にもそのまま使えます。

見積書の内訳で確認する項目

「開発一式」だけでは、金額を削ったときに何が失われるのか分かりません。工程ごとの作業、工数または算定根拠、成果物、前提条件が対応しているかを確認します。

名称は会社によって異なります。項目名があるだけで安心せず、その費用で行う作業と残る成果物を説明できるかを見ます。とりわけテストや管理の費用が見えない場合は、無料なのか、実装費に含むのか、そもそも対象外なのかを確認すべきです。

見積もりの妥当性を判断する5つの基準

1. 対象範囲と除外項目が対になっている

「会員管理を作る」という記載だけでは、登録、招待、退会、権限変更、パスワード再設定のどこまでを含むか判断できません。機能一覧とともに、対象外、発注側対応、外部サービスで代替する部分を確認します。

2. 工数の根拠が機能や成果物につながっている

工数は作業量を表す尺度です。画面数、機能、データ項目、連携先、成果物など、規模を捉える単位と結び付いていれば、人数の多寡に惑わされず説明を追えます。

IPAの資料では、見積もる対象と測定単位を定め、成果物の規模から、プロジェクト特性による変動を考慮して工数を求める流れが示されています。また、標準的な生産性から外れる要因を洗い出す考え方も紹介されています。したがって、単価や工数の数字だけでなく、「どの複雑さを織り込んだか」を尋ねることが妥当性の確認になります。

3. 非機能要件が金額に反映されている

同じ機能でも、扱う情報、アクセス量、停止できる時間、ログの保存、権限管理、対応端末が違えば設計とテストは変わります。非機能要件を後回しにした安い見積もりは、比較上だけ安く見えているおそれがあります。

2026年7月24日時点で公開されているデジタル庁の「デジタル社会推進標準ガイドライン」には、要件定義書と調達仕様書の標準テンプレートを含む実践ガイドブックが掲載されています。政府情報システム向けの資料であり、そのまま小規模な民間開発へ適用するものではありません。それでも、セキュリティを企画から運用まで扱い、関係者の役割を定義する考え方は、見積もりの漏れを探す参考になります。

4. 未確定事項と変更時の扱いが明記されている

概算の段階で細部まで確定額を求めると、開発会社は仮定を置かざるを得ません。その仮定が見えないことが問題です。未確定事項、確定期限、確定後に増減する費用、仕様変更の承認方法を記載してもらいます。

要件が変われば、当初の見積もりも変わります。IPAも、工程の進展に合わせた段階的な見積もり、要件変更ルール、変更に伴う再見積もり、根拠の明確化を挙げています。変更を一切起こさない約束より、変更を判断できる手順のほうが現実的です。

5. 発注後の責任分担まで説明できる

受入テスト、データ移行の確認、外部サービスの契約、公開判断、問い合わせ対応を誰が担うのかを揃えます。納品の定義と検収条件も欠かせません。見積書、提案書、契約書で範囲が食い違う場合は、発注前に修正します。

この5点が揃えば、削れる機能、残すべき品質、発注側に移せる作業を具体的に話し合えます。最安値を探す段階から、予算内で何を実現するかを選ぶ段階へ進めます。

概算から正式見積もりへ進める手順

最初から一度で確定させようとせず、情報量に応じて精度を上げます。

1. 業務課題、必須機能、制約、予算上限をまとめる
2. 同じ資料と質問項目で複数社へ概算を依頼する
3. 各社の前提、対象外、リスク、確認事項を並べる
4. 発注候補と要件整理や技術調査を行う
5. 確定した範囲、変更方法、検収条件に基づいて正式見積もりを受ける

この順番なら、概算を確約と誤解せずに済みます。予算が先に決まっている場合は、その枠内で実現できる機能量を見積もり、優先順位の低い要件を後続の開発へ回します。見積もり前にSaaS・パッケージ・個別開発の範囲を決めるには、フルスクラッチ開発を選ぶ判断表を使えます。

相見積もりでは、金額以外の回答も表にします。前提を具体的に質問し、リスクを先に示す会社は、一見高くても比較対象に残す価値があります。質問がほとんどないまま確定額が出た場合も、置かれた仮定を一つずつ確認します。

AIを使う開発見積もりで確認したいこと

AI支援によって、コードのたたき台作成や定型的な実装を効率化できる場面はあります。要件定義、設計、生成物のレビュー、セキュリティ確認、テストには人の責任が残ります。AIが速くする対象と、人が責任を持つ工程を分けて確認します。

• AI利用を織り込んだ工程と、見積もりへの反映方法
• 入力してよい情報と、機密情報・個人情報の扱い
• 生成されたコードや文書のレビュー担当者
• テスト、脆弱性対応、第三者ライセンス確認の責任範囲
• 利用するAIサービスの費用と、運用開始後の負担

「AIを使うから安い」という説明だけでは判断できません。実装工数が減っても、業務を理解して仕様を決め、品質を確認する責任は残ります。小規模なMVP、業務システム、既存システム改修、AI機能の組み込みでも同じです。

発注前に開発会社へ聞く質問

発注前には、見積書を見ながら次の質問へ回答してもらいます。

• この金額が成立する前提は何か
• どの機能、品質、成果物が対象外か
• 最も工数へ影響している要素は何か
• 未確定事項をいつ、誰が決めるか
• 仕様変更時に、費用と納期をどう再計算するか
• テストと検収で、双方が何を担当するか
• リリース後に別途発生する費用と作業は何か

回答を各社で横並びにすれば、総額差の理由が見えてきます。説明できない差額を残したまま、価格だけで選ばないことが大切です。

システム開発の見積もりは、相場との近さに加え、各社が置いた条件から妥当性を判断します。仕様を固め切れない段階でも、未確定事項、確定する工程、再見積もりの条件を明記すれば比較できます。対象範囲、内訳、非機能要件、変更条件、責任分担が同じ土俵に載っているか。その確認を終えて初めて、総額が事業の予算と得たい価値に見合うかを判断できます。

株式会社adding編集部

費用、期間、契約、法務・税務上の扱いは条件により異なります。記事の確認日とリンク先の一次情報を確認し、個別判断は専門家へご相談ください。

システム開発・発注ガイドへ戻る