追記 2018/06/12: 次の記事を書きました。興味のある方はぜひご覧ください。

• ウェブ制作における RFI / RFP / RFQ とは

前回の なぜ RFP が重要なのか というお話の続きとして、今回は「 RFP 作成を検討している方」と「 RFP を作ろうとしている方」を対象に、 ウェブサイト制作における RFP の構成サンプル をご紹介します。

この記事をご覧になっている方はおそらく RFP が何かというのはご存知かと思いますが、ご存知ない方のためにかんたんにご説明します。

RFP とは Request for Proposal の略で、日本語では「提案依頼書」と呼ばれるものです。 ウェブサイトやシステムの制作に関して見積もり・契約をもらう前に、「こういうサイトを作りたいと思っています。それを実現する形を提案していただけませんか？」と、発注者側から制作会社に依頼すること、またはその際に用いる資料のことを指します。

RFP は法律でフォーマットが定められたようなものではないため「絶対にこの形でないと」という固定のフォーマットはありません。 極端にいえば、どんな構成で作ってもそれは担当者の自由です。

ただ、 RFP は「提案を依頼するための資料」であり、その読み手は「制作会社」です（サイト制作の文脈でお話をしています）。 制作会社から少しでもよい回答を得るためには、制作会社にとってわかりやすく回答しやすい、回答しようと思える RFP にすることが大切です。

RFP の構成サンプルを以下にご紹介します。

概要（大項目のみ）

構成の概要は次のとおりです。

• A. プロジェクト概要
• B. サイト概要
• C. 求める提案内容
• D. 求める提案方法
• E. その他

ちなみに、読み手の負担・読みやすさを考慮して RFP には目次を付けるべきです。

概要（小項目も含む）

小項目も含む概要は次のとおりです。

• A. プロジェクト概要
  • 概要
  • 目的・目標
  • 背景
  • 押さえるべきポイント
  • 押さえるべきポイントへのアプローチ
  • 予算
  • ターゲット・便益
  • リスク
  • スケジュール
• B. サイト概要
  • 概要
  • コンセプト
  • 想定するユーザーグループ
  • 必要な機能
  • 必要なページ
  • デザイン上の要望
  • 対応が必要な環境
  • その他実現が必要なポイント
• C. 求める提案内容
  • 対応可能な範囲
  • 納品成果物
  • 必要な機能の実現可否
  • 追加で提案する機能
  • 必要なページの実現可否
  • 追加で提案するページ
  • デザイン方針・デザイン案
  • 運用方針
  • 体制
  • スケジュール
  • 概算見積もり
  • その他
• D. 求める提案方法
  • 形態
  • 提出方法
  • 期日
• E. その他
  • その他補足事項

詳細

上にあげた各項目の詳細です。 各項目について、重要度とかんたんな解説をつけてご説明していきます。 重要度は★〜★★★で表現していて、★★★が最も重要度が高いという意味です。

A. プロジェクト概要

概要 ★★★

プロジェクト全体の説明です。サイトの概要では「どういうサイトなのか」を説明するのに対して、こちらでは「サイトを含むプロジェクトの全体像」を説明します。

目的・目標 ★★

プロジェクト全体の定性的な「目的」と定量的な「目標」を記述します。例えば、目的は「問い合わせのウェブ利用による業務効率の向上による売上向上」、目標は「問い合わせ対応件数 200% （現状 50 件 / 日、サイト導入後 100 件 / 日）、その結果売上を○円アップ」とします。最終的には「売上を上げる」か「コストを下げる」が多くのプロジェクトの上位目的になるので、そのどちらかなのかを明確に書くと、より的を射た返答を得ることができます。

背景 ★★

プロジェクト全体の背景です。なぜこのプロジェクトを実施するに至ったのか、このプロジェクトに期待されていること等を、上位の背景や他のプロジェクトとの関係を交えて説明します。ビジネスリテラシーの高い制作会社であれば、ビジネス上の意義を共有した方がよりよい関係で仕事を進めることができます。

押さえるべきポイント ★

目的・目標を達成するために、プロジェクトを実施する上で必ず押さえるべきポイントを記述します。例えば、「既存の電話や競合の X 社の問い合わせと同等以上の問い合わせ UI 」「スタッフがウェブ問い合わせを効率よく捌けるようになる十分なトレーニング」といったことを記述します。目的・目標・背景と論理的・経験的に整合していることが重要です。これが考えられていると、運用が始まってからの KPI 設定や PDCA がスムーズです。理想は、人間が短期記憶で記憶できる数に絞り、優先順位が付いたものです。意味合いとしては MBA ・ビジネス管理でいう「 KSF (Key Success Factor) 」と同等です。

押さえるべきポイントへのアプローチ ★

前の項で規定した、目的・目標のために押さえるべきポイントに対して、具体的にどのようなアプローチを取るつもりなのかを説明します。例えば、「競合と同等以上の UI を実現するために、専門の熟練の UI 設計者をメンバーに招き、プロトタイプを使った十分な検証を行う」といったことを書きます。「押さえるべきポイントまでは明確なんだけど、それを押さえるアプローチはまだわからない」といった場合は、例えば「求める提案内容」に「プロの視点から、その効果的なアプローチを提案してほしい」と記述するとよいでしょう。

予算 ★★★

このプロジェクトに割り当てている予算です。厳密に決まっている場合はそのまま「○万円」と記述するとよいでしょう。予算がまだ取れておらず、相場感もまったくわからない場合は「未定」と書きたくなりますが、予算はなるべく明記するのがおすすめです。目的・目標を設定して正しく企画ができている場合は「割ける予算の概算」が導き出せるはずなので、できるだけ記述するのがよいでしょう。予算の情報が提供されない場合、制作会社は想定とかけ離れた提案をしてきたり、「ただ予算策定に利用されているな」と思って力を抜いたりする可能性があります。また、予算を提示できるかどうかは、その人の仮説思考力や組織内でのリーダーシップとも関係するので、予算を提示せずに何度もコンタクトを取っていると、腕のよい制作会社には相手にされなくなることもあるでしょう。予算は発注者側が主体的に提示することが発注者自身のためになります。

ターゲット・便益 ★★

プロジェクトの主なターゲットとターゲットに対する提供便益です。例えば、「顧客: 商品購入の直前・直後のサイト訪問者 / 社内: 問い合わせ担当チーム」と記述します。理想は、セグメンテーション等の分析に裏打ちされたターゲティング設定と Reason to Believe のある便益の説明ですが、そこまでは行かずとも、「誰に何を提供したいのか」（ WHO & WHAT ）は最低限書いておくことのがおすすめです。このターゲットと便益は、「目標」の数値や「押さえるべきポイント」と論理的に整合していることが重要です。

リスク ★

想定されるリスクとその対応方法を記述します。コントロールのできない「外部要因」と比較的コントロールのしやすい「内部要因」とに分けて記述されているのがよいでしょう。すべての可能性を洗い出すには時間がいくらあっても足りないので、プロジェクトの意義そのものや継続性に関わるクリティカルなものを優先的に記述するとよいでしょう。日本には、言霊的発想で「事故のことを考えると本当に事故が起こるから考えないでおこう」としたり、「もしものことを考えるなんて、ネガティブなやつめ！やる気がないのか！」と怒り出したりする人がいますが（笑）、主要なリスクを正しく認識して共有することは各ステークホルダーとの信頼関係に大きく影響します。

スケジュール ★★★

期待するスケジュールを記述します。プロジェクトそのもののスケジュールはもちろんですが、影響を受ける他プロジェクトがある場合や、会社や業界的に重要なイベントがある場合はあわせて記載するとよいでしょう。

B. サイト概要

概要 ★★★

構築すべきサイトの概要説明です。どのようなサイトなのかを簡潔に説明します。例えば、「問い合わせ対応窓口サイト。購買を検討している見込み客が、既存の問い合わせ窓口である電話と同じような形で、匿名で気軽に質問ができるサイト。」と書きます。「企業サイト」「キャンペーンサイト」「 SNS サイト」「 EC サイト」など一般的な分類でいうとどれにあたるのか、そして、誰にどんな機能を提供するものなのかという情報を含めるとよいでしょう。

コンセプト ★

サイトのコンセプトです。マーケティング的な対外的メッセージとしてのコンセプトでも、事業内の役割・位置づけを表す社内コンセプトでもどちらもでもよいでしょう。概要でサイトの「 WHAT 」を説明するとしたら、こちらは「 HOW 」の説明をする形になるでしょうか。

想定するユーザーグループ ★

そのサイトを利用する人にはどんな人がいるのかをグループ別にリストアップします。ここでは、「吉田さん」「田中さん」などの個人ではなく、例えば、「新規の見込み客」「問い合わせ担当チームスタッフ」「問い合わせ担当チームマネージャー」「事業マネージャー」「システム管理者」といったグループをリストアップすることを心がけるとよいでしょう。制作会社にとってわかりやすいグループの単位は「できることが同じ人」です。例えば、「メンバー」と「チーフ」という役職の人がいる場合、サイトで閲覧できる情報やできる操作が同じ場合は区別なく 1 つのグループとみなしても大丈です。できる操作が異なる場合は別のグループとして上げておくのがよいでしょう。

必要な機能 ★★★

サイトに必要な機能の一覧です。複数の粒度で細かく説明されていることが理想です。例えば、経験の少ない方は「 EC 機能が必要」とだけ説明すればすべて伝わると思いがちですが、制作側はそれでは効果的な提案や見積もりができません。「 EC 機能」と言ったときに、具体的に決済方法はどんなものを考えているのか、決済のタイミングとしてどのような形を用意したいのか。購入の管理や顧客の管理としてどういうことが行いたいのか、あるいは行えなくてもよいのか。すべてを網羅することはできなくても、必要と思っている最低限のことはできるかぎり洗い出しておくのがよいでしょう。かといって、細かい粒度での説明だけに終止してしまうと、「押さえるべきポイント」との整合性などがわかりづらく、読み手の読む気も損ねてしまうので、大きな視点と小さな視点の両方で説明できていることが理想です。

必要なページ ★★

必要なページの一覧です。「押さえるべきポイント」を押さえて目的・目標を達成する上で、なくてはならない重要なページをリストアップします。その構成やユーザーの導線まで考えられている場合は、それらもあわせて記述するとよいでしょう。

デザイン上の要望 ★★★

デザイン提案に関する要望について説明します。戦略レベルの「情報設計」のレイヤーのことを書くか、戦術レベルの「装飾のテイスト」のレイヤーのことを書くか、あるいはその両方を書くかは自由ですが、ターゲットや機能と整合性のある、筋の通ったデザイン提案をもらいたければ、なるべく正確・具体的に要望を提示するのがよいでしょう。実際にデザイン提案をもらったときに期待から大きく外れた提案が出てきた場合はお互い労力と時間がムダになってしまうので、感覚の問題で片付けられがちなデザインこそ、ことばを尽くして丁寧な説明を心がけるとよいでしょう。デザインに関していちばんよくないのは「とりあえずデザイン案を作って見せてください」というものです。もしそれで「わかりました、ではとりあえず・・・」と言ってそのまま仕事を進めようとするデザイナーがいたら、その人はえせデザイナーの可能性があります。

対応が必要な環境 ★

ウェブサイトの利用環境としてサポートしたい OS やブラウザを指定します。ここは当然、ターゲットや便益と整合している必要があります。対応環境に関して 2010 年代で大きな意思決定ポイントは、スマートフォン対応をするかどうかです。メインターゲットが 10 代男女の場合はもちろんスマートフォン対応が必要でしょうし、ビジネスシーンでの利用のみが想定されている場合はスマートフォン対応が不要となることも多いでしょう。ターゲットや提供便益と整合したサポート範囲に設定することが重要です。技術的に細かいことがわからない場合は「細かいことはわからないので、ターゲット層にあわせて提案をお願いします」とするとよいでしょう。

その他実現が必要なポイント ★

その他実現が必要なポイントがもしあれば追加で記述します。多くのサイトで考慮すべきは、稼働やパフォーマンス、セキュリティの面での対応です。月間数万人以上の利用者数を想定している場合は、パフォーマンス面については少なくとも言及するのがよいでしょう。セキュリティについては、通信の暗号化や機微情報の暗号化、悪意のある攻撃への対応など、わかる範囲についてはできるだけ言及しておくのがよいでしょう。

C. 求める提案内容

対応可能な範囲 ★★★

ウェブサイト制作プロジェクトの中でどこからどこまで対応してもらえるかを明示してもらいましょう。基本的なページデザインとサイト設置はほとんどの制作会社が行いますが、情報設計などを含む高度なデザインや、他にあまり無い独自機能の開発、マーケティング・販促戦略の策定やオペレーション設計、初期コンテンツの制作など、ウェブサイトの立ち上げに付随する作業はさまざまで、そのうちどこからどこまでを担えるかは制作会社によって大きく異なります。どこまでがお願いできて、どこまでは自社でやる必要があるのかをしっかりと確認しましょう。

納品成果物 ★★

プロジェクト完了時に納品してもらえる成果物についても事前に明記してもらうのがよいでしょう。ウェブサイトそのものを納品するのはもちろんですが、マニュアルや画像素材など、どのようなものをどのような形で納品してもらえるのかを確認しておきましょう。

必要な機能の実現可否 ★★★

要望としてあげた「必要な機能」のうち、制作会社に実現できるものとそうでないものがある場合もあります。どれが実現できてどれができないのか、正確に確認しておくのがよいでしょう。

追加で提案する機能 ★

プロジェクトの目的や目標、押さえるべきポイントに対して、プラスアルファで追加提案できる機能があればあげてもらうようにするとよいでしょう。この項目は必須ではありませんが、目的や押さえるべきポイントに則したよい提案を出せるかどうかで、その制作会社が「言われたものをただ作るだけの会社」なのか「目的を共有して一緒に目標達成を目指してくれるパートナーになりうる会社」なのかを推し量ることができます。

必要なページの実現可否 ★★★

要望としてあげた「必要なページ」のうち、実現できるページとそうでないページがあれば、それをあげてもらうのがよいでしょう。

追加で提案するページ ★★

「追加で提案する機能」と同じく、プラスアルファで提案してもらえるページ案があれば出してもらうとよいでしょう。こちらも必須ではありませんが、目的・目標と押さえるべきポイントに合った、感度のよい提案をできるかどうかで、制作会社や担当者の力量をある程度知ることができます。ただ、 RFP への回答は無償で行うことが多いのが現状です。あまりに多くを求めすぎると、「アイデアを無料でもらおうとしているな」と思われるのでやり過ぎには注意が必要です。

デザイン方針・デザイン案 ★★

デザインの方向性やデザイン案についての提案を書いてもらいます。目に見える「デザイン案」の方がわかりやすくインパクトがありますが、どちらかというと重要なのは「デザイン方針」の方です。一定レベル以上の制作会社の場合は、デザイン案のレベルはどこも似たり寄ったりでそう大きな差は出ません。それよりも、目的やターゲット層に合った、「筋の通った説得力のあるデザイン方針」を打ち出してもらえるかどうかの方が重要です。

運用方針 ★★

運用方針についての提案を書いてもらいます。このあたりができるかどうかは、制作だけを行う会社なのか、ウェブ活用を総合的にサポートできる会社なのかによって、大きく異なります。ウェブをどのように活用していけばいいのかわからない、社内に運用方針を決めて運用ルール設計をリードできる人がいない、という場合は、この部分をリードしてくれる制作会社を選ぶのがよいでしょう。

体制 ★★

契約が決まったときのプロジェクト体制について記載してもらいます。 RFP の回答者がプロジェクトに関わらなかったり、メンバー構成が不明瞭だったり、といった、プロジェクトの失敗に繋がる兆候がないかを確認するとよいでしょう。事前に提示された体制図と実際にプロジェクトが始まってからの体制に違いがある場合などは、会社のスタッフの入れ替わりが激しかったり、嘘を付く会社であったりすることがあるので、そのようなことが無いように事前に念押ししておくのがよいでしょう。

スケジュール ★★

見通しのスケジュールを記載してもらいます。期待したスケジュールに合った、現実的なスケジュールを出してもらえるかどうかを確認しましょう。フェーズの分け方が妥当か、粒度が適切か、といったところからも、その制作会社の力量を推し量ることができます。

概算見積もり ★★

概算の見積もり金額を記載してもらいます。極端に金額が高い場合や低い場合を除き、金額が多少多いか少ないかはあまり問題ではありません。それよりも、提示した予算と整合しているか、明細が明確で、わかりやすい、納得できるロジックになっているかどうかの方を重視するとよいでしょう。

その他 ★

その他補足すべき点があれば記載してもらいましょう。

4. 求める提案方法

形態 ★★★

提出形態についての要望を書きます。紙の場合はサイズ等を、データの場合は拡張子などのフォーマットを指定しておくとよいでしょう。このあたりがあいまいでわかりにくと、それだけで制作会社が敬遠してしまうこともあります。

提出方法 ★★

具体的な提出方法について書きます。データの場合はメールの窓口やフォームの URL を、紙の場合は窓口を記載します。

期日 ★★★

提出期日についての要望を書きます。持ち込みでの提出を望む場合は、日付だけでなく時間まで記載しておくとよいでしょう。

5. その他

その他補足事項 ★

ここまでに上がらなかったポイントで、強いて伝えておくべき情報、依頼があれば補足して記載します。事前に質問の期間を設ける場合などは、質問の窓口と期限、回答方法等について記載しておくとよいでしょう。

……

というわけで、 RFP の構成例のご紹介でした。 あくまでもいちサンプルに過ぎませんが、ぜひ参考にしてみてください。

冒頭のお断りの繰り返しですが、 RFP は「絶対にこの形でしないといけない」というものではありません。 要は、制作会社から回答・情報提供をもらう上で、必ず伝えておくべき情報、提供してもらいたい情報をモレなく効果的に伝えられるなら、どんな構成で作っても大丈夫です。

ですので、「正解の構成」にこだわりすぎず、担当の方が自社の意思と必要な情報を伝えるのに最も伝えやすい形で作ればよいと思います。 上のサンプルはあくまでも参考として、プロジェクトごとに何が必要かを考えて最適な構成を作り上げていくとよいかと思います。

最後にいくつか注意点を述べておきます。

RFP に関していちばんよくないのは、「正解がわからないから」というのを言い訳に何の工夫も努力もしないことです。 RFP を出すべき場面で何も提示できないと、もうそれだけで、腕がよく人気の制作会社や技術者には見向きもされない、ということも起こりえます。 どういう風に作ればよいかわからない場合でも、まずは手を頭を動かして実際に作りはじめてみることをおすすめします。

また、当然ですが、 RFP に社内で合意の取れていない考えや虚偽の情報を書くことはご法度です。 制作会社はもしプロジェクトが始まれば中長期にわたりいっしょに働くパートナーです。 制作会社には「プロジェクトに必要なことはすべて開示・共有する」が原則だと思ってください。 守秘義務等が理由でどうしても言えないことがあるのであれば、嘘を書くのではなく「理由があって言えないこと」を率直に伝えるのがよいでしょう。

RFP を作ろうとしている方はぜひ参考にしてみてください :D