基幹システムの刷新が決まり、情報システム部門に「まずベンダーに声をかけて提案をもらってほしい」と依頼が届いたものの、要件はまだ固まっていない。こうした場面で、RFIから始めるべきか、いきなりRFPを出すべきかで迷う担当者は少なくありません。

両者は名前が似ていますが、求める情報の深さも、出すタイミングも、社内での使われ方も異なります。この記事では、RFIとRFPの違いを整理したうえで、RFQやRFCとの関係、システム発注での使い分けと進め方を解説します。

この記事を読むと理解できること

• RFIとRFPの違いを、目的・タイミング・記載内容・対象社数で整理できる

• RFQ・RFCを含めた調達文書の関係と、出す順番がわかる

• 基幹・業務システムの発注でRFIを省略してよいケースと省略すべきでないケースがわかる

• RFIからRFPへ進める具体的な手順と、社内の合意形成の進め方がわかる

• RFIに記載する項目と、比較しやすい回答フォーマットの作り方がわかる

• 大企業のシステム発注でRFIとRFPの使い分けを誤ったときに起きる失敗と対策がわかる

RFIとRFPの違いとは 目的とタイミングで比較

RFIはRequest for Informationの略で、日本語では情報提供依頼書と呼ばれます。発注側がベンダーに対して、会社概要や製品・サービスの特徴、導入実績、技術的な対応範囲などの一般的な情報を求める文書です。

RFPはRequest for Proposalの略で、提案依頼書と呼ばれます。実現したいことや要件を発注側が示し、それに対する具体的なシステム構成、体制、スケジュール、費用の提案をベンダーに求める文書です。RFPの基本はRFPとは何かを解説した記事でも整理しています。

一言でまとめると、RFIは「何ができる会社や製品があるのかを知るための問い」であり、RFPは「自社の課題をどう解くのかを提案してもらうための依頼」です。RFIとRFPの違いは、求める情報の具体性と、その後の意思決定への結びつき方にあります。

RFIとRFPの違いを比較表で整理

RFIは要件を固めるための材料集め

この文書の役割は、自社だけでは見えていない選択肢を知ることです。パッケージで実現できるのか、スクラッチ開発が向いているのか、クラウドサービスの組み合わせで足りるのかといった方向性は、各社の回答を並べて初めて判断できることが多くあります。

また、回答には各社の得意領域や想定する導入アプローチが表れます。これを読み込むことで、RFPに書くべき要件の粒度や、評価で重視すべき観点が見えてきます。

RFPは発注先を決めるための比較の土台

RFPは、複数のベンダーに同じ条件で提案してもらい、公平に比較するための文書です。要件、範囲、制約、評価基準が明確であるほど、提案の質がそろい、選定の根拠を社内に説明しやすくなります。

一方で、要件が曖昧なままRFPを出すと、各社が独自の前提で提案するため比較が難しくなります。RFIを経ずにRFPを出した結果、提案内容がばらばらで選定が止まるという事態は、システム発注で起きやすい失敗の一つです。

RFIとRFPの違いに加えて押さえたいRFQとRFC

調達の場面では、RFIとRFPの違いに加えて、RFQやRFCという言葉も出てきます。これらをまとめてRFxと呼ぶこともあります。

RFQは見積もりに特化した依頼書

RFQはRequest for Quotationの略で、見積依頼書と呼ばれます。仕様や数量がすでに決まっている前提で、価格、内訳、納期、支払い条件などを求める文書です。

ハードウェアやライセンスの調達のように仕様が明確な場合は、RFQだけで発注先を決めることもあります。一方、基幹・業務システムの開発では、RFPで提案を受けて発注先候補を絞った後、詳細な条件をすり合わせてRFQで最終見積もりを取る流れが一般的です。

RFCは仕様案への意見を求める文書

RFCはRequest for Commentの略で、意見招請と訳されます。発注側が作成した仕様書や要件の案に対して、ベンダーや関係者からコメントを集めるための文書です。

システム発注では、RFIとRFPの間にRFCに近い工程を挟むことがあります。RFPの案を候補ベンダーに事前に見せ、実現性や記載の曖昧さについて意見をもらうことで、正式なRFPの精度を上げられます。

RFI・RFP・RFQ・RFCの違いと順番

基本の順番はRFI、RFP、RFQです。段階が進むほど発注側が示す内容は具体的になり、対象となるベンダーの数は少なくなります。RFCは必須ではなく、RFPの品質を高めたい場合に挟む工程と考えるとよいでしょう。

システム発注でRFIとRFPを使い分ける判断基準

すべての案件でRFIが必要なわけではありません。RFIとRFPの違いを踏まえ、どこから始めるかは案件の状況で判断します。

RFIから始めるべきケース

次のような状況では、RFIから始めるほうが結果的に選定が早く進みます。

• 基幹システム刷新など、対象範囲が広く実現方式の選択肢が多い

• パッケージ、クラウド、スクラッチのどれが適しているか判断できていない

• 現行システムがブラックボックス化しており、移行の難易度が読めない

• 生成AIなど新しい技術の活用を検討しており、市場の動向を把握したい

• 取引実績のあるベンダー以外にも候補を広げたい

特に大企業の基幹システムでは、既存システムとの連携や段階移行の方式によって、適したベンダーが大きく変わります。RFIで各社のアプローチを把握しておかないと、RFPの段階で前提のずれが表面化します。

RFIを省略してRFPから始めてよいケース

既存システムの機能追加や、要件と実現方式がほぼ決まっている案件では、RFIを省略してRFPから始めても問題ないことがあります。候補となるベンダーが明確で、過去の取引で各社の能力を把握している場合も同様です。

ただし、省略する場合でも、RFPを出す前に候補ベンダーと非公式に情報交換をしておくと、RFPの書き漏れを防げます。RFIという正式な文書を出さなくても、RFIが担う情報収集の工程そのものを飛ばさないことが重要です。

判断に迷ったときの目安

判断に迷うときは、RFPに書くべき要件を自社だけで書き切れるかを確認します。現状の業務とあるべき姿の整理ができていない場合は、RFIで外部の知見を取り込む段階だと考えられます。現状とあるべき姿の整理方法はAs-Is/To-Beの記事で解説しています。

RFIからRFPへ進めるシステム発注の進め方

ここでは、基幹・業務システムの発注を想定して、RFIからRFPへ進める流れを紹介します。

ステップ1 構想と目的を社内で定義する

最初に、システム導入の背景、解決したい経営課題、対象業務の範囲を整理します。この段階で情報システム部門だけで進めると、事業部門の期待とずれやすくなります。

経営層、事業部門、情報システム部門の三者で、何のための刷新なのかを言葉にしておくことが大切です。ここで定義した目的が、RFIの送付文にもRFPの背景にもそのまま使われます。

ステップ2 RFIを作成し候補ベンダーに送付する

目的と検討領域を記載したRFIを作成し、候補となるベンダーに送ります。送付先は、既存取引先だけでなく、展示会や業界の情報、各社の公開資料などから幅広く選ぶとよいでしょう。

あわせて、回答期限と質問の受付方法を決めておきます。ベンダーにとって回答作成は営業コストになるため、目的を明確にし、回答しやすい形式にすることが回答の質を左右します。

ステップ3 RFIの回答を比較し候補を絞り込む

回収した回答を、同じ観点で比較します。機能の対応範囲だけでなく、導入実績のある業種や規模、提案される導入方式、体制の厚みなどを確認します。

必要に応じて、ベンダーとの面談や製品デモを実施します。資料だけでは判断しにくい操作感や、担当者の理解度を確かめられるためです。この段階で、RFPを送る候補を数社に絞り込みます。

ステップ4 RFPを作成し提案を依頼する

情報収集で得た内容をもとに、要件、範囲、スケジュール、評価基準を具体化したRFPを作成します。各社の回答で見えた選択肢の違いを踏まえ、比較したい観点をRFPの提案項目に反映させるのがポイントです。RFPの書き方はRFPの書き方の記事で詳しく解説しています。

RFPの送付後は、質疑応答の期間を設けます。ある社からの質問への回答は、公平性の観点から全社に共有するのが基本です。

ステップ5 提案を評価しRFQで条件を確定する

提案書を受け取ったら、事前に定めた評価基準に沿って採点し、プレゼンテーションを経て発注先候補を決めます。その後、範囲や契約形態を詰めたうえでRFQを出し、最終的な見積もりと条件を確定させます。

評価結果と選定理由は、稟議に添付できる形で文書化しておきます。RFIからRFPまでの経緯が記録として残っていれば、経営層やセキュリティ審査の担当部門への説明もしやすくなります。

RFIに記載する項目と回答フォーマットの作り方

RFIに記載する項目は、大きく分けて発注側が伝える情報と、ベンダーに求める情報の二つです。

発注側が伝える情報

• RFIの趣旨と目的、回答の使い道

• 自社の概要と事業の状況

• 検討の背景と解決したい課題

• 検討対象の業務領域とシステムの範囲

• 現行システムの概要と連携が必要なシステム

• 今後の検討スケジュールの見通し

• 回答期限、提出形式、問い合わせ窓口

• 本RFIが発注を約束するものではない旨と、秘密保持の取り扱い

ベンダーに求める情報

• 会社概要、事業内容、体制、親会社やグループ会社との関係

• 提案可能な製品・サービスの概要と提供形態

• 対象業務に対する機能の対応可否

• 同業種や同規模での導入実績

• 想定される導入アプローチと期間の目安

• セキュリティや認証の取得状況

• 保守運用の体制と、内製化を支援する方針の有無

比較しやすい回答フォーマットにする

回答を自由形式にすると、各社の資料の構成がばらばらになり、比較に時間がかかります。機能の対応可否は、標準機能で対応、設定で対応、追加開発で対応、対応不可といった選択肢を用意した表形式にすると比較しやすくなります。

一方で、項目を細かくしすぎると、ベンダーの負担が増えて回答が遅れたり、提案の余地が狭まったりします。この段階はあくまで情報収集が目的なので、自由記述欄を残して各社の考え方を書いてもらう余白をつくるのがよいでしょう。

RFIとRFPの違いを踏まえた大企業の失敗と対策

大企業のシステム発注では、RFIとRFPの違いを理解していても、運用の段階でつまずくことがあります。代表的な失敗と対策を紹介します。

RFIの回答をそのままRFPの要件にしてしまう

情報収集の段階で集めた機能一覧を寄せ集めて、RFPの要件にしてしまうケースがあります。この方法では、特定の製品の機能に引きずられた要件になり、結果的に一社に有利なRFPになりがちです。

RFPの要件は、あくまで自社の業務と課題から導くものです。集めた回答は、実現方式の選択肢や要件の粒度を判断する参考情報として扱いましょう。

現場の業務が見えないまま要件を書いてしまう

RFIとRFPの作成を情報システム部門だけで進めると、紙の上では整った要件でも、現場で使われないシステムになるおそれがあります。要件定義書の言葉だけでは、事業部門や現場の担当者が完成形をイメージしにくいためです。

対策としては、RFPを作る前の段階で、画面のイメージや業務の流れを可視化して関係者と確認することが挙げられます。抽象的な議論を具体的な形にしてから要件に落とし込むことで、合意形成にかかる時間も短くなります。

既存ベンダーへの依存から抜け出せない

長年同じベンダーに保守を任せている場合、RFIの送付先が既存取引先に偏り、選択肢が広がらないことがあります。既存システムの仕様が特定のベンダーにしかわからない状態では、RFPを出しても他社が適切に見積もれません。

RFIの段階で送付先を広げること、現行システムの情報を可能な範囲で整理して開示することが、ベンダーロックインを避ける第一歩です。詳しくはベンダーロックインの記事も参考にしてください。

RFIとRFPの作成に時間をかけすぎてしまう

稟議や各部門のレビューを重ねるうちに、RFIとRFPの作成だけで数か月が過ぎることも珍しくありません。その間に事業環境が変わり、前提が古くなってしまうこともあります。

情報収集の段階では完璧を目指さず、目的と範囲が伝わる最小限の内容で早めに出すことが有効です。RFPの作成に社内リソースが足りない場合は、外部の支援を活用する方法もあります。RFP作成を支援する会社についてはRFP作成支援の会社を紹介した記事で紹介しています。

株式会社FAKEでは、FDE支援として大企業DXの上流工程に入り、プロトタイプとヒアリングを反復しながら認識合わせと要件定義書の作成を一つのフローで進めています。パッケージ前提ではない提案を行うため、RFIやRFPで実現方式を比較検討する段階から伴走できます。

まとめ

RFIは情報提供依頼書で、市場やベンダーの情報を集めて候補を絞り込むための文書です。RFPは提案依頼書で、要件を示したうえで具体的な提案を比較し、発注先を決めるための文書です。RFIとRFPの違いは、求める情報の具体性と、意思決定のどの段階で使うかにあります。

調達の流れは、RFIで情報を集め、RFPで提案を比較し、RFQで条件を確定するのが基本です。RFCは、RFPの案に意見をもらって精度を高めたいときに挟む工程です。

基幹・業務システムの発注では、実現方式の選択肢が多い案件ほどRFIから始める価値があります。RFIの回答を要件の寄せ集めに使わず、自社の業務と課題から要件を導くこと、そして現場や経営層と早い段階で完成形のイメージを合わせることが、選定を成功させる鍵です。

RFIとRFPの違いに関するよくある質問

RFIとRFPは必ず両方作成する必要がありますか

必須ではありません。要件と実現方式がほぼ決まっていて、候補ベンダーの能力も把握している案件では、RFPから始めることもあります。ただし、基幹システムの刷新のように選択肢が多い案件では、RFIで情報を集めておくほうがRFPの精度が上がり、結果的に選定が早く進みます。

RFIの回答期間はどのくらいに設定すればよいですか

一般的には2週間程度を目安とするケースが多く見られます。質問項目が多い場合や、ベンダー側で社内確認が必要な内容を含む場合は、もう少し長めに設定すると回答の質が上がります。期限とあわせて、質問の受付期間も明示しておきましょう。

RFIに予算を記載したほうがよいですか

RFIの段階では、予算を記載しないことも多くあります。情報収集が目的のため、予算を示すと各社の回答がその金額に引きずられ、選択肢の幅が狭まる可能性があるからです。一方、RFPでは予算の上限や目安を示したほうが、実現性の高い提案を受けやすくなります。

RFIに回答したベンダーにはRFPを送る必要がありますか

その必要はありません。RFIは候補を絞り込むための工程なので、回答内容を比較したうえで、RFPを送るベンダーを選びます。RFIの送付時に、回答が発注やRFPの送付を約束するものではない旨を記載しておくと、ベンダーとの認識のずれを防げます。

RFIとRFPはどの部門が作成するのが一般的ですか

システム発注では、情報システム部門やDX推進部門が取りまとめることが一般的です。ただし、業務要件や課題は事業部門でなければ書けない部分も多いため、事業部門の担当者やPMOを巻き込んで作成することが大切です。経営層への報告のタイミングもあらかじめ決めておくと、稟議が円滑に進みます。