RFPとRFIはいずれも、民間企業や公的機関がシステムやサービスを導入・刷新するプロジェクトで作成する、重要なドキュメントのひとつです。自社のニーズに合うシステムやサービスを選定し、プロジェクトを成功させるためには、ドキュメントに記載するべき項目を理解しておかなければなりません。RFPとRFIの作成を担当しているものの、それぞれの違いが曖昧な方に向けて、概要や違い、メリット、作成時の注意点もわかりやすくまとめています。
RFPとRFIの違いは？それぞれの概要
「RFP」と「RFI」では、ドキュメントの目的や記載項目、発行するタイミングなどに違いがあります。
RFP（Request For Proposal）とは？
RFPとは、「Request For Proposal」の略称であり、「提案依頼書」と訳します。民間企業や公的機関がシステムを導入・刷新する際、ベンダーやSIerに自社の状況改善や課題解決に最適な提案を要求するために発行する書類です。通常、自社のニーズを具体化した上で、RFIで収集した情報に基づいてRFPを作成し、提案を受けたい相手側に提示します。
要件定義書との違いや作成メリットなど、RFPについて詳しくは以下の記事をご覧ください。
RFI（Request For Information）とは？
RFIとは、「Request For Information」の略称であり、「情報提供依頼書」と訳します。民間企業や公的機関がシステムの導入・刷新を計画する際、ベンダーやSIerにさまざまなシステムの基本情報や詳細仕様、会社概要、開発実績などの開示を要求するために発行する書類です。
情報を幅広く収集することで、システムの比較検討だけではなく、導入すべきシステムの要件の妥当性などの判断もできます。また、システム選定時の公平性や正当性を担保することも目的のひとつです。
ベンダーやSIerが公式サイトやカタログなどに、最低限の情報を公開しているケースが多いものの、要件定義やシステム選定に必要な情報を網羅しているとは限りません。したがって、より多くの情報を収集する手段として、作成したRFIを相手側に提示する形が最適です。
参照元：デジタル庁「デジタル・ガバメント推進標準ガイドライン 実践ガイドブック」
※P189をご参照ください
RFPに記載するべき5つの項目
基本的な情報を要求するRFIとは異なり、RFPでは具体的な提案を要求するものです。RFPのサンプルは以下のページでダウンロードできるので、記載例を確認したい場合は参考にしましょう。
RFPに記載するべき項目は以下の5点です。
- プロジェクトの背景と自社の課題
- プロジェクトの目的とゴール
- プロジェクトの範囲と方針および現在のシステム構成
- 提案依頼内容
- 選考の進め方
上記のページでダウンロードできるサンプルの内容に触れつつ、RFPの記載項目について理解しておきましょう。
1. プロジェクトの背景と自社の課題
RFPの序盤では、プロジェクトの背景や自社の課題に関する見出しを作成し、提案に必要な基礎情報を提供します。サンプルでは、見出し2と3にあたる部分です。
「2. プロジェクトの背景」にはシステムの導入に至った経緯を簡潔に、「3. 現在抱えている課題」にはシステムの導入によって解決したい課題を明確にまとめましょう。課題が複数ある場合は、必要に応じて箇条書きを活用すると、視認性が向上します。
2. プロジェクトの目的とゴール
ベンダーやSIerから具体的な提案を受けるには、共有すべきプロジェクトの目的やゴールも含めましょう。サンプルでは、見出し4と5にあたる部分です。
「4. プロジェクトの目的」には、プロジェクトの背景や自社の課題を踏まえた上で、システムの導入によって達成したい目的を伝えます。「5.プロジェクトのゴール」は、自社のニーズを「品質／費用／納期」に分けて共有します。
目的やゴールを曖昧なまま設定すると、プロジェクトは成功しません。目的やゴールを伝える際には、定量的な指標も含め、明確化することが重要です。
3. プロジェクトの範囲と方針および現在のシステム構成
サンプルの見出し6から8までは、プロジェクトの範囲や方針、現在のシステム構成に触れています。
「6. プロジェクトの範囲」は、ベンダーやSIerに要求する作業範囲を伝える項目です。システム開発のみを要求する場合と、セットアップなどを含む包括的な作業を要求する場合とでは提案内容が変わるため、詳細な内容が求められます。
「7. プロジェクトの方針」は、自社の理想となるプロジェクトの進行方向を伝える項目です。求める機能や想定しているシステム構成も含めて、ベンダーやSIerに提示したい内容をまとめましょう。
RFPの提示後に機能追加を要求する場合は、提案書や見積書を再度作成してもらわなければなりません。相手側とのやり取りが長引いた場合、スケジュールに遅れが生じるリスクもあるため、最初に提示する段階で内容に漏れがないことを確認しておくことをおすすめします。
「8. 現在のシステム構成」は、既存のシステム構成図や外部システムとの連携図などを見せる項目です。システム構成図の作成が難しい場合は、最低限として現在使用しているシステムのパッケージ名を挙げましょう。
4. 提案依頼内容
サンプルの見出し「9. 提案依頼内容」には、以下の項目に従い、提案書に含めてほしい内容を箇条書きで列挙します。
- 会社・組織情報
- 提案システム概要
- システム構成
- プロジェクトスケジュール
- プロジェクト体制図
- プロジェクトマネジメント方法
- 会議体一覧
- サポート体制・運用方法、SLA
- 納品物一覧
- ドキュメントサンプル
- 概算費用
- 契約条件
上記のほか、システムを選定する際に重視するポイントがある場合には、項目を追加しましょう。
5. 選考の進め方
サンプルの見出し10にあたる部分は、選考の進め方を伝えるRFPの終盤です。「10. 選考の進め方」では、選考スケジュールや提案書の提出先、提案評価過程などを項目別に整理します。
選考スケジュールには、自社として想定している提案書の提出期限や内容の精査期間、発注手続き予定日、プロジェクト開始予定日などをまとめれば問題ありません。
複数社からスケジュールの見直しを要求された場合は、その意見を考慮して再検討すべきです。提案書の提出先には、担当者の氏名やメールアドレスなど、提案評価過程には、提案書の審査を行う際に重視するポイントを伝えましょう。
RFIに記載するべき5つの項目
RFIは要件定義の前段階として、複数社からシステム選定に必要な情報を収集するために作成します。RFIに記載するべき項目は以下の5点です。
- RFI発行元の情報（自社の情報）
- RFI発出の主旨・目的
- ベンダー・SIerなどの企業情報
- 製品・サービスの基本情報に関する開示依頼
- 製品・サービスの機能（詳細）に関する開示依頼
1. RFI発行元の情報（自社の情報）
ほとんどのRFIは、ベンダーやSIerと初めてコンタクトを取る段階に発行するドキュメントです。今後、自社の重要なパートナーになり得る相手に対して、自己紹介を行いましょう。RFI発行元の情報として以下の内容を開示します。
- 企業名・部署名
- タイトル
- 発出年月日
企業名や部署名は、「xxx株式会社●●部門」の形式が基本です。タイトルは「行内勘定システム移行に係る情報提供依頼書（RFI）」などと付け、発出年月日は「2024年12月1日」のように、「西暦年月日」の形式で記録します。
2. RFI発出の主旨・目的
主旨や目的を伝えずにRFIを発行した場合、ベンダーやSIerから期待通りの回答を得られないリスクがあります。システムやサービスの導入を検討してRFIの作成に至った経緯や、収集したい情報を明確に整理しましょう。
必要に応じて、自社の課題やゴールについて説明する項目も別途用意し、その情報を提供することで、ベンダーやSIerから期待通りの回答を得られます。
3. ベンダー・SIerなどの企業情報
システム自体に関する情報だけではなく、回答を要求する企業や組織に関する情報も求められます。情報開示を要求する項目の具体例は、以下の通りです。
- 社名
- 所在地
- 資本金
- 売上高
- グループ情報（親会社、体制図）など
近年では、グループ企業と連携して、システム開発やサービス提供を行うベンダーが少なくありません。同時に資本関係のある複数社にアプローチする無駄を省くため、RFIの段階においてグループ情報を把握しておきましょう。
4. 製品・サービスの基本情報に関する開示依頼
導入を検討しているシステムやサービスに関する情報収集も、RFIの重要なポイントです。社内で比較検討する際に必要な情報を整理した上で、質問項目として漏れがないようにまとめましょう。
システムやサービスに関して、最低限の質問を投げかけるべき項目の具体例は以下の通りです。
- システム・サービスの正式名称、市販名
- システム・サービスの販売開始時期
- システム・サービスの市場想定売価
メーカーによっては、市販品と入札用で型番を区別していることがあります。正式名称と市販名の双方を開示してもらうことにより、正しい情報把握が可能です。
販売開始時期はシステムやサービスのライフサイクルを把握すること、市場想定価格は公式サイトやカタログなどに「オープン価格」と表示されているシステムやサービスの価値を把握することが目的です。この市場想定価格を把握できた場合、入札時に提示される価格の目安をつかめます。
5. 製品・サービスの機能（詳細）に関する開示依頼
システムやサービスの機能に関して、公式サイトやカタログで確認できる内容以上の情報を把握したい場合は、RFIで質問します。開発に使用する言語や自社と同業種に対する導入事例なども質問項目に追加し、開示を要求するとよいです。
RFIで開示を要求できる情報に細かなルールはないため、上記以外に把握したい内容があれば、適宜追加が可能です。例えば、類似プロジェクトの実績が豊富な企業をパートナーとして選択したい場合は、自社と同業種の事例の開示を要求しましょう。
RFI／RFPのメリット
RFIとRFPはいずれも、プロジェクトの成功を支える重要なドキュメントです。双方のメリットは、作成時の予備知識として確認しておくことをおすすめします。
自社要求の妥当性を客観的に判断できる
RFIやRFPを提示して回答や提案を受けると、システム・サービスの導入の目的が自社の状況改善や課題解決であるものの、ベンダーやSIerに対する自社の要求は過剰ではないかどうか、妥当であるかどうかなどを客観視できます。これにより、ベンダーやSIerから情報を収集する過程で、要求への対応が可能かどうかを判断しやすくなります。
要求の妥当性に疑問を感じた場合には、収集した情報に基づいて再考しましょう。自社の状況改善や課題解決を図るために、最適なシステムやサービスを見極め、無理のないスケジュールを設定してプロジェクトを進行するには、システム開発に関する広範な知識が不可欠です。担当者の知識のみに頼ってプロジェクトを開始した場合、求める機能の見落としや予算超過が生じる可能性があります。
RFIやRFPを活用することで、各分野の専門家の意見を幅広く取り入れられます。専門家の意見を参考にして自社の計画を見直せば、プロジェクトの成功率アップが可能です。
ベンダー・SIer選定の根拠を示せる
RFIやRFPを発行することで、複数社の中からピックアップした企業にアプローチして提案を受けるまでの、一連の流れを明確な記録として残せます。ドキュメントで提示した基準に沿って選定を進めると、入札談合や不正入札などによるガバナンス違反の回避にも有効です。
また、ベンダーやSIerなどの評価基準を事前に設定しておけば、個人のバイアスを排除した公平な審査を行いやすくなります。ロジカルな審査に基づいた選定により、社内関係者の納得を得やすい点もメリットのひとつです。
スクリーニングの役割も果たす
RFIとRFPは、プロジェクトの初期段階で複数社にアプローチし、要件定義やシステムの選定に必要な情報の提供や、システムの基本情報や詳細仕様の開示を要求するドキュメントです。このドキュメントの内容を確認することで、自社の要望とのミスマッチが発覚するケースが多く、スクリーニング資料として機能します。RFIやRFPの発行は、各社から統一的なフォーマットで回答や提案を得られるため、比較する際に自社のニーズに合うシステムを効率的に絞り込めます。
選定後のトラブル防止に役立つ
口約束のみで搭載する機能や仕様、納期などを決定した場合、双方の認識に食い違いが生じて、トラブルが発生するリスクがあります。RFIやRFPに重要事項を明記し、事前に提示することで、双方の認識のすり合わせが可能です。双方が納得した状態でプロジェクトを開始すると、認識の不一致によるトラブルを回避できます。
RFI／RFP作成時の注意点
RFIやRFPの作成時には公平な審査に役立てるため、提案の粒度がそろう質問を意識しましょう。これは、粒度が異なると内容を比較しにくく、公平性に支障を来すケースがあるためです。例えば、プロジェクトの進行スケジュールに対する回答を求める場合は、「週単位で振り分け」「機能別・タスク担当者別に色分け」などの詳細な指示を追記すると、同じ粒度の回答を得られます。そのほかにも、システム稼働後のサポート体制について質問する場合は、「サポート窓口・対応体制・緊急対応窓口を明記」などの指示の記載をおすすめします。
RFIやRFPを発行する際には、十分な回答期間を設定することも重要です。企業やプロジェクトの規模が大きいほど回答を得るのに時間がかかるので、最低限として約2週間の回答期限を設けた方が質の高い回答を得やすくなります。ベンダーやSIerから回答期限の延長を要求された場合は、十分な回答を得るためにもスケジュールを見直しましょう。
まとめ
RFPとRFIはいずれも、システムやサービスの導入時に発行するドキュメントですが、RFPは自社の状況改善や課題解決に最適な提案を要求すること、RFIはシステムの基本情報や詳細仕様などの開示を要求することが目的です。記載項目や発行するタイミングなどは異なりますが、双方ともシステム選定時の比較検討で大いに役立ちます。本記事で解説した内容を参考に、RFPとRFIを適切に作成・発行し、プロジェクトの成功を目指しましょう。
