システム開発の見積もりの見方｜発注側・受注側が確認したい項目と相場の考え方

システム開発の見積書は、合計金額ではなく「何を、どの工程で、どれだけの工数と単価で、どこまでの品質で作るか」という前提の記述を読むものです。

金額の大小だけで見積もりを比べると、対象範囲やテストの深さが違う提案を同じ土俵に並べてしまい、契約後に追加費用や認識の食い違いが出やすくなります。本記事では、システム開発の発注を担当する情報システム部門・企画部門の方が見積書を読み解けるよう、項目の見方、金額が変わる要因、複数社の比較方法、事前に整理しておく情報、契約前の確認事項、想定と違ったときの対処を順に整理します。受注側で見積もりを出す立場の方にとっても、発注側がどこを見ているかを知る手がかりになります。なお、本記事の内容は2026年10月時点の一般的な整理であり、個別の契約判断は弁護士など専門家へのご相談をおすすめします。

見積もりの前段にあたる発注先選びは「システム開発会社の選び方」、見積もりの土台になる仕様の整理は「システム開発の仕様書とは？種類と書き方の基本」で扱っています。

見積書に載る項目の見方

システム開発の見積書は、開発費・管理費・保守費、そしてそれぞれの工数と単価の2層で読むと全体像をつかめます。まず大きな費目の区分を押さえ、次に内訳の数字を確認します。

開発費・管理費・保守費

開発費は作るための費用、管理費は進行を管理するための費用、保守費は稼働後に支える費用で、この3つは性質が違うため分けて確認します。

• 開発費：要件定義、設計、開発（プログラミング）、テストといった工程ごとの作業にかかる費用です。見積書の中心になります。
• 管理費：進捗管理、課題管理、品質管理、発注側との調整などプロジェクト全体を回す費用です。開発費に対する一定割合で示される例が多く、割合は会社や案件で異なります。
• 保守費：稼働後の障害対応、問い合わせ対応、軽微な修正などの費用です。開発費に含まれず、月額や年額で別建てになる場合が一般的です。

管理費が見積書に独立して載っていない場合は、開発費の単価に含まれているのか、そもそも管理の作業が見込まれていないのかを確認します。保守費が空欄のときは、稼働後の対応範囲と費用が別途協議になるのかを質問しておくと、運用開始後に困りません。

工数と単価の表記

工数は作業量を人日や人月で表したもので、金額は「工数×単価」で組み立てられます。人月は1人が1か月働いた量で、人日はその1日分です。

見積書では、工程ごとに工数と単価が分かれて書かれているかが読み解きの出発点です。単価は工程によって異なるのが普通です。たとえばフリーコンサルタントの月額単価の例では、要件定義や戦略策定のような上流の工程は、運用・保守寄りの工程より高く、IT戦略が150〜200万円程度、運用・保守寄りのIT・システム案件は下限が50〜60万円台まで下がる例があるとされています。システム開発の見積もりでも、工程によって単価に差があること自体は不自然ではありません。

次の表は、読み方を示すための架空の見積もり例です（金額は説明用の仮の数字で、実際の相場を示すものではありません）。

この例では、テストの工数が全体の約2割を占め、管理費が開発費の10%という前提が見えます。発注側は「テストの工数はこの水準で足りるのか」「管理費の10%には何が含まれるのか」を質問でき、受注側も根拠を説明しやすくなります。工数の合計だけが書かれた「一式」表記の見積書は、後から範囲の議論になりやすいため、内訳の提示を依頼するのが安全です。

金額が変わる主な要因

システム開発の金額は、機能の範囲、品質・テストの水準、納期の3つで大きく変わります。同じシステム名でも、この3点の条件が違えば見積もりは別物になります。

機能の範囲

機能の数と複雑さが増えるほど、設計・開発・テストのすべての工数が増えて金額が上がります。画面の数、帳票の数、他システムとの連携の有無が代表的な判断材料です。

同じ「顧客管理システム」でも、顧客情報の登録と検索だけの構成と、営業の進捗管理や外部の会計システムとの自動連携まで含む構成では、必要な作業量がまったく異なります。見積書の対象範囲に「何が含まれ、何が含まれないか」が明記されているかを確認してください。含まれない項目が書かれていない場合は、発注側が当然含まれると考えていた機能が対象外だった、という食い違いにつながります。

品質・テストの水準

求める品質が高いほど、テストの種類と件数が増えて金額が上がります。基幹業務や個人情報を扱うシステムは、社内の補助的なツールより厳しい水準が求められるのが一般的です。

確認したいのは、単体テスト、結合テスト、総合テスト（システムテスト）のうちどこまでが受注側の作業に含まれ、受入テスト（発注側が行う最終確認）の支援がどこまであるかです。性能テストやセキュリティの診断は、標準の範囲に入らず別料金になることがあります。テストの進め方そのものは「システム開発のテスト工程」で整理していますので、見積書のテスト項目と照らして読むと理解が進みます。

納期

納期が短いほど、人員を同時に多く投入する必要が出て金額が上がる傾向があります。人を増やすと作業を分担できる反面、調整の手間も増えるため、単純に期間が半分になれば費用が半分になる関係ではありません。

希望納期が固い事情（法改正への対応、事業開始日が決まっているなど）があるなら、その理由を伝えたうえで、優先度の高い機能から先に出す進め方を相談します。納期の根拠を伝えると、受注側も無理のない計画を立てやすくなります。

複数社の見積もりを比較する

複数社の見積もりは、総額ではなく同じ項目・同じ前提にそろえて比較します。前提が違うまま並べると、安い理由も高い理由も読み取れません。

比較表のつくり方

比較表は、見積書の項目を縦に、各社を横に置き、同じ粒度の情報を記入して作ります。各社の見積書の書式がばらばらでも、発注側で一つの表に写し替えると違いが見えます。

この架空の例では、B社は対象範囲が機能6までで、テストも単体までという前提です。金額が最も低くても、A社・C社と同じ条件に直せば差が縮まる可能性があります。比較は「金額の高低」ではなく「同じ条件での差」で行います。条件が読み取れない箇所は、各社に同じ質問を同じ文面で送ると、回答の質も比べられます。

相場の目安を知りたいときは、公的機関の実績データが参考になります。情報処理推進機構（IPA）は、エンタープライズ分野のソフトウェア開発データを2005年から収集・分析し、5,546プロジェクトの定量データを分析してきました（現在は発行終了）。ただし、案件ごとの条件で工数や金額は大きく変わるため、平均的な数字は自社案件の見積もりを評価する際の参考にとどめ、各社の根拠説明と合わせて判断します。

安すぎる見積もりの注意点

他社より大幅に安い見積もりは、対象範囲の漏れ、テスト工数の不足、前提条件の見落としが隠れている可能性があります。安いこと自体が悪いわけではなく、安い理由を説明できるかが分かれ目です。

• 対象範囲が他社より狭くないか（機能の抜け、データ移行や教育の除外）
• テストや管理の工数が極端に少なくないか
• 追加費用が発生する条件が広く書かれていないか
• 保守費や稼働後の対応が別途となっていないか

編集部が実務者の声を整理すると、見積もりのトラブルは金額そのものより「前提の食い違い」から生じるという見方が多く聞かれます。契約前に質問票で前提をそろえる手間は、稼働後の調整コストを下げる投資と捉えるとよいでしょう。

発注側が準備しておく情報

発注側が要件と予算の優先順位を整理しておくと、見積もりの精度が上がり、各社の比較もしやすくなります。情報が曖昧なほど、受注側は余裕を見込んだ金額を出さざるを得なくなります。

要件の整理

要件の整理とは、システムで実現したい業務と、必要な機能を言葉にして一覧にすることです。完璧な仕様書は不要ですが、「何のために」「誰が」「何をできるようにするか」は最低限そろえます。

整理する項目の例は、現在の業務の流れ、解決したい課題、必要な機能（必須と希望の区別）、利用者の人数と権限、連携する既存システム、データの量と移行の有無です。要件定義書の書き方は「Web開発における要件定義書の書き方」にまとめています。情報が足りない段階では、要件定義だけを先に別契約にして、その結果をもとに開発の見積もりを依頼する進め方もあります。

予算と優先順位

予算の上限と、機能ごとの優先順位は、見積もりの依頼時に受注側へ伝えておく項目です。予算を隠すと、提案が大きすぎたり小さすぎたりして、やり取りが長引きます。

優先順位は、必須・重要・あれば望ましいの3段階に分けると伝わりやすくなります。予算を超える見積もりが出た場合に、どの機能から削るか、あるいは後回しにするかをその場で相談できます。数字を一点で示すのが難しければ、「最大でこの金額まで」という上限と、「できれば抑えたい」目標額の2つを伝えるのも有効です。

契約前の確認事項

契約前には、追加費用が発生する条件と、納品物を受け入れる検収基準の2点を書面で確認します。見積金額が同じでも、この2点の取り決めで最終的な負担は変わります。

追加費用の扱い

追加費用は、どういう変更が追加扱いになり、誰がどう承認するかを事前に決めておけば、無用な争いを防げます。要件の変更は開発では起こりうるため、変更を禁止するのではなく、変更の手続きを決める考え方が現実的です。

確認しておきたいのは、契約形態です。業務委託契約の一般的な整理では、請負契約は成果物の完成・納品が報酬の対象で、受注側に完成義務があります。準委任契約は業務の遂行そのものに報酬が発生し、成果物の完成義務は負いません。SES契約のように、月140〜180時間などの時間精算で報酬が決まる形態もあります。システム開発の見積もりでも、どの契約形態を前提にした金額かで、追加作業の費用負担や責任の範囲が変わります。契約形態の違いは「業務委託・準委任・請負の違い」で詳しく解説しています。契約条項の法的な解釈は案件によって異なるため、個別の判断は専門家に相談してください。

• 追加費用が発生する変更の定義（仕様変更、範囲外の作業、再テストなど）
• 変更を依頼する手続きと、見積もりを取り直す流れ
• 追加の単価の考え方（契約時の単価を適用するか）

検収基準

検収基準とは、納品物が契約の要件を満たしていると発注側が認める条件です。基準が曖昧だと、いつまでも納品が完了せず、支払いの時期も定まりません。

決めておきたい内容は、検収の対象物（プログラム、設計書、テスト結果報告書など）、検収の期間（納品から何営業日以内に確認するか）、合格の条件（テストの合格率や重大な不具合がないことなど）、不具合が見つかった場合の修正の扱いです。検収の期間を過ぎた場合に合格とみなすかどうかも、契約書で確認しておきます。見積書の段階で、検収に必要な成果物が費用に含まれているかを見ておくと、後から追加で請求される事態を避けられます。

見積もりが想定と違うときの対処

見積もりが想定より高いときは、いきなり値引きを求めるのではなく、範囲の見直しと段階発注を検討します。金額を下げる交渉より、金額の根拠を動かす方が納得感のある結果になります。

範囲の見直し

範囲の見直しとは、機能の優先順位をもとに、今回の開発に含めるものと後回しにするものを分け直すことです。最初から全機能を作る必要がない場合は、費用を大きく抑えられます。

進め方は、見積書の機能別の内訳を確認し、必須でない機能を洗い出します。画面や帳票の数を減らす、既存のパッケージや外部サービスで代替できる部分は使う、データ移行は最小限にとどめる、といった選択肢があります。受注側に「予算内に収める案」の再提案を依頼すると、範囲の調整案を専門家の視点で示してもらえます。

段階発注の選択

段階発注は、開発を複数の段階に分け、各段階ごとに見積もりと契約を行う方法です。全体の金額と期間の見通しが立ちにくい案件で、リスクを抑えられます。

たとえば、第1段階で要件定義と基本設計までを行い、その成果をもとに第2段階の開発の見積もりを取り直します。要件が固まってから開発の金額を確定できるため、見積もりの精度が上がる利点があります。一方で、段階ごとの契約手続きが増える点や、後の段階の金額が現時点では確定しない点は、デメリットとして理解しておきます。どの段階で次へ進むかを判断する基準を、最初の契約のときに決めておくと進行がスムーズです。

見積もりの読み方に迷う場面では、プロジェクトの進行を支援するPMOやITコンサルタントなど、発注側に立って見積もりを評価できる専門人材を活用する選択肢もあります。

出典・参考情報

1. 独立行政法人情報処理推進機構（IPA）「ソフトウェア開発分析データ集」（2026-10-05参照）

本記事の見積もり例は説明用の架空の数字です。最終更新日は2026年10月5日で、契約や法務に関する個別の判断は専門家にご相談ください。