はじめに

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

今回のテーマはRFPです。私自身、これまで在籍した企業でシステムやWebサイトを外注する際にはベンダーさんや広告代理店さん向けにRFPを作りオリエンテーションを行ってきました。

いまではRFPをいただいて開発する側でもあるのですが、この両方を体験してきたからこそできる「成果の出るRFP」の作り方、と題して記事を書いていこうと思います。

また、今回はシステム開発とWebサイト制作用のRFPテンプレートもご用意しております。

こちらからダウンロードしていただき、記事内容とともにご活用ください。

・ダウンロードリンク｜Webサイトリニューアル用 RFPテンプレート
・ダウンロードリンク｜システム開発用 RFPテンプレート

RFPとは

RFP(Request for Proposal)は日本語では「提案依頼書」となります。

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

なぜRFPが必要なのか？

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

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

これらを解決し、最適な提案を受けるために利用されているのがRFPです。

RFPをつくる前に

この記事ではRFPのつくり方を記載していますが、しっかりとした成果を出すためにはRFPをつくる前段階の準備が非常に重要です。

このあとに記載していくRFPの基本構成に出てくるそれぞれの内容を事前に準備するのは当然ですが、これらを社内の利害関係者に合意を得ておくことが必要となるはずです。

事前にチームを編成しておく

前述した利害関係者の整理として、プロジェクトを進めるチーム編成を行うことが、最初のステップかと思います。

構築するシステムやWebサイトによって編成するメンバーは変わるはずですが、まずはこのプロジェクトのトップとなるオーナーを設定しましょう。

プロジェクトのオーナーは、予算やスケジュールの決裁が可能な役員や執行責任者クラスが通常は選任されます。

そこからPMやPLなどを設定していきます。あとはマーケティングやPR、情報システム部、といった役割別に必要となるメンバーをアサインしてください。

RFPの基本構成

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

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

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

Wakkaで配布している簡単に作れるRFPのテンプレートもあります。こちらからダウンロードしてぜひご利用ください。

プロジェクト概要

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

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

パッと見て把握しやすいレイアウトにしておくと良いでしょう。概要における小項目は以下にて説明していきます。

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

今回のプロジェクトにおける背景と目的を記載します。

なぜ、どういった経緯で今回のプロジェクトを行うことになったかを把握してもらうことで、目的を達成できる提案をもらいやすくなるのはもちろん、当初の趣旨からズレることなく各社の提案を受け取ることができます。

また、発注側もオリエンからはじまり長くプロジェクトを推進していると、目的を見失った行動を取ることがあります。これらをベンダー側でも抑止することが可能になります。

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

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

どの職種のどんな人が使うシステム(Webサイト)なのか。どの年代のどういったフェーズにいるユーザーなのか。

これらはシステムやWebサイトの機能だけではなく、UI/UXや、コンテンツ内容を決定するために必要となる大事な情報です。

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

課題

課題はRFPにおいて非常に重要な要素のひとつです。

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

できるだけわかりやすく、簡潔に記載するように注意してください。

競合

主にWebサイトリニューアル時やマーケティングをともなうプロジェクトの際に記載することが多い項目です。

自社サービスや製品と競合となる企業のWebサイトやシステムについて、なぜ競合となるのかを記載します。

これらの情報をもとにしてベンダーのプレゼンで情報収集や課題解決の提案がなされているかを確認することができます。

スケジュール

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

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

また、RFP公開から提案までのリードタイムが短い場合は、提案にかける工数が少なくなることや、コンペにかかるコストを圧縮するために各ベンダーの提案が薄くなることがあります。

この点には注意が必要で、事前に社内の利害関係者としっかりスケジュール調整しておくことが重要です。

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

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

既存のシステムにおける基本構造やWebサイトのサイトマップ(機能をあわせた)などを記載することによって、各ベンダーや制作会社が現状把握を構造的に行うことが可能になります。

簡易的なものをRFPで提供しておいて、開発前には別途詳細の構造を提出することもあります。

以前納品されたドキュメントや、普段から社内で利用するようなものがあれば良いですが、無い場合でも担当者やチームでの現状確認ができるので余裕があればぜひ作成をしてみてください。

現在の体制や運用工程

構造と同様に、現状のシステムやWebサイトを運用しているチーム体制や運用フローを記載しておきます。

これを共有することで、提案の中であらたに運用の役割が必要になる場合どういったフローで行うかをベンダー側で提案できる場合があります。

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

要件

さて、次は2つめの大きなカテゴリである、要件について記載していきます。

これまでのチーム編成や、プロジェクト概要の合意、RFPへの記載をしっかり行ったうえではじめて要件の記載をしていくのが重要です。

前提条件が変わってくれば要件に対する提案の方向性や深さなどが変わってくるためです。

余談ではありますが、われわれベンダー側では受注後にRFPやヒアリングで得たこれらのプロジェクト概要やクライアント企業のチーム編成もあわせて、関わるすべてのSEやプログラマ、デザイナーに共有がなされます。

すべての関係者が目線をあわせてプロジェクトを行っていくためです。そのため、要件を伝える前段階までの情報も非常に重要なものになってきます。

依頼範囲

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

たとえばWebサイトリニューアルであれば大きなカテゴリでも戦略設計、UI設計、デザイン、コーディング、開発、テストなど工程がわかれます。

システムも同様ですが、大枠の開発とは別に、サーバーの設定や設置や、店舗であればPOSシステムの導入など、プロジェクトによって必要になる提案は多岐にわたります。

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

納品物

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

システムであればソースコードは当然ですが、要件定義書や設計書などのドキュメントが必要かどうかで大きく工数も変わってきます。

今後の運用面も考慮した納品物を記載するように心がけてください。また、ドキュメントは各社でレベル感が違う場合がありますので、事前にドキュメントのサンプルを入手しておくのがおすすめです。

もし納品物について判断ができない場合は、各ベンダーや制作会社に納品物を明示してもらうことで選定のポイントにすることもできます。

保守要件

システムやWebサイトの納入後、運用にかかわる要件を記載します。Webサイトであれば更新範囲や頻度などを伝えます。

システムも同じように今後の運用における機能拡張の計画やベンダー側で確保しておいてほしい工数や人員を事前に決定しておくとスムーズです。

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

プロジェクト体制

ここでのプロジェクト体制は、ベンダーや制作会社側の体制を指します。

単にプロジェクト体制の明示を求めるのではなく、どういった情報を提案時に提出してほしいかを明確にしておくことで、選定や比較材料のひとつとします。

当然ながらベンダー側は人員選定が未確定の場合もあると思いますが、その場合は候補としてあがるプロマネやメンバーの情報を提示してもらいましょう。

プロジェクト体制で記載してもらう情報として、メンバーの経歴や最低限のスキルセットがわかるように記載いただくと比較時の良い材料となります。

費用

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

費用については、プロジェクトの規模によって正確に記載できる場合とそうでない場合があると思います。

その場合でも構築時の費用と保守費用であらかじめわけて提出してもらうようにRFPに記載してください。

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

契約、支払方法

最後に契約と支払方法について提示してもらうように記述しましょう。

大型のプロジェクトになればなるほど契約条項の精査が当然ながら重要となります。

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

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

RFPで成果を出すために

ここまで基本的に構成要素をもとに作成方法についてご案内をしてきました。

しっかりと成果を出すためにはどういったことをするべきか。シンプルにひとことでいうと、目的を達成するための提案をブレなくしてもらう、ということにいま一度フォーカスしてください。

ベンダーや制作会社のスキルや提案力を100％発揮してもらうためには、しっかりとしたRFP作成が必要です。そのうえで最後にコンペや選定を行ううえで重要となる提案に対しての2つの手法をご紹介していきます。

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

RFP配布後に、それぞれのベンダーや制作会社から受けた質問に対する回答や、オリエン時に口頭のみで伝えていた事象についてはすべての関係者へ情報共有をするようにしてください。

これらがなされない場合は情報格差が出てくるため、アウトプットされる提案についても前提条件が変わったものになってしまうことがあります。

オリエン時の議事録やメール、メッセの回答記録などは漏らさず行い、各社への情報共有方法についても事前に決定しておきましょう。

ベンダー評価のための準備をしておく

RFPをもとに各ベンダーや制作会社から提案やプレゼンがなされます。

このときにどのように各社を評価していくかを事前に準備しておくことで、スムーズな選定が可能になります。

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

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

最も重要なのはRFPをもとに行われた提案内容ですが、そのほかにも社としての実績やメンバーの経歴、さらには担当者のコミニュケーションスキルなどを評価するようにします。

評点も重要度に応じて配点し設定をしておくことで、各社の総合点をできるだけ平等にバランス良く評価し選定できるように準備しておきます。

さいごに

成果を出すためのRFPのポイントについて解説してきましたが、いかがでしたでしょうか。
RFPの目的から、ベンダー・制作会社選定まで成果を出すための手法をここまで記載してきました。

コンペや相見積もりを行う場合、きちんとしたRFPがないとベンダーや制作会社側でも契約までにかかるコストが増大し、商談前半で離脱していくことも少なくありません。

単純に複数社を比較すれば良いシステムやWebサイト、ベンダーや制作会社に巡り会えるわけではありません。
最適な提案を最高のクオリティで提出してもらうためには、発注者側の努力や準備も非常に重要になってきます。

大きなプロジェクトになればなるほど、伴走するパートナーを選定するには労力を惜しまずかけ、社内のチームをしっかりと取りまとめることがプロジェクトの成功の鍵を握ります。

また、コンペや相見積もりでは無い場合でもしっかりとRFPをまとめておくことでプロジェクトの円滑な運用が可能になります。ぜひこの記事やテンプレートを活用してRFPをつくってみてください。

Wakka Inc.ではシステムやWebサービスの開発にあたり、お客様のビジネスを理解し、企画・提案・開発・運用保守までトータルサポートが可能です。
また、大規模案件から継続案件までトータルコストを抑える『ラボ型オフショア開発』もご用意しています。

開発の外注を検討される際には、RFPの作成とともにぜひわたしたちにもお声がけいただけると嬉しいです。
ぜひお気軽にお問い合わせください。

お問い合わせはこちら