RFP(提案依頼書)

コンサルティングや情報システム調達の現場で、発注側と受注側の認識齟齬はなぜ生まれるのか。その根本的な原因の多くは、要件の曖昧さと情報の非対称性にある。RFP（Request For Proposal）は、この問題を構造的に解消するために機能する。

発注企業が自社の目的・要件・制約を文書として体系的に整理し、複数のベンダー（受注候補企業）に同一条件で提示することで、提案内容の比較検討を客観的に行える状態をつくり出す。

IT調達やコンサルティング案件のみならず、人事制度設計・業務プロセス改善・マーケティング支援など、専門的外部知見を活用するあらゆる業務委託において、RFPは発注品質と調達効率を左右する重要なプロセスである。

RFPとは

RFP（Request For Proposal）は「提案依頼書」と訳され、発注企業が調達プロセスにおいて作成・配布する正式文書である。

RFPが成立する条件は次の2点に集約される。

第一に、発注側が自社の要件・条件・評価基準を明文化していること。

第二に、その文書を複数のベンダー候補に配布し、競争的提案（コンペティティブ・プロポーザル）を取得する形式であること。いずれかを欠く場合は、単なる口頭ヒアリングや個別相談にとどまり、RFPとは区別される。

RFPはRFI（Request For Information：情報提供依頼書）およびRFQ（Request For Quotation：見積依頼書）と並ぶ調達文書の一つであり、これら三者は調達プロセスの異なるフェーズに対応する（詳細は後述の比較表を参照）。

RFPに記載される主な項目は以下のとおりである。

• プロジェクトの背景・目的（実現したい未来像）
• 対象業務の現状フロー・課題の詳細（現状開示）
• 必要な機能・サービス要件の提示
• 運用・保守・セキュリティ体制に関する要件
• 暫定スケジュール（開発着手日・本番稼働日等）
• 暫定予算・見積り依頼範囲
• ベンダーの会社概要・導入実績・技術説明の提出依頼
• 評価基準・選定プロセスの開示
• その他相談事項・補足条件

RFPには法定の様式は存在しないが、上記の構成要素が網羅されていることが実務上の水準とされている。

RFPの概念構造図：調達プロセスにおける位置づけ

RFPの具体例／ミニケース

ERPシステム（Enterprise Resource Planning：企業の基幹業務を統合管理するシステム）導入を検討する製造業A社の事例を示す。

A社は既存の販売管理・在庫管理・会計システムが別々に運用されており、データ連携の遅延と二重入力による工数増加が課題であった。

A社はまずRFIを複数のERPベンダーに配布し、自社業種に対応した製品ラインアップと導入実績の情報を収集した。

RFI回答をもとに5社を絞り込んだのち、A社はRFPを作成・配布した。RFPには「2,000アイテムの在庫をリアルタイム連携できること」「既存の販売管理システムとのAPI連携が可能なこと」「導入後6ヶ月以内の稼働」「概算予算2億円以内」など、定量的な要件が記載されていた。

各ベンダーはRFPをもとに技術構成・導入体制・スケジュール・費用を盛り込んだ提案書を作成し、A社のプレゼンテーション審査に臨んだ。

A社は評価基準（機能充足度・導入実績・費用・サポート体制）に基づき最終ベンダーを選定した。

このプロセスにより、A社は恣意的な発注を避け、複数案の客観比較と契約条件の明確化を同時に実現した。

RFI・RFQ・SOWとの違い

RFIとRFPは混同されやすいが、目的が根本的に異なる。RFIは「どのようなベンダー・技術が存在するか」を知るための情報収集であり、特定の提案を求めるものではない。

これに対しRFPは「自社の要件に対して何ができるか・いくらかかるか」という具体的提案を競争的に取得するための文書である。

SOW（Statement of Work：作業範囲記述書）はRFPとは発行タイミングが異なる。RFPがベンダー選定前に発行されるのに対し、SOWはベンダー選定後の契約段階で作成・合意される文書であり、プロジェクトの作業定義・成果物・品質基準を契約的に確定する役割を持つ。

コンサルティング業務でのRFPの位置づけ

論点設計（イシュー出し）

コンサルティングにおける論点設計フェーズでは、クライアントの調達課題の本質を特定することが起点となる。

RFP作成支援においては、「何を外部に委託すべきか」「内製と外注の境界をどう引くか」「調達範囲の定義に漏れはないか」といった論点を体系的に整理する。

RFPが不明確なまま調達を進めると、ベンダー側の提案がバラバラな前提に基づくこととなり、比較不能な状態が生じる。

コンサルタントはまずクライアントの業務課題をMECE（Mutually Exclusive, Collectively Exhaustive：相互排他・全体網羅）に整理し、RFPが答えるべき論点を特定する。

現状分析（As-Is整理）

現状分析では、クライアントの業務フロー・システム構成・組織体制・予算制約を可視化し、RFPの「現状開示」セクションに落とし込む作業を行う。

この段階でコンサルタントが担うのは、クライアントが自社業務を客観的に記述できるよう情報を整理・構造化することである。

業務プロセスの曖昧な記述はベンダーの見積もりを歪め、後のスコープクリープ（当初想定を超えた作業範囲の拡大）の温床となる。

インタビューやワークショップを通じた詳細ヒアリングと文書化が、RFP品質を左右する。

施策設計（To-Be）

施策設計フェーズでは、RFPに記載する「実現したい未来像」と「要求機能」の粒度・優先度を設計する。

要件定義が曖昧なRFPでは、必須要件（Must）と希望要件（Want）が混在し、ベンダー間の提案に大きな差異が生まれる。

コンサルタントはMoSCoW法（Must have・Should have・Could have・Won't have：要件の優先順位付け手法）等を活用して要件を構造化し、評価基準と重みづけを明文化することで、客観的なベンダー比較を可能にする。

資料作成（スライド構造）

RFP関連の成果物は、クライアントの社内稟議用資料とベンダー向け配布文書の2種類に大別される。

社内稟議用スライドでは、調達目的・予算規模・スケジュール・評価プロセスを経営層向けに簡潔に整理する構成が標準的である。

ベンダー向け文書は、要件の一覧性と回答フォーマットの統一性を優先した構成とする。提案評価シートをRFP本体と連動させ、定量的スコアリングが可能な形式にすることで、ベンダー選定の透明性が高まる。

RFPの導入メリットと注意点

導入メリット

• 発注・受注間の認識齟齬の防止：要件を文書化することで、口頭説明では生じやすい解釈のばらつきを最小化できる。
• 複数ベンダーの客観比較：同一条件での提案取得により、技術力・体制・費用の横断比較が可能になる。
• 契約リスクの低減：要件・スコープ・予算・スケジュールの事前合意が、納期遅延・スコープクリープ・紛争を抑制する。
• 調達プロセスの透明性確保：評価基準の明文化により、選定結果に対する社内外の説明責任が果たしやすくなる。
• ベンダーの自己スクリーニング：RFPの内容から自社対応の可否を判断できるため、受注能力のないベンダーが早期に辞退でき、双方の無駄を省ける。

注意点・失敗パターン

• 要件の過剰詳細化：RFPに仕様を書き込みすぎると、ベンダーの創意工夫を妨げ、より良い代替案を排除してしまう。要件は「何を実現したいか（What）」を中心に記述し、「どう実現するか（How）」はベンダーに委ねることが原則である。
• 評価基準の非公開：評価基準をベンダーに開示しない場合、提案の焦点がずれたり、信頼性の低下につながる。
• スケジュールの非現実性：RFP配布から提案締め切りまでの期間が短すぎると、ベンダーの提案品質が低下する。一般的に2〜4週間程度の回答期間が適切とされる。
• RFPと選定基準の乖離：RFPに記載した要件と実際の評価で重視する項目が異なる場合、ベンダー側の信頼を損なう。
• 発注側の準備不足：要件定義が固まっていない段階でRFPを発行すると、回答が返ってきた後に大幅な要件変更が生じ、調達プロセス全体が長期化する。

コンサル採用面接とRFPの関係

コンサルティングファームの採用面接において、RFPという用語が直接問われる機会は多くない。しかし、RFPの背景にある「発注者と受注者の情報非対称性をどう解消するか」「要件をどのように構造化すれば客観的な比較が可能になるか」という思考は、ケース面接で求められる問題整理の能力と本質的に重なる部分がある。

ケース面接では、クライアントの状況を整理し、論点を特定し、解決策を提案する一連のプロセスが問われる。RFPの構成要素（目的・現状・要件・制約・評価基準）を整理する思考法は、この問題構造化の作業と同じ骨格を持つ。

また、戦略・IT・業務コンサルティングを問わず、実務ではRFP作成支援やベンダー評価への関与が早期から生じる。プロジェクトの調達フェーズにおいてRFPがどのような役割を果たし、何が品質を左右するかの概要をおさえておけば、実務的な文脈理解の基盤として機能する。

FAQ

Q1. RFPとは何か、一言で説明すると？

RFPとは、発注企業が外部委託の調達において、自社の要件・条件・予算を文書化し、複数のベンダー候補に対して具体的な提案の提出を正式に求める調達文書である。

RFPを活用することで、発注者は複数案を同一条件で比較でき、受注候補者は自社の対応可否を事前に判断できる。

情報システム開発・コンサルティング・マーケティング支援など、専門的外部知見を要する業務委託全般において使用される。

RFP作成のプロセス自体が、発注側に要件の明確化と優先順位の整理を促す効果を持ち、プロジェクト開始前のリスク低減にも寄与する。

Q2. RFIとRFPはどう違うのか？

RFI（Request For Information：情報提供依頼書）とRFPの最大の違いは、発行の目的と調達フェーズにある。

RFIは「どのようなベンダー・製品・技術が市場に存在するか」を把握するための情報収集文書であり、特定の要件に対する提案を求めるものではない。

対してRFPは、すでに自社の要件がある程度固まった段階で配布され、その要件に対する具体的な技術提案・体制・費用・スケジュールの提出を求める。

一般的な調達プロセスでは、RFIで候補ベンダーを絞り込んだうえでRFPを発行する順序が基本となる。コンサルティング支援においてはRFI・RFP双方の作成支援を行うケースがある。

Q3. RFPはどのフェーズで作成し、何を盛り込むべきか？

RFPは要件定義がある程度固まった段階、すなわちRFI回答をもとにベンダー候補を絞り込んだ後に作成・配布するのが原則である。作成フローとしては、
①業務課題・目的の整理
②現状業務フローの文書化
③必要機能・非機能要件の定義（Must have・Should have・Could have・Won't haveの分類）
④評価基準と重みづけの設計
⑤暫定スケジュール・予算の設定
⑥提案フォーマットの指定
という順序が実務上の標準とされる。

このうち③の要件定義において、必須要件と希望要件を混在させずMoSCoW法等で優先順位を明示することが、提案品質と比較評価の精度を左右する重要な工程である。

Q4. コンサルティング実務においてRFPはどのように活用されるか？

コンサルティング実務におけるRFP活用は大きく2つの文脈に分かれる。

第一は「RFP作成支援」であり、クライアントの調達プロジェクトにおいて要件定義・調達文書の設計・ベンダー評価基準の策定を支援する役割である。

第二は「コンサルファームが受け取る側」としての文脈であり、クライアントがコンサルティングサービスそのものを外部調達する際にRFPが発行されるケースがある。

後者では、RFPに記載された課題・目的・評価基準を精読し、クライアントの真の課題（ビジネスイシュー）を把握したうえで提案書を構成する能力が問われる。

ITコンサルファームではRFP作成支援が独立したサービスラインとして存在する場合もある。

Q5. RFPに関してよくある誤解は何か？

RFPに関する代表的な誤解は「要件を詳細に書けば書くほどよい」という認識である。実際には、要件の過剰詳細化はベンダーの自由な提案を妨げ、より優れた代替案を排除するリスクがある。

RFPが記述すべきは「何を達成したいか（目的・成果）」であり、「どのように実現するか（手段・仕様）」をすべて規定してしまうと、ベンダーの専門知識を活かせなくなる。

また「RFPを出せば良い提案が集まる」と考えるのも誤りで、目的の明確さ・評価基準の透明性・回答期間の適切さなど、RFP自体の品質が提案品質を直接左右する。

さらに、RFPはあくまで調達手続きの文書であり、契約書やSOW（作業範囲記述書）の代替にはならない点にも注意が必要である。

Q6. RFPなしで発注するとどのようなリスクが生じるか？

RFPなしの発注は、認識齟齬・スコープクリープ・コスト超過・納期遅延の四大リスクを同時に抱える状態となる。

発注側と受注側が共有する書面上の合意がないため、プロジェクト進行中に「言った・言わない」が頻発し、変更対応の都度交渉コストが発生する。

特に情報システム開発においては、要件の曖昧さに起因する手戻りがプロジェクトコストや工期に大きな影響を与えるケースが報告されている。

また、RFPなしの随意契約（競争入札を経ない特定ベンダーとの直接契約）は、社内外へのコスト説明責任を果たしにくく、ガバナンス上のリスクにもなりうる。

まとめ

RFPは、外部委託における発注側と受注側の情報非対称性を解消し、競争的かつ透明な調達プロセスを実現するための基本文書である。

RFPが担う本質的な機能は2つある。

一つは、発注企業が自社の要件・目的・制約を構造的に整理する「思考の器」としての役割。

もう一つは、複数ベンダーを同一条件で比較するための「評価の基準線」を設ける役割である。

コンサルティング業務においてRFPは、戦略・IT・業務改善を問わず、調達フェーズで頻繁に登場する実務文書である。

要件定義の質がRFP品質を決め、RFP品質がベンダー提案の質を決め、ひいてはプロジェクト成果を左右するという連鎖を理解しておくことは、実務上の有用な視点となる。

コンサルティングへの転職・就職を考える場合、RFPの仕組みや関連文書（RFI・RFQ・SOW）の役割の概要をおさえておくことは、業務委託・調達に関わる議論においてスムーズな文脈理解の基礎となる。

出典

• 経済産業省・IPA「情報システムの信頼性向上のための取引慣行・契約に関する研究会 ～情報システム・モデル取引・契約書～（パッケージ、SaaS/ASP活用、保守・運用）追補版」（2008年4月）
  https://www.meti.go.jp/policy/it_policy/softseibi/model_tuiho/model_tuiho.pdf
• IPA 独立行政法人情報処理推進機構「ストーリーで学ぶ要件定義実践入門」（社会基盤センター編）
  https://www.ipa.go.jp/archive/files/000072323.pdf
• デジタル庁「デジタル庁情報システム調達改革検討会」
  https://www.digital.go.jp/councils/procurement-reform