基幹システムの刷新や業務システムの新規開発が決まり、ベンダー選定の準備に入ったものの、上司からまずRFPを用意するように言われて手が止まっている。そんな情報システム部門やDX推進部門の担当者は少なくありません。

RFPは単なる発注書類ではなく、社内の要件を整理し、複数のベンダーから質の高い提案を引き出すための土台です。この記事では、RFPとは何かという定義から、大企業のシステム開発で果たす役割や目的、構成要素の全体像、作成の流れまでを解説します。

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

• RFPとは何か、システム開発における提案依頼書の基本的な意味

• RFP・RFI・RFQの違いと、発注プロセスの中での位置づけ

• 大企業のシステム開発でRFPが果たす役割

• RFPを作成する目的と、メリット・デメリット

• RFPの構成要素の全体像と、各項目に書く内容

• RFPの作成からベンダー決定・契約までの大まかな流れ

• 大企業がRFPを作成する際に押さえたいポイント

RFPとはシステム開発の要件を伝える提案依頼書

最初に、RFPという言葉の意味と、似た書類との違い、作成するタイミングを整理します。

RFPの基本的な意味

RFPとは、Request for Proposalの略で、日本語では提案依頼書と呼ばれます。システム開発を発注する企業が、開発ベンダーやSIerに対して、実現したいことや要件を示したうえで具体的な提案と見積もりを依頼するための文書です。

RFPには、プロジェクトの背景や目的、現状の課題、求める機能、予算やスケジュール、提案書の提出方法や評価の観点などをまとめます。ベンダーはRFPを読んで発注側の意図を理解し、それに沿ったシステム構成や体制、費用を提案します。

口頭の打ち合わせやメールのやり取りだけで発注を進めると、ベンダーごとに受け取る情報がばらつき、前提の異なる提案が集まりがちです。RFPという共通の文書を用意することで、すべてのベンダーに同じ情報を同じ形で渡せるようになります。

RFP・RFI・RFQの位置づけ

RFPと混同されやすい書類に、RFIとRFQがあります。RFIはRequest for Informationの略で情報提供依頼書、RFQはRequest for Quotationの略で見積依頼書を指します。

一般的な発注プロセスでは、まずRFIで各社の製品や技術、実績などの情報を集めて候補を絞り込みます。そのうえでRFPを出して具体的な提案を受け、仕様が固まった段階でRFQにより価格の詳細を確認する、という順番で使われます。

候補のベンダーが最初から明確な場合は、RFIを省略していきなりRFPを出すこともあります。3つの書類の違いや使い分けは、RFIとRFPの違いで詳しく解説しています。

RFPを作るタイミング

RFPは、発注先の検討を始めた早い段階で作成に着手します。ベンダーの選定や本格的な要件定義、設計に入るより前に、発注側として何を実現したいのかを文書にしておく必要があるためです。

大企業のプロジェクトでは、RFPの作成だけで数週間から数か月かかることも珍しくありません。稟議や予算確保のスケジュールから逆算し、余裕をもって準備を始めることが大切です。

大企業のシステム開発でRFPが果たす役割

関係者が多く、既存システムとの連携も複雑になりやすい大企業では、RFPの役割はより重くなります。ここでは代表的な4つの役割を紹介します。

発注側の要件をベンダーへ正確に伝える

RFPの最も基本的な役割は、発注側が求めていることをベンダーへ正確に伝えることです。業務の流れや既存の基幹システムの構成、利用部門の規模といった前提は、社外のベンダーからは見えません。

RFPに前提条件と要件を整理して記載することで、ベンダーは的外れな提案を避け、発注側の状況に合った解決策を検討できます。結果として、提案の段階から実現性の高い議論ができるようになります。

複数ベンダーの提案を同じ物差しで比較する

複数のベンダーに同じRFPを渡すことで、各社は同じ条件のもとで提案を作成します。前提がそろっているため、費用や体制、スケジュール、技術的なアプローチを横並びで比較できます。

RFPに評価の観点をあらかじめ示しておけば、選定の基準が社内外に明確になります。調達の透明性が求められる大企業では、なぜそのベンダーを選んだのかを説明できる状態をつくることも、RFPの重要な役割です。

稟議と社内合意形成の土台になる

RFPを作る過程では、情報システム部門、事業部門、経営層など、立場の異なる関係者の意見をすり合わせる必要があります。何を目的に、どこまでの範囲を、どの程度の予算で進めるのかを文書に落とし込むことで、社内の認識をそろえられます。

完成したRFPは、そのまま稟議や予算申請の説明資料としても活用できます。プロジェクトの背景と目的が整理されているため、経営層への説明もしやすくなります。

契約後の認識ズレと追加費用を防ぐ

システム開発のトラブルで多いのが、発注側とベンダーの間の認識のズレです。RFPに要件や前提条件を明記しておけば、言った言わないの行き違いを減らせます。

開発が進んでから要件の追加や変更が発生すると、追加費用やスケジュールの遅延につながります。RFPの段階で範囲と条件を明確にしておくことは、プロジェクト全体のリスクを抑えることにもつながります。

RFPを作成する目的とメリット・デメリット

RFPを作成する目的は、一言でいえば発注の質を高めることです。ここでは、作成によって得られるメリットと、あらかじめ理解しておきたいデメリットを整理します。

自社の課題と目指す姿を言語化できる

RFPを書くためには、現状の業務やシステムにどのような課題があり、導入後にどのような状態を目指すのかを言語化しなければなりません。この作業を通じて、社内で暗黙のままになっていた課題や、部門ごとに異なっていた理想像が明らかになります。

現状と目指す姿の整理は、システム開発の成否を左右する重要な工程です。RFPの作成は、ベンダーのためだけでなく、自社の業務を客観的に見直す機会にもなります。

ベンダーの提案の質を高められる

RFPで背景や目的が丁寧に共有されていると、ベンダーは要件をこなすだけでなく、より良い実現方法を考えた提案を出しやすくなります。発注側が想定していなかった技術や進め方が提案されることもあります。

また、RFPを広く提示することで、これまで取引のなかったベンダーの中から実力のある会社を見つけられる可能性もあります。既存ベンダーとの関係に依存しない選定ができる点も、RFPのメリットです。

作成に時間と工数がかかるというデメリット

一方で、RFPの作成には相応の時間と工数がかかります。関係部門へのヒアリングや要件の整理、社内レビューを重ねるため、検討開始から開発着手までの期間は長くなりがちです。

担当者が通常業務と兼務している場合は、作成が後回しになり、内容が不十分なままRFPを出してしまうこともあります。体制とスケジュールを確保したうえで取り組むことが、RFPを有効に機能させる前提になります。

RFPの構成要素の全体像

RFPの構成は企業やプロジェクトによって異なりますが、大きくは次の4つの区分に整理できます。

プロジェクト概要

プロジェクト概要には、なぜこのシステムが必要なのかという背景と目的、現状の課題、導入後に目指す姿を記載します。対象となる業務や部門、利用者の規模といった範囲も、ここで明確にします。

RFPの中で最もベンダーの理解に影響するのが、この部分です。現状の課題と目指す姿がしっかり伝わっていれば、要件の行間にある意図までくみ取った提案を期待できます。

提案依頼事項

提案依頼事項には、ベンダーに提案書へ盛り込んでほしい内容を記載します。システム構成や開発手法、プロジェクト体制、スケジュール、費用の内訳、類似案件の実績などが代表的な項目です。

各社の提案を比較しやすくするため、費用の内訳の出し方や提案書の構成をある程度指定しておくのが一般的です。

システム要件

システム要件には、システムが備えるべき機能を示す機能要件と、性能や可用性、セキュリティ、運用保守などの品質を示す非機能要件を記載します。大企業では、既存の基幹システムや周辺システムとのデータ連携、段階的な移行の方針、利用部門への教育なども重要な項目です。

要件は、必ず満たすべきものと、できれば実現したいものに分けて優先度を示すと、ベンダーが提案の範囲を判断しやすくなります。

選定の進め方と契約条件

最後に、提案書の提出期限や提出方法、質疑応答の受付方法、選定のスケジュール、評価の観点を記載します。契約形態や知的財産の扱い、守秘義務といった契約に関わる条件も、この区分で示しておきます。

それぞれの項目を実際にどう書くかはRFPの書き方で、すぐに使える項目一覧はRFPのテンプレートで紹介しています。

RFPの作成からベンダー決定までの流れ

RFPは書いて終わりではなく、ベンダーを選び契約を結ぶまでの一連のプロセスの中で使われます。ここでは全体の流れを6つのステップで概観します。

ステップ1 プロジェクト体制を整え目的を明確にする

まず、情報システム部門と事業部門を中心にプロジェクトチームを編成します。そのうえで、プロジェクトの目的とゴール、対象範囲を定め、経営層とも方向性をすり合わせます。

ステップ2 現状を把握し課題と要件を整理する

現場の担当者や管理職、情報システム部門などにヒアリングを行い、現状の業務とシステムの課題を洗い出します。洗い出した課題から解決の方向性を検討し、必須の要件と希望する要件に分けて整理します。

ステップ3 RFPを作成し社内で合意する

整理した内容をもとにRFPを作成し、関係部門のレビューを経て内容を確定させます。この段階で社内の合意が取れていないと、提案を受けた後に要件が変わり、選定がやり直しになることがあります。

ステップ4 候補のベンダーにRFPを提示する

候補のベンダーを選び、必要に応じて秘密保持契約を結んだうえでRFPを提示します。説明会を開いて背景や意図を補足し、ベンダーからの質問には全社に同じ回答を共有すると、公平性を保てます。

ステップ5 提案書を評価し発注先を決める

各社から提案書と見積書を受け取ったら、事前に定めた評価基準に沿って採点し、必要に応じてプレゼンテーションの場を設けます。費用だけでなく、課題の理解度や体制、進め方の妥当性を含めて総合的に判断します。

ステップ6 条件を調整して契約を結ぶ

発注先が決まったら、提案内容をもとに範囲や費用、スケジュールを最終調整し、契約を締結します。請負か準委任かといった契約形態も、プロジェクトの性質に合わせてこの段階で確定させます。

大企業がRFPを作成する際に押さえたいポイント

最後に、大企業ならではの事情を踏まえて、RFPを作成する際に押さえておきたいポイントを4つ紹介します。

対象システムの全社的な位置づけを確認する

大企業のシステムは、基幹システムや周辺システムと複雑に連携していることが多くあります。RFPを書き始める前に、対象のシステムが全社のシステム構成の中でどこに位置し、どのシステムに影響するのかを確認しておくことが重要です。

影響範囲が広い場合は、全社のIT戦略や経営課題と照らし合わせたうえで、RFPの範囲を決める必要があります。

情報システム部門と事業部門を早期に巻き込む

RFPを情報システム部門だけで作ると、現場の業務に合わない要件になりやすくなります。反対に事業部門だけで作ると、セキュリティや運用、既存システムとの整合が抜け落ちることがあります。

作成の初期段階から両部門を巻き込み、PMOや経営層も含めて論点をすり合わせておくことで、後からの手戻りを防げます。

セキュリティ審査と非機能要件を初期から織り込む

大企業では、新しいシステムの導入にあたって社内のセキュリティ審査や監査部門の確認が必要になるケースが一般的です。これらの要件を後から追加すると、提案のやり直しや費用の増加を招きます。

RFPの段階で、社内のセキュリティ基準や情報管理のルール、求める可用性などの非機能要件を明記しておくことが大切です。

要件を縛りすぎずベンダーロックインを避ける

RFPで実現方法まで細かく指定しすぎると、ベンダーの創意工夫の余地がなくなり、より良い提案を受ける機会を逃してしまいます。特定の製品や技術を前提にした書き方は、結果的に特定ベンダーへの依存を強めることにもなります。

RFPでは何を実現したいかを中心に記載し、どう実現するかはベンダーの提案に委ねる姿勢が有効です。特定ベンダーへの依存が生むリスクについては、ベンダーロックインの記事も参考にしてください。

RFPの作成を外部の支援で進めるという選択肢

社内にRFPの作成経験を持つ人材が少ない場合や、関係部門の合意形成に時間がかかっている場合は、外部の専門家の支援を受けるのも一つの方法です。第三者が入ることで、現状の課題整理や要件の優先度づけが進みやすくなります。

株式会社FAKEでは、FDE支援として大企業のDXの上流工程に入り、プロトタイプとヒアリングを繰り返しながら抽象的な議論を具体化し、認識合わせと要件定義書の作成までを一つの流れで進めています。RFPの作成を支援してくれる会社の選び方は、RFP作成支援の記事で紹介しています。

まとめ

RFPとは、システム開発の発注者がベンダーに対して要件を伝え、具体的な提案と見積もりを依頼するための提案依頼書です。RFIで情報を集め、RFPで提案を受け、RFQで価格を確定させるという流れの中で、ベンダー選定の中心を担います。

大企業のシステム開発では、RFPは要件を正確に伝える文書であると同時に、複数の提案を公平に比較し、社内の合意形成や稟議を支える土台にもなります。プロジェクト概要、提案依頼事項、システム要件、選定の進め方という全体像を押さえたうえで、全社的な位置づけや関係部門の巻き込みを意識して作成することが、プロジェクトの成功につながります。

RFPに関するよくある質問

RFPとは簡単にいうと何ですか

RFPとは、システム開発などを外部に発注する際に、発注側の目的や要件を示して、ベンダーに提案と見積もりを依頼する文書です。日本語では提案依頼書と呼ばれ、複数のベンダーから同じ条件で提案を集めるために使われます。

RFPは誰が作成するものですか

RFPは発注側の企業が作成します。大企業では情報システム部門やDX推進部門が取りまとめ役となり、事業部門や経営層、PMOの意見を反映しながら作成するのが一般的です。

社内にノウハウが不足している場合は、外部のコンサルティング会社などの支援を受けて作成することもあります。

RFPを作らずにシステム開発を発注してもよいですか

小規模な改修や、発注先と要件がすでに明確に共有できている場合は、RFPを作らずに進めることもあります。ただし、複数のベンダーを比較したい場合や、関係部門が多く既存システムとの連携が必要な場合は、RFPを作成したほうが認識のズレやトラブルを防ぎやすくなります。

RFPと要件定義書の違いは何ですか

RFPは、ベンダーを選定するために発注側の要望や前提条件をまとめた文書です。一方の要件定義書は、発注先が決まった後に、発注側とベンダーが協力してシステムに必要な機能や仕様を詳細に確定させる文書です。

RFPに記載した要件は、その後の要件定義の出発点になります。RFPの段階で目的や課題を明確にしておくほど、要件定義もスムーズに進みます。