良い提案を引き出すWebサイトRFPの作り方｜発注側が整理すべき項目と書き方

Webサイトの制作やリニューアルを外注するとき、「問い合わせを増やしたい」「デザインを新しくしたい」といった要望だけを制作会社へ伝えると、各社が異なる前提で提案を作ることになります。

A社はSEOを中心に提案し、B社はページ数を増やし、C社は全面リニューアルを提案する。

見積金額も300万円、500万円、800万円と異なる。これでは、金額の差が会社の違いなのか、提案範囲の違いなのか判断できません。

そこで必要になるのがRFP（Request for Proposal／提案依頼書）です。

ただし、RFPは発注側がWeb制作の仕様を細部まで決める資料ではありません。

自社が解決したい課題、絶対に守りたい条件、制作会社に考えてほしい領域を整理し、同じ前提から質の高い提案を出してもらうための資料として使うことが重要です。

IPAが公開するSEC journalの研究でも、RFPの記述が十分でない場合、契約後に発注側が意図した要求と、受注側が理解した要求との間にギャップが明らかになることがあると指摘されています。

「提案依頼書に含まれる無理難題の分類」でも、RFPを開発プロジェクトのベースとなる重要な文書として扱っています。

良いRFPを作るには、テンプレートを埋める前に「発注側が決めること」と「制作会社へ提案してもらうこと」を切り分ける必要があります。

1．RFPは「仕様を指示する資料」ではなく「良い提案を引き出す資料」

RFPを作ると聞くと、ページ数、CMS、デザイン、必要機能などをできるだけ細かく決めるものだと考えがちです。

しかし、解決方法まで発注側が指定すると、制作会社は決められた内容を実装するだけになります。RFPで重要なのは、制作方法を指定することではなく、何を解決したいのかを明確にすることです。

1-1．RFPがないと各社の提案条件が揃わない

例えば、「問い合わせが増えるホームページを作りたい」とだけ依頼した場合、問い合わせが増えない原因を各社がそれぞれ推測します。

検索流入が不足していると考える会社もあれば、サービスページの説明不足、問い合わせ導線、フォームの使いにくさを問題と考える会社もあります。

提案の方向性が異なること自体は問題ではありません。しかし、現在のアクセス状況や課題、予算、期限などの前提条件まで異なる状態では、提案を正しく比較できません。

1-2．RFPで「共通のスタート地点」を作る

RFPには、少なくとも現状、課題、目的、ターゲット、予算、期限、制約、提案してほしい内容を整理します。

ここまでを共通情報として渡したうえで、「この課題をどう解決するか」を制作会社へ提案してもらいます。

つまりRFPは、答えを指定する資料ではなく、同じ問題について複数の専門家から答えを出してもらうための前提資料です。

1-3．細かく指定するほど良いRFPになるわけではない

例えば、

「WordPressで構築すること」

と指定する前に、本当に必要なのは何かを考えます。

要望が「社内担当者が月2回、導入事例を自分で追加できること」であれば、それを要求として記載し、CMSの選択は提案してもらう方法があります。

発注側が決めるべきなのは、実現したい状態です。専門的な解決方法まで分からない場合は、無理に仕様化する必要はありません。

2．RFPを書く前に「目的・課題・施策」を分ける

RFP作成で起こりやすい失敗が、「サイトをリニューアルすること」そのものが目的になることです。

制作会社へ依頼する前に、なぜWebサイトへ投資するのか、何が問題なのか、どの成果を求めるのかを分けます。

2-1．「リニューアル」は目的ではなく手段

例えば、問い合わせ改善を目的としたリニューアルなら、次のように整理できます。

分類	記載例
現状	月間問い合わせ20件
課題	サービスページからフォームへの遷移が少ない
目的	新規商談を増やす
ゴール	月間問い合わせを20件から30件へ増やす
検討する施策	導線、コンテンツ、フォームなどの改善
手段	Webサイトのリニューアル

このように整理すると、「サイトを新しくしてください」ではなく、「問い合わせ増加という目的を実現する方法を提案してください」と依頼できます。

デザイン刷新が必要なのか、ページ構成の変更で済むのか、コンテンツ追加が必要なのかは、その後に判断できます。

2-2．現状の「事実」と原因の「仮説」を分ける

RFPには、確認できている事実と、自社が推測している原因を分けて書きます。

「サービスページからフォームへの遷移率が低い」はデータから確認できる事実です。

一方、「デザインが古いから問い合わせされない」は仮説です。

仮説を確定事項として扱い、「デザインを全面刷新すること」と書いてしまえば、制作会社が別の原因を発見しても提案へ反映しにくくなります。

事実は共有し、原因と解決方法には提案余地を残すことが重要です。

3．社内の要求を集め、優先順位をつける

Webサイトには、経営者だけでなく営業、人事、広報、マーケティング、システム担当など複数の関係者が関わります。

発注後に各部署から追加要望が出続けると、予算とスケジュールが膨らみます。

RFP作成時点で要求を集め、今回やることとやらないことを決めておきます。

3-1．要求をMust・Should・Could・Won’tへ分ける

すべての要望を同じ重要度で扱わず、次のように分類します。

優先度	意味	Webサイトでの例
Must	満たせなければ発注できない	スマホ対応、社内更新機能
Should	原則として実現したい	導入事例の絞り込み
Could	予算・期間次第	動画制作、多言語対応
Won’t	今回は実施しない	会員システムの刷新

特に重要なのがWon’tです。

「今回はやらないこと」を決めておかなければ、制作途中で「あれも追加したい」という要望が増え、当初の目的から離れていきます。

3-2．最終決定者を決める

要求を出す人と、採用する要求を決める人も分けます。

営業、人事、経営者のすべての意見をそのままRFPへ入れるのではなく、プロジェクト目的への影響を判断したうえで採否を決めます。

デザインやページ構成についても、最終承認者を発注前に決めておくと、制作段階で意思決定が止まりにくくなります。

4．Webサイト制作のRFPに必要な基本項目を書く

社内整理が終わったら、RFP本体へ落とし込みます。

重要なのは、項目をすべて埋めることではありません。

制作会社が提案を考えるために必要な情報が揃っているかを確認します。

4-1．プロジェクト概要

背景、現状、課題、目的、ターゲット、目標、公開希望時期、予算を記載します。

「2019年に制作して古くなったため」だけでなく、「サービスが3事業から7事業へ増え、現在のサイト構造ではユーザーが目的の情報へ到達しにくい」といった、なぜ今取り組むのかが分かる情報を書きます。

4-2．現在のWebサイト環境

CMS、ドメイン、サーバー、問い合わせフォーム、アクセス解析、広告タグ、外部システムとの連携などを整理します。

技術的な内容が分からない場合は、推測して記載せず、「現状調査を提案範囲に含める」とする方法もあります。

4-3．制作対象と役割分担

何ページ作るかだけでなく、原稿、画像、撮影、既存コンテンツ移行を誰が担当するかを決めます。

作業	自社	制作会社	要相談
商品・サービス情報の提供	○
原稿作成		○
写真撮影		○
導入事例の取材			○
既存記事の移行		○
公開後のお知らせ更新	○

役割分担が曖昧なままでは、見積金額や制作期間も揃いません。

「サイト制作一式」という言葉だけで発注せず、素材準備まで含めて担当範囲を整理します。

4-4．セキュリティやアクセシビリティも要件として具体化する

「安全なサイトにする」「アクセシビリティに配慮する」といった表現だけでは、納品時に達成できたか判断できません。

セキュリティについては、IPAの「安全なウェブサイトの作り方」が、SQLインジェクションやクロスサイト・スクリプティング、アクセス制御など、Webサイトで考慮すべき代表的な脆弱性と対策を整理しています。

アクセシビリティについても、デジタル庁の「ウェブアクセシビリティ導入ガイドブック」は、発注・受託業務で確認すべきポイントを対象読者に含めています。

対応水準を指定する場合は、「アクセシビリティ対応」とだけ書かず、対象ページと基準を明確にします。W3Cの「Web Content Accessibility Guidelines（WCAG）2.2」では、適合レベルをA・AA・AAAに分けています。

要件は、できるだけ納品時に確認できる表現へ変えることが重要です。

5．「発注側で決めること」と「制作会社へ提案してもらうこと」を分ける

RFPの質を左右するのが、この境界です。

発注側が何も決めなければ丸投げになりますが、すべてを決めれば制作会社の専門性を生かせません。

5-1．発注側は「条件」を決める

目的、予算、期限、ターゲット、必須要件、社内ルールなどは発注側が決めます。

一方、サイト構造、UX、具体的な導線、デザイン、CMSの選択などは、目的を達成する方法として提案してもらえる領域です。

違いを整理すると、次のようになります。

解決方法を先に指定	実現したい状態を伝える
WordPressを使う	社内担当者だけで更新できる
トップページに動画を置く	初訪問者が短時間で事業内容を理解できる
FAQを30件作る	問い合わせ前の疑問を自己解決できる
メニューを固定する	主要ページへ迷わず移動できる
50ページ作る	必要な情報を不足なく整理できる

発注側がWeb制作の専門家になる必要はありません。

「どう作るか」ではなく「どうなってほしいか」を正確に伝えることが、制作会社の提案力を引き出します。

6．制作会社へ提案してほしい内容を具体的に書く

「自由に提案してください」だけでは、各社から提出される資料の内容が揃いません。

比較したい内容については、何を提案書へ記載してほしいかをRFPで指定します。

6-1．課題に対する改善方針を求める

サイトマップだけを提出してもらうのではなく、「現在の課題をどのように解決する設計なのか」まで説明を求めます。

例えば、問い合わせ増加が目的なら、サービスページ、導線、CTA、フォームをどう設計するのか、その考え方を提案内容に含めてもらいます。

6-2．体制とスケジュールを求める

制作会社側の工程だけでなく、自社側で必要になる作業も提示してもらいます。

「5月：デザイン」と書くだけではなく、「5月10日までに発注側がサービス原稿を提出」のように、自社がいつ何を準備するのかまで分かる提案にします。

6-3．見積もりの分け方を指定する

総額500万円という見積もりだけでは、他社と比較できません。

企画・設計、デザイン、実装、CMS、コンテンツ制作、撮影、移行、公開作業など、主要項目を分けて提示してもらいます。

ここで重要なのは、価格を安くすることではなく、各社の見積もりに何が含まれ、何が含まれないかを確認できる状態にすることです。

7．予算・スケジュール・提出条件を曖昧にしない

RFPの目的や要件が明確でも、予算や期限が曖昧では、制作会社は現実的な提案を作れません。

発注条件も提案品質を左右する情報として扱います。

7-1．予算は対象範囲とセットで書く

例えば、

「予算500万円」

ではなく、

初期制作費400～500万円を想定。企画、情報設計、デザイン、実装、CMS構築、公開作業を含む。写真撮影と公開後の保守費用は別途提示。

と書きます。

同じ500万円でも含まれる業務が違えば、提案内容は変わります。

7-2．希望日と絶対期限を分ける

「10月公開希望」と「10月1日にキャンペーンを開始するため公開必須」では意味が違います。

絶対に動かせない期限がある場合は、その理由まで伝えます。

また、RFP配布後には質問受付期間を設けます。重要な質問への回答は参加企業へ共通で共有し、企業ごとの情報格差が生じないようにします。

8．RFP完成後に「良い提案ができる資料か」を確認する

RFPの完成基準は、ページ数や情報量ではありません。

第三者が読んだときに、「何が問題で、何を実現するための提案を求められているのか」を理解できる状態になっているかを確認します。

発注前には、次の項目をチェックします。

確認項目	判断
Webサイトへ投資する理由を説明できる	○／×
現状の事実と原因の仮説を分けている	○／×
最優先の目的が決まっている	○／×
Must要件が明確	○／×
今回やらないことが明確	○／×
制作会社へ提案してほしい範囲が分かる	○／×
自社と制作会社の役割を分けている	○／×
予算に含む範囲を明記している	○／×
提案書で回答してほしい内容が明確	○／×
公開期限と最終承認者が決まっている	○／×

複数の項目が「×」になる場合は、RFPを配布する前に社内整理へ戻ります。

特に「目的」「Must要件」「提案してほしい範囲」の3つが曖昧なままでは、制作会社へ渡す情報を増やしても良い提案にはつながりにくくなります。

9．RFPは制作会社へ渡した後も判断基準として使う

RFPは制作会社を決めたら役目を終える資料ではありません。

Web制作では、プロジェクトが進むにつれて「動画を追加したい」「このページも作りたい」といった要求が増えることがあります。

そのたびに、RFPへ記載した目的へ戻ります。

9-1．追加要望を目的と照合する

例えば、「トップページへ動画を追加したい」という要望が出た場合、追加するかどうかを好みだけで決めません。

問い合わせ増加という目的に必要なのか、Must要件なのか、費用と公開時期へどの程度影響するのかを確認します。

必要性が低ければ、次回改善へ回す判断もできます。

9-2．変更内容を記録する

仕様を変更した場合は、変更内容、理由、追加費用、スケジュールへの影響を残します。

公開前には当初のRFPと成果物を照合し、Must要件が満たされているか、依頼した内容が実装されているかを確認します。

RFPをプロジェクト全体の判断基準として使えば、制作途中の要望追加によって目的が変わってしまうことも防ぎやすくなります。

まとめ｜良いRFPは「作ってほしいサイト」より「解決したい課題」が明確

良いRFPを作るために、発注側がWeb制作の専門知識をすべて身につける必要はありません。

整理すべきなのは、なぜWebサイトへ投資するのか、現在何が問題なのか、何を必ず実現したいのか、どこから制作会社へ提案してほしいのかです。

細かな解決方法まで発注側が決めれば提案の余地がなくなり、反対に何も決めなければ丸投げになります。

最初にRFPのテンプレートを開くのではなく、A4一枚に次の3項目を書いてください。

「今回解決したい経営・営業上の課題」
「今回必ず実現したいこと」
「制作会社へ提案してほしいこと」

この3つを経営者と担当者で合意してから、背景、要件、予算、役割分担、提案依頼内容へ落とし込んでいきます。

RFPを「制作会社へ何を作らせるかを指示する文書」ではなく、自社の課題を正しく伝え、専門家から良い解決策を引き出すための文書として作ることが、Webサイト発注の質を高める第一歩です。