システム開発を外部へ依頼するとき、

「1社だけでは金額が妥当なのか分からない」

「複数の開発会社から見積を取りたい」

「相見積もりでは何を各社へ伝えればよいのか」

と悩むことがあります。

システム開発では、複数社から見積を取得する「相見積もり」が有効です。

複数の提案を見ることで、

• 開発費の相場感
• 必要な機能
• 技術構成
• 開発期間
• 保守費
• 開発会社ごとの提案力

などを比較できます。

しかし、相見積もりには注意点があります。

例えば、

A社には
「スマートフォン対応が必要」
と伝えた

B社には
伝えていない

という状態で見積を取った場合、

A社：
400万円

B社：
300万円

となっても、同じものを比較しているとは言えません。

システム開発の相見積もりで最も重要なのは、

複数社へ同じ前提条件を伝え、比較可能な見積を取ること

です。

この記事では、システム開発で相見積もりを取るときの注意点、依頼前に決めておきたい項目、開発会社への依頼方法、比較しやすい見積を受け取るためのポイントまで解説します。

システム開発で相見積もりを取るメリット

相見積もりには主に3つのメリットがあります。

1．費用の相場感が分かる

例えば3社へ依頼して、

A社：
300万円

B社：
350万円

C社：
330万円

なら、今回の要件では300万円台が一つの目安だと判断できます。

一方、

A社：
100万円

B社：
400万円

C社：
450万円

となった場合は、

なぜA社だけ安いのか？

を確認するきっかけになります。

ただし、相見積もりの目的は単に最安値を探すことではありません。

2．実現方法を比較できる

同じ業務課題でも、会社によって提案が異なることがあります。

例えば、

Excel業務をシステム化したい

という相談に対して、

A社は、

完全オーダーメイド開発

B社は、

既存SaaS
+
必要部分だけカスタマイズ

C社は、

ローコード
+
独自API

を提案するかもしれません。

複数の選択肢を見ることで、費用・機能・保守性を比較できます。

3．開発会社の対応力を比較できる

相見積もりでは金額だけでなく、

質問内容

レスポンス

ヒアリング力

提案内容

説明の分かりやすさ

も比較できます。

システム開発は数か月以上の付き合いになることも多いため、提案段階のコミュニケーションも重要な評価材料です。

相見積もりを取る前に決めておきたい7項目

システム開発では、いきなり複数社へ、

見積をお願いします

と依頼するより、先に条件を整理した方が比較しやすくなります。

最低限、次の7項目を整理します。

1．システム開発の目的

2．現在の業務・課題

3．開発対象範囲

4．必要な主要機能

5．利用者・利用規模

6．希望納期

7．予算

順番に見ていきます。

1．システム開発の目的を揃える

最初に、

なぜシステムを作るのか

を整理します。

例えば、

在庫管理システムが欲しい

だけではなく、

3拠点が別々のExcelで
在庫を管理している。

本社が毎週3つのファイルを統合しており、
集計に約3時間かかっている。

全拠点の在庫を一元管理して
手作業の集計をなくしたい。

まで伝えます。

目的が分かれば、開発会社も単なる機能見積ではなく、業務改善を踏まえた提案ができます。

2．現在の業務・課題を各社へ同じように伝える

例えば、

現在：

注文
↓
Excel入力
↓
事務担当へメール
↓
販売管理システムへ再入力

という業務なら、そのまま共有します。

さらに、

・二重入力に時間がかかる
・入力ミスが発生する
・最新状況を確認できない

といった課題も伝えます。

できれば、

• 現在使っているExcel
• 業務フロー
• 帳票
• 既存システムの画面
• CSVサンプル

なども各社へ同じ条件で共有します。

3．開発対象範囲を決める

例えば顧客管理システムなら、

今回対象：

○ 顧客管理
○ 案件管理
○ 対応履歴
○ CSV出力

今回対象外：

× 請求書発行
× 会計機能
× AI分析

と整理します。

対象外を書いておかないと、

A社：
顧客管理だけ

B社：
請求管理まで含む

という見積になり、比較が難しくなります。

4．主要な機能を整理する

詳細仕様まで決まっていなくても構いません。

例えば、

ID	機能	優先度
F01	ログイン	必須
F02	顧客登録	必須
F03	顧客検索	必須
F04	案件管理	必須
F05	対応履歴	必須
F06	CSV出力	高
F07	ダッシュボード	中

という一覧があるだけでも比較しやすくなります。

5．利用人数・データ量を揃える

例えば、

利用者：
約30名

最大同時利用：
10〜20名程度

顧客：
約20,000件

年間増加：
約5,000件

とします。

利用者30人向けと3万人向けでは、必要なシステム構成が変わります。

各社へ同じ前提を伝えます。

6．希望納期を伝える

例えば、

2027年4月1日から利用開始したい

と伝えます。

さらに、

新年度の業務開始に合わせるため、
4月1日は変更できない

など、期限の重要度も共有します。

これによって、

全機能を4月にリリース

または

主要機能を4月
追加機能を6月

など、現実的な提案を受けられます。

7．予算感を伝える

予算を伝えない方が安くなると思うこともあるかもしれません。

しかし、

発注者：
100〜200万円を想定

開発会社：
1,000万円規模を想定

では、双方に大きな時間ロスが発生します。

例えば、

予算：
300〜500万円程度

のようにレンジで伝える方法があります。

相見積もりで特に注意したい12のポイント

ここから、実際に相見積もりを取るときの注意点を見ていきます。

注意点1｜各社へ同じ資料を渡す

最も重要です。

例えば、

A社：
RFP＋Excel＋業務フロー

B社：
口頭説明だけ

C社：
RFPだけ

では比較できません。

原則として、

同じ資料

同じ要件

同じ質問回答

同じ期限

を各社へ提供します。

注意点2｜各社で要件を変えない

打ち合わせをしているうちに、

A社との打ち合わせで
新しい機能が必要だと分かった

ということがあります。

その場合は、B社・C社にも同じ情報を共有します。

例えば、

追加要件：

管理者向けCSV出力が必要

と各社へ連絡します。

そうしないと比較条件が変わってしまいます。

注意点3｜見積フォーマットをできるだけ揃える

例えばA社は、

システム開発一式：
400万円

B社は、

要件定義：
50万円

設計：
70万円

開発：
200万円

テスト：
80万円

という形式かもしれません。

比較しやすくするため、依頼時に、

要件定義

設計

開発

テスト

データ移行

リリース

PM

保守

などの内訳を依頼します。

注意点4｜「一式」だけの見積は詳細を確認する

一式見積が必ず悪いわけではありません。

しかし、

開発一式：
300万円

だけでは、

何が含まれているのか

が判断できません。

最低限、

対象工程

対象機能

対象外

前提条件

を確認します。

注意点5｜開発範囲だけでなく「対象外」も聞く

例えば、

データ移行は含みません

操作マニュアルは含みません

クラウド費用は別途です

保守は別契約です

などです。

安い見積ほど悪いわけではありませんが、

安い理由

が単純に対象範囲の違いである可能性があります。

注意点6｜データ移行を忘れない

業務システムの相見積もりでは特に重要です。

例えば、

既存Excel：
30ファイル

顧客：
20,000件

案件：
50,000件

があるなら共有します。

さらに、

各Excelで形式が違う

ことも伝えます。

開発会社によって、

移行プログラムだけ対応

データ整理も対応

移行は発注者側

など条件が異なります。

注意点7｜インフラ・外部サービス費を確認する

開発費とは別に、

AWS

Azure

Vercel

Supabase

メール送信

SMS

決済

AI API

外部SaaS

などの月額費用が発生する場合があります。

例えば、

A社：
開発300万円
月額5万円

B社：
開発350万円
月額1万円

なら、長期的には結果が変わります。

注意点8｜保守費も同時に見積もってもらう

リリース後に、

保守費を聞いていなかった

とならないようにします。

例えば、

月額保守費

保守対象

受付時間

障害対応

軽微な修正

追加開発の単価

を確認します。

長期間利用するシステムなら、初期費用だけでなく年間コストも比較します。

注意点9｜追加費用の条件を確認する

システム開発では、仕様変更が発生することがあります。

例えば、

画面追加

帳票追加

外部API追加

データ量増加

仕様変更

などです。

そこで、

どのような場合に
追加費用が発生しますか？

と聞きます。

さらに、

追加費用発生

↓

見積提示

↓

発注者承認

↓

作業開始

という運用になっているか確認します。

注意点10｜見積有効期限を確認する

見積には、

有効期限：
30日

などが設定されている場合があります。

例えば見積を取得して半年後に発注すると、

人件費

クラウド料金

開発体制

が変わり、再見積になる可能性があります。

ベンダー選定スケジュールも考えて依頼します。

注意点11｜見積金額だけで交渉しすぎない

例えば、

他社は300万円です。
250万円になりませんか？

と金額だけを下げようとすると、

テスト削減

ドキュメント削減

保守削減

などによって調整される可能性があります。

予算を下げたい場合は、

この機能を次期開発へ回せませんか？

既存SaaSを利用できませんか？

初回リリースを小さくできませんか？

と、開発範囲を見直して費用を下げる方が分かりやすいでしょう。

注意点12｜相見積もりを価格交渉だけに使わない

相見積もりの価値は、

安い会社を探す

だけではありません。

複数社の提案から、

必要な機能

適切な技術

開発期間

潜在的なリスク

業務改善方法

を知ることもできます。

相見積もりは何社から取ればよい？

案件によりますが、3社程度から比較する方法は実務上扱いやすいでしょう。

例えば、

候補調査：
10社

↓

問い合わせ：
5社

↓

提案・見積：
3社

↓

最終候補：
2社

↓

1社選定

という進め方です。

あまり多くの会社へ本格的な提案を依頼すると、

質問対応

打ち合わせ

提案書確認

見積比較

に多くの時間がかかります。

重要なのは数ではなく、

今回の案件に
合いそうな会社

へ依頼することです。

相見積もりであることは伝えてよい？

基本的には、

複数社から提案・見積をいただき、
総合的に選定する予定です。

など、相見積もりであることを伝えて問題ありません。

むしろ開発会社側も、

提案期限

選定スケジュール

競争案件であること

を把握できます。

ただし、他社の具体的な提案書・見積書を無断で別会社へ共有するのは避けます。

例えば、

A社の見積書を
そのままB社へ送る

ようなことは、機密情報・提案ノウハウの扱いという点でも適切ではありません。

比較したい条件だけ自社側で整理します。

他社の見積金額を伝えてもよい？

例えば、

他社は300万円なので、
それ以下にしてください

と伝える方法もありますが、価格だけの競争になりやすくなります。

予算に合わない場合は、

当社予算は300万円程度です。

現在の提案内容から、
優先度の低い機能を外すなどして
予算内に収める方法はありますか？

と相談する方が建設的です。

これなら、

機能削減

段階開発

SaaS活用

仕様簡略化

などの提案を受けられます。

相見積もり依頼時に伝える内容

最低限、次を各社へ渡すと見積を作りやすくなります。

【開発背景】

現在どのような業務をしているか


【課題】

何に困っているか


【目的】

システム導入後にどうしたいか


【利用者】

誰が何人使うか


【主要機能】

何が必要か


【既存データ】

Excel・既存システム等


【外部連携】

他システムとの接続有無


【希望納期】

いつ利用開始したいか


【予算】

予算レンジ


【依頼範囲】

要件定義からか
開発だけか
保守までか

これらをまとめたものが、RFPや提案依頼書です。

【コピペ用】相見積もり依頼時のチェックリスト

【依頼前】

□ システム開発の目的を整理した

□ 現在の業務フローを整理した

□ 解決したい課題を整理した

□ 必要な主要機能を整理した

□ 今回対象外の機能を決めた

□ 利用人数を整理した

□ データ量を確認した

□ 既存Excel・システムを整理した

□ 予算レンジを決めた

□ 希望リリース日を決めた


【各社への依頼】

□ 同じ資料を渡した

□ 同じ機能一覧を渡した

□ 同じデータ件数を伝えた

□ 同じ希望納期を伝えた

□ 同じ提案期限を設定した

□ 相見積もりであることを必要に応じて伝えた


【見積内容】

□ 要件定義を含むか確認した

□ 設計を含むか確認した

□ テストを含むか確認した

□ データ移行を含むか確認した

□ リリースを含むか確認した

□ マニュアルを含むか確認した

□ 対象外を確認した

□ 前提条件を確認した

□ 保守費を確認した

□ クラウド費を確認した

□ 外部サービス費を確認した

□ 追加費用の条件を確認した


【選定】

□ 総額だけで比較していない

□ 要件理解を比較した

□ 提案内容を比較した

□ 開発実績を確認した

□ PM・担当者を確認した

□ 保守体制を確認した

相見積もりを取りやすい見積フォーマット例

各社へ、次の形式で提出を依頼すると比較しやすくなります。

工程	工数	単価	金額	備考
要件定義
基本設計
詳細設計
開発
テスト
データ移行
インフラ構築
リリース
PM
合計

さらに、

対象機能：

対象外：

前提条件：

月額保守：

月額インフラ：

見積有効期限：

も記載してもらいます。

相見積もりで金額差が大きいときはどうする？

例えば、

A社：
200万円

B社：
450万円

C社：
500万円

だった場合、

A社が安いので決定

とする前に理由を確認します。

主な原因として、

開発範囲が違う

工数が違う

単価が違う

要件定義の有無

テスト量の違い

データ移行の有無

保守の有無

技術構成の違い

があります。

例えばA社へ、

他社と比較して工数が少ないようですが、
どのような前提で算出されていますか？

と聞きます。

合理的な説明があれば問題ありません。

相見積もりで安すぎる会社に確認したいこと

例えば他社が400〜500万円なのに一社だけ150万円なら、

なぜこれほど安いのか

を確認します。

考えられる理由は、

既存パッケージ利用

ノーコード利用

既存資産の再利用

少人数開発

などです。

一方、

要件定義なし

テストが少ない

データ移行なし

保守なし

必要機能の見積漏れ

の可能性もあります。

金額差には必ず理由があります。

相見積もりで高い会社にも理由を聞く

逆に一社だけ高い場合も確認します。

例えば、

高可用性構成

手厚いテスト

データ移行作業

セキュリティ対策

PM工数

保守

まで含めているかもしれません。

その場合、

今回のシステムに
本当にその水準が必要なのか

を相談します。

過剰設計なら仕様を落として費用を調整できる可能性があります。

相見積もりは同時期に取る

例えば、

A社：
1月に見積

B社：
6月に見積

C社：
12月に見積

では、条件が変わっている可能性があります。

特に長期間空くと、

要件

人件費

利用サービスの価格

為替

クラウド費用

などが変化します。

できるだけ同じ時期に依頼します。

提案期限は現実的に設定する

複雑なシステムなのに、

明日までに
正式見積をください

では、精度の低い見積になる可能性があります。

開発会社には、

資料確認

質問

社内工数見積

技術検討

の時間が必要です。

簡易見積なのか、正式提案なのかも明確にするとよいでしょう。

概算見積と正式見積を分ける

初期段階では要件が曖昧なことがあります。

その場合、

まず概算見積

↓

候補を絞る

↓

詳細ヒアリング

↓

正式見積

という方法があります。

例えば最初に、

概算：
300〜500万円

程度で確認し、候補会社だけ詳細見積へ進めます。

これにより発注者・開発会社双方の負担を抑えられます。

要件が曖昧すぎる場合は無理に相見積もりを取らない

例えば、

業務システムが欲しい

必要機能：
まだ不明

予算：
不明

利用者：
不明

納期：
不明

という状態では、各社の見積が大きくばらつきます。

その場合は先に、

業務ヒアリング

↓

課題整理

↓

システム化範囲

↓

主要機能

↓

RFP・要件資料

↓

相見積もり

と進めた方が比較しやすくなります。

相見積もりでよくある失敗

失敗1｜各社へ別々の内容を伝える

比較条件が変わります。

同じ資料を利用します。

失敗2｜見積を取るたびに要件を追加する

追加した要件は他社にも共有します。

失敗3｜一番安い会社だけを見る

見積範囲・体制・提案内容まで確認します。

失敗4｜対象外を確認しない

必要な作業が見積に含まれていない可能性があります。

失敗5｜保守費を後回しにする

年間コストが大きく変わる可能性があります。

失敗6｜予算を伝えない

予算と提案規模が大きくずれることがあります。

失敗7｜他社の提案書をそのまま共有する

他社の具体的な提案内容・見積資料の取り扱いには注意します。

失敗8｜多すぎる会社へ依頼する

発注者側の比較工数も増えます。

候補をある程度絞ってから正式提案を依頼します。

失敗9｜短すぎる期限で依頼する

見積精度が下がる可能性があります。

失敗10｜要件が曖昧なまま価格比較する

比較しているシステム自体が違ってしまいます。

相見積もりに関するよくある質問

システム開発では相見積もりを取った方がよいですか？

複数の開発会社を比較したい場合は有効です。

価格だけでなく、技術構成・提案内容・開発体制などの違いも確認できます。

一方、依頼先が決まっている小規模案件などでは必須ではありません。

相見積もりは何社くらいが適切ですか？

正式な提案・見積まで依頼するなら3社前後は比較しやすい数です。

案件規模や候補数によって調整します。

相見積もりであることは伝えるべきですか？

複数社を比較して選定する予定であることを伝えて問題ありません。

提案期限・選定予定日も伝えると、開発会社側もスケジュールを把握しやすくなります。

他社の見積金額を伝えてもよいですか？

価格交渉だけを目的に他社金額を利用するより、自社の予算を伝え、その範囲でどこまで実現できるか相談する方法がおすすめです。

他社の見積書・提案書そのものを無断共有することは避けます。

要件が決まっていなくても相見積もりできますか？

概算見積なら可能な場合があります。

ただし要件が曖昧なほど見積差が大きくなるため、正確な比較をするなら主要要件を先に整理します。

一番安い会社を選んではいけませんか？

安いこと自体は問題ありません。

重要なのは、

必要な範囲が含まれているか

なぜ安いのか

追加費用が発生しないか

を確認することです。

hiro-dev-labの要件整理・業務システム開発支援

hiro-dev-labでは、Webシステム・業務システムについて、実装だけではなく発注前の要件整理から対応しています。

例えば、

• 現状業務のヒアリング
• 業務フロー整理
• 課題整理
• システム化範囲の整理
• 業務要件・機能要件整理
• 非機能要件整理
• RFP作成に必要な情報整理
• 技術構成の検討
• データ移行方針整理
• Java・Python・TypeScriptによるWebシステム開発
• リリース後の運用・保守

などを検討できます。

例えば、

複数社から
相見積もりを取りたい

↓

しかし各社へ
何を伝えればよいか分からない

という場合でも、

現在の業務を整理

↓

課題を整理

↓

必要要件を定義

↓

システム化範囲を決定

↓

比較可能な見積条件を整理

という順番で準備できます。

相見積もりの目的は「最安値を探すこと」ではなく「比較できる条件を作ること」

システム開発の相見積もりで重要なのは、

A社：
300万円

B社：
400万円

C社：
500万円

という数字を並べることではありません。

最初に確認すべきなのは、

各社は
同じシステムを
見積もっているのか？

です。

そのため、

1．開発目的を整理する

2．業務・課題を整理する

3．対象範囲を揃える

4．主要機能を揃える

5．利用人数・データ量を揃える

6．各社へ同じ資料を渡す

7．見積内訳を揃える

8．対象外・前提条件を確認する

9．保守・運用費まで確認する

10．価格以外の提案内容も比較する

という順番で進めることが重要です。

適切に相見積もりを取れば、

費用

提案力

技術構成

開発体制

運用方法

を比較し、自社に合った開発会社を選びやすくなります。

「相見積もりを取りたいが要件が整理できていない」

「各社へ何を伝えればよいか分からない」

「複数の見積を比較できる状態にしたい」

「要件定義から設計・開発まで相談したい」

といった段階からでも、システム化の整理を進めることができます。

要件定義・業務システム開発について相談する