発注の基本

RFP（提案依頼書）あーるえふぴー（ていあんいらいしょ）

提案依頼書ベンダー選定システム発注RFI要件定義調達

RFPって何？どう使うの？

簡単に言うとこんな感じ！

「うちのシステムをこういう条件で作ってほしい。いくらでできる？どうやって作る？提案して！」って複数のベンダーに一斉に送る”お題書”だよ。これがあるから各社が同じ条件で競争できるし、発注側も比較しやすくなるんだ！

RFPとは

RFP（Request for Proposal＝提案依頼書）とは、システムや製品・サービスの調達を検討している組織が、複数のベンダー（システム会社など）に対して「こういうものを作ってほしい、提案と見積もりを出してほしい」と正式に依頼するための文書のことです。口頭や雰囲気で相談するのではなく、要件・条件・評価基準を文書化して全社に同じ条件で提示するのがポイントです。

RFPを出すことで、複数のベンダーから「どう実現するか（提案内容）」「いくらかかるか（見積もり）」「いつできるか（スケジュール）」を揃った形で受け取ることができます。これにより、発注側は提案を横並びで比較・評価でき、感情や営業トークではなく内容で選定できるようになります。

特にシステム発注の経験が少ない担当者にとって、RFPは「何を決めておかなければいけないか」を整理する羅針盤にもなります。RFPを書く過程で要件の曖昧さや抜け漏れに気づけるため、発注失敗リスクを下げる重要なプロセスです。

RFPに書く主な項目

RFPに盛り込む内容は案件によって異なりますが、一般的には以下の構成が標準です。

章	項目	書く内容の例
1	プロジェクト概要	背景・目的・対象範囲
2	現状と課題	今のシステム・業務の問題点
3	要件（機能・非機能）	必須機能・性能・セキュリティ要件
4	制約条件	予算上限・納期・利用環境
5	提案に含めてほしいこと	提案書の構成・デモの有無など
6	評価基準	価格・技術力・実績の重み付け
7	スケジュール	提案締切・選定完了日
8	契約・守秘に関する条件	NDA締結・知的財産の扱いなど

覚え方：「背現要制提評ス契」

RFPの8章構成は語呂で覚えると便利です。「背（景）現（状）要（件）制（約）提（案）評（価）ス（ケジュール）契（約）」 ――「背景に現れた要制（要制止）、提案を評価してスケジュール契約！」とイメージすると章の流れが頭に入りやすいです。

機能要件 vs 非機能要件

RFPの中でも特に重要なのが要件の整理です。

種類	意味	例
機能要件	システムが「何をするか」	在庫照会ができる、請求書を自動発行する
非機能要件	システムが「どう動くか」	応答速度1秒以内、99.9%稼働率、不正アクセス対策

非機能要件を書き忘れると「動きはするが遅すぎて使えない」「セキュリティが甘かった」といったトラブルにつながります。両方を必ずRFPに盛り込むことが重要です。

歴史と背景

1960〜70年代（米国政府調達）：RFPの概念は米国の政府調達プロセスで生まれた。公平な競争入札のために「条件を文書化して複数社に提示する」仕組みが整備された
1980年代（民間企業への普及）：ITシステムの調達が増えるにつれ、民間企業でもRFPを使った発注が一般化。特にERPやメインフレームなど大型案件で標準化が進む
1990〜2000年代（日本への導入）：日本では官公庁のIT調達に関するガイドラインが整備され、RFP作成が義務化・推奨される案件が増加。経済産業省や総務省がRFP作成指針を公開
2010年代以降（クラウド時代のRFP）：クラウドサービスやSaaSの普及により、RFPの内容も「作ってもらう」から「選んで設定してもらう」にシフト。セキュリティ要件やデータ所在地の記載が重要性を増す
現在：DX推進の流れを受け、アジャイル開発への対応やベンダー共創型の「RFP＋対話」形式も広がっている

RFI・RFQ との違い

RFPと混同しやすい似た書類が2つあります。調達プロセスの流れと合わせて整理しましょう。

書類	正式名称	目的	出すタイミング
RFI	Request for Information	「何ができるか」情報収集	要件定義の前
RFP	Request for Proposal	「どう作るか・いくらか」提案依頼	要件定義の後
RFQ	Request for Quotation	「正確な金額」見積取得	仕様確定の後

実務上のポイント： 大型案件では RFI → RFP → RFQ の順に段階を踏みますが、中小規模の案件では RFP だけで提案と概算見積を同時に依頼することも多いです。

RFPがないと何が起きる？

RFPを省略して「口頭で依頼 → 1社だけに見積」を行うと、以下のリスクが発生します。

【RFPなしで発注した場合の典型的な失敗パターン】

発注側：「いい感じにシステム作って」
   ↓
ベンダー：（各社が独自に解釈して提案）
   ↓
発注側：「これ思ってたのと違う…」「こんなに高いとは…」
   ↓
手戻り・追加費用・納期延長・最悪は契約トラブル

RFPで要件・評価基準・制約を明文化することで、「言った言わない」「そのつもりじゃなかった」を防ぐことができます。