RFPとは
RFPはRequest For Proposalの頭文字を取ったもので、日本語訳すると提案依頼書です。
発注側の企業が受注側である制作会社に対してシステム開発の目的や概要を伝えた上で希望に沿った提案を依頼するドキュメントを指します。
受注側の企業はRFPの内容を吟味した上で、システムに関する提案や見積もりを返します。
複数社にRFPを送ることが多く、一般的にはコンペを経て発注先を決めるでしょう。
しかしRFPの内容が曖昧だとクライアントである発注者が望む提案が得られず、発注先を決めるどころか再度作り直す必要さえあります。
無駄な工数をかけないためにもベンダー側に開発意図が正確に伝わるRFPについて情報を整理していきます。
RFPを作る目的
まずはRFPを作る目的から整理していきましょう。主に以下の3点を意識します。
自社の目的に叶うソリューションの提案を受けられる
まずは、特定の問題やニーズに対して最適な解決策やソリューションの提案をもらわなければなりません。自社の要件や期待に合致する提案を受けることで、最良の選択をすることができます。
適切な提携先の選定
外部の企業やベンダーとの提携を検討するという場面もあるでしょう。ゴールに向けた考え方や体制などの他、社風や文化など相性も見極めたいところ。長期視点で継続可能か否かを見落とさないように、選定するための基準や条件を提示します。
選定基準、契約条件の明確化
プロジェクトの範囲や目的、納品物、納期、価格など、契約条件を明確にします。これにより、提案者は要件を理解し、提案書を適切に作成することができます。
RFPへの記載事項
それではまず、RFPへの記載事項を簡単にまとめてみます。プロジェクトに直接関与する事だけでなく、発注の背景となっている事業環境に関する情報が必要になります。
3Cフレームワークに沿って整理すると、現状の整理や発注目的の明確化にも役立ちます。記載事項自体が戦略的アプローチになっており、提出された提案書が比較しやすい構造になり効率的です。
プロジェクトについて
- 施策の目的
- 目的達成の方法と目標
- 重点課題
- 納期
- 予算
自社の事業について
- 会社概要（事業の変遷などブランドのストーリー）
- 自社の強み／弱み
- 事業目標、戦略
顧客に関する情報
- 顧客セグメント（どんなタイプの顧客がいるか）
- ターゲット（最も重視する顧客セグメント）
- 顧客のベネフィット、意見や感想などフィードバック
競合に関する情報
- 業界のリーダー
- 直接の競合、各々の強みや弱み
- 自社と他社の差別化要因
依頼範囲（プロジェクトスコープ）
- 企画範囲
- コンテンツ制作範囲（文章や写真、動画など）
- 機能要求事項（CMSやフォームの有無、仕様など）
- 集客要件（SEOなどの必要があれば）
- サーバ／ドメイン取得の有無
- 保守管理の有無
- その他要件
- 評価基準
- 納品方法
現状環境、条件
- デザインに対するガイドライン、要望
- サーバホスティング先（既存利用の場合）
- サーバ側ソフトウェアのバージョン
- CMSの名称、バージョン（利用中の場合）
- 対象デバイス、ブラウザ範囲
- ユーザのデバイス比率
- 各種計測タグ管理の状況
- MAなどの導入状況
- 質問の期限と回答方法
提案書に記載する内容
- 与件整理、現状分析
- ターゲットについての考察
- 課題解決のアプローチ
- 課題解決可能性の根拠
- 同課題に関する事例、実績など
- サイト構成案
- ページ構成案
- デザイン案
- 見積金額
- スケジュール
- プロジェクト体制
RFPのサンプルテンプレートはこちら
ベンダーの力を引き出すための工夫
システム要件が詳細に記載されたRFPがあれば、ベンダー側にとっては見積もりが出しやすくありがたいですが、そもそもなぜ新たなシステムが必要なのか本質的な理由が見えてこなければ良い提案は出てきません。
ベンダー側は何かしらの専門性や強みを持っているものですが、クライアントの業界に関しての知見が深いとは限りません。だからといって、業界の知見があるベンダーだから良いという事でもありません。業界に関する知見以上にソリューションに関する知見が重要な場合もあります。
クライアントの事業や戦略に対して、十分なヒアリングと理解の深度があるか、調査能力や適切な施策の提案が出来ているか否かを見極める事が発注成功のカギとなります。
また要件をしっかりと明文化しておくことで互いに納得した上で契約を履行できます。
要件が曖昧なまま制作が進んでしまうと、想定と全く違った成果物が納品されることになりかねません。
場合によっては追加コストが発生してしまうので、ある程度柔軟性を持たせた上で重要なポイントは明確にしておくとよいでしょう。
RFPに記載するプロジェクト概要
全体像が把握できたところで、記載の目的を整理してみましょう。
施策の目的
まず、WEBサイトやシステムの制作目的を明確にしましょう。
古くなったから、見た目を良くしたいから…という程度であれば、RFPは不要かもしれません。
RFPが必要になるのは、具体的なビジネス目標がある場合です。（…だと思います）
特に具体的なベンチマークとなる数値を上げることが大事です。
“月間トラフィックを○○にする”や“コンバージョン数を50%向上する”など具体的なゴールを数値化することで目標を共有できます。数字が把握できていない場合は、競合を調査して目標値を設定する方法もあります。
この目標に対して、いつまでに目標達成したいのかという期限を設けることも具体性が上がります。ただし、現在のWEBサイトの状態から判断して現実的な目標か否かを問う姿勢も大切です。非現実的な目標を提示するだけでは、リスクを感じて提案を控えられてしまう事も起こり得ます。
とはいえ、マーケティング戦略を立てられていない、WEBマーケティングの目標値を調べたり、設定する方法がわからないなどのケースもあると思います。
そのような時は、ビジネスの目的、顧客に提供したい価値を伝えて、適切なプランの提案を求めましょう。客単価×件数＝売上という簡単なモデルを利用して、WEBに求められる能力を試算できます。あくまで簡易な目標値の出し方ですが、ひとまずの目標設定としては役に立ちます。
場合によってはリサーチの予算が必要になる場合がありますが、ベンダー側に制作意図を汲み取ってもらえる資料作成ができれば、プロジェクトの成功確率はぐっと高まるでしょう。
目的達成の方法と目標
具体的な方法は、ベンダーの提案に任せて良いと思います。
例えば、
- SEOによる集客を強化して売上につなげる
- 導線やナビゲーションを改善して購入率を向上する
- 求人応募を増やすためにブランディングを強化する
- 利便性向上のためにカスタマイズした予約機能を提供したい
など、大まかな方針を示せばOKです。
WEBに関する知見がなくて、方針が示せない場合は、
- サイトへの訪問者が少なすぎる
- サイトが使いにくいと言われる
- 求人応募が集まらない
- 利用者の利便性を向上したい
など課題感を示すだけでもよいです。
重点課題
この項目は、先の項目に関連して「課題解決する上のハードル」を示します。
例えば
- ブログを運用したいが、人手が足りていない
- なるべく自社内で修正できるようにしておきたい
- 社員の写真は使いにくいので別の手段が必要
- 問い合わせ対応の業務フローを複雑にしたくない
など、人的な問題や業務フローなど、WEBサイトの機能以外で重要な課題があれば記載します。
納期・予算
どんなプロジェクトにも共通して言えることですが、必ず予算と納期が存在します。
できる／できないの判断は、技術的な問題だけでなく、予算や納期の制約も関連します。
トラブルを回避するために予算・納期は事前に設定しておきましょう。
自社の事業環境
どのようなビジネス環境にあるのかは、コンテンツやデザインを企画する上で重要な情報です。ターゲットの顧客や競合についての情報、ブランディング／マーケティング戦略や事業方針などを記載します。3C形式でのまとめ方がおすすめです。
RFPに記載する依頼範囲
対象となる範囲を明らかにする
Webサイトのリニューアルを行う上で対象となる範囲（スコープ）を明確にする必要があります。
メインとなるサイト上にサブドメインを利用した別サイトや全く異なるドメインのLPやキャンペーンサイトなどが存在することは少なくありません。当面の対象範囲と将来的な対象範囲が不明瞭なケースも、よく目にします。
このようなケースでは、ベンダーによって対象範囲の解釈が違ってしまい、提案の精度が低くなったり 比較困難になったりします。
複雑な構成のサイトの場合はサイトマップを記載するなど、わかりやすくまとめる工夫が求められます。
最初に対応しておけば、後に発生する制作サイドからの質問を防ぐことができるのでお互いに手間が省けます。
企画範囲
デザインと制作だけなのか、マーケティングやコンテンツの企画も含めるのかを示します。
WEBサイトやサービスの開発では、提案者に求める提案の範囲として以下を含む事が多いです。
- ウェブサイトのデザインとユーザーエクスペリエンスの企画および制作。
- マーケティング戦略の立案と実行。ターゲットオーディエンスの特定、競合分析、オンラインプロモーション戦略など。
- コンテンツ戦略の策定。ウェブサイトに適切なコンテンツの種類や量、配信スケジュールの提案。
コンテンツ制作範囲
自社が提供するコンテンツの種類（テキスト、画像、動画など）を記載します。ベンダーに制作を求める場合は、その旨を伝えます。コンテンツの量やフォーマットに関する要件があれば、合わせて記載します。
機能要求事項
ウェブサイトのコンテンツの管理や更新を容易にするためのCMSの要件の他、問い合わせフォーム、検索機能、ユーザー登録、オンラインショッピングなどウェブサイトが持つべき特定の機能やモジュールを明確に定義します。
アクセシビリティ要件やセキュリティ要件も機能的要件として指定します（例: WCAG 2.0準拠など）。
主要なブラウザ（Chrome、Firefox、Safari、Edgeなど）で正常に表示されることを要求するブラウザ五感要件も記載できればしておきます。自社サイトのユーザの実情から判断することが適切です。
CMS導入の希望有無と、CMSに指定やCMSに対する機能的な要望があれば記載します。
必要な機能（フォーム、ユーザーアカウント管理、データベースの統合など）の要求があれば、それらも記載します。
集客要件
サイト制作するときには、その目的を達成するために必要な集客要件を考慮します。広告を運用予定なのか、検索エンジン最適化（SEO）が必要なのか、集客要件も忘れずに加えておきます。対象となる商品やサービスから、想定されるキーワードや成果予測などの提案を求めればよいでしょう。
SEO対策に関する具体的な要件や提案者に求めるアプローチは、WEBサイトの企画設計や制作要件に大きく関与します。また、ソーシャルメディアプロモーションや広告キャンペーンの可能性があれば、予定や計画を記載します。
サーバ／ドメイン取得
サーバの選定基準（共有サーバ、専用サーバ、クラウドホスティングなど）があれば理由とともに明示しておきます。ドメイン取得に関する指示や、DNSサーバの設定について作業依頼があるかも記載します。
保守管理
サイトのアップデート、セキュリティ対策、バックアップに関するポリシーや頻度の指定、サポート体制や保守契約に関する要望を記載します。
その他要件
グローバル展開や多言語対応など、特殊な要件について説明します。デザインガイドラインがない場合、デザインのスタイルや雰囲気に関する要望なども記載しましょう。
評価基準
提案書の評価基準についての明示します。
提案者がどのような情報を提供すべきかを詳しく説明しておきます。
価格、デザインや提案のクオリティ、提案者の専門知識などが基準として考えられます。
納品方法
プロジェクトの納期や納品物に関する詳細な説明が必要です。
納品形式として、本番公開までの作業か、テスト環境やオンライン、あるいは物理的なメディアなどでのデータ納品かなどを指定します。
これらの詳細な情報が含まれることで、提案者はプロジェクトに対する理解を深め、より適切な提案を作成することができるでしょう。
現状環境、条件
デザインに対するガイドライン、要望
ウェブサイトのデザイン要件やスタイルガイド、カラースキーム、ブランドガイドラインなどがあれば提供します。無い場合は企業の理念やビジョンなど、自社のアイデンティティを示す資料が役立ちます。
ホスティングとドメイン
サーバやドメインの現状を引き継ぐのであれば、現在のサーバに関する情報を記載します。ホスティング先の会社名、サービス名やプラン名、ドメインやDNSの管理情報、設定内容などが記載対象になります。
サーバ側ソフトウェアのバージョン
サーバOSやWEBサーバソフト、データベース、PHPなどミドルウェアのタイプやバージョンを記載します。サーバ側のソフトウェアを更新する必要の有無など課題が発見される事にもつながります。
CMSの名称、バージョン（利用中の場合）
もし既存のCMSがある場合、その名称とバージョン情報を記載します。WordPressのプラグインなどの情報もあれば記載しましょう。
対象デバイス、ブラウザ範囲
ウェブサイトが対応するべきデバイス（デスクトップ、タブレット、スマートフォンなど）およびブラウザを指定します。ユーザの閲覧環境はGoogle Analyticsなどでアクセスログを参考にすると把握できます。
ユーザのデバイス比率
利用者がどのデバイスでウェブサイトを閲覧するかに関する統計的情報です。こちらもGoogle Analyticsなどを用いて調べ、重視すべきデバイスや画面サイズを整理しておきます。
各種計測タグ管理の状況
Google Analyticsや広告効果測定、他の計測タグの導入状況と管理方法に関する情報を記載します。
MAなどの導入状況
マーケティングオートメーションツールなど、マーケティングツールの導入状況を記載します。
質問の期限と回答方法
提案者からの質問に対する回答方法や期限について説明します。質問内容はRFP文書の一部として提供されることが多いです。
提案書に記載する内容の指定
提案者に提出してほしい情報や文書の形式、提案書の締め切りなどを指示します。ベンダー任せにすると、書式や内容がまちまちになり、比較しにくくなってしまいます。ある程度自由度があって良いのですが、最低限の骨格が同じになるように記載項目を指定しておきましょう。