RFPとは？ 10分でわかりやすく解説

UnsplashのCHUTTERSNAPが撮影した写真  

RFP（Request for Proposal、提案依頼書）は、システム導入や改修で、目的・対象範囲・要件・制約・評価基準を先にそろえ、ベンダー提案を比較可能にする文書です。複数社から提案を受けたい案件、価格だけでなく体制や進め方まで見て選びたい案件では効果が出やすくなります。反対に、要件がほとんど固まっておらず市場の選択肢から探したい段階なら、先にRFIを挟んだ方が進めやすい場面もあります。

RFPとは何か

定義

RFPは、発注側がベンダーへ提案を依頼するための文書です。単なる問い合わせではなく、調達対象、実現したい業務、必須要件、スケジュール、見積前提、評価基準を示し、各社の提案を同じ条件で比べられる状態を作ります。

仕様書との違い

RFPは仕様書そのものではありません。仕様書は実装内容を確定するための文書ですが、RFPは提案を比較するための前提整理に重心があります。発注側で既に確定している事項と、ベンダーに提案してほしい事項を切り分けて書くことで、比較しやすい提案が返りやすくなります。

RFPが機能しやすい案件

• 複数ベンダーから提案を受け、価格以外の差も見たい案件
• 業務要件と非機能要件を整理したうえで、方式や体制は提案させたい案件
• 稟議やシステム監査で選定根拠を説明する必要がある案件
• 導入後の運用体制や変更管理まで含めて比較したい案件

先にRFIを挟んだ方がよい案件

• 市場にどの選択肢があるか分かっていない
• クラウド、パッケージ、スクラッチのどれを選ぶべきか判断材料が足りない
• 予算感や実現方式の幅を先に把握したい
• 要件より先に、実現可能性やおおまかな相場を知りたい

この段階でいきなりRFPを出すと、各社が異なる前提で提案を作り、比較が崩れます。情報収集の段階ならRFI、提案比較の段階ならRFP、仕様が固まっていて価格比較が中心ならRFQという切り分けが扱いやすくなります。

RFI・RFP・RFQの違い

三つの違いを曖昧にすると、発注側の狙いとベンダー側の出力がずれます。まだ選択肢を広く見たいのにRFQを出す、逆に仕様が固まっているのに自由提案型のRFPを出す、といった進め方では評価がぶれやすくなります。

RFPに何を書くか

最初にそろえる項目

• 背景と目的：なぜ今やるのか、何を改善したいのか
• 現状：既存業務、既存システム、課題、制約
• 対象範囲：対象業務、対象拠点、対象ユーザー、対象データ
• 要件：必須要件、要望要件、性能、セキュリティ、運用
• スケジュール：マイルストーン、切替時期、繁忙期制約
• 見積条件：初期費用、保守費用、ライセンス、変更費の扱い
• 評価基準：配点、必須条件、失格条件
• 提出方法：提出物、体裁、締切、質疑方法

比較できるRFPにするための書き方

網羅的に書くだけでは足りません。ベンダーが同じ粒度で返答できる書き方にする必要があります。たとえば「使いやすいこと」とだけ書くより、対象ユーザー、利用頻度、許容する操作時間、教育コストの考え方まで示した方が提案はそろいます。

同様に、セキュリティ要件も「安全であること」とだけ書くのではなく、認証方式、権限管理、監査ログ、データ保管場所、委託先管理、脆弱性対応の前提まで明文化した方がぶれにくくなります。

発注側が先に決めておくべき線引き

RFPで最もつまずきやすいのは、発注側が決める領域と、提案に委ねる領域が混ざることです。成果条件と制約は発注側で固め、実現方式や体制は提案に委ねる、という切り分けをしておくと比較しやすくなります。

• 発注側で固める項目：目的、予算上限、期限、法務・セキュリティ条件、対象範囲
• 提案に委ねる項目：製品構成、アーキテクチャ、体制、移行計画、教育方法

RFPがもたらす効果

提案の比較精度が上がる

RFPが整っていると、ベンダーごとの提案の前提差が減ります。価格だけでなく、要件適合、体制、スケジュール、保守範囲、障害対応まで横並びで見やすくなります。

選定理由を説明しやすくなる

複数社比較では、「なぜその会社を選んだのか」を後から説明できる状態が必要です。評価基準と配点が先に決まっていれば、選定結果を稟議や監査へ載せやすくなります。

契約後の揉めごとを減らしやすくなる

提案段階で責任分界、成果物、検収条件、変更管理の考え方まで示しておくと、選定後の「聞いていない」「範囲外だ」という衝突を減らしやすくなります。RFPは提案比較の文書であると同時に、契約前の認識ずれを減らす文書でもあります。

RFP作成で失敗しやすい点

要件が曖昧で、各社が別の前提で提案する

現状、対象範囲、移行期限、必須要件が薄いまま出すと、各社が独自に前提を置きます。その結果、価格もスケジュールも比較できなくなります。最低限、ユーザー数、拠点数、連携先、データ量、移行期限はそろえておきます。

仕様を細かく決め過ぎて、提案の余地を潰す

方式や製品まで固定し過ぎると、ベンダーの工夫が出にくくなります。成果条件と制約を明確にしつつ、方式は提案させる書き方の方が、比較の幅を確保しやすくなります。

見積条件がそろっていない

見積差の原因が単価差なのか、範囲差なのかが分からないケースは少なくありません。要件定義、設計、開発、テスト、移行、教育、保守のどこまでを見積に含めるかを書いておくと、比較の精度が上がります。

法務やセキュリティの論点が後ろへずれる

個人情報や機密情報を扱う案件では、秘密保持、データ保管場所、ログ保全、委託先管理、脆弱性報告、障害時の連絡体制を後から足すと手戻りが大きくなります。既存設計書を外部へ開示する場合は、秘密保持契約を前提にする運用も先に決めておく方が安全です。

提案評価の進め方

評価表を先に作る

提案を見てから評価軸を決めると、後付け評価になりやすくなります。RFPを出す前に、必須条件、配点、重み付けを整理しておくと、主観に流れにくくなります。

• 要件適合：必須要件を満たしているか
• 実現性：体制、スケジュール、品質管理に無理がないか
• 運用性：保守範囲、障害対応、変更時の扱いが明確か
• 費用：初期費用だけでなく継続費用まで読めるか

書面だけで決めない

提案書の文章だけでは見えにくい論点もあります。必要に応じて、プレゼン、質疑、デモ、PoCを組み合わせ、前提条件や運用の現実性を確認した方が失敗は減ります。

Q&Aの共有ルールを整える

質疑応答で前提が変わる場合は、特定ベンダーだけが有利にならないよう、回答を全候補へ同時に共有します。回答で条件が変わったときは、改版したRFPを正式版として残します。

RFPをうまく運用するための体制

RFPは文書単体で完結しません。取りまとめ役、最終決裁者、評価メンバー、質疑窓口を先に決めておくと、選定プロセスの停滞を避けやすくなります。利用部門、情報システム部門、セキュリティ担当、法務、経理の誰がどの観点を持つかを整理しておくと、後から論点が増えにくくなります。

案件が終わった後は、要件漏れ、見積前提のずれ、評価基準の妥当性を振り返ると、次のRFPの質が上がります。RFPは一度作って終わる書式ではなく、組織の調達品質を積み上げるための運用資産です。

まとめ

RFPは、目的・要件・制約・評価基準をそろえ、ベンダー提案を比較可能にするための文書です。複数社から提案を受ける案件や、価格だけでなく体制・進め方・運用まで見て選びたい案件では特に効きます。一方で、要件がまだ粗い段階では、先にRFIで市場と選択肢を把握した方が進めやすい場面もあります。発注側で固める条件と提案に委ねる条件を切り分け、見積条件と評価基準を先に整えておくと、比較の精度が上がります。

FAQ