RFI・RFP

まず軸を「どの段階で・何を得るために出すか」に置くと、二つの文書の役割が分かれます。RFIは調達の入口で、発注側がまだ選択肢を把握しきれていない段階に使います。RFPはある程度候補が定まり、具体的な提案を比べたい段階に使います。

• RFI（情報提供依頼）
  製品の機能、対応できる業務範囲、過去の導入実績、概算費用の目安などを幅広く集めます。この段階では相手を絞り込むより、市場に何があるかを知ることが主眼になります。
• RFP（提案依頼）
  自社の課題と要件を提示し、それにどう応えるかの提案、体制、スケジュール、見積もりを求めます。回答内容がそのまま比較・選定の材料になります。

RFIを飛ばしていきなりRFPを出すこともありますが、要件が固まりきっていないと提案の粒度がばらつき、比較しにくくなります。逆に情報だけ集めて次に進まないと、ベンダー側の協力を得にくくなる場合もあります。

軸を「誰が・何を・どの順で」に置いて進め方を整理します。中心になるのは発注側のプロジェクトマネージャーで、社内の関係者とベンダーの間に立って文書と回答を回します。

• 要件の棚卸しと文書化
  業務部門やシステム部門から現状の課題とやりたいことを吸い上げ、RFIやRFPに落とし込みます。要件定義の前段にあたる作業で、成果物はRFI/RFP本体と評価基準の一覧です。
• 候補ベンダーへの配布と質疑対応
  複数のベンダーへ同じ条件で配布し、質問を受け付けます。回答の公平性を保つため、質問と回答は全社に共有する形をとることが多いです。
• 回答の評価と選定
  提案書と見積もりを、あらかじめ決めた評価基準に沿って点数化し、社内の意思決定者に諮ります。ここで価格だけでなく体制やリスク対応も見ていきます。

プライムベンダーを立てる大規模な調達では、この一連を通じて主契約先を決めるため、後工程の責任範囲にも影響します。

軸を「提案を比較可能にするために何を明示するか」に置くと、RFPに盛り込む項目が定まります。曖昧なまま出すと提案の前提がベンダーごとにずれ、横並びで比べられなくなります。

• 背景と目的
  なぜこの調達を行うのか、解決したい課題は何かを記します。ベンダーが提案の方向性を合わせるための出発点です。
• 要件とスコープ
  実現したい機能、対象業務、対象システムの範囲を示します。含めない範囲も明記すると、認識のずれを減らせます。
• 制約条件
  予算の考え方、希望する稼働時期、既存システムとの連携、社内の運用ルールなどを伝えます。
• 提案に求める形式と評価基準
  提案書の項目立て、見積もりの内訳の粒度、提出期限を指定し、どの観点で評価するかも可能な範囲で示します。

成果物として発注側が得るのは、各社の提案書・見積書・体制図です。これらは選定の記録として残り、契約後の要件定義でも参照されます。書式を指定しておくと、後の突き合わせが楽になります。

軸を「どこで比較が崩れるか」に置くと、実務で起きやすい問題が見えてきます。多くは要件の曖昧さと段取りの前後関係から生じます。

• 要件が固まらないままRFPを出す
  スコープが揺れると、提案の前提がばらつき、見積もりの高い安いが実態を反映しなくなります。RFIで情報を集めてから進めると、この揺れをある程度抑えられます。
• 評価基準を後から決める
  提案を見てから基準を作ると、特定の提案に有利な形になりがちです。配布前に基準を用意しておくほうが、選定の説明もしやすくなります。
• 要件定義との混同
  RFP段階の要件はあくまで提案を求めるための粗い要件で、契約後に行う要件定義でさらに詳細化されます。RFPで細部まで決めきろうとすると、かえって時間がかかることがあります。

隣接する文書として、見積もりだけを求めるRFQ（Request for Quotation）があります。RFQは価格が主眼で、提案の中身を問うRFPとは目的が異なります。何を知りたいかに応じて使い分けるとよいでしょう。

RFI・RFPを扱えることは、発注側のプロジェクトマネージャーにとって調達の入口を任せられる根拠になります。要件を関係者から引き出して文書にまとめ、評価基準を先に立てて公平に比較する。この一連は、プロジェクトの土台をつくる工程であり、後の要件定義や体制づくりにそのまま影響します。ベンダー側で提案を受ける立場でも、発注側が何を求めているかを読み解く力として役立ちます。転職を考える際には、単に文書を作った経験だけでなく、どの課題をどう要件に落とし込み、どんな軸で選定を進めたかを語れると、調達や上流の工程を任せられる人材として見てもらいやすくなります。SIerやプライムベンダーとの関わりが多い環境では、特に問われる場面が増えていきます。

RFIとRFPはどちらを先に出しますか。

一般的にはRFIを先に出します。市場や製品の情報を集めて候補を把握し、絞り込んだうえで、具体的な提案を求めるRFPを出す流れです。ただし要件が明確で候補も見えている場合は、RFIを省いてRFPから始めることもあります。案件の性質に応じて選びます。

RFPを書くのは誰の役割ですか。

発注側のプロジェクトマネージャーが中心となり、業務部門やシステム部門から要件を集めて文書化することが多いです。評価基準の設定や質疑対応、提案の比較も担います。大規模な調達では調達部門や外部の支援者が関わる場合もあります。

RFPと要件定義書はどう違いますか。

RFPは提案を求めるための文書で、そこに書く要件は比較的粗い粒度です。要件定義書は契約後に発注側とベンダーが詳細を詰めて作る成果物です。RFP段階で決めきろうとすると時間がかかるため、詳細は要件定義に委ねる形が一般的です。