こんにちは。Wakka Inc.のテクニカルマネージャーとしてベトナム拠点で活動している鍋山です。
今回のテーマはRFPです。私自身、これまで在籍した企業でシステムやWebサイトを外注する際にはベンダーさんや広告代理店さん向けにRFPを作りオリエンテーションを行ってきました。
いまではRFPをいただいて開発する側でもあるのですが、この両方を体験してきたからこそできる「成果の出るRFP」の作り方、として、本記事に付録しているテンプレートを利用して書き方の記事を書いていこうと思います。

ということで、今回はシステム開発とWebサイト制作用のRFPテンプレートをご用意しております。
こちらからダウンロードしていただき、記事内容とともにご活用ください。

株式会社Wakka Inc.

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

株式会社Wakka Inc.

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

RFPとは

RFP(Request for Proposal)は日本語では「提案依頼書」となります。
システム開発やWebサイトリニューアルを行う際に発注者が提案を受けるために各ベンダーや制作会社に対して発注要件や課題などを整理し作成します。

RFP活用が発展した背景

いまでは当たり前となったRFPですが、以前はシステム開発やWeb制作の現場で発注前のオリエンテーションを行う場合、発注側へのヒアリングからスタートし、単に口頭での要望確認や仕様確認のみで提案までを行うことがほとんどでした。
しかしこれでは発注をする側、される側どちらも認識のズレが発生することが多く、さらに複数ベンダーでのコンペを行う場合には、情報格差から提案の方向性のブレが多く発生していました。
これらを解決し、最適な提案を受けるために利用されているのがRFPです。

RFP作成の意味

RFPを用意することで認識ズレやベンダーへの情報格差を生まないようにすることができるわけですが、さらに社内の認識やプロジェクトに対する向き合い方がよりポジティブなものになります。
そもそも、Webサイト構築やシステム開発といったプロジェクトでは、多部署間でのコミュニケーションはもちろんのこと、それぞれの部署によって期待する事象や懸念点などがバラバラです。
こうしたさまざまな社内課題や目標を一定の認識にあわせておくために、事前にRFPを作成しておくことは大変有意義です。

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

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

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

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

RFPの基本構成

チームでの合意が完了したら実際にRFPをつくっていきます。RFPの一般的な構成としては以下の大きく3つです。

・全体を把握してもらうためのプロジェクト概要
・提案を引き出すための要件
・他、補足情報

この3つに紐づく小項目を網羅することで、より最適な提案をもらえるようにRFPを作成していきましょう。

プロジェクト概要

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

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

パッと見て把握しやすいレイアウトにしておくと良いでしょう。プロジェクト名は意外と後回しにしがちですが、多部署間における共通名称として設定し、疑似名称と判別しやすくする目的もあります。必ず名称を決定しておきましょう。
概要における小項目は以下にて説明していきます。

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

今回のプロジェクトにおける背景と目的を記載します。
なぜ、どういった経緯で今回のプロジェクトを行うことになったかを把握してもらうことで、目的を達成できる提案をもらいやすくなるのはもちろん、当初の趣旨からズレることなく各社の提案を受け取ることができます。
また、発注側もオリエンからはじまり長くプロジェクトを推進していると、目的を見失った行動を取ることがあったり、利害関係者多数存在すると目的がブレがちです。これらをベンダー側・発注側双方で抑止することが可能になります。

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

システムを使うユーザー、またはWebサイトを利用するユーザーを想定しておきます。
どの職種のどんな人が使うシステム(Webサイト)なのか。どの年代のどういったフェーズにいるユーザーなのか。
これらはシステムやWebサイトの機能だけではなく、UI/UXや、コンテンツ内容を決定するために必要となる大事な情報です。
この前提条件を間違うだけで出来上がるものが大きく変化します。ターゲットを決める際にこれまでのデータやマーケティングにおける仮説が必要になるような場合は慎重に決定しましょう。

課題

課題はRFPにおいて非常に重要な要素のひとつです。
現在のシステムやWebサイトにおける課題を記載します。RFPでは大きなカテゴリとして課題の概要を記載して、それぞれの業務やシステム上、Webサイト上の課題詳細についてはスプレッドシートなどの別紙で作成しても構いません。できるだけわかりやすく、簡潔に記載するように注意してください。また、課題解決がプロジェクトの目的に合致することも重要です。目的から課題解決まで一連の流れがロジックに叶っているかもしっかり確認していきましょう。

競合

主にWebサイトリニューアル時やマーケティングをともなうプロジェクトの際に記載することが多い項目です。自社サービスや製品と競合となる企業のWebサイトやシステムについて、なぜ競合となるのかを記載します。構築するシステムやWebサイトによって競合比較する場合にはさまざまな角度が存在すると思います。ベンダーに伝達する場合は特に重要視する項目を中心に記載してください。
これらの情報をもとにしてベンダーのプレゼンで情報収集や課題解決の提案がなされているかを確認することができます。

スケジュール

スケジュールには、ベンダーや制作会社へのRFP公開から、発注決定、開発、リリースまでの想定スケジュールを記載します。
一般的に開発規模が大きければ当然工数がかかりますので、スケジュールは余裕をもったものにしなければならず、この時点で想定とズレがある場合はベンダー側からも指摘があることが多いです。
また、RFP公開から提案までのリードタイムが短い場合は、提案にかける工数が少なくなることや、コンペにかかるコストを圧縮するために各ベンダーの提案が薄くなることがあります。この点には注意が必要で、事前に社内の利害関係者としっかりスケジュール調整しておくことが重要です。

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

システムのリプレイスや、Webサイトのリニューアルを行う際に記載することが多い項目です。
既存のシステムにおける基本構造やWebサイトのサイトマップ(機能をあわせた)などを記載することによって、各ベンダーや制作会社が現状把握を構造的に行うことが可能になります。簡易的なものをRFPで提供しておいて、開発前には別途詳細の構造を提出することもあります。
最近のプロジェクトでは、SaaSや他システムとのAPI連携も多くみられるようになってきました。外部システムとの連携が前提になる場合など、工数が変わってきたり設計に盛り込むことが必要になってきますのでRFP制作の時点でわかっている場合はこちらも内容に盛り込んでおくと便利です。
構成図などは既存のベンダーから納品されたドキュメントや、普段から社内で利用するようなものがあれば良いですが、無い場合でも担当者やチームでの現状確認ができるので余裕があればぜひ作成をしてみてください。

現在の体制や運用工程

構造と同様に、現状のシステムやWebサイトを運用しているチーム体制や運用フローを記載しておきます。これを共有することで、提案の中であらたに運用の役割が必要になる場合どういったフローで行うかをベンダー側で提案できる場合があります。
また、現在のチームを維持する前提で提案作成できる場合もあるので、しっかりと現状を共有してください。

要件

さて、次は2つめの大きなカテゴリである、要件について記載していきます。
これまでのチーム編成や、プロジェクト概要の合意、RFPへの記載をしっかり行ったうえではじめて要件の記載をしていくのが重要です。前提条件が変わってくれば要件に対する提案の方向性や深さなどが変わってくるためです。
余談ではありますが、われわれベンダー側では受注後にRFPやヒアリングで得たこれらのプロジェクト概要やクライアント企業のチーム編成もあわせて、関わるすべてのSEやプログラマ、デザイナーに共有がなされます。
すべての関係者が目線をあわせてプロジェクトを行っていくためです。そのため、要件を伝える前段階までの情報も非常に重要なものになってきます。

依頼範囲

ここでは提案を依頼したい範囲を明確にしておきます。
たとえばWebサイトリニューアルであれば大きなカテゴリでも戦略設計、UI設計、デザイン、コーディング、開発、テストなど工程がわかれます。システムも同様ですが、大枠の開発とは別に、サーバーの設定や設置や、店舗であればPOSシステムの導入など、プロジェクトによって必要になる提案は多岐にわたります。
システムやWebサイト納入後の運用面でも必要な提案があれば記述するようにしましょう。

納品物

納品してもらいたい納品物一覧を記載します。
システムであればソースコードは当然ですが、要件定義書や設計書などのドキュメントが必要かどうかで大きく工数も変わってきます。
今後の運用面も考慮した納品物を記載するように心がけてください。また、ドキュメントは各社でレベル感が違う場合がありますので、事前にドキュメントのサンプルを入手しておくのがおすすめです。
もし納品物について判断ができない場合は、各ベンダーや制作会社に納品物を明示してもらうことで選定のポイントにすることもできます。

保守要件

システムやWebサイトの納入後、運用にかかわる要件を記載します。Webサイトであれば更新範囲や頻度などを伝えます。
システムも同じように今後の運用における機能拡張の計画やベンダー側で確保しておいてほしい工数や人員を事前に決定しておくとスムーズです。
また、サーバーなどのインフラ関連費用や保守内容も忘れてはなりません。サーバーの死活監視やアクセス増大時のトラブル対応など、必要になるであろう要件や既存のアクセス解析情報などを記載しましょう。

プロジェクト体制

ここでのプロジェクト体制は、ベンダーや制作会社側の体制を指します。
単にプロジェクト体制の明示を求めるのではなく、どういった情報を提案時に提出してほしいかを明確にしておくことで、選定や比較材料のひとつとします。
当然ながらベンダー側は人員選定が未確定の場合もあると思いますが、その場合は候補としてあがるプロマネやメンバーの情報を提示してもらいましょう。
プロジェクト体制で記載してもらう情報として、メンバーの経歴や最低限のスキルセットがわかるように記載いただくと比較時の良い材料となります。

費用

ここでの費用は、ベンダーや制作会社の提案時に提出してもらう費用についてです。冒頭で発注者側が提示する予算とは別のものとなります。
費用については、プロジェクトの規模によって正確に記載できる場合とそうでない場合があると思います。その場合でも構築時の費用と保守費用であらかじめわけて提出してもらうようにRFPに記載してください。
また、RFP概要で記載した予算を超える費用提示がある場合には、その裏付けが提案内に存在するかどうかも選定ポイントとなります。

契約、支払方法

最後に契約と支払方法について提示してもらうように記述しましょう。大型のプロジェクトになればなるほど契約条項の精査が当然ながら重要となります。システム開発における契約形態には請負契約や準委任型契約があります。それぞれメリデメがあるのでプロジェクト内容にあわせて選択しましょう。
また、契約でのチェックポイントとして瑕疵担保期間などがあります。ベンダーによって担保期間が違ったりすることもありますし、契約条項中にあきらかに不利な条件がある場合は提案時から交渉をしていきます。
支払条件についても自社の支払いフローや支払サイトにマッチするかをよくチェックするようにしてください。

RFP作成後の流れ

開発会社(ベンダー)の選定

RFIを元にベンダー候補からオリエンテーションを行うベンダーを絞ります。
候補ベンダーから得た会社情報やサービス、パッケージ仕様、または同行の実績例といった情報から、RFPに沿うベンダーを絞り込みましょう。候補社数はできるだけ少なくしておくと選定負荷が高くなりすぎず、ベンダー側からも良い提案が引き出しやすくなります。そのためのRFIやRFPでもあるのです。

オリエンテーション

オリエンテーションでは、RFPを提示しその内容に沿って詳細をベンダーに説明します。
ベンダーからの質疑応答や、オリエンで生まれたあらたな要件やアイディアなどはしっかりと保存しましょう。またそれらを各候補ベンダーへ情報共有していくルールも大切です。前述しましたがベンダー間での情報格差が生まれ正しい評価ができなくなることがありますので注意してください。

評価と発注(契約)

オリエンテーションが終わり提案内容が出そろったら各ベンダーの評価に移ります。事前準備で前述した評価ポイントをもとに採点し、発注の旨を該当ベンダーへ通知しましょう。
契約内容についてもベンダー評価の一部になります。契約における納品物や瑕疵担保(請負契約であれば)、支払フローといったポイントもチェックして契約締結まで気を抜かず進めましょう。

RFP活用における注意点

ここまで基本的に構成要素をもとに作成方法についてご案内をしてきました。
しっかりと成果を出すためにはどういったことをするべきか。シンプルにひとことでいうと、目的を達成するための提案をブレなくしてもらう、ということにいま一度フォーカスしてください。
ベンダーや制作会社のスキルや提案力を100％発揮してもらうためには、しっかりとしたRFP作成が必要です。そのうえで最後にコンペや選定を行ううえで重要となる提案に対しての2つの手法をご紹介していきます。

情報共有の仕組みを統一する(各ベンダーへ同一情報を周知)

RFP配布後に、それぞれのベンダーや制作会社から受けた質問に対する回答や、オリエン時に口頭のみで伝えていた事象についてはすべての関係者へ情報共有をするようにしてください。
これらがなされない場合は情報格差が出てくるため、アウトプットされる提案についても前提条件が変わったものになってしまうことがあります。
オリエン時の議事録やメール、メッセの回答記録などは漏らさず行い、各社への情報共有方法についても事前に決定しておきましょう。

提案の内容説明を詳細に聞き出す

開発ベンダーによくあることなのですが、広告代理店や戦略コンサルといった業態と違い、技術的な要素を深く追求する開発ベンダーは提案表現が苦手な場合があります。実際にはRFPから考察し選定した技術の背景や、利便性、拡張性といった説明が存在するにも関わらず、それらが表現されていない(または説明されない)こともあるため委託企業側でのヒアリングにある程度厚みがあると評価がガラッと変わることがあります。
提案書だけに頼らず、しっかりとベンダー側の提案については確認したり質疑応答を行うなどの対応があるとよりよいベンダー選定ができます。

RFPのテンプレート

検索するとRFPのテンプレートダウンロードができるページがいくつかヒットしますが、Wakka Inc.が用意しているテンプレートではこの記事の内容に沿ったページ構成で、システム開発用RFPテンプレートと、Web制作用RFPテンプレートの2種類のRFPをご用意しています。
これらを利用することでRFP作成の時間短縮はもちろんのこと、設定項目の漏れを防止したり、自社のフォーマットに置き換えたりという利用が可能です。パワーポイント形式で配布しておりますので是非ご利用ください。

さいごに

成果を出すためのRFPのポイントについて解説してきました。
コンペを行う場合、きちんとしたRFPがないとベンダーや制作会社側でも契約までにかかるコストが増大し、商談前半で離脱していくことも少なくありません。
単純に複数社を比較すれば良いシステムやWebサイト、ベンダーや制作会社に巡り会えるわけではありません。
最適な提案を最高のクオリティで提出してもらうためには、発注者側の努力や準備も非常に重要になってきます。
大きなプロジェクトになればなるほど、伴走するパートナーを選定するには労力を惜しまずかけ、社内のチームをしっかりと取りまとめることがプロジェクトの成功の鍵を握ります。
また、コンペや相見積もりでは無い場合でもしっかりとRFPをまとめておくことでプロジェクトの円滑な運用が可能になります。ぜひこの記事やテンプレートを活用してRFPをつくってみてください。

Wakka Inc.ではシステムやWebサービスの開発にあたり、お客様のビジネスを理解し、企画・提案・開発・運用保守までトータルサポートが可能です。
また、大規模案件から継続案件までトータルコストを抑える『ラボ型オフショア開発』もご用意しています。
開発の外注を検討される際には、RFPの作成とともにぜひわたしたちにもお声がけいただけると嬉しいです。ぜひお気軽にお問い合わせください。

【あわせて読みたい】おすすめ関連資料

●すぐに使えるRFPテンプレート｜システム開発用
＞システム開発のRFPについて、情報を埋めるだけで簡単に作成ができるテンプレートです。

●すぐに使えるRFPテンプレート｜サイトリニューアル用
＞サイトリニューアルの際に、テンプレートの情報を埋めるだけで簡単にRFPが作成できます。

●DX進め方ガイドブック
＞DXプロジェクトを検討している担当者の方に向けて、失敗しない社内体制の構築から開発リソース確保までを網羅して解説しています。