【サンプル付】RFPとは？テンプレートと書き方ガイドで完全解説

一般的にシステム開発の依頼を開発会社に行う際には、RFPを作成することになります。
しかし、どのようにRFPを作ればよいか分からず悩んでいる方も多いのではないでしょうか。

そこで今回は、RFPの概要やRFPを作成すべき理由に加え、RFP作成時の重要ポイントと押さえるべき項目について徹底解説していきます。

システム開発に必須なRFP（提案依頼書）とは？

RFP（提案依頼書）とは？

RFP（Request for Proposal：提案依頼書）とは、発注側が開発会社に対して提案して欲しいことをまとめた文書のことです。
RFPという形で要望や依頼事項を整理して記載することで、各社共通の条件で提案書と見積を取得できます。これにより、提案内容の比較検討もしやすくなります。

RFP（提案依頼書）の目的

RFPは、自社の要件にあった提案を受けることを目的としています。
前述のとおり、RFPとは提案してほしいことをまとめた文書です。
提案に必要な情報をあらかじめ提出しておくことで、自社で欲している内容で提案してもらえることができ、その提案内容を基に候補先の評価や比較がしやすくなります。

一方で、RFPを作成しないと提案依頼先により提案範囲や見積条件がバラバラとなります。
これでは、各社を平等に比較することは難しいです。
さらに、こちらの依頼内容が正確に伝わらず納品物が想定外のものとなってしまうリスクや、要望が伝えきれず漏れてしまうといった問題も生じます。

このような事態を防ぎ、最適な委託先を選定してプロジェクトを成功させるためにも、RFPが必要となります。

RFI（情報提供依頼書）との違い

RFI（情報提供依頼書）は、しばしばRFPと混同されることがありますが、両者は異なるものです。

RFPとの違いは、目的や利用されるフェーズが異なる点にあります。
RFIは、日本語では情報提供依頼書と呼ばれています。
提案を依頼する前の段階で候補先に問い合わせをする際に、システム開発の目的や要求事項を説明したうえで、対応可否や各社の技術力などに関する情報を提供してもらうための文書です。

RFIの目的は、RFIによって収集する会社の情報を基に、コンペに呼ぶ会社を選定することとなります。

RFPやRFIが使用される大きな流れについては、以下のブログ記事で詳しく説明しています。

【テンプレ付】失敗しないホームページ制作会社の選び方 比較ポイントと流れを徹底解説

要件定義書との違い

要件定義書とRFP（提案依頼書）の違いは、文書の作成者と利用されるフェーズが異なる点にあります。

要件定義書は、発注側ではなく開発側となるパートナーや開発会社が作成します。
この文書は、成果物に関して、現状の課題やプロジェクトの目的、要件、詳細な条件、対応内容などを文書化したもので、開発側が発注側とプロジェクトについての理解を合わせることを目的としています。
発注側の要望を正しく理解し、要件を文書に落とし込むことは、発注側の要望を開発側社内で認識を併せることができるほか、発注側と開発側の認識の齟齬や曖昧さをなくすことにつながります。

また、要件定義書の制作は、開発側が独自の視点で進行してしまい結果的に発注側の要望を適切に反映できていない、といった事態を回避することができます。
要件定義書より前段階でRFPのやり取りが行われることで、パートナーや開発会社はRFPを参考に要件定義書を制作できるため、意思疎通がスムーズとなりスピーディな進行を実現できます。

RFP作成前に押さえるべき5つのポイント

RFP作成には事前の準備が肝要です。
以下では、PFP作成に入る前に確認すべき5つのポイントを紹介します。

①目的の明確化

RFPを作成するためには、ビジネス要件を明確にする必要があります。
ビジネス要件とは、プロジェクト実施の目的や背景、予算やスケジュール等のことを指します。
この中でも、目的を明確にすることは最も重要です。
よくあるシステム開発の目的としては、「業務効率化」「新事業参入」「リスク削減」などが挙げられます。

目的を明確化することは、プロジェクト進行中に起こりがちな「手段の目的化」を防ぐことにもつながります。
よくあるのが、プロジェクトが進行するにつれてシステムの導入自体が目的にすり替わってしまうケースです。
あくまでもシステムは手段にすぎません。
システム導入によって何を実現したいのか、目的を明確化したうえでプロジェクト中に方向性をブレさせないことが重要です。

②システムの提供価値の定義

システムを構築する上では、ユーザーに対してどのような価値を提供する成果物なのか定義するべきです。
上述で記載した「目的」を実現するためには、システムで具体的にどのような価値を提供しなければならないのかを整理しましょう。
その際、ビジネスの全体像においてシステムがどのような役割を果たし、何に貢献するものなのかという観点が重要です。
具体的な例としては以下の通りです。

＜提供価値の具体例＞

• ユーザーが欲している情報に素早くたどり着ける
• ユーザーが欲しい製品をわかりやすいUIによって直感的に探せる
• 100件の大量作業をすぐに完了できる

提供価値は必ずしも一つに限定する必要はありません。
ここで定めた提供価値が具体的な要件を洗い出す際の指針となるため、RFP作成においては重要なポイントといえます。

③制約条件の確認

ビジネス要件を整理する上では、事前にプロジェクトの制約事項を確認しておかなければなりません。
どのようなプロジェクトでも確実に抑えておくべき制約条件は「予算」「スケジュール」の2つです。
予算とスケジュールによって、実施できるプロジェクト規模が決まります。

スケジュールの設定においては、システム開発後に必要となる作業期間も考慮しましょう。
社内での受入テストや運用体制の構築、社外向けシステムであればプレスリリースの準備など、様々なタスクが発生します。
これらのタスクに必要な期間も考慮して、最終的な期限に間に合うようにシステムの完成期限を設定します。
スケジュール期限は各社が依頼を受けられるかどうかを判断する重要な情報となりますので、プロジェクトの途中で変更することがないように注意深く設定しなければなりません。

④構築後の運用設計

上述したとおり、プロジェクトにおける「手段の目的化」は陥りやすいリスクとなっています。

たとえば、システムの開発が進むにつれて、単純な見た目など目的を達成するために無関係な要素へのこだわりが強くなり 、運用に影響するというような事態も起きがちです。
そうならないためにも、制作後どのように運用していくのかをRFP作成前に明確化します。
もし明確化が難しい場合、開発会社に必要な運用体制についても提案してもらうことも有効です。

⑤選定基準のすり合わせ

最後に、委託先の選定基準について社内で認識合わせをしておきましょう。
選定基準を明確化しておくことで、選定時に論点が分散することを避けられます。

選定基準は会社事情やプロジェクトの目的から掘り下げて決定することが一般的です。
たとえば、以下のような観点のうちどれを重要視するかを検討します。

＜評価項目の例＞

• ビジネス理解
• 提案力
• 機能要件の充足度合い
• エンジニアリング力
• デザイン力
• 実績（自社と同規模または大手企業の実績、同業種の実績 ）
• コミュニケーション体制
• 価格

委託先の決定方法は様々ですが、観点ごとに採点形式で決める方法もあります。
その場合、重要視する観点を高めに配点し、そうではない要素を低めに設定する方法も一案です。

自社にあった選定基準を設定し、定量的に判断できる準備を整えましょう。

RFPで絶対におさえるべき項目15選。テンプレートでサンプル例を参照しながら確認しよう

ここでは、実際にRFPを制作するにあたり絶対に押さえるべき15の項目をご紹介します。
ぜひ以下から RFP のテンプレートをダウンロードし、サンプル例を参照しながらポイントを確認してみてください。

プロジェクト概要

RFPにまず必要なのが、プロジェクトの概要です。
システム開発の目的をより深く理解してもらうためには、プロジェクトの背景や目的について提案依頼先に理解してもらうことが大切です。

１．表紙・表題

最初に目にする表紙・冒頭には、RFPの件名が分かるように「〇〇プロジェクト提案依頼書」といった表題を付けましょう。
加えて会社名及び担当者名も記載し、連絡先も明確にします。

以降は、簡単な概要説明を兼ねたあいさつ文を記載します。
詳細については後ほど伝えるため、冒頭では今回の依頼の全体像を簡潔にまとめましょう。

２．背景・目的・課題・ゴール

今回の依頼に至る背景や自社が抱えている課題について記載します。

プロジェクトを実施する理由となるのが背景であり、プロジェクトの目的を達成するために解決が必要となるのが課題です。
これらを提案依頼先に理解してもらうことで、より自社にニーズに沿った提案となることが期待できます。

事業・組織の問題意識や環境の変化に伴う改善ニーズなど、認識している課題についてはできるだけ幅広く言及しましょう。
課題が複数ある場合、省略する必要はありません。
複数の課題は箇条書きや表などを利用することで伝わりやすくなります。
背景や課題で提示した内容を、プロジェクトでどう解決に導きたいのかを明記しましょう。

プロジェクト対象範囲

RFPでは、プロジェクトの対象範囲を明確にすることも必要です。
対象範囲が明確でないと、各社の提案を同じ基準で比較できません。
対象範囲を明確化するためには、同時に対象範囲外となる部分も明確にする必要があります。
さらに、必須ではないものの追加で提案してもらいたい要件がある場合は、オプション提案としてまとめます。

３．現行システム・新システムの範囲

まず、今回の提案依頼の対象範囲を具体的に明示します。
現行システムがある場合は、現行システムの概要をAs-Isとして、また新システムの範囲についてTo-Beとして記載します。

これらは図として示すとわかりやすいでしょう。赤枠などでシステムの対象範囲を明確化することで、誰が読んでも対象範囲が分かりやすくなります。

４．利用ユーザー

システムの利用者について記載します。
各利用者がどのようなユースケースでシステムを利用するか、また各利用者の人数はどの程度であるかを記載することで、利用者ごとのシステムの使い方と利用規模が明確になります。

５．委託範囲

具体的に開発会社に委託を行いたい作業について記載します。
通常であれば、以下のとおり要件定義～リリースまでの一連の作業を委託することとなりますが、例えば「ユーザー教育も行ってほしい」「運用設計もサポートしてほしい」などの要望があれば追記します。

＜記載項目の例＞

• 要件定義
• 設計・開発
• テスト
• データ移行
• リリース
• セキュリティ対策
• 運用保守・アフターサポート
• 必要に応じた改善施策の提案・実施
• プロジェクトスケジュールの作成と管理
• プロジェクト体制の提案と構築

６．対象外範囲・特記事項

提案において対象外となる範囲も明確にしておきましょう。
自社で開発を担当したい部分がある場合や、既存システムからのデータ抽出など現行の開発会社などに委託する必要がある範囲などは、事前に対象外であることを記載します。

また、サーバーOSやミドルウェア、OSのバージョンなど、自社のインフラ環境に指定がある場合には特記事項として記載します。
今回の提案対象範囲外のシステムなどと連携する必要がある場合は、必要性を記載したうえで連携方法や条件などを提案に含めてもらうようにします。

７．オプション提案範囲

必須で対象範囲とはしないものの、追加で提案してほしい要素についてはオプション提案範囲としてまとめます。
たとえば、業務に必須ではないもののあると便利な機能については、コスト見合いで開発するか検討することもできますので、いったん提案を頂くことも検討できるでしょう。

オプション提案は各社により差が付きやすい要素といえます。
各社の力量や考え方が見える部分ですので、委託先を選定する際の一つのポイントとなるでしょう。

予算・スケジュール

提案にあたって重要なのが、予算とスケジュールです。
各社は予算とスケジュールを前提に提案可否や提案内容を検討しますので、できるだけ詳細に記載しましょう。

８．プロジェクト予算

想定予算を明記せず提案に任せるのも一案ですが、開発会社によって金額がバラバラだと同条件での比較が難しくなります。
予算の上限を設定し、各提案の条件を同じにしましょう。その際、金額だけではなく項目も明確にしておくべきです。
以下のようにイニシャルコストとランニングコストを明記してもらうことで、システムのライフサイクルコストでの評価が可能となります。

■イニシャルコスト

• アプリ開発費用
• 基盤構築費用
• ライセンス費用
• インフラ費用（ハードウェア・ソフトウェアなど）
• その他

■ランニングコスト

• 運用保守作業費用
• SaaS利用料・ライセンス保守費用
• インフラ保守費用

その一方で、予算を絶対条件にすると最小限の提案となりやすいという側面もあります。
質の良い提案を集めるためには、理由の明記を条件としたうえで、予算を超過した提案を認めることも検討しましょう。

９．プロジェクトスケジュール

プロジェクトの想定スケジュールを記載します。
いつ頃のリリースを見込んでいるのか、どのようなマイルストーンを想定しているのか、できるだけ詳しく記載しましょう。

作業項目やマイルストーンが多い場合は、横軸に時間軸、縦軸に作業項目を記載した表と矢羽根を用いてまとめると視覚的に分かりやすいでしょう。

10．選定スケジュール

提案依頼から委託先選定までのスケジュールも記載します。
提案の締め切り日だけでなく、選考日やプレゼンの日程、結果通知の日程も記載しましょう。

また、スムーズに進めるために質問受付期間や回答日を明記することをおすすめします。
これにより、提案依頼先もスケジュールを立てやすくなります。

要件

ここでは、システムを開発するにあたっての要件を提示します。
発注側が要件を明確に提示しなければ、完成形が全く希望に合っていないという事態にもなりえます。
要件は可能な限り詳細に提示することで双方のズレを防ぐことができます。

11．機能要件

まず、機能要件としてシステムに必要な機能を定義しましょう。
たとえば予算管理システムであれば、予算編成機能やモニタリング機能、マスタ管理機能などが必要です。

各社は記載内容に応じて提案を行うため、複数人で洗い出しを行うなど要件に漏れがないように気をつけてください。
もちろん、機能の詳細は委託先決定後にすり合わせが必要ですが、RFPの段階で可能な限り機能を盛り込むようにしましょう。

RFPに記載されていない機能を後から追加すると、場合によっては発注金額の増加やスケジュールの変更といった事態にもなります。
抽象的でも構わないので、まずは希望を記載することが重要です。

12．非機能要件

機能要件と同様に非機能要件も明記しましょう。
非機能要件とは機能以外のすべての要件のことであり、具体的には求めるレスポンス速度やOS・ブラウザ等の動作環境、バージョンアップ・バックアップの必要性などが挙げられます。

非機能要件は、機能要件よりも記載項目が多くなります。
提案依頼先に伝わりやすくなるように、IPA（独立行政法人情報処理推進機構）が定義する「非機能要求グレード※」に基づき、以下の項目に分けて記載することをおすすめします。

• 可用性
• 性能・拡張性
• 運用・保守性
• 可用性
• 移行性
• セキュリティ
• システム環境・エコロジー

※参考：独立行政法人情報処理推進機構「システム構築の上流工程強化（非機能要求グレード）

非機能要件を記載するためには専門的な知識が必要であるため、知識のあるメンバーや提案依頼先などに聞いてみるとよいでしょう。

納品物

ここでは、最終的な成果物となる納品物を提示します。

13．納品物

RFPには、成果物として納品してほしいものについても記載します。
システムのプログラム一式はもちろんですが、要件定義書や設計書、各種テスト結果なども納品物として指定しておくことをおすすめします。

これらの納品物を受領しておくと、将来的にシステムのリニューアルを実施する際に役に立ちます。

提案依頼内容

RFPの最後には、提案に関する必要な情報をまとめて記載します。提出物や提出期限などもここで改めて定義します。

14．提出日・提案物

下表の通り提案の提出に関する情報をまとめます。
特に、提案書のデータ形式やフォーマットを指定しておくと、選定時に比較しやすくなります。

また、提案書の内容に関しては、具体的な制作案だけでなくプロジェクトのチーム体制やスケジュールなども記載してもらいます。
その他、比較検討に必要だと思うことを盛り込みましょう。たとえば提案書のフォーマット（章立て）を決めてしまうのもひとつの方法です。

15．契約条件・対応窓口

システム開発を行うためには、委託先に自社の機密情報を開示する必要があります。
また、著作権の取り決めなども重要な観点です。これらの契約条件についてもRFPに記載します。

加えて、質問の受付先など窓口を決めたうえで、記載します。提案書と見積書の提出先を変えたいケースでは担当窓口が複数に分かれます。
それぞれの担当窓口と対応範囲を明確にしておきましょう。電話やメールといった連絡手段もあわせて記載します。

RFPの無料テンプレートをDLして、実際に制作してみよう

本記事では、システム開発のRFPとは何か、その作成目的や作成方法についてお伝えしました。

RFPを明確に作成すれば、各社からの提案はより優れたものになります。
理想のシステム開発を可能とする会社を見つけるためにも、RFPを作りこむことが重要です。

当社では、システムを開発したいと考えている方に向けて、本記事で紹介した15の観点を網羅したRFPのテンプレート（サンプル例）をご用意しています。テンプレートはこちらからダウンロードできますので、お困りの際はご利用ください。

今回の記事が少しでも、あなたのビジネスに役立てましたら幸いです。

スパイスファクトリーではユーザー起点のシステム開発やサイト制作に尽力しています。
システムを新しく構築したいけれど、どこに頼めばいいかわからないというようなお悩みがある方は、お気軽にお問い合わせください。

また、スパイスファクトリーではRFP作成サービスも承っています。RFPの作成に悩まれている方は、ぜひお気軽にお問い合わせください。

システム開発のRFPをダウンロードサイト制作のRFPをダウンロード