【テンプレートあり】RFPの作り方は？RFIや要件定義書との違いも解説

こんにちは。Wakka Inc.のテクニカルマネージャーとしてベトナム拠点で活動している鍋山です。

今回のテーマはRFPの作り方です。私自身、これまで在籍した企業でシステムやWebサイトを外注する際にはベンダーさんや広告代理店さん向けにRFPを作りオリエンテーションを行ってきました。
いまではRFPをいただいて開発する側でもあるのですが、この両方を体験してきたからこそできるRFPの作り方、そして、本記事に付録しているテンプレートを利用して書き方について解説したいと思います。

今回はシステム開発とWebサイト制作用のRFPテンプレートをご用意しておりますので、ぜひご活用ください。

株式会社Wakka Inc.

【無料】そのまま使えるRFPテンプレート｜システム開発用

株式会社Wakka Inc.

【無料】そのまま使えるRFPテンプレート｜サイトリニューアル用

システム開発を検討されている方に向けてすぐに使える『RFP（提案依頼書）テンプレート』をご用意！

編集しやすいパワーポイント形式のテンプレートなので、項目を埋めるだけで簡単にRFPが作成できます。

RFP（提案依頼書）とは

RFP（Request for Proposal）は日本語では「提案依頼書」といいます。

システム開発やWebサイトリニューアルを行う際に発注者が提案を受けるために各ベンダーや制作会社に対して発注要件や課題などを整理し作成します。

RFP活用が発展した背景

今では当たり前となったRFPですが、以前はシステム開発やWeb制作の現場で発注前のオリエンテーションを行う場合、発注側へのヒアリングからスタートし、単に口頭での要望確認や仕様確認のみで提案までを行うことがほとんどでした。

しかし、これでは発注をする側、される側どちらも認識のズレが発生することが多く、さらに複数ベンダーでのコンペを行う場合には、情報格差から提案の方向性のブレが多く発生していました。
これらを解決し、最適な提案を受けるために利用されているのがRFPです。

RFP作成の目的

RFPを用意することで、認識のズレやベンダーへの情報格差を防ぐことができます。
さらに、これにより社内の認識やプロジェクトへの取り組み方がより前向きなものへと変化します。

そもそも、Webサイト構築やシステム開発といったプロジェクトでは、多部署間でのコミュニケーションはもちろんのこと、それぞれの部署によって期待する事象や懸念点などがバラバラです。
こうしたさまざまな社内課題や目標を一定の認識に合わせておくために、事前にRFPを作成しておくことは有意義です。

RFPと要件定義書の違い

RFP（提案依頼書）は、システム開発やソフトウェア開発などを依頼する担当者が、開発企業に対して具体的な提案を依頼するための文書です。

対して要件定義書とは、依頼者がどのようなシステムやソフトウェアの開発を望んでいるか、要件や要望を明確化するために開発企業が作成します。
現状の課題を把握し目的達成に向けた内容を明確化するための文書で、業務の成果物として要件定義書を納品します。

要件定義の目的は、依頼者と開発者間での認識を共有するためであり、認識の相違によるミスやエラーを防止することも目的の1つです。

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

RFPと似ている言葉に、RFIがあります。
RFIは「Request For Information」の略で情報提供依頼書を意味します。

RFIはRFPと違い候補となるベンダーから提案をもらうためのものではなく、ベンダーの企業情報やサービス情報などを提供してもらうための依頼フォーマットです。
この情報を利用して提案依頼を行うベンダーを選定したり、提案依頼書を作成するための材料にすることもあります。

RFIの内容は「RFIの目的」から始まり、該当ベンダーの会社情報、候補となるITサービスやパッケージの仕様、実績例、サービス価格などを含みます。
これらのベンダー企業に関する情報を収集することで、依頼する側はベンダーやサービスの選定をより効率的に行えます。

RFPの作り方

RFPの作り方は、次の通りです。

• プロジェクトのチームを編成する
• プロジェクトの目的を明確化する
• スケジュールの立案を行う
• 現状や現行システムの課題を洗い出す
• システムの要件を定義する
• 提案書の評価基準を明確にする
• RFPの形式にまとめる
• システムの要件を定義する
• 関係者とレビューを実施する

上記の手順を踏むことで、スムーズにRFPを作成できます。それぞれの手順を確認して、RFPを作成しましょう。

プロジェクトのチームを編成する

前述した利害関係者の整理として、プロジェクトを進めるチーム編成を行うことが、最初のステップです。
構築するシステムやWebサイトによって編成するメンバーは変わるはずですが、まずはこのプロジェクトのトップとなるオーナーを設定しましょう。

プロジェクトのオーナーには、通常、予算やスケジュールの決裁権を持つ役員や執行責任者クラスが選任されます。その後、PMやPLなどの役割を設定しましょう。
さらに、マーケティング、PR、情報システム部門など、必要な役割に応じてメンバーをアサインしてください。

プロジェクトの目的を明確化する

次に、開発の目的を明確にします。
RFPの作成段階でも対ベンダーに目的を共有していきますが、事前準備での目的作成は、社内での共通の目的を設定しておくことを意味しています。

目的は社の理念やビジョンから連動し各部署が共通で認識するようなものから、特定の業務に対してフォーカスした目的を設定するパターンなど、その時の状況や会社の状態によってさまざまなものがあります。
関係者全員で認識できる目的を設定し、それをしっかりと共有して共通の目的としておきましょう。

スケジュールの立案を行う

スケジュールについても、RFPの作成段階でベンダー向けのスケジュールを共有しましょう。
事前準備でのスケジュール立案には、プロジェクトの準備や関係各所との調整などを含めて、あらかじめ作成しておくことが重要です。

開発完了後の運用や、社内でのフィードバック・評価まで想定しておくと、よりスムーズに進行できます。

現状や現行システムの課題を洗い出す

現状や現行システムの課題を洗い出すことで、RFPをスムーズに作成できます。

RFPは、依頼者が現状の課題や現行システムの課題を解消するために、新システムの開発を依頼する目的で作成するものです。
現状の課題を洗い出すには、現場で改善したい内容と、現行システムにはないが欲しているシステムを把握する必要があります。

具体的には、現場の従業員にヒアリングやアンケートを実施することで、改善するポイントを可視化できます。

システムの要件を定義する

現状の課題を可視化した後は、開発するシステムの要件を定義しましょう。
どのような機能や仕様を備えたシステムが必要か、要件を定義することでRFPを作成できます。

RFPは、開発側に依頼者が求める要件を伝える文書なので、必要な機能や予算をまとめておく必要があります。
システムの要件を定義した上で、RFPの作成に取り掛かりましょう。

提案書の評価基準を明確にする

RFPを作成する際には、提案書の評価基準を明確にする必要があります。
評価基準を決める際は、次の項目を用意しておきましょう。

• 企業の評価項目
• 提案に対する評価項目
• システムの機能に関する評価項目
• コスト面での評価項目

上記の評価項目を設けることで、複数の開発企業にシステム開発を依頼した際に、選ぶべき最適な企業を見極められます。
複数の開発企業を比較検討するために、提案書の評価基準を設定しておきましょう。

RFPの形式にまとめる

RFPを作成する際は、RFPの形式にまとめることが大切です。
依頼したいシステム開発の要件や予算を提示するだけでなく、RFPを構成する形式にまとめて、読み手に分かりやすく要件を伝えましょう。

RFPの形式として、次のような構成が効果的です。

開発側に依頼内容を正確に伝えるために、RFPの要件を形式にまとめましょう。

関係者とレビューを実施する

RFPを作成する際は、関係者とレビューを実施することが大切です。
システムの要件に不満があるか、事前に関係者からレビューを実施することで、RFPを提出する前に確認できます。

膨大な時間を費やした上で、RFPを作り直すには手間と労力がかかるため、関係者のレビューを確認しておくことが大切です。
レビューを実施せずにRFPを提出すると、関係者からの信頼を失い、今後の協力体制に影響を及ぼす可能性があります。

円滑な関係を継続し、スケジュールの遅延を防止するために、RFPのレビューを実施しましょう。

システム開発を検討されている方に向けてすぐに使える『RFP（提案依頼書）テンプレート』をご用意！

編集しやすいパワーポイント形式のテンプレートなので、項目を埋めるだけで簡単にRFPが作成できます。

RFPに書くべきプロジェクト情報

チームでの合意が完了したら実際にRFPをつくっていきます。RFPに書くべきプロジェクト情報は主に次の通りです。

・プロジェクト概要
・プロジェクトの背景と目的
・ターゲットとするユーザーの確認
・課題
・競合
・スケジュール
・システム、Webサイトの構造
・現在の体制や運用工程

上記の情報を押さえて、より最適な提案をもらえるRFPを作成していきましょう。

プロジェクト概要

概要の頭には、社内決定している以下の概要情報を記載します。

・プロジェクト名
・対象システム、対象サイト
・リリース予定日
・予算範囲

ここでのポイントは、パッと見て把握しやすいレイアウトを心がけることです。
プロジェクト名は意外と後回しにしがちですが、多部署間における共通名称として設定し、疑似名称と判別しやすくする目的もあります。できる限り名称を決定しておきましょう。

概要における小項目は以下で説明します。

プロジェクトの背景と目的

プロジェクトの背景と目的を記載することは重要です。
関係者全員が、なぜこのプロジェクトを行うことになったのか、その経緯を理解する上で有効だからです。

この情報があると、目的達成に向けた適切な提案を受けやすくなります。さらに、プロジェクトの本来の意図から外れることなく、各社からの提案を評価できます。

また、長期プロジェクトでは、時間の経過とともに当初の目的を見失いがちです。
特に、多くの利害関係者が関与する場合は、目的がぶれてしまいやすいものです。

RFPでプロジェクトの背景と目的を明確にし、ベンダー側と発注側の双方が一貫性を保ちつつ、スムーズな進行ができるように準備しましょう。

ターゲットとするユーザーの確認

システムを使うユーザー、又はWebサイトを利用するユーザーを想定しておきましょう。

どの職種のどのような人が使うシステム（Webサイト）なのか、どの年代のどのようなフェーズにいるユーザーなのか、といった内容が重要です。
これらはシステムやWebサイトの機能だけではなく、UI/UXや、コンテンツ内容を決定するために必要となる大事な情報です。

この前提条件を正確にしておけば、できあがるものが大きく変化します。
ターゲットを決める際に、これまでのデータやマーケティングにおける仮説が必要になるような場合は、慎重に決定しましょう。

課題

課題はRFPにおいて重要な要素のひとつです。
現在のシステムやWebサイトにおける課題を記載しましょう。

RFPでは大きなカテゴリとして課題の概要を記載して、それぞれの業務やシステム上、Webサイト上の課題詳細についてはスプレッドシートなどの別紙で作成しても構いません。
できるだけ分かりやすく、簡潔に記載するように注意してください。

また、課題解決がプロジェクトの目的に合致することも重要です。
目的から課題解決まで一連の流れがロジカルになっているかもしっかり確認していきましょう。

競合

主にWebサイトリニューアル時や、マーケティングを伴うプロジェクトの際に記載することが多い項目です。
自社サービスや製品と競合となる企業のWebサイトやシステムについて、なぜ競合となるのかを記載しましょう。

システムやWebサイトの構築において、競合比較には多角的な視点が必要です。
ベンダーへの伝達時は、特に重要な項目に焦点を当てて記載しましょう。
これにより、ベンダーのプレゼンテーションが適切な情報収集と課題解決の提案を含んでいるかを評価できます。

スケジュール

スケジュールには、ベンダーや制作会社へのRFP公開から、発注決定、開発、リリースまでの想定スケジュールを記載しましょう。

一般的に開発規模が大きければ当然工数がかかるため、スケジュールは余裕をもったものにしなければなりません。
この時点で想定とズレがある場合は、ベンダー側からも指摘があることが一般的です。

また、RFP公開から提案までのリードタイムが短い場合は、提案にかける工数が少なくなることや、コンペにかかるコストを圧縮するために各ベンダーの提案が薄くなることがあります。
この点には注意が必要で、事前に社内の利害関係者としっかりスケジュール調整しておくことが重要です。

システムやWebサイトの構造

システムやWebサイトの構造は、システムのリプレイスや、Webサイトのリニューアルを行う際に記載することが多い項目です。

既存のシステムにおける基本構造や、Webサイトのサイトマップ（機能をあわせた）などを記載することによって、各ベンダーや制作会社が現状把握を構造的に行うことが可能です。
あるいは、簡易的なものをRFPで提供しておいて、開発前には別途詳細の構造を提出することもあります。

近年のプロジェクトでは、SaaSや他システムとのAPI連携が増加しています。
外部システムとの連携が前提となる場合は、工数の変更や設計への組み込みが必要です。

RFP作成時点で連携が判明している場合は、これらの情報も含めておくと有益です。
システム構成図については、既存ベンダーから提供されたドキュメントや社内で日常的に使用しているものがあれば活用できます。
そうでない場合でも、担当者やチームで現状を確認できるため、可能であれば作成しましょう。

現在の体制や運用工程

構造と同様に、現状のシステムやWebサイトを運用しているチーム体制や運用フローを記載しておきましょう。
これらを共有することで、提案の中で新たに運用の役割が必要になる場合に、どのようなフローで行うかをベンダー側で提案できる可能性があります。

また、現在のチームを維持する前提で提案作成できる場合もあるので、しっかりと現状を共有しましょう。

RFPに書くべき要件

RFPに書くべき要件は、次の通りです。

• 依頼範囲
• 納品物
• 保守要件
• プロジェクト体制
• 費用
• 契約、支払方法

これまでのチーム編成や、プロジェクト概要の合意、RFPへの記載をしっかり行った上で、初めて要件の記載をしていくのが重要です。
前提条件が変わってくれば、要件に対する提案の方向性や深さなどが変わってくるからです。

なお、われわれベンダー側では、受注後にRFPやヒアリングで得たプロジェクト概要やクライアント企業のチーム編成を、プロジェクトに関わるすべてのSE・プログラマー・デザイナーと共有します。
これらは、すべての関係者が同じ視点でプロジェクトに取り組むためです。ゆえに、要件を伝える前段階の情報も重要といえます。

依頼範囲

ここでは提案を依頼したい範囲を明確にしておきます。

例えば、Webサイトリニューアルであれば、大きなカテゴリでも戦略設計、UI設計、デザイン、コーディング、開発、テストなど工程が分かれます。
システムも同様ですが、大枠の開発とは別に、サーバーの設定や設置や、店舗であればPOSシステムの導入など、プロジェクトによって必要になる提案は多岐にわたります。

システムやWebサイト納入後の運用面でも、必要な提案があれば記述しましょう。

納品物

納品してもらいたい納品物一覧を記載します。

システムであればソースコードは当然ですが、要件定義書や設計書などのドキュメントが必要かどうかで大きく工数も変わってきます。
今後の運用面も考慮した納品物を記載するように心がけてください。

また、ドキュメントは各社でレベル感が違う場合があるので、事前にドキュメントのサンプルを入手しておくのがおすすめです。
もし納品物について判断ができない場合は、各ベンダーや制作会社に納品物を明示してもらうことで選定のポイントにすることもできます。

保守要件

システムやWebサイトの納入後、運用にかかわる要件を記載します。Webサイトであれば更新範囲や頻度などを伝えます。
システムも同じように、今後の運用における機能拡張の計画や、ベンダー側で確保しておいてほしい工数・人員を事前に決定しておくとスムーズです。

また、サーバーなどのインフラ関連費用や保守内容も忘れてはなりません。
サーバーの死活監視やアクセス増大時のトラブル対応など、必要になりそうな要件や既存のアクセス解析情報などを記載しましょう。

プロジェクト体制

ここでのプロジェクト体制は、ベンダーや制作会社側の体制を指すものです。
単にプロジェクト体制の明示を求めるのではなく、どのような情報を提案時に提出してほしいかを明確にしておくことで、選定や比較材料のひとつとします。

当然ながら、ベンダー側は人員選定が未確定の場合もあります。
そのような場合は、候補として挙がるプロジェクトマネージャーやメンバーの情報を提示してもらいましょう。
プロジェクト体制で記載してもらう情報として、メンバーの経歴や最低限のスキルセットが分かるように記載してもらうと、比較時の良い材料となり役立ちます。

費用

ここでの費用は、ベンダーや制作会社の提案時に提出してもらう費用についてです。
冒頭で発注者側が提示する予算とは別のものです。

費用については、プロジェクトの規模によって正確に記載できる場合とそうでない場合があります。
いずれも構築時の費用と保守費用で、あらかじめわけて提出してもらうようにRFPに記載してください。

また、RFP概要で記載した予算を超える費用提示がある場合には、その裏付けが提案内に存在するかどうかも選定ポイントとなり得ます。

契約、支払方法

最後に契約と支払方法について提示してもらうように記述しましょう。
大型のプロジェクトになればなるほど契約条項の精査が当然ながら重要となります。

システム開発における契約形態には請負契約や準委任型契約があります。それぞれメリデメがあるのでプロジェクト内容にあわせて選択しましょう。

また、契約でのチェックポイントとして瑕疵担保期間などがあります。
ベンダーによって担保期間が違ったりすることもありますし、契約条項中にあきらかに不利な条件がある場合は提案時から交渉をしていきます。

支払条件についても自社の支払いフローや支払サイトにマッチするかをよくチェックするようにしてください。

【無料ダウンロード可能】Wakka Inc.のRFPテンプレート

Wakka Inc.ではこの記事の内容に沿ったページ構成で、システム開発用RFPテンプレートと、Web制作用RFPテンプレートの2種類のRFPをご用意しています。

これらを利用することでRFP作成の時間短縮はもちろんのこと、設定項目の漏れを防止したり、自社のフォーマットに置き換えたりといった活用が可能です。
PowerPoint形式で配布していますので、ぜひご利用ください。

システム開発用RFPテンプレート

Wakka Inc.は、システム開発を検討されている方向けに、「RFP（提案依頼書）テンプレート」を用意しています。
編集しやすいPowerPoint形式のテンプレートなので、項目を埋めるだけで簡単にRFPが作成できます。

主に、次のような方におすすめです。

• システム開発の流れについて知りたい方
• 外部の開発会社からシステム開発の提案、見積りが欲しい方
• RFP（提案依頼書）を作成する時間がない方

RFPのPowerPointテンプレートを利用すれば、RFP作成の手間を軽減できます。
システム開発用のRFPを作成する際には、Wakka Inc.のPowerPointテンプレートを活用しましょう。

株式会社Wakka Inc.

【無料】そのまま使えるRFPテンプレート｜システム開発用

Webサイトリニューアル用RFPテンプレート

Wakka Inc.は、企業のサイトリニューアルを検討中の方向けに、「RFP（提案依頼書）テンプレート」を用意しています。
Webサイト制作用RFPテンプレートを利用すれば、ビジネスニーズやマーケティング課題など開発背景を明確化し、より良い提案を受けるRFPを作成できます。

Wakka Inc.のWebサイトリニューアル用RFPテンプレートは、主に次のような方におすすめです。

• サイトリニューアルの流れについて知りたい方
• 制作会社からサイトリニューアルの提案、見積りが欲しい方
• RFP（提案依頼書）を作成する時間がない方

Webサイト制作用RFPテンプレートを活用すれば、Webサイト制作やサイト改善を効率的に進められます。
詳しくは、下記よりテンプレートをダウンロードできるので、RFPを作成する際の参考としてご請求ください。

株式会社Wakka Inc.

【無料】そのまま使えるRFPテンプレート｜サイトリニューアル用

RFP作成のポイント

RFPを作成する際は、次のポイントを押さえておきましょう。

• 具体的な数値や例を用いて記述する
• 曖昧な表現を避ける
• 専門用語は補足説明を加える

それぞれのポイントを押さえて、RFPで開発企業に要件や現状の課題を共有しましょう。

曖昧な表現ではなく具体的な数値や例を用いる

RFPは具体的な数値や例を用いて記述し、曖昧さを排除することが重要です。

システム開発を依頼する際には、曖昧な表現や抽象的な希望ではなく、「何をどのように改善したいか」「どの程度の数値を求めるか」といった具体的な情報を伝える必要があります。
RFPにはできるだけ数値や例を用い、読み手が要望を容易に理解できるよう内容を明確にしましょう。

例えば、「営業課の6名が使用予定」「5,000万円を上限予算とする」のように、明記すると開発企業が正確なイメージをつかみやすくなります。

曖昧な表現では、開発企業に依頼内容が正確に伝わらず、期待通りの成果物が得られない可能性があります。
システム開発の要件や課題を伝えるために、誰が読んでも用途や要望が明確に伝わる内容にすることが大切です。

専門用語は補足説明を加える

専門用語は、知識がない方が呼んだ場合に意味が伝わらない可能性があります。

RFPは、誰が読んでも正確に意味が伝わるよう工夫する必要があるため、専門用語を記述する際は補足説明を加えましょう。

できるだけ専門用語を使用せず、読み手を選ばずにシステム開発を依頼できるようRFPを作成してください。

RFP作成後の流れ

RFP作成後の流れは、次の通りです。

1. 開発会社（ベンダー）の選定
2. ベンダー評価のための準備
3. オリエンテーションの開催
4. 評価と発注（契約）

それぞれの手順を確認して、RFP制作をスムーズに進めましょう。

開発会社（ベンダー）の選定

RFIを元に、ベンダー候補からオリエンテーションを行うベンダーを絞ります。
候補ベンダーから得た会社情報やサービス、パッケージ仕様、又は同行の実績例といった情報から、RFPに沿うベンダーを絞り込みましょう。

候補社数はできるだけ少なくしておくと、選定負荷が高くなりすぎず、ベンダー側からも良い提案が引き出しやすくなります。
RFIやRFPはそのための存在でもあります。

ベンダー評価のための準備

RFPをもとに各ベンダーや制作会社から提案やプレゼンがなされます。
このときに、どのように各社を評価していくかを事前に準備しておくことで、スムーズな選定が可能です。

評価をする際には、大きく4つのカテゴリに評価項目を分類します。

1.　提案内容についての評価
2.　提案してきた会社についての評価
3.　提案してきた会社のメンバーや窓口担当者についての評価
4.　契約、支払条件についての評価

もっとも重要なのはRFPをもとに行われた提案内容ですが、その他にも社としての実績やメンバーの経歴、さらには担当者のコミュニケーションスキルなどを評価するようにします。
評点も重要度に応じて配点し設定をしておくことで、各社の総合点をできるだけ平等にバランス良く評価し選定できるように準備しておきましょう。

オリエンテーションの開催

オリエンテーションでは、RFPを提示しその内容に沿って詳細をベンダーに説明します。
ベンダーからの質疑応答や、オリエンで生まれたあらたな要件やアイデアなどはしっかりと保存しましょう。

また、それらを各候補ベンダーへ情報共有していくルールも大切です。
ベンダー間での情報格差が生まれ、正しい評価ができなくなるケースに注意してください。

評価と発注（契約）

オリエンテーションが終わり、提案内容が出揃ったら各ベンダーの評価に移ります。
事前準備で前述した評価ポイントをもとに採点し、発注の旨を該当ベンダーへ通知しましょう。

契約内容もベンダー評価の一部です。
契約における納品物や瑕疵担保（請負契約であれば）、支払フローといったポイントもチェックして契約締結まで気を抜かず進めましょう。

RFPの作り方を理解しよう

ここまでは、成果を出すためのRFPのポイントについて解説してきました。

コンペを行う場合、きちんとしたRFPが存在しないとベンダーや制作会社側でも契約までにかかるコストが増大し、商談前半で離脱していくことも少なくありません。
また、単純に複数社を比較すれば、良いベンダーや制作会社に巡り会えるわけではありません。

最適な提案を高いクオリティで提出してもらうためには、発注者側の努力や準備も重要です。
大きなプロジェクトになればなるほど、伴走するパートナーを選定するには労力を惜しまずかけ、社内のチームをしっかりと取りまとめましょう。
コンペや相見積もりではない場合でも、しっかりとRFPを作成しておくことでプロジェクトの円滑な運用が可能です。

ぜひ、本記事やテンプレートを参照してRFPを作成してみましょう。

システム開発を検討されている方に向けてすぐに使える『RFP（提案依頼書）テンプレート』をご用意！

編集しやすいパワーポイント形式のテンプレートなので、項目を埋めるだけで簡単にRFPが作成できます。