システム開発の見積もりの妥当性は9つの内訳で判断

「3社に見積もりを頼んだら、金額がまったく違っていて、どれが妥当なのか分かりません」「提示された金額が高いのか安いのか、社内に判断できる人がいません」「値引きをお願いすべきか迷っています」。システム開発を外部に頼むとき、発注側の多くがこうした悩みを抱えます。この記事では、見積もりの妥当性を発注側が判断するための考え方を先にお伝えし、そのうえで、会社によって金額が違う理由、確認する9つの内訳、比較表の作り方、ベンダーへの確認質問の例、値引きより先に考えたい範囲の見直し、AIを使った開発で変わってきていることを順に説明します。

結論：金額の高い安いより「前提・範囲・内訳」がそろっているかで判断する

見積もりの妥当性は、金額そのものでは判断できません。同じ「販売管理システムの開発」でも、何を作るか、どこまで含めるか、どんな条件で作るかが違えば、金額が違うのは当然だからです。判断の手がかりになるのは、次の3つがそろっているかどうかです。

前提：どの業務を、どんな利用者数・データ量・稼働条件で動かす前提なのかが書かれていること
範囲：見積もりに含まれる作業と、含まれない作業（対象外）がはっきりしていること
内訳：金額が工程・機能・体制などに分けて示され、どこに作業量がかかっているかが読めること

この3つがそろっていれば、「この部分は前提が違う」「この機能は今回は要らない」と、項目ごとに話し合えます。逆に「開発一式」としか書かれていない見積もりは、高いか安いかの前に、何に対する金額なのかが分かりません。見積もりを比べるときは、まず前提と範囲をそろえ、内訳の同じ行どうしを比べる、という順番で進めます。

見積もりが会社によって大きく違う5つの理由

複数社の見積もりの金額が大きく違うと、どこかが高すぎる、あるいは安すぎると考えがちです。しかし多くの場合、差は次のような「見積もりの置き方の違い」から生まれます。見積もりの比較についてご相談を受けると、金額の差の多くは、各社の前提と範囲の違いから来ています。

1. 前提の違い

発注側が渡した資料に書かれていないことは、各社がそれぞれ想定して補います。利用者数、扱うデータ量、既存システムとの連携の有無、スマートフォンでの利用、帳票の数などです。ある会社は最小限の前提で見積もり、別の会社は将来の拡張まで想定して見積もる、ということが起こります。

2. 範囲の違い

要件定義から含めるのか、設計からなのか。テストは誰がどこまで行うのか。データ移行や操作研修、稼働後の保守を含むのか。範囲の線の引き方は会社ごとに違い、同じ「開発費」という名前でも中身が揃っていないことがよくあります。

3. リスクの見込み

要件がまだ固まっていない段階では、開発会社は「後から仕様が増えるかもしれない」「既存システムの調査で想定外の作業が出るかもしれない」といった不確かさを見込んで金額を出します。見込み方は会社の経験や方針で異なります。不確かさが大きいほど見積もりの幅が広がるのは、どの会社にも共通する性質です。

4. 品質の考え方

同じ機能でも、テストの厚さ、性能の確認、セキュリティの対策、設計書をどこまで残すかによって作業量は変わります。業務の中心となるシステムで止まると困るのか、社内の一部で使う補助的なツールなのかによって、必要な品質の水準は違って当然です。発注側がどの水準を求めているかを伝えていないと、各社の想定がばらつきます。

5. 体制の違い

プロジェクトマネージャーを専任で置くか、設計と開発を同じ人が担うか、どの工程を何人で進めるかといった体制の組み方も、会社ごとに異なります。期間を短くしたい場合は人数を増やす必要がある、といった体制と期間の関係もあります。

このように、金額の差は「どちらかが間違っている」ことより、「同じものを見積もっていない」ことから生まれる場合が多くあります。だからこそ、比べる前に前提と範囲をそろえることが大切です。

見積もりで確認する9つの内訳

見積もりを受け取ったら、次の9つの観点で内訳が示されているかを確認します。すべてが別の行として書かれている必要はありませんが、どこに含まれているのかを説明してもらえる状態が望ましいです。

内訳	確認すること	曖昧なときに起きやすいこと
1. 工程別	要件定義・設計・開発・テスト・移行・稼働後の対応ごとの作業量	どの工程に作業が集中しているか分からず、比べられない場合
2. 機能別	画面・帳票・連携・バッチ処理など、機能ごとの作業量	優先度の低い機能を外したときの影響が読めない場合
3. 体制と期間	役割ごとの人数と期間、発注側に求める参加の度合い	発注側の担当者の負荷が想定より大きくなる場合
4. 前提条件	利用者数・データ量・対応端末・連携先などの想定	前提が変わったときに追加の見積もりになる場合
5. 対象外	見積もりに含まれない作業の一覧	後から「それは範囲外です」となる作業が出てくる場合
6. 保守・運用	稼働後の問い合わせ対応・不具合対応・小さな改修の扱い	稼働後の体制が決まらないまま本番に入る場合
7. テスト	誰が、どの種類のテストを、どこまで行うか	発注側が行う受け入れテストの準備が間に合わない場合
8. 移行	既存データの移行・新旧の切り替えの作業	移行の作業量が後から大きく見えてくる場合
9. プロジェクト管理	進捗管理・課題管理・会議体の作業	管理の作業がどこに含まれているか分からない場合

いくつか補足します。

前提条件と対象外は、9つの中でも特に大事な項目です。前提条件は「この条件なら、この金額で作れます」という約束の土台であり、対象外は「ここから先は別途です」という線引きです。この2つが書かれていない見積もりは、金額が確定しているように見えて、実は変わりやすい見積もりといえます。

テストは、開発会社が行うテストと、発注側が業務の目で確かめる受け入れテストに分かれます。受け入れテストに使う業務のデータやシナリオを誰が用意するのかは、見積もりの段階で確認しておくと、後の行き違いを防げます。

移行は、軽く見られやすい項目です。経済産業省のレガシーシステムモダン化委員会総括レポートでも、システムの移行やモダン化で問題が発生しやすいのはデータ移行であり、データの質と量、管理の精度で難易度が大きく変わると指摘されています。既存のデータがどこに、どんな形で、どれくらいあるのかを見積もりの前に共有しておくと、移行の作業量を見積もりやすくなります。

保守・運用は、開発費とは別の見積もりになっていることが多い項目です。稼働後に誰が直し、誰が機能を足すのかが決まっていないと、仕組みが特定の担当者や会社にしか分からない状態になりかねません。その状態になったときの立て直し方はブラックボックス化したシステムの引き継ぎ方で扱っています。また、既存のパッケージに追加開発を重ねている場合は、基幹システムの追加開発費用が高くなる理由と打ち手も判断の材料になります。

複数社の見積もりを比べる比較表の作り方

複数社の見積もりを並べるときは、各社の見積書をそのまま横に並べるのではなく、発注側で比較表の形を決めてから当てはめます。手順は次の5つです。

同じ資料を渡す：最初の依頼の時点で、目的・対象業務・必要な機能・前提条件・求める品質を書いた資料を全社に渡します。依頼の資料の書き方は中小企業のためのRFPの書き方で説明しています。
行を内訳でそろえる：比較表の行を、前の章の9つの内訳と、自社が必要とする機能の一覧にします。各社の見積書の項目名が違っていても、この行に当てはめ直します。
前提と対象外を書き出す：金額の列の隣に、各社の前提条件と対象外を書き出します。ここに違いがあれば、金額を比べる前に質問して埋めます。
空欄を質問で埋める：どの行にも当てはまらない金額や、どこにも書かれていない作業は、各社に確認します。
最後に金額を比べる：前提と範囲がそろったところで、行ごとに金額と作業量を比べます。差が大きい行は、作り方や体制の違いを聞く手がかりになります。

比較表は、たとえば次のような形にします。

比較する行	A社	B社	C社
前提（利用者数・データ量・連携先）	記載あり	一部記載	記載なし
要件定義	含む	含む	別途
機能：受注入力	金額・作業量	金額・作業量	金額・作業量
機能：帳票出力	金額・作業量	金額・作業量	金額・作業量
テスト（受け入れテストの支援）	含む	対象外	含む
データ移行	含む	含む	対象外
保守・運用	別見積もり	月額で提示	記載なし
対象外の一覧	あり	あり	なし

この表を作ってみると、「一番安い見積もりは移行と要件定義が含まれていなかった」「高く見えた見積もりは、受け入れテストの支援まで含んでいた」といったことが見えてきます。金額だけでなく、前提や対象外をどれだけ丁寧に書いているかも、その会社と進めたときの進めやすさを測る材料になります。

ベンダーへの確認質問の例

見積もりの内容を確かめる質問は、相手を疑うためのものではなく、同じ認識に立つためのものです。答えやすいよう、具体的に聞きます。

前提と範囲について

「この金額は、利用者数・データ量・連携先をどう想定していますか。」
「見積もりに含まれない作業を一覧で教えていただけますか。」
「前提が変わった場合、どの項目の金額が変わりますか。」

作り方と体制について

「工程ごとの作業量と、各工程の担当の役割を教えていただけますか。」
「当社側に求める参加の度合い（打ち合わせの頻度、確認の担当者）はどのくらいですか。」
「開発の中で、既存のサービスやライブラリ、AIを使った開発の手法を使う部分はありますか。」

品質と稼働後について

「テストはどの種類を、どこまで行う前提ですか。受け入れテストの支援は含まれますか。」
「稼働後の不具合対応と小さな改修は、どのような形で依頼できますか。」
「設計書や手順書は、どの程度の内容で納品していただけますか。」

リスクについて

「この見積もりで、不確かさが大きいと考えている部分はどこですか。」
「要件定義の後に見積もりを見直す前提ですか。」

最後の2つは特に役に立ちます。不確かな部分を正直に挙げてくれる会社とは、問題が起きたときにも早めに相談し合える関係を作りやすいためです。要件定義を先に別の契約で進め、その結果をもとに開発の見積もりを出し直す進め方を提案されることもあります。契約の形や役割分担を考えるときは、IPAが公開している情報システム・モデル取引・契約書が参考になります。契約の条項の判断が必要な場合は、法務の専門家に確認してください。

値引き交渉より範囲の見直し

見積もりが予算に合わないとき、まず値引きをお願いしたくなります。しかし、作業量はそのままで金額だけを下げると、テストや設計書の作成など、見えにくい作業が薄くなるおそれがあります。発注側にとって効果が大きいのは、作るものの範囲を見直すことです。

優先度の低い機能を後回しにする

機能の一覧を、業務への効果で並べ替えます。考え方は「手間×頻度×価値」です。毎日多くの人が使い、手作業の手間が大きく、ミスが起きると影響が大きい業務を支える機能は、最初から作る価値があります。一方で、年に数回しか使わない機能や、手作業でも困っていない機能は、2回目以降に回せます。

このとき、効果を数字で定義しておくと判断がぶれません。「受注入力の時間を何割減らす」「転記ミスによる手戻りをなくす」のように、コスト削減か売上向上かを先に決めると、その効果に必要な機能と、なくても困らない機能が分かれます。私たちが医療卸の基幹システムの刷新に関わった際も、分断していた業務を工程単位で棚卸しして再設計し、そのうえで作る範囲を決めました。

標準機能やSaaSで代替する

会計や勤怠のように、どの会社でも進め方がほぼ同じ業務は、パッケージやSaaSの標準機能で足りることが多くあります。自社の強みに関わる業務や、既製品では合わない業務だけを作り、それ以外は既製品を使う、という分け方をすると、作る範囲を小さくできます。どこを作り、どこを既製品にするかの考え方は、基幹システムリプレイスの進め方で詳しく説明しています。

段階に分けて発注する

最初から全体を一度に作るのではなく、効果の大きい範囲から作って使い始め、使われ方を見て次の範囲を決める進め方もあります。最初の範囲が小さければ、前提も絞りやすく、見積もりの不確かさも小さくなります。

AIを使った開発で、作り方そのものが変わってきている

見積もりを見るときに知っておきたいのが、開発の作り方そのものが変わってきていることです。設計・実装・テストの一部にAIを使うことで、必要な機能に絞った仕組みを、以前より短い期間で作れる場合が出てきています。前述の総括レポートでも、ベンダー企業が生成AI等でのレガシーコード解析やコード生成の手法を開発し、広く展開していくことの重要性が示されています。

どの工程でどこまでAIが役立つかは、作るものや既存システムの状態によって異なります。そのため、見積もりの段階で「AIを使った開発の手法を、どの工程で使う前提ですか」と聞いてみる価値があります。使う・使わないのどちらが正しいということではなく、作り方の前提を知ることで、見積もりの中身を理解しやすくなります。

もう一つの視点は、作るシステムの側にAIを組み込むことです。たとえば、紙やPDFの書類の読み取り、問い合わせへの回答の下書き、入力内容のチェックなど、これまで人が手で行っていた作業の一部を、AIを前提に設計できる場合があります。機能の一覧を見直すときに、AIで置き換えられる作業がないかを優先順位の候補に入れておくと、作る範囲や業務の流れそのものを考え直すきっかけになります。どの業務がAIに向くかの見極め方はAI化する業務の洗い出し方で、検証から本番に進めるための条件はAIのPoC止まりの原因と本番移行の条件で説明しています。

社内で判断しにくいときは第三者に見てもらう

社内にシステム開発の経験者がいない場合、比較表を作っても、前提が妥当か、作業量の置き方が自然かを判断しきれないことがあります。そのようなときは、見積もりを出した会社とは別の第三者に見てもらう選択肢があります。

第三者に頼めることは、たとえば次のようなものです。

依頼の資料（RFP）に、前提・範囲・品質の水準が書かれているかを確認すること
各社の見積もりを同じ行にそろえ、前提と対象外の違いを洗い出すこと
ベンダーへの確認質問を一緒に作り、回答の読み方を補うこと
機能の優先順位と、段階に分けた発注の進め方を一緒に考えること

第三者の役割は、特定の会社を選ばせることでも、開発会社の見積もりを否定することでもありません。発注側が自分で判断できるよう、判断の材料をそろえることです。そもそも社内でDXの進め方を整理している段階であれば、DX担当を任されたら何から始めるかもあわせてご覧ください。

なお、経済産業省の総括レポートでは、モダン化が順調な企業ほど、開発計画や投資対効果・見積に関する情報を経営層と共有している傾向があることも示されています。見積もりの判断を担当者一人で抱えず、前提と範囲を整理した比較表をもとに、経営層や業務部門と一緒に決めることが、判断の質を上げる近道です。

まとめ：見積もりは前提と範囲をそろえてから比べる

見積もりの妥当性は、金額の高い安いではなく、前提・範囲・内訳がそろっているかで判断します。
会社によって金額が違うのは、前提、範囲、リスクの見込み、品質の考え方、体制の違いから来ることが多くあります。
工程別・機能別・体制と期間・前提条件・対象外・保守運用・テスト・移行・プロジェクト管理の9つの内訳を確認します。
比較表は発注側で行を決め、前提と対象外を書き出し、空欄を質問で埋めてから金額を比べます。
予算に合わないときは、値引きより先に、優先度の低い機能の後回しや、標準機能・SaaSでの代替、段階的な発注を検討します。
AIを使った開発で作り方が変わってきているため、どの工程でAIを使う前提かを確認し、AIで置き換えられる作業も機能の見直しの候補に入れます。

見積もりの読み方や比較表づくり、機能の優先順位の整理から、発注側の立場でご一緒できます。複数社の見積もりを前に判断に迷われている段階でも、コンサルティングの支援内容をご覧のうえ、お気軽にご相談ください。