システム開発の相見積もり｜取り方と比較方法

システム開発の相見積もりは、同じ依頼資料を3社前後へ渡し、価格だけでなく範囲・前提条件・提案・体制・契約・保守費用まで比較することが重要です。最安値ではなく、見積もりの根拠が明確で、目的達成まで任せられる会社を選びましょう。

• 相見積もりの目的・依頼社数・必要期間
  • 相見積もりは3社前後が基本
  • 選定には2〜8週間程度を見込む
• 同じ条件で相見積もりを取るための準備と進め方
  • 最初に社内で決めること
  • RFPに提案条件と回答形式を記載する
  • 相見積もりの進め方
• 見積書は金額・範囲・前提条件をそろえて比較する
  • 概算見積もりと正式見積もりを区別する
  • 見積書の比較チェックリスト
  • 契約形態と変更手続きを確認する
• 提案・担当者・リスク対応を含めた比較方法
  • 評価表で判断基準をそろえる
  • 面談では実際の担当予定者と話す
  • よくある失敗と回避策
• まとめ
• よくある質問
  • Q. システム開発の相見積もりは何社に依頼すべきですか？
  • Q. 相見積もりで予算を伝えてもよいですか？
  • Q. 見積金額に大きな差があるのはなぜですか？
  • Q. 要件が固まっていなくても相見積もりできますか？

相見積もりの目的・依頼社数・必要期間

相見積もりの目的は最安値を探すことではなく、適正な予算と実現方法を把握し、自社に合う開発会社を選ぶことです。金額の高低だけで判断すると、見積もりに含まれる作業の違いを見落とし、発注後に追加費用が生じる可能性があります。

相見積もりは3社前後が基本

依頼先は、一般的には3社前後が現実的な目安です。1社だけでは価格や提案の妥当性を判断しにくく、5社以上では説明会、質疑応答、提案書の確認に大きな負担がかかります。

候補会社は、同じ特徴の会社だけで固めず、次のような観点から選ぶと比較の意味が生まれます。

• 対象業務や類似システムの経験がある会社
• 要件定義から相談できる会社
• 特定の業界、技術、セキュリティ要件に強い会社
• 小さく開始する段階開発を提案できる会社
• 公開後の保守運用まで対応できる会社

類似実績を確認するときは、実績の件数だけでなく、その会社が担当した工程を聞いてください。企画から保守まで担当した案件と、一部の開発作業だけを担当した案件では、得られている知見が異なります。今回の担当予定者が過去の案件に関わっていたかも確認すべきポイントです。

選定には2〜8週間程度を見込む

相見積もりの依頼から選定までの期間は、要件の整理状況や案件規模によって変わります。次の期間はあくまで一般的な目安であり、契約交渉や社内決裁の期間は別途必要です。

要件が曖昧な状態で各社に開発総額を出してもらっても、前提条件が異なるため正確には比較できません。この場合は、要件定義（＝作るものや業務上の条件を具体的に決める工程）や事前調査だけを先に依頼する方法があります。

要件定義だけを切り出す場合、小〜中規模案件では数十万〜数百万円、期間は2週間〜2カ月程度になることがあります。ただし、対象業務、関係者数、既存資料、外部連携の有無によって変動します。無料見積もりの範囲で詳細な業務分析まで求めるのではなく、調査工程を有償で実施したほうが結果的に比較精度が高まることもあります。

同じ条件で相見積もりを取るための準備と進め方

比較可能な相見積もりにするには、全社へ同じ依頼資料、回答期限、質問への回答を共有することが重要です。ただし、各社固有の提案や独自のアイデアまで競合へ開示してはいけません。

最初に社内で決めること

開発会社へ連絡する前に、少なくとも次の項目を整理します。すべての仕様を決める必要はありませんが、目的や優先順位が不明なままでは各社の想定がばらつきます。

• 解決したい経営課題・業務課題
• システムを使う人と利用人数
• 現在の業務フローと困っている点
• 必須機能と、予算次第で見送れる機能
• 希望予算と予算上限
• 希望公開日と、遅らせられない理由
• 連携する既存システムや外部サービス
• データ移行の対象、件数、データの状態
• セキュリティや社内規程上の条件
• 開発後の保守、問い合わせ対応の希望
• 選定責任者、決裁者、社内の確認体制

公開希望日については、単に「なるべく早く」ではなく、法改正、既存契約の終了、キャンペーン開始などの背景を伝えます。期限の理由が分かれば、開発会社は機能を段階的に公開する案や、先に検証すべき項目を提案しやすくなります。

RFPに提案条件と回答形式を記載する

RFP（＝開発会社へ提案を依頼するための資料）を用意すると、情報の抜けや会社ごとの条件差を減らせます。RFPには、開発内容だけでなく、見積書や提案書に記載してほしい項目も含めます。

依頼資料に入れたい項目は次のとおりです。

• 会社・事業の概要
• 開発の背景、目的、期待する成果
• 現行業務と新しい業務の想定
• 機能一覧と優先順位
• 利用端末、利用環境、想定利用者数
• 外部システム・APIとの連携条件
• データ移行、インフラ、マニュアル作成の範囲
• 希望する開発スケジュール
• 予算の目安と支払い条件
• 成果物、検収、保守に関する希望
• 提案書と見積書の指定項目
• 評価基準、質問期限、提出期限

RFPの具体的な項目や作成手順は、RFPの作り方｜システム開発の依頼準備でも解説しています。

「予算を伝えると上限まで見積もられるのではないか」という相談を受けることがあります。しかし予算を伏せたままでは、予算1,000万円の案件に3,000万円規模の構成が提案されるなど、実現性の低い比較になりかねません。予算上限、必須条件、予算に含めたい範囲を伝えたうえで、次のように分けて提案してもらう方法が有効です。

• 予算内で実現する基本案
• 優先度の低い機能を追加した拡張案
• 将来の追加開発を考慮した段階導入案

相見積もりの進め方

相見積もりは、次の順番で進めると条件をそろえやすくなります。

1. 目的、予算、希望時期、決裁者を社内で確認する
2. 候補会社を3社前後に絞る
3. 必要に応じてNDA（＝秘密保持契約）を締結する
4. 全社へ同じRFPと関連資料を送る
5. 同じ基本説明を行い、質問期限を設定する
6. 共通事項への回答を全社へ共有する
7. 提案書と見積書を評価表で採点する
8. 上位候補と面談し、前提条件や契約内容を確認する
9. 社内決裁後、選定結果を各社へ連絡する

質問への回答を共有するときは、特定会社の提案内容や質問者名を伏せ、案件の前提をそろえるために必要な情報だけを配布します。提案期限の直前に新しい要件を追加した場合は、全社へ伝えたうえで期限延長の要否も検討してください。

見積書は金額・範囲・前提条件をそろえて比較する

見積書は総額だけでなく、「何が含まれ、何が含まれず、どの条件が変わると追加費用になるか」を確認します。同じシステム名でも、会社ごとに想定する品質や作業範囲が違うためです。

概算見積もりと正式見積もりを区別する

見積もりの名称や定義は会社によって異なります。名称だけで判断せず、金額の前提と有効期限を確認してください。

要件が固まっていない段階の概算は、金額に幅があること自体が問題なのではありません。未確定事項が明示され、それが金額へどう影響するか説明されていることが重要です。根拠のない単一金額より、条件別の幅を示す見積もりのほうが意思決定に役立つ場合があります。

見積書の比較チェックリスト

各社の見積もり範囲が違う場合は、そのまま総額を比較せず、除外項目を補正します。例えば、A社にはデータ移行と保守引き継ぎが含まれ、B社には含まれないなら、B社側に必要な追加費用を確認してから比較します。

比較時には、初期開発費だけでなく、公開後に必要なTCO（＝導入から運用終了までにかかる総費用）も確認します。主な費用は次のとおりです。

• クラウドやサーバーの月額利用料
• 外部API、地図、決済、メール配信などの利用料
• ソフトウェアや管理ツールのライセンス料
• 監視、バックアップ、セキュリティ対応費
• 問い合わせ対応、障害対応、軽微な改善費
• OSや外部サービスの更新に伴う改修費

保守契約の比較方法については、システム保守費用の相場｜契約・見積もりの見方も参考になります。

契約形態と変更手続きを確認する

請負契約（＝合意した成果物の完成を約束する契約）は、仕様と納品物を明確にできる開発に向いています。準委任契約（＝専門的な業務を一定期間遂行してもらう契約）は、要件を調整しながら進めるプロジェクトに向いています。

ただし、契約名だけで責任範囲が自動的に決まるわけではありません。次の条件を契約書、見積書、仕様書の間でそろえてください。

• 対象業務と除外業務
• 成果物と納品方法
• 検収基準と検収期間
• 仕様変更の申請・承認方法
• 追加費用と納期変更の計算方法
• 不具合修正の範囲と期間
• 知的財産権、ソースコード、アカウントの帰属
• 再委託の有無と管理責任
• 契約終了時のデータ返却と引き継ぎ

仕様変更が起こること自体を完全に避けるのは困難です。重要なのは、変更を誰が承認し、費用と納期への影響をどの時点で合意するかを決めることです。

提案・担当者・リスク対応を含めた比較方法

開発会社は、価格に加えて目的理解、提案の妥当性、担当体制、リスクへの説明力で評価します。提案書が魅力的でも、実際の担当者や進行方法が不明なら、契約前に確認が必要です。

評価表で判断基準をそろえる

評価項目と配点を提案書の受領前に決めておくと、社名の知名度やプレゼンテーションの印象だけで選ぶことを防げます。次の配点は一例であり、案件の目的に合わせて調整してください。

評価担当者が複数いる場合は、採点後に点数だけを合算せず、低い評価を付けた理由も共有します。現場部門は使いやすさ、情報システム部門は運用性、経営層は投資対効果を重視するなど、立場によって判断軸が異なるためです。

面談では実際の担当予定者と話す

発注のご相談を受ける開発会社の立場から見ると、見積もり段階の質問には会社の姿勢が表れます。画面数や機能数だけでなく、利用者、例外業務、権限、データ品質、公開後の運用まで質問する会社は、認識のずれを早期に見つけようとしていると考えられます。

面談には、営業担当者だけでなく、プロジェクト責任者や主要な担当予定者にも参加してもらい、次を質問してください。

• この開発の目的と最大のリスクをどう理解していますか
• 見積もりで未確定になっている項目は何ですか
• 予算を超える場合、どの機能から見直しますか
• 発注者側で必要な作業と担当人数はどの程度ですか
• 進捗遅延や品質問題をどのように検知しますか
• 担当者の変更や再委託がある場合、どう引き継ぎますか
• 公開後の障害や改善要望には誰が対応しますか

分からないことをその場で断定せず、「確認して回答する」と言えることも重要です。技術的な不確実性を隠した楽観的な回答より、調査事項と判断期限を明確にする会社のほうが、リスクを管理しやすい場合があります。

よくある失敗と回避策

大幅な値引きが提示された場合は、値引きそのものを問題視するのではなく、体制、作業範囲、成果物、品質条件が変わっていないか確認します。また、不採用会社にも選定結果を連絡し、預かった資料やアカウントの返却・削除を依頼してください。

相見積もり用の要件整理や、届いた見積書を比較できる状態にしたい場合は、開発のご相談はこちらからご相談ください。

まとめ

• 相見積もりは、同じ条件で3社前後へ依頼するのが基本です
• 選定期間は2〜8週間程度が目安で、要件整理や社内決裁の期間も確保します
• RFPには目的、利用者、必須機能、予算、納期、依頼範囲、回答形式を記載します
• 各社に同じ資料と共通質問への回答を共有し、比較条件をそろえます
• 見積書は総額だけでなく、範囲、工数、除外項目、追加費用、保守まで確認します
• 要件が曖昧なら、要件定義や事前調査を先に発注する方法があります
• 価格だけでなく、目的理解、提案、担当者、リスク対応、契約条件を評価します
• 最安値ではなく、公開後を含む総費用と目的達成の確度で選ぶことが重要です

よくある質問

Q. システム開発の相見積もりは何社に依頼すべきですか？

3社前後が一般的な目安です。1社では価格や提案の妥当性を判断しにくく、5社以上では説明、質疑、評価の負担が大きくなります。同じ依頼資料と回答期限を提示して比較してください。

Q. 相見積もりで予算を伝えてもよいですか？

予算上限と必須条件は伝えることをおすすめします。予算内の基本案、追加機能を含む拡張案、段階導入案を分けて提案してもらうと、投資の優先順位を判断しやすくなります。

Q. 見積金額に大きな差があるのはなぜですか？

各社が想定する機能、品質、作業範囲、体制、契約形態、リスクの織り込み方が異なるためです。工程別工数、除外項目、追加費用、保守費用をそろえ、条件を補正して比較してください。

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

概算見積もりは可能ですが、前提がそろわず金額の幅が大きくなります。要件定義や事前調査だけを先に依頼し、対象範囲と優先順位を決めてから開発費を相見積もりする方法が適しています。