RFPとRFIの違い——RFIは、重たいRFPの前に打つ「ジャブ」です

2026年9月17日

支援先で「RFPを作りましょう」という話をすると、かなりの確率でこう聞かれます。

「RFIというのもあるみたいなんですが、何が違うんですか。それも作らないとだめですか」

先に、答えのほうを書いておきます。

RFPとRFIの違いは、ひとことで言うと「重さ」です

	RFI（情報提供依頼書）	RFP（提案依頼書）
何をお願いするか	御社と、御社の製品のことを教えてください	うちの課題に対して、提案と見積もりをください
いつ出すか	選定のはじめ。候補を広く見ている段階	候補を数社に絞ったあと
分量	数ページ	数十ページになることも珍しくありません
受け取る側の手間	軽い。手元の資料でだいたい答えられます	重い。読み解いて、体制を考えて、提案書を書きます

RFIは Request for Information、RFPは Request for Proposal の略です。もうひとつ、RFQ（Request for Quotation・見積依頼書）という言葉も並んで出てきます。金額をあらためて聞くための書類ですが、システム導入では、RFPの中で見積もりも一緒にお願いすることが多いので、この記事では脇に置きます。順番は、RFI → RFP（→ 必要ならRFQ）です。

一般的な説明では、RFIは「発注する側が情報を集めるための書類」とされています。各社の会社情報、製品の機能、実績、だいたいの価格帯を、同じ質問で聞いて横並びで比べる。候補を絞り込む材料にする。これは、そのとおりです。

ただ私は、RFIにはもうひとつ、あまり説明されない役割があると思っています。現場では、そちらのほうが効くことが多い。ベンダーさんへの「ジャブ」です。

この話をするには、まず、RFPがどれだけ重たいものかを書かないといけません。

「選べばいいんでしょ」では、選べません

顧客管理、生産管理、会計。こういう大型のツールを入れるとき、「いくつか比べて、良さそうなのを選べばいいんでしょ」と考えている会社は、少なくありません。

会計は、少し毛色が違うかもしれません。やることが制度で決まっている部分が大きいので、比較的ツールに合わせやすい領域です。

けれども、顧客管理や生産管理は、自社のいまの業務をつまびらかにしないと、選べません。 RFPを作った経験がない会社ほど、ここが「分かっているつもりで、分かっていない」状態になっていると感じます。

整理しなければいけない範囲は、思っているよりずっと広いです。生産管理なら、ほぼ全社の棚卸しになります。顧客管理でも、営業部門だけでは済みません。営業につながっている業務部門、その先のサポートの体制まで、見ておく必要があります。

しかも、ツールを入れるということは、「いまのままではだめだ」という前提があるはずです。何が課題で、どう変えていきたいのか。ここの整理も要ります。

この棚卸しの話は、ツールに業務を合わせる、に私は賛成ですに詳しく書きました。

選定までは、標準で半年。1年近くかかることも珍しくありません

「選ぶだけ」と思っていると、選定までを1〜2か月で考えがちです。

実際には、しっかり時間を取って、標準で半年。社内の承認まで含めると、1年近くかかるケースも多いです。規模や領域によってはもっとかかります。生産管理の乗り換えなら1年半を見ておいてください、という話は知識よりも、現場を巻き込めるかどうかですに書いたとおりです。（期間はあくまで目安です。会社の規模や体制で変わります）

ここを上の人が軽く考えていると、よく分からないまま導入が決まり、現場が無理やりツールに合わせることになり、結局フィットしなかった、という結果になりがちです。

RFPは、この半年なり1年なりの整理の結果を、ベンダーさんに渡すための書類です。自社の業務の中身、課題、実現したいことが、長い文章で書いてあります。重たくて当然なのです。

重たいRFPを、受け取る側から見てみます

ここで、ベンダーさんの側に立ってみてください。

RFPを受け取ったベンダーさんは、その長い文書を読み解き、自社のツールで応えられるかを検討し、体制と金額を考えて、提案書を書きます。1件の提案に、相応の時間と人手を使います。

ですから、ベンダーさんのほうも、「この話に乗るか、乗らないか」をシビアに判断しています。

発注する側は、つい「こちらはお客なのだから、提案はしてもらえるだろう」と思いがちです。

以前は、たしかにそうでした。よほど内容がずれていない限り、提案を断るベンダーさんは多くありませんでした。

いまは違います。統計を取ったわけではなく、あくまで私の体感ですが、辞退がはっきり増えています。 理由として返ってくるのは、たいてい「人が用意できない」です。条件が合わないからではなく、体制が組めないから。後ろ向きな回答が増えたな、という印象があります。

そこへ、何の前触れもなく、重たいRFPが突然届く。ベンダーさんも驚きますし、乗るかどうかの判断材料も足りません。相手の時間をいきなり大きく使わせるお願いですから、失礼にあたることもあります。

だから、先にジャブを打ちます

それがRFIです。

「こういう趣旨のプロジェクトを考えています。御社の製品は、この条件に合いそうでしょうか。合いそうなら、あらためて正式に提案をお願いするかもしれません」

軽い書類で、先にこれを伝えておく。ベンダーさんは心づもりができますし、合わないなら合わないと、早い段階で言えます。合わない相手に重たいRFPを読ませずに済むのは、お互いにとっていいことです。

発注する側にも、得るものがあります。情報が集まるのはもちろんですが、返事の速さや答え方で、その会社がこの話をどのくらいの温度で受け止めているかが、なんとなく見えてきます。

RFIには、細かく書きすぎないでください

RFIを書くときに、いちばん気をつけてほしいことです。

まじめな会社ほど、網羅性を気にして、細かいところまで詰めて書こうとします。けれども、細部を詰めすぎると、大局がつかめなくなります。ベンダーさんのほうも、この話に乗るべきかどうか、かえって判断しづらくなります。

多少の漏れは、あって構いません。書くのは、「ここを満たしていなければ、その時点で選定の対象外になる」という、プロジェクトの根本の趣旨に関わるところです。たとえば、こういうものです。

• オンプレミスからSaaSへ移ることが必須
• レポートの機能やバーコードでの管理など、絶対に外せない特定の機能がある
• これまで週次で締めていたデータを、リアルタイムで見られるようにしたい

こうした絶対条件の1〜2点を、相手がカバーできているか。それが確認できれば、RFIの役割としては十分です。

もちろん、自社の業務の前提に合っているかどうかの確認は、ある程度は要ります。ただ、それを細かく聞くのは、RFPの仕事です。

RFIに書く項目は、最低限この5つです

では、何を書くのか。最低限なら、この5つで足ります。

• 自社の概要。 業種、規模、どの部門の話なのか。相手が「うちの得意な領域かどうか」を判断できる程度で構いません
• プロジェクトの趣旨。 なぜいま入れ替えるのか、何を変えたいのか。数行で書きます
• 絶対に外せない条件。 先ほどの1〜2点です
• 聞きたいこと。 その条件に応えられるか。近い業種や規模での実績はあるか。だいたいの費用感と期間はどのくらいか。機能について聞くなら、短い表にして、〇✕の欄のとなりにコメントの欄を設けておきます（理由はあとで書きます）
• 返答の期限と、その後の予定。 いつまでに返事がほしいのか、RFPはいつごろ出すつもりなのか

全部合わせても、数ページです。

「ひな形はありませんか」と聞かれることもあります。ただ、欄を埋めれば完成するような書式を、ここで一律にお見せするのは避けたいと思います。何を絶対条件に置くのか、相手に何を聞くのかは、会社の状況とプロジェクトの趣旨によって、まったく変わるからです。

それに、書式が先にあると、どうしても「欄を埋める作業」になります。埋めているうちに、細かく書きすぎるほうへ引っぱられていきます。

5つの項目を、自社の言葉で、短く書く。まずはそれで十分です。

何社に声をかけているかも、相手は見ています

もうひとつ、バランスの話です。

一般には、RFIの段階では広めに声をかけて、RFPを出す段階で数社に絞ります。RFIが軽い書類でなければいけない理由は、ここにもあります。広く声をかける段階の書類だからです。

細かくて重たいRFIを受け取り、しかも「10社のうちの1社」だと分かったら、ベンダーさんは辞退したくなります。手間がかかるうえに、選ばれる見込みが薄いからです。

何社に声をかけているかは、聞かれることがあります。聞かれたら、ごまかさないほうがいいと私は思います。そのうえで、広く聞くなら軽く。重たいお願いは、絞ってから。 この順番を守るだけで、ベンダーさんの受け止め方はずいぶん変わります。

ただし、絞りすぎにも気をつけてください。

辞退が増えているいま、RFPを2社にしか出さないのは、怖いです。両方に辞退されれば振り出しに戻りますし、1社に辞退されただけでも、もう比較ができなくなります。

ですから、RFPを出す社数は、以前よりも少し多めでいいのではないか、というのが私の考えです。（何社が適切かは、プロジェクトの規模や候補の数で変わります。目安として受け取ってください）

ここでも、RFIが効きます。RFIの返事を見れば、「RFPを出したら、提案してもらえそうか」の感触が、先に分かります。その感触を踏まえて、RFPを出す社数を決められます。

返ってきた回答は、〇の数より、読んだときの体感です

先ほど、返事の速さや答え方で相手の温度が見える、と書きました。もう少し具体的に書きます。

たとえば、聞きたい機能を絞ってエクセルの表にして、「この機能はどうですか」と1行ずつ答えてもらうことがあります。そのとき、〇✕の欄のとなりに、コメントの欄を設けておきます。

ちゃんと検討してくれている会社は、このコメント欄をしっかり書いてきます。そして、返事も速い。そういう傾向があります。逆に、コメントがあまり埋まっていない会社は、〇ばかりが並んでいても、少し怪しいなと感じることがあります。

〇✕やABCを点数にして比べることは、もちろんやったほうが見えやすくなります。ただ、実際に回答を読んだときの体感は、各社でまったく違います。そしてこの体感は、その後の提案での業務の理解度や、コミュニケーションが噛み合うかどうかに、かなり関係してきます。 私はそう強く感じています。

ひとつだけ、あらかじめ分かっておいてほしいことがあります。

営業の場面と、実際に開発が始まってからとでは、状況が違います。担当の方も変わります。営業はあくまで案件を取るためにやっている、という面があるのも事実です。RFIや提案の段階で感じた手ごたえが、そのまま開発の現場まで続くとは限りません。そこは分かったうえで、体感を判断の材料のひとつにしてください。

RFIという形は省けても、ジャブは省かないでください

では、RFIは必ず作らないといけないのか。

形式としてのRFIは、省ける場面があると思います。候補がはじめから2〜3の製品に絞れていて、知りたいことが公開されている情報でだいたい分かる場合です。そこに書類を一往復はさむ意味は、あまりありません。

けれども、その場合でも、ジャブそのものは省かないでください。電話でも、メール1通でも構いません。「近いうちに、こういう趣旨でRFPをお出ししようと思っています。ご検討いただけそうでしょうか」と、先に伝えておく。

RFIの本質は書類の形式ではなく、重たいお願いをする前に、相手に判断の材料と時間を渡しておくことだと、私は思っています。

それに、絶対に外せない条件を1〜2点に絞るという作業は、自社にとっても意味があります。「このプロジェクトは、結局なにがしたいのか」を、短い言葉で言えるようにする作業だからです。ここが言えないままRFPを書き始めると、RFPのほうも、細かいだけで芯のないものになります。

ポイント

• RFPとRFIの違いは「重さ」です。 RFIは「御社のことを教えてください」、RFPは「うちの課題に提案と見積もりをください」。順番は RFI → RFP です
• 大型ツールは「選べばいい」では選べません。 顧客管理や生産管理は、自社の業務をつまびらかにしてからでないと選定できません
• 選定までは標準で半年、社内承認を含めると1年近く。 1〜2か月で考えていると、現場が無理やり合わせる結果になりがちです（期間は目安です）
• ベンダーさんも、提案に乗るかどうかをシビアに判断しています。 私の体感では、「人が用意できない」という理由の辞退が、以前よりはっきり増えています
• いきなり重たいRFPを送らない。 その前に打つジャブがRFIです
• RFIには細かく書きすぎない。 満たしていなければ対象外になる絶対条件を、1〜2点に絞ります
• RFIに書くのは最低限5つ。 自社の概要／趣旨／絶対条件／聞きたいこと／返答の期限と予定。一律のひな形は、状況で変わるのでここでは出しません
• 広く聞くなら軽く、重たいお願いは絞ってから。 何社に声をかけているかも、相手は見ています
• ただし絞りすぎない。 2社だと、1社の辞退で比較ができなくなります。RFPを出す社数は、以前より少し多めでいいと私は考えています（目安です）
• 返ってきた回答は、〇の数より、読んだときの体感。 コメント欄をしっかり書いて返事も速い会社は、その後の提案でも話が噛み合いやすい。ただし営業と開発では担当も状況も変わります
• 書類としてのRFIは省けても、ジャブは省かない。 電話でもメールでも、先に伝えておきます

RFPの作り方はRFPを作りたいに、システムの入れ替え全般の考え方は基幹システムの入れ替えを検討することになったに書いています。