システム開発の見積もりの見方｜項目・妥当性チェック・比較のポイント

システム開発の見積もりは、総額や人月単価だけを比べても妥当性を判断しにくいものです。同じ「開発」と書かれていても、要件定義、テスト、移行、保守、外部サービス費用などの含有範囲が異なれば、金額差は単純な価格差ではなく条件差になります。

この記事では、見積書の項目、人月と体制の照合方法、相見積もりの評価、追加費用の確認、契約前の進め方を整理します。読後には、見積総額ではなく条件をそろえて比較・判断する方法が分かり、不足や曖昧さがある見積もりを質問・保留・再見積の対象として扱えるようになります。

見積もりは総額だけでなく、要件から検収・変更条件までのつながりを確認して比較します。

01Section見積総額だけでは妥当性を判断できない理由

見積金額が低いから有利、高いから過剰とは、総額だけでは判断できません。比較すべきなのは、同じ要件・品質・納期・責任範囲に対する費用かどうかです。

金額差は「価格差」ではなく「条件差」として生じる

見積額に差が出る主な理由は、対象機能や画面・帳票の範囲、設計やテストの深さ、体制と稼働時期、移行・外部連携の扱い、未確定事項への前提の置き方にあります。たとえば、ある会社が結合テストや移行リハーサルを含め、別の会社が対象外としている場合、総額を並べるだけでは比較になりません。

まず、次の対応関係を説明できる状態をつくります。

要件・制約 → 作業範囲 → 成果物 → 工数・体制 → 納期 → 費用 → 検収・変更条件

このつながりのどこかが不明なら、金額の高低を評価する前に確認が必要です。特に、対象外事項、未確定事項、テスト範囲、変更時の扱い、発注側の回答期限が書かれていない見積もりは、質問への回答や改訂版がそろうまで判断を保留します。

妥当性は「要件から契約条件までの整合」で点検する

見積もりの確認では、「この金額は相場より高いか」ではなく、「この金額で、何を、どこまで、どのような条件で実施するのか」を確認します。既存システムの改修や再構築では、現行調査に専門性、時間、費用が必要になることもあります。そのため、調査や影響確認が見積範囲に入るかも確認対象です。

また、見積比較の段階と契約前の確定段階は分けて考えます。比較段階では範囲・工数・提案内容を確認し、契約前には仕様・検収・支払・変更管理・責任分担を文書で最終確認します。

「開発一式」は補足資料との対応で確認する

「開発一式」という表記だけで候補外にする必要はありません。一方で、その表記だけでは比較や契約に必要な範囲が分かりません。提案書、工程表、成果物一覧、前提条件一覧、質問回答を合わせて、対象範囲・成果物・対象外・変更条件を説明できるか確認しましょう。

02Section見積書は「作業・成果物・前提・対象外」で読む

工程名や費目名の分け方は、会社、開発手法、契約形態によって異なります。要件定義は「何を実現するか」を整理する工程、設計は「どう実現するか」を決める工程として捉えると、名称の違いを読み替えやすくなります。

IPAの情報システム・モデル取引・契約書でも、開発段階ごとの責務、仕様、プロジェクト管理、検収方法について、関係者間で共通理解を得る考え方が示されています。見積書の費目名だけでなく、補足書類を横断して確認することが重要です。

成果物と承認方法を先に確認する

「設計費」「テスト費」といった費目があっても、成果物や承認方法が不明なら、何をもって工程を完了とするか分かりません。要件定義書、画面・帳票の一覧、連携仕様、テスト計画・結果、移行手順などについて、作成の有無だけでなく、発注側の確認者、確認期限、差戻し時の扱いを確認します。

発注側の確認が遅れると、受託側の作業開始や後続工程に影響する場合があります。工程表には、レビュー対象、判定責任者、回答期限を置き、期限変更時は納期・費用への影響も記録します。

初期費用と保守・外部費用の責任分担を確認する

クラウド、ライセンス、外部サービス、連携先の改修は、初期開発費とは別に発生することがあります。契約主体が自社か受託側か、初期・月額・年額・従量のどれか、更新時や上限超過時の負担は誰にあるかを確認しましょう。

移行費用についても、対象データの件数や品質、データ整備、試行、切替立会いが含まれるかで費用と期間が変わります。「移行対応あり」という記載だけではなく、対象と手順を確認することが必要です。

03Section人月は「単価」ではなく工数・体制・工程の整合で読む

人月単価だけでなく、見積工数を実際の体制と配置時期で供給できるかを照合します。

人月は、作業量と体制を表す単位です。費用は、基本的に次の式で確認します。

費用合計 = Σ（役割別工数［人月］×役割別単価）

一方、見積書に記載された工数を実際に供給できる体制かは、次の式で照合します。

供給工数 = 担当人数 × 稼働率 × 配置月数

役割別の単価が異なること自体では判断せず、担当範囲、責任、レビュー、テスト、不具合修正、進捗・変更管理を含めて確認します。IPAのCoBRA法に基づく見積り支援ツールも、規模や工数実績に加え、工数の変動要因を把握して見積評価を行う考え方を示しています。

架空試算で費用と供給工数を照合する

以下は計算構造を示すための架空例です。単価、工数、人数、稼働率、体制は相場、標準単価、適正な工数比率、標準体制を示すものではありません。

この例では、費用合計は「96万円＋132万円＋228万円＋64万円＝520万円」です。供給工数も、役割ごとの人数・稼働率・配置月数から計算すると合計5.2人月となり、見積工数と一致します。いずれかが一致しない場合は、体制表、配置時期、または見積工数の確認が必要です。

人月を人日・人時へ換算する場合も、見積書と契約書の稼働条件を確認します。特定の換算値を契約上の前提として固定せず、各案件の精算条件や稼働時間の定めに従うことが大切です。

人数を増やしても短縮できない工程を確認する

4か月の予定であっても、要件確認、設計承認、結合テスト、受入テスト、修正、リリース判定には前後関係があります。開発者を増やせば一部の実装は並行できる可能性がありますが、共通設計や連携仕様が未確定なら着手できません。

請負か準委任かによって、成果物、検収、報酬請求・精算の確認観点は異なります。IPAのモデル契約資料を確認の参考にしつつ、個別の契約条件は契約書と社内の法務・購買基準で確認してください。

04Section相見積もりは必須条件・加点評価・リスク評価を分ける

相見積もりでは、発注可否を決める必須条件、提案の評価、残るリスクを分けて記録します。

相見積もりを有効にするには、全候補へ同じ依頼条件を渡すことが前提です。目的、対象業務、必須機能と優先順位、現行環境、連携先、移行、希望時期、制約、未確定事項を、版番号と更新日を付けて共有します。

質問への回答、仕様変更、前提条件の追加も、全候補に同じ内容・同じ時点で共有します。未確定事項は「未定」と明記し、各社が置いた前提を提案書・見積書に記載してもらうと、後から条件差を追いやすくなります。

デジタル庁の標準ガイドライン解説書では、要件理解、作業範囲、成果物、スケジュール、提案の具体性・整合性などが評価観点として扱われています。民間委託に適用義務がある方式ではありませんが、比較軸を設計する参考になります。

必須条件で候補外を先に判定する

加点評価の前に、満たせないと発注できない条件を判定します。必須機能、リリース時期、予算上限、必要なセキュリティ条件、契約上の必須条件などが該当します。条件付きで満たせる場合は、条件の内容、確認期限、満たせない場合の扱いを記録します。

最安値以外を選ぶ理由を評価メモに残す

最安値ではない候補を選ぶ場合は、感覚的な評価にしないことが重要です。たとえば、テスト範囲が具体的である、体制と工程が納期に整合している、保守の責任分担が明確である、未確定事項の進め方が示されている、といった差を評価メモに残します。

最安値以外を選ぶ場合は、費用構造やリスクの差を選定理由として残します。重み例は正解の配点ではありません。納期を優先する案件、安定運用を重視する案件、要件が未確定の案件では、評価項目と配点を自社の購買規程・意思決定基準に合わせて調整します。

05Section総費用と追加費用リスクを二段階で確認する

予算確認では、初期開発費に加えて運用開始後や変更時に発生し得る費用を分けて整理します。

予算は初期開発費だけで組まず、運用開始後や変更時に発生する費用を分けて確認します。初期費用が低く見えても、保守、ライセンス、従量課金、連携先の改修費を含めると、総費用の見通しは変わることがあります。

費用構造と予算設計をより詳しく確認したい場合は、システム開発の費用に関する記事も参照してください。

公的データを予算仮説の補助にする

費用相場の考え方や内訳の詳細は、システム開発の費用に関する記事を参照してください。工数・工期の公的データとしては、IPAのソフトウェア開発分析データ集やJUASのソフトウェア・メトリクス調査が参考になります。公開データの数値に一致するかではなく、自社案件の対象範囲、工数、工期、変動要因、対象外事項が説明できるかを確認しましょう。

予算または時期が合わない場合は条件を調整する

希望予算や希望時期と見積もりに差がある場合は、単純な値引きだけで解決しようとせず、必須機能の優先順位、対象業務の絞り込み、段階導入、要件定義の先行、希望時期の見直しを比較します。

前提を変えて再見積を依頼する場合は、変更内容、未確定事項、質問回答、回答期限を全候補に同じ条件で共有します。条件を変えた会社だけ安く見える状態を避けることが、再比較の前提です。

06Section見積依頼から契約・開始までの進め方

見積比較は、受領した見積書を読むだけで終わりません。依頼条件をそろえ、質問回答を記録し、選定理由と残るリスクを稟議へつなげ、契約前に仕様と責任分担を確定します。

見積依頼前にそろえる情報と未確定事項の伝え方

依頼資料を完璧に仕上げてからでなければ見積依頼できないわけではありません。ただし、未確定事項を伏せると、各社が異なる前提で見積もることになります。未確定事項は、決定者、決定予定日、決定が遅れた場合の影響確認を含めて共有します。

見積比較時と契約前で確認書類を分ける

比較時に使う中心書類は、見積書、提案書、工程表、質問回答です。ここでは、範囲・前提・工数・体制・提案内容をそろえ、追加質問や再見積が必要な点を洗い出します。

一方、発注確定前には、仕様書、契約書、保守仕様、外部契約一覧で最終確認します。成果物、検収、支払、変更管理、責任分担は、見積書だけで確定したと扱わないことが重要です。保守や外部サービスの契約主体と更新条件も確認します。

発注側の回答責任者と期限を工程表に置く

要件確認、設計レビュー、受入テスト、リリース判定では、受託側だけで完結しない判断があります。工程ごとに、発注側の作業担当者と最終判定者を分け、必要資料と回答期限を工程表に置きます。

回答期限を変更した場合は、議事録、課題表、質問票、変更要求票、改訂見積のいずれかに残します。納期、費用、品質、対象範囲への影響を追えるようにするためです。情報システム調達の手続や資料設計は、デジタル庁の調達手続マニュアル・雛形等も参考になりますが、民間企業の手続きを一律に定めるものではありません。

開発会社の比較・相談先を探す

要件や見積条件を整理したうえで、開発会社の比較を進めたい場合は、Webアプリ・SaaS開発の相談先を探せます。

Webアプリ・SaaS開発4593社掲載

Webアプリ・SaaS開発の会社を探す