複数の開発会社に見積を依頼するとき、口頭やメールで「こういうシステムを作りたい」と伝えるだけで見積を取ることがあります。手軽な方法ですが、各社に伝わる情報がばらついていると、出てくる見積も前提がそろわず、金額を同じ土俵で比較できなくなります。そこで役立つのが、RFP（Request for Proposal、提案依頼書）です。
本記事は連載第10回として、RFPなしで見積を取るとどうなるか、そしてRFPに何を入れるべきかを整理します。RFPは大企業だけのものではなく、中小企業の発注でも、相見積もりの精度を上げる実用的な道具になります。
まず結論
- RFPなしで見積を取ると、各社が異なる前提で見積もるため、金額を同じ土俵で比較できません。
- 簡易RFPには、背景、目的、対象範囲、必須要件、連携先、予算感、希望時期、見積の内訳粒度を入れます。
- RFPは完璧な要件定義書ではなく、各社に同じ前提で提案してもらうための発注前メモとして使えます。
| 見る項目 | 判断のしかた | 発注前の確認ポイント |
|---|---|---|
| 背景・目的 | なぜ作るか | 提案の方向性をそろえる |
| 対象範囲 | どの業務・機能か | 見積対象のずれを防ぐ |
| 見積条件 | 粒度・含める費目 | 比較できる形式で依頼する |
OUTCOME BLUEPRINT
AI/DX投資の前に、成果KPIと発注条件を整理しませんか？
補助金、SaaS選定、開発見積、PoCの前に、業務要件・費用レンジ・RFP・合格条件を成果起点で整理します。
この連載での位置づけ
- 前に読む記事：連載第9回：再委託・オフショア
- 次に読む記事：連載第11回：比較表
- 比較表で整理する：連載第11回：比較表
- 発注前の質問に落とし込む：連載第12回：開発会社への20問
RFPとは何か
RFPは、発注側が「何を作りたいか」「何を実現したいか」「どういう条件で提案してほしいか」をまとめ、開発会社に提案と見積を依頼する文書です。要件定義書ほど詳細でなくてもよく、発注側の意図と前提を各社に等しく伝えるための土台になります。
RFPがあると、各社は同じ情報をもとに提案・見積を作るため、出てくる見積の前提がそろい、比較がしやすくなります。RFPの作り方や項目は、システム開発のRFPテンプレート（中堅BtoB向け）やシステム開発向けRFPテンプレートも参考になります。
RFPなしで見積を取ると起きること
RFPがないまま見積を依頼すると、次のようなことが起きやすくなります。
| 起きること | 理由 |
|---|---|
| 各社の前提がばらつく | 伝わった情報が会社ごとに異なる |
| 金額を比較できない | 含まれる範囲がそろっていない |
| 安く見える見積に偏る | 前提を狭く取った会社が安く見える |
| 後から追加費用が増える | 伝えきれていない要件が後で表面化する |
| 提案の質を比べられない | 評価する共通の軸がない |
とくに問題になりやすいのが、「前提を狭く取った会社の見積が安く見える」点です。本来必要な作業を見込んでいない見積が、たまたま安く見えてしまい、その金額を基準に他社が高く見える、という比較のゆがみが起こります。これは連載第5回で扱った「範囲をそろえて比べる」ことの裏返しでもあります。
また、「提案の質を比べられない」ことも、実務上の大きな問題です。共通の前提がなければ、提案書の読み比べをしようとしても、着目している業務課題や提案するシステムの範囲が会社ごとにまったく違う、という事態が起きます。そうなると、「A社はこの機能を提案しているが、B社には載っていない」という差異が、本当に必要かどうかを評価する前に「どちらが良い提案か」の判断そのものを難しくします。RFPで前提をそろえることは、金額の比較だけでなく、提案の中身を評価できる状態を作ることでもあります。
RFPに入れておきたい項目
RFPは完璧である必要はありませんが、最低限、次の項目を入れておくと各社の前提がそろいます。
- 背景・目的：なぜシステムを作りたいのか、何を解決したいのか
- 対象範囲：どの業務・どの部署を対象にするか
- 実現したいこと：必要な機能のイメージ、優先順位
- 現状：いまの業務の進め方、既存システム、データの状況
- 連携：連携が必要な既存システムやサービス
- 非機能要件：想定利用者数、性能、セキュリティ、運用の希望
- 予算・スケジュール：予算の幅、希望時期
- 提案してほしい内容：体制、進め方、見積の内訳の粒度
- 見積の様式：工程ごとに内訳を出してほしい、などの依頼
とくに「見積の内訳の粒度をそろえて出してほしい」と依頼しておくと、連載第1回で扱った一式見積を避け、比較しやすい見積を受け取れます。
RFPに含める項目のうち、見落とされやすいのが「制約条件」です。「既存の会計システムとのデータ連携は必須」「リリースは特定の時期までに行う必要がある」「社内ネットワーク環境の制約がある」といった条件は、あらかじめRFPに書いておかないと、各社が自由に前提を設定します。制約が後から出てくると、提案の修正や追加見積が必要になります。RFP作成時に「前提として共有しておくべき制約はないか」を一度確認しておくと、後の手戻りが減ります。
前提がそろわないと追加費用につながる理由
RFPなしの発注で後から問題になりやすいのは、追加費用です。発注側が「当然含まれている」と思っていた作業が見積の前提に含まれていなかったことが、開発の途中で初めて分かるケースがあります。このとき、開発側は「見積の前提外の作業」として追加の費用や工数を求めることになります。
この種の認識のずれは、RFPで前提を文書化しておけば、多くの場合に事前に解消できます。「データ移行は含まれるか」「テストの範囲はどこまでか」「操作マニュアルは成果物に含まれるか」といった項目をRFPに明示しておくと、各社の見積にその回答が含まれる形になります。システム開発の見積書の見方でも、この「含まれていないもの」の確認が発注前の重要な論点として挙げられています。追加費用の発生条件については、連載第6回で詳しく扱っています。
RFPは詳しすぎなくてよい
「RFPを作るには専門知識が必要では」と感じるかもしれませんが、最初から完璧なものを目指す必要はありません。背景・目的・対象範囲・実現したいこと・予算感・希望時期が伝われば、出発点としては十分です。むしろ、細部まで作り込みすぎると、開発会社からの提案の幅を狭めてしまうこともあります。
RFP作成の段階で開発会社や第三者に相談し、論点を一緒に整理する進め方もあります。要件がまだ固まっていない場合は、連載第3回で触れた要件定義フェーズを先に置く方法も選べます。
RFPと要件定義書の違い
RFPと要件定義書は混同されがちですが、役割が異なります。RFPは「何をしてほしいかを伝え、提案を依頼する」ための文書で、発注前に発注側が作ります。要件定義書は「何を作るかを確定する」ための文書で、要件定義の工程を経て作られます。順序としては、RFPで各社に提案を依頼し、選んだ会社と要件定義を進めて要件定義書を作る、という流れになります。RFPの段階で完璧な要件定義書は必要なく、意図と前提が伝わる粒度で十分です。
RFPを渡す相手の数の考え方
RFPを何社に渡すかは、手間と比較のバランスで考えます。多くの会社に渡すほど選択肢は増えますが、各社の提案を読み、質問に答え、比較する手間も増えます。一般的には数社程度に絞ると、提案の質を丁寧に比較しやすくなります。やみくもに数を増やすより、自社の課題に合いそうな会社を選び、同じRFPで前提をそろえて依頼するほうが、比較の精度は上がります。
発注前チェックリスト（RFPの準備）
- システム化の背景・目的を言葉で説明できるか
- 対象とする業務・部署の範囲が決まっているか
- 実現したいことの優先順位（必須・任意）を整理したか
- 現状の業務・既存システム・データの状況をまとめたか
- 連携が必要な既存システム・サービスを洗い出したか
- 発注側として守らなければならない制約（時期・環境・セキュリティ）を書き出したか
- 想定利用者数・運用の希望などの非機能要件を整理したか
- データ移行・テスト・操作マニュアルなど、含めてほしい作業の前提を明記したか
- 予算の幅と希望時期を社内で共有したか
- 各社に「見積の内訳の粒度をそろえて出してほしい」と依頼したか
開発会社に確認する質問
- 「この内容で見積を出すうえで、追加で必要な情報はありますか」
- 「見積の内訳は、工程ごとにそろえて出していただけますか」
- 「私たちが提示した前提のうち、リスクが高いと感じる部分はどこですか」
- 「要件がまだ固まっていない部分は、どう進めるのがよいですか」
- 「RFPの内容について、整理を手伝ってもらうことはできますか」
RFPの不足を補う質問を返してくれる相手は、前提をそろえて提案しようとする姿勢があると判断できます。
相談前に整理しておくとよい情報
- システム化で解決したい課題と、その背景
- 対象業務・部署と、関係する担当者
- 実現したいことの優先順位（必須・あると良い）
- 既存システム・データ・連携先の状況
- 予算の幅、希望時期、社内の決裁ルート
これらを整理しておくと、簡易なRFPの形に落とし込みやすく、相見積もりの前提をそろえられます。
GXOの発注前レビューで見る実務メモ
GXOが見積書の相談を受けるときは、最初から「高い」「安い」を判定せず、見積の前提を分解します。まず初期費用、月額費用、追加費用、発注側作業、リスク項目の5区分に分けます。そのうえで、3社比較、5年TCO、社内稟議、契約条件の順に確認します。これにより、金額の差が価格差なのか、範囲差なのか、リスクの見込み方の差なのかを説明しやすくなります。
発注側で用意しておくとよいのは、完璧な要件定義書ではありません。現行業務の流れ、利用者数、画面・帳票・連携の数、希望時期、予算の幅、社内決裁者、止められない業務、個人情報や機密情報の有無です。これらが曖昧なまま見積を取ると、開発会社ごとに前提が変わり、相見積もりの比較が難しくなります。
| 確認領域 | 発注側が用意する情報 | 見積で確認すること |
|---|---|---|
| 業務範囲 | 対象部署、利用者数、現行フロー | どこまでが開発対象か |
| 機能規模 | 画面数、帳票数、API本数 | 工数の根拠が説明できるか |
| データ | 移行対象、件数、クレンジング要否 | 移行費・移行リハーサルの有無 |
| 運用 | 利用時間、障害時の影響、社内担当 | 保守範囲、SLA、月額費用 |
| 契約 | 請負/準委任、検収、知財、再委託 | 責任分界と追加費用の条件 |
| 稟議 | 予算上限、比較対象、判断基準 | 3社比較や5年TCOで説明できるか |
この整理を先に行うと、AI開発、セキュリティ要件、補助金活用を含む案件でも、見積の前提を同じ粒度にそろえやすくなります。特に補助金を使う場合は、対象経費と対象外経費、発注前着手の可否、証憑の残し方を見積段階で確認しておく必要があります。
参考にすべき一次情報・確認観点
見積書を社内稟議やベンダー比較に使う場合は、一般論だけで判断せず、公式資料と自社データを照合してください。特に契約形態、責任分界、DX投資の目的、セキュリティ要件は、見積金額より前にそろえるべき前提です。
- IPA「情報システム・モデル取引・契約書」：請負、準委任、成果物、検収、責任分界を確認する際の参考になります。
- 経済産業省「DX推進指標」：経営課題、ITシステム、組織体制を分けて、DX投資の目的を確認する際の参考になります。
- 自社の見積比較では、3社比較、5年TCO、月額5万円・10万円・15万円、画面20件、帳票10件、API3本、移行データ1000件、受入テスト5日、操作研修2回、障害受付24時間、初期予算500万円・1000万円など、仮でも数字を置いて前提をそろえます。
- AI開発、セキュリティ要件、補助金活用を含む案件では、機能要件だけでなく、ログ保管、個人情報、権限管理、証跡、補助対象経費の切り分けも見積条件に入れてください。
よくある質問
Q. RFPは中小企業でも必要ですか。
A. 大企業だけのものではありません。背景・目的・対象範囲・予算感を整理した簡易なRFPでも、各社の前提がそろい、相見積もりの精度が上がります。最初から完璧な文書である必要はなく、意図と前提が伝わる粒度で十分です。
Q. RFPと要件定義書は、どう違いますか。
A. RFPは「何をしてほしいか」を伝え、提案を依頼する文書で、発注前に発注側が作ります。要件定義書は「何を作るか」を確定する文書で、要件定義の工程を経て作られます。順序としては、RFPが先、要件定義書が後になります。
Q. RFPは何社に渡せばよいですか。
A. 手間と比較のバランスから、数社程度に絞るのが一般的です。やみくもに数を増やすより、自社の課題に合いそうな会社を選び、同じRFPで前提をそろえて依頼するほうが、提案の質を丁寧に比較できます。
Q. 開発会社にRFP作成を手伝ってもらうことはできますか。
A. 相談に応じてくれる会社は多く、RFP作成の段階から一緒に論点を整理する進め方を取ることもできます。ただし、特定の会社だけに相談すると、その会社に有利な前提になりやすいため、複数社への問合わせと並行するか、第三者に相談する方法が有効です。RFPの前提が発注側の意図を正確に反映しているかを確認してから、各社に配布するとよいでしょう。
まとめ
RFPなしで見積を取ると、各社の前提がばらつき、金額を同じ土俵で比較できなくなります。とくに前提を狭く取った見積が安く見えることで、比較がゆがみやすくなります。背景・目的・対象範囲・実現したいこと・予算感を整理した簡易なRFPを用意し、見積の内訳の粒度をそろえて依頼することで、相見積もりの精度が上がります。次回は、そろえた見積を実際に比較する「相見積もり比較表の作り方」を扱います。
関連記事
システム開発の見積・相見積もりを整理しませんか
GXOでは、システム開発の見積書、相見積もり、要件定義、開発会社選定について、発注前の整理をご支援します。総額だけでなく、工数、保守範囲、追加費用、体制、契約条件まで確認し、自社に合う進め方を一緒に整理します。
※ 初回相談では、営業資料の説明よりも見積内容と発注前の論点整理を優先します。
