RFI・RFP・RFQの違いとは？PMBOK×外注プロセスを完全解説

何千万円かけた社内システムを、誰も使ってくれなかったら？

「あなたが大きなプロジェクトのリーダーだとして、何年もの月日と何千万円もの予算を注ぎ込み、ついに最新鋭の社内システムを完成させたとします」。ところが導入してみると、現場の社員から「今の業務フローに全く合っていない」「前のほうが圧倒的に使いやすかった」と猛反発を受け、結局だれ一人ログインすらしてくれない。動画はこんな悪夢のような場面から始まります。

動画のテーマは、こうした大失敗を防ぐための「究極の保険」です。大きく2つの柱が出てきます。

• プロジェクトを成功に導く基盤になる知識体系：PMBOKとBABOK
• 外部のパートナーを見極める委託先の選定：RFI・RFP・RFQ

動画では、焦って闇雲に進めると冒頭のような事態を招くので、まず世界標準の考え方と適切な手順を頭に入れておくことが強力な武器になる、と説明されます。

PMBOK：スピードを出すためのガードレール

最初の知識体系はPMBOK（ピンボック）です。動画では、PMI日本支部が発行している第7版によると、12の原則と8つのパフォーマンスドメインに分けて、プロジェクトマネジメントの標準的なフレームワークが記載されている、と紹介されます。

動画では「安全装置があるからこそ、思いっきりアクセルを踏める」とまとめ、PMBOKはどうやって正しく進めるか（How）のための世界標準と位置づけます。

（補足：動画にない確認です。Wikipediaの記述では、PMBOKガイドの第7版（2021年）は、それまでの10の知識エリアを12の原則に置き換える大きな構成変更をした版です。2025年には第8版が発表され、6つの原則と7つのパフォーマンスドメインで構成されています。令和8年4月1日現在、第8版はすでに出ているので、動画の説明は第7版のものと考えてください。なお、第7版が8つのパフォーマンス領域（英語では performance domains）で構成される点は、PMI日本支部の公開資料で確認できました。「PMI日本支部が発行」の点は確認できていません。）

BABOK：「何を解決するのか」を掘り下げる知識体系

もう一つの知識体系がBABOK（バボック）です。動画では、プロジェクト開発の中で行うビジネス分析について定めたもので、そのタスクやテクニックが「4つの要求」と「6つの知識領域」に分けてまとめられている、と紹介されます。

そこで動画は役割を分けます。PMBOKが「プロジェクトをどうやって正しく予算どおりに進めるか」というHowのルールブックだとすれば、BABOKは「そもそも自分たちのビジネスは何を解決すべきなのか」「なぜその機能が必要なのか」というWhat・Whyを徹底的に掘り下げるルールブックです。

動画の結論は、BABOKで「何を解決すべきか」を定義し、PMBOKで「どう実現するか」を管理する。この2つは別物ではなく、ビジネスを成功させるための両輪だ、というものです。

（補足：BABOKはIIBA（International Institute of Business Analysis）が発行する知識体系です。IIBAの公式ページには、BABOKガイドは6つの知識エリアを定め、知識エリアは関連するタスクをまとめたもの、テクニックはタスクを行うための手法だと書かれています。動画の「6つの知識領域」は、この記述と合います。一方、BABOK v3 には要求を4種類（ビジネス要求・ステークホルダー要求・ソリューション要求・移行要求）に分類する考え方があります（解説記事での確認で、IIBA原文は取得していません）。ただし、これは要求の分類であり、動画の「タスクとテクニックが4つの要求と6つの知識領域に分けられる」という言い方がそのまま公式の整理と合うかは確認できませんでした。ここでは動画の言い方として紹介するにとどめます。）

委託先の選定：なぜRFI・RFP・RFQに分けるのか

完璧な設計図と管理手法があっても、実際に手を動かす建設業者が最悪なら、建物は崩れ落ちてしまいます。しかも自社だけでシステム開発をすべてこなせる企業はほとんどなく、外部のプロに頼ることになります。そこで重要になるのが委託先の選定です。動画では、ここでも多くの企業がリスクの高いギャンブルをしてしまっている、と指摘されます。

委託先を選ぶために、一般的にRFI、RFP、RFQで情報提供や提案を依頼する、と動画は説明します。アルファベット3文字が並んでごっちゃになりやすいので、まず3つを並べます。

略称	意味	動画での役割
RFI	Request for Information（情報提供依頼）	相手にどんな技術や経験があるかを確認する
RFP	Request for Proposal（提案依頼）	具体的な提案を求め、委託先を選ぶ材料にする
RFQ	Request for Quotation（見積依頼）	提案内容を実行する正確なコストを確認する

動画では、この順で段階的に進めることが決定的に重要だと語られます。RFIで実力のある業者に絞り込み、RFPで自社の課題に対する最適な解決策を競わせ、RFQでその解決策の正確なコストを比べる、というまとめ方です。

RFI：まず相手の実力を確かめる

RFIは、発注前に、相手の企業にどのような技術や経験があるのかを確認するために行うものと説明されます。これを飛ばして、いきなり「いい建物を提案して」と頼むとどうなるでしょうか。動画のたとえでは、こうなります。

• ある業者は、木造の平屋を提案してくる。
• 別の業者は、鉄筋の3階建てを提案してくる。
• ところが本当に必要だったのは、巨大なショッピングモールだった。そもそもモールを建てた経験のない業者に、提案を作らせてしまった。

これでは、お互いに膨大な時間の無駄です。だからRFIの段階で、「御社は過去にどんな規模のシステムを作った経験がありますか」「我が社の要望に応えられる技術的な土台はありますか」といった情報を、まず集めます。動画では、これを「スクリーニング」と言い換える場面があります。

（補足：英語版Wikipediaでは、RFIは供給者の能力に関する情報を書面で集める手続きと説明されています。IPAの情報処理技術者試験シラバス（FE Ver.9.2）では、ベンダー企業にシステム化の目的や業務内容を示してRFIを作成する、という形で書かれています。日本語版Wikipediaには、RFIは入札の招待ではなく、買い手と売り手のどちらも拘束しない、という説明があります。）

RFP：具体的な提案をもらって比べる

相手が自社のニーズに合う優秀なシェフだと確認できたら、そこで初めて次のステップのRFPに進みます。動画では、RFIで得た情報にもとづいて、相手に具体的な提案をするよう求めるものだと説明されます。依頼元は、このRFPに対して出された提案内容に基づいて、最終的な委託先を選定することになります。

レストランでいえば、「うちの冷蔵庫にはこんな食材があって、予算は限られています。これで具体的なディナーのコースを提案してください」とお願いする段階です。複数の業者からいろいろなコースメニューの提案をもらい、どれがいちばん自社の課題を解決できそうかを比較検討します。

（補足：日本語版Wikipediaでは、RFPにはシステムの概要、技術的な要件、納期などを書くとされています。IPAのシラバスでは、調達対象システム、提案依頼事項、調達条件などを示してRFPを提示し、提案書の提出を依頼する、と書かれています。）

RFQ：最後に「いくらか」を確定する

では逆に、RFPを飛ばして、RFIからいきなりRFQへ進むとどうなるでしょうか。「こんな感じのシステムを作りたいんだけど、いくら？」と聞くパターンです。動画はこれを最悪のパターンとし、日常業務でいちばんやってしまいがちなミスだと語ります。

業者の立場になって考えてみます。要件や提案内容がまだ固まっていないのに、「いくらかかるか約束して」と言われるわけです。あとから「あれも追加して、これも直して」と言われるリスクを見越して、安全マージンを上乗せするのが当然でしょう。その結果、本来なら1,000万円で済むはずのシステムに莫大な安全マージンが載り、3,000万円という法外な見積もりが出てくる、というのが動画の例です。上乗せは2,000万円、3倍にあたります。

つまり、順番を守らずにいきなり見積もりを聞くことは、結果的に自社が損をする原因になる、というのが動画の主張です。

補足：順番の説明は資料によって少し違う

（補足：ここからは動画にない確認です。）動画は「一般的に」RFI→RFP→RFQの順と説明していました。覚えやすい型ですが、確認できた資料では、RFPとRFQの関係の書き方に違いがありました。

• IPAの情報処理技術者試験シラバス（FE Ver.9.2・AP Ver.7.2）では、RFIを作成したあと、ベンダー企業にRFPおよびRFQを提示して提案書・見積書の提出を依頼し、提案書・見積書を受け取ったあとに調達選定へ進む、という順で書かれています。RFPとRFQが同じ段階にまとめられている点が、動画の説明と違います。
• 日本語版Wikipediaには、RFQは、一般的な価格帯を決めるために、本格的なRFPを発行する前に使うこともある、と書かれています。仕様がすでに分かっていて、価格が選定の主な要素になるときにRFQを使う、という説明もあります。

つまり、動画の「RFPで解決策を決めてからRFQで金額を確認する」という流れは、一つの分かりやすい型として理解するのが安全です。動画の説明を否定する資料は確認しませんでしたが、RFPとRFQを同時に出す、RFQを先に使うなど、資料により順序や組み合わせが異なります。試験での問われ方は、この記事では確認していません。

動画の最後の問いかけ：日常の仕事にも当てはまる

動画の終わりでは、「この順番を守るアプローチは、システム開発の業者選びだけにとどまらないのでは？」と投げかけられます。たとえば他部署の同僚に、少し重たい仕事を頼むとき、自分は次のどれをしているのでしょうか。

動画では、これらをごちゃ混ぜにして「これ明日までにやって。どうやればいいと思う？」といきなり丸投げしてしまうから、日々のコミュニケーションで摩擦が起きるのかもしれない、と語られます。そして、いま自分たちはどのステップの会話をしているのかを意識して、明日の業務にこっそり当てはめてみてください、と締めくくられます。

まとめ

動画では、どちらのテーマも根底にあるのは、思い込みによる暴走を防ぎ、関係者全員が納得して確実に前へ進むためのプロセスだと語られます。