LASSIC Media らしくメディア
システム開発の相見積もりの取り方｜比較すべき項目と精度を上げる進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- 相見積もりの精度は、依頼前の前提統一（RFP作成）で大きく変わります。条件が揃わないと価格差の原因を正しく把握できません。
- 工数内訳の工程別比率を確認することで、テスト省略や隠れた追加費用リスクを事前に発見できます。
- 評価は価格だけでなく、実績・体制・コミュニケーション適合性の5軸で総合判断することが大切です。
目次
システム開発の相見積もりとは
システム開発の相見積もりとは、同一の要件・条件で複数のベンダーから見積書を取得し、価格・提案内容・体制を比較したうえで発注先を選定するプロセスを指します。単に安い業者を探す行為ではなく、要件の伝わり方の差異を発見し、ベンダーの技術力・リスク認識・コミュニケーション適合性を並べて評価する機会です。
相見積もりで得られる3つの効果
相見積もりには、価格の妥当性確認以上の効果があります。第一に、同じRFP（提案依頼書）を複数社に送ることで、各社の要件理解の差異が表面化します。要件の捉え方に大きなバラつきがある場合、そのRFP自体が不明瞭である証拠になります。
第二に、各社の提案内容を比較することで、見積もりに含まれている工程の範囲が違うことが分かります。あるベンダーではテスト工程が別途見積もり扱いだったり、データ移行を対象外としていたりするケースは少なくありません。
第三に、比較プロセスを通じてベンダーのレスポンス速度・説明能力・提案の解像度を体感できます。これは稼働後の協業を見越した重要な判断材料になります。
相見積もりが形骸化するケース
相見積もりが機能しない典型的な状況があります。前提条件を統一せずに複数社に依頼するケースでは、各社が異なる解釈で見積もりを作成するため、価格差の原因が要件の違いなのか、単価の違いなのか判別できなくなります。
また、結果的に価格だけで判断してしまうと、追加費用が発生しやすい構造を見抜けません。相見積もりは「比較する環境を整える行為」であり、比較後の評価軸をあらかじめ設計しておくことが不可欠です。
見積もり依頼前に揃える前提条件——RFP作成の要点
IPA（独立行政法人情報処理推進機構）が2020年12月に公表した「情報システム・モデル取引・契約書」第二版では、ユーザ企業とITベンダーの双方が「プロジェクトマネジメント義務および協力義務」を担うと明記されています*1。発注側が要件を正確に伝える責任は、法的な枠組みとしても位置づけられています。
見積もりの精度は、依頼前に発注側が整備する情報の質に比例します。RFP（Request for Proposal：提案依頼書）は、その情報を体系的にまとめた文書です。
RFPに盛り込む6つの項目
- プロジェクトの背景と目的：現状の課題、開発の目的、想定する効果（定性的なゴールで可）
- 機能要件と非機能要件：必須機能の一覧・優先度、性能・セキュリティ・可用性の要件
- スコープの明示：開発対象の範囲、対象外の業務、データ移行やインフラ構築の扱い
- スケジュール：稼働希望日・各フェーズの期限（ターゲット）
- 予算感：上限予算または目安（可能な範囲で開示することで提案精度が上がります）
- 評価基準と選考プロセス：提出期限・評価項目・コンペの進め方
この6項目を明文化してから各社に送付することで、受領した見積書が同じ土台に立っているかを確認できます。
前提が揃わないと比較できない理由
テスト工程・データ移行・環境構築などは、RFPに明記しない場合、ベンダーが対象外と判断することが多い項目です。これらをスコープに含んでいるかどうかの違いだけで、見積もり総額が数十〜数百万円の差になります。
価格差が2倍以上ある場合、単価の違いより「前提のズレ」が原因であることが実務上は多いです。確認なしに安い方を選ぶと、稼働後に大規模な追加費用が発生するリスクがあります。まず「何が含まれていて何が含まれていないか」を各社に確認することが最初のステップです。
相見積もりの4ステップ
依頼から発注先決定までのプロセスを、実務で抜けやすい論点を含めて整理します。
ステップ1：RFP作成と内部合意
前節で示した6項目をRFPとして文書化したうえで、社内の関係部門（現場・経営・情報システム部門）の合意を取ります。RFP提出後に社内から追加要件が出てくると、ベンダーの比較条件が変わるため、この段階での合意形成が重要です。
ステップ2：依頼先の選定と送付（3社が標準）
実務上、3社前後が比較精度とコストのバランスとして適切とされています。2社では優劣の判断軸が不足し、5社以上では評価工数が大きくなりすぎ、価格のみで判断するリスクが高まります。
依頼先の候補は、過去の取引実績・業界特化の有無・会社規模・技術スタックの適合性で絞り込みます。類似案件の実績があるベンダーを1社以上含めることで、提案の解像度が上がります。
ステップ3：質問受付と前提統一
RFP送付後は、各社からの質問を集約する期間を設けます。一社だけに口頭で補足説明をすると、他社との情報格差が生じます。質問と回答は全社に共有するルールを事前に伝えておくことで、公平な比較環境が保てます。
ステップ4：見積書受領と精査
受領した見積書は、次章で解説する工数内訳の精査と比較軸での評価を行います。不明点は書面で質問し、回答を記録として残しておくことが後工程の契約交渉でも役立ちます。
工数内訳の精査——適正比率と隠れたリスクの読み方
見積書の総額よりも、工程ごとの工数配分を確認することで、見積もりの実態を読み取ることができます。工程別の比率が大きく外れている場合、後工程で手戻りや追加費用が発生するリスクの目安になります。
工程別の適正比率チェック
一般的に、ウォーターフォール型の開発では以下の工程比率が参考にされています。
| 工程 | 目安比率 | 比率が低い場合のリスク |
|---|---|---|
| 要件定義 | 10〜15% | 仕様の確認不足が設計・実装フェーズで手戻りにつながります。 発注側の確認コストも増加します。 |
| 設計（基本・詳細） | 20〜25% | 設計工数が少ない場合、実装後の仕様変更対応が困難になります。 |
| 実装（製造） | 30〜40% | 比率が低すぎる場合、外部委託先への再委託で品質管理が希薄になるリスクがあります。 |
| テスト | 20〜30% | 10%を下回る場合は品質面の懸念が大きくなります。 テスト工程の省略は稼働後の障害につながる可能性があります。 |
| PM・管理 | 10〜15% | 管理工数が見えない場合、スケジュール遅延の際に責任が曖昧になります。 |
この比率はプロジェクトの性質によって変動します。既存システムの改修ではテスト比率が高くなり、要件が固まった状態からの開発では要件定義比率が低くなることもあります。表の数値はあくまで参考値として、大きく乖離する工程があれば理由を確認することが大切です。
単価・バッファ・スコープ外の確認
工数（人月）が確認できたら、人月単価との掛け合わせで総額が正しく計算されているかを確認します。参考として、市場では職種別に異なる水準が見られますが、単価は各社・地域・案件規模によって幅があります。費用レンジは一次資料による公式統計ではないため、実際の見積もりはベンダーに個別確認してください。
次に、バッファ（リスク余裕）が含まれているかを確認します。バッファが全く含まれていない見積もりは、仕様変更が発生した際に即座に追加費用の請求につながります。バッファの有無と対応方針は、見積もり受領後の質問事項として明示的に確認することをお勧めします。
最後にスコープ外の確認です。「一式」表記のある項目や、データ移行・研修・マニュアル作成・インフラ構築が含まれているかを確認します。これらはRFPに記載していても、各社の解釈で対象外になっていることがあります。
比較すべき5つの評価軸
複数の見積書が揃ったら、以下の5軸で総合評価します。評価は複数の担当者がそれぞれスコアをつける形にすると、特定の担当者の印象に引っ張られるリスクを下げられます。
価格以外の4つの評価軸
①類似案件の実績：同業種・同規模のシステム開発実績があるかを確認します。技術スタックが同じでも、業務理解が不足していると要件の取りこぼしにつながります。実績については、事例の概要や担当者の経験年数を提案書に盛り込んでもらう形で確認します。
②プロジェクト管理体制：PM（プロジェクトマネージャー）が常駐するかどうか、進捗報告の頻度・方法をどう設計しているかを確認します。IPAのモデル契約書では、ベンダー側のプロジェクトマネジメント義務が明示されていますが*1、実際の体制は提案書の段階で確認が必要です。
③コミュニケーション適合性：見積もり期間中のレスポンス速度・説明の分かりやすさ・質問への対応姿勢を確認します。これは開発期間中の協業品質の先行指標になります。「担当者と話してみて、認識のズレが小さいか」という定性的な評価も重要です。
④保守・サポート体制：稼働後の障害対応時間・問い合わせ窓口・保守費用の条件を確認します。開発費のみで比較すると、保守費用の差が後になって顕在化するケースがあります。
評価シートで複数評価者が判定
5つの評価軸（価格・実績・体制・コミュニケーション・保守）に対して、評価者ごとに点数と選定理由のコメントを記録する評価シートを作成します。点数だけでなく「なぜその点数をつけたか」を残すことで、後日の意思決定の説明責任を果たしやすくなります。
評価の重みづけ（ウェイト）は案件の性質によって変えます。短納期のプロジェクトでは管理体制のウェイトを高く、長期の保守前提では保守体制のウェイトを高く設定することが実務上有効です。
避けるべき進め方と落とし穴
相見積もりを取る際によく発生する問題パターンを整理します。事前に把握しておくことで、プロセスの設計段階で対策できます。
価格の低さだけで選ぶと追加費用が膨らむリスク
低価格を実現する手段はいくつかあります。テスト工程の圧縮、オフショア開発への全面委託、要件確認を省いたトップダウン見積もりなどです。これらが組み合わさっている場合、稼働後の不具合対応や追加機能の実装で当初の見積もりを大幅に上回るコストが発生するリスクがあります。
価格が著しく低い場合（他社より30〜50%以上安い場合）は、何がスコープから外れているかを書面で確認することを推奨します。合理的な説明がない場合は、選定候補から外す判断基準の一つになります。
前提統一なしでの比較
RFPを作成せずに「口頭で説明してから見積もりを取る」方法では、各社の担当者が異なる理解をした状態で見積もりが作られます。この状態での価格比較は意味をなさず、最も積極的に話を聞いた担当者の会社が低く見積もられるという逆転現象も起こり得ます。
RFP作成を「手間のかかる準備作業」と捉えるよりも、「比較可能な見積もりを取るための投資」として位置づけることで、プロジェクト全体のリスクを下げることができます。
依頼社数が多すぎる場合の弊害
依頼社数が多くなると、各社の提案への対応工数が増えます。質問受付・前提統一・評価の手間が増大し、比較精度が下がります。また、多数のベンダーが参加するコンペでは、各社の提案モチベーションが低下し、提案内容の質が下がる傾向も見られます。3社前後を基本として、特定技術や業種特化のベンダーを加える場合は4社までを目安にすることが実務上適切です。
まとめ：相見積もり精度を上げる3つの判断軸
本稿では、システム開発の相見積もりを精度高く進めるためのプロセスを整理しました。要点を3つに集約します。
第一に、前提統一です。RFPで機能要件・スコープ・スケジュール・予算感を明文化してから依頼することで、各社の見積もりが比較可能な状態になります。価格差の原因が単価の違いなのかスコープの違いなのかを判別できるかどうかが、相見積もりの質を決めます。
第二に、工数内訳の精査です。工程別の比率（特にテスト工程が全体の20%以上確保されているか）とスコープ外項目の確認により、追加費用のリスクを事前に発見できます。「一式」表記や工程欠落がある見積書は、書面で内容確認を求めることが大切です。
第三に、5軸評価です。価格・実績・体制・コミュニケーション・保守の5軸で複数の担当者が評価シートに記録することで、選定根拠が明確になります。稼働後の協業を見越した体制・コミュニケーション評価を加えることで、開発完了後もプロジェクトが継続する状況に備えられます。
よくある質問
相見積もりは何社に依頼するのが適切ですか？
実務上は3社前後が比較精度とコストのバランスとして適切とされています。2社では優劣の判断材料が少なく、5社以上になると評価工数が増えすぎて価格のみで判断するリスクが高まります。特定技術や業種に特化したベンダーを加える場合でも、4社までを目安にすることをお勧めします。
RFPを作成する時間がない場合でも相見積もりは取れますか？
RFPを整備せずに依頼した場合、各社が異なる前提で見積もりを作成するため、価格の差異が何に起因するかを判断できなくなります。時間が限られている場合は、機能要件・スコープの範囲・稼働時期の3点だけでも文書化してから依頼することで、比較の精度が大きく改善します。完璧なRFPを目指すよりも、「条件が揃っているかどうか」を確認できる最低限の資料から始めることが大切です。
見積もりの価格差が大きい場合、どのように対処すればよいですか？
価格差が2倍以上ある場合は、単価の違いよりも前提条件のズレが原因であることが多いです。まず各社に「何がスコープに含まれているか」を書面で確認します。テスト工程・データ移行・インフラ構築・研修など、スコープの解釈が異なる項目を特定することで、価格差の合理的な説明ができるかどうかを判断できます。合理的な説明がない極端な安値は、追加費用リスクの観点から慎重に検討することをお勧めします。
アジャイル開発の場合、相見積もりはどのように取ればよいですか？
アジャイル開発では、要件が開発途中で変化することを前提とするため、固定スコープの完成物に対する価格を比較するウォーターフォール型の相見積もりとは手法が異なります。IPA「情報システム・モデル取引・契約書」アジャイル開発版（2020年公表・2025年更新）では、準委任契約を前提に「チームの稼働コスト×期間」で費用を見積もる形を推奨しています*1。比較するなら、チームの体制規模・スプリント単価・同種プロダクトの実績を評価軸に加えることが大切です。
相見積もりの結果を断るベンダーへの連絡はどのように行えばよいですか？
選定に至らなかった場合は、RFPへの対応に費やした相手の工数を考慮し、なるべく早いタイミングで結果を伝えることが望ましいです。理由の詳細開示は必須ではありませんが「総合評価の結果、他社に決定しました」という形で誠実に伝えることで、将来の再コンペや参考相談につながる関係性を維持しやすくなります。メールでの通知が一般的ですが、口頭で補足できる関係があれば対応の負担を軽減できます。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：独立行政法人情報処理推進機構（IPA）「情報システム・モデル取引・契約書（第二版）」（2020年12月公表）／「情報システム・モデル取引・契約書（アジャイル開発版）」（2020年3月公表・2025年4月最終更新）
