Web制作でRFPが必要な理由と、無しで起きる典型的な問題

Webサイトのリニューアルや制作会社の乗り換えは、「見た目を変える」だけの話ではありません。問い合わせ・採用・商談化などの成果に直結する一方で、社内外の関係者が多く、失敗すると機会損失も大きくなります。そこで効くのがRFPです。RFPは、要望を並べる資料ではなく「同じ条件で提案してもらい、比較できる状態をつくる」ための設計書です。

RFPが無い、または簡易すぎると、そもそも提案の前提が揃いません。例えば、A社は「戦略・要件整理まで込み」、B社は「デザインと実装のみ」、C社は「運用設計や計測まで込み」というように、含まれる作業がバラバラになります。その結果、安く見える案を選んだのに後から追加が積み上がる、逆に高い案の価値を説明できず見送る、といった意思決定ミスが起きやすくなります。

典型的に起きるズレは次の通りです。

• 見積の前提が揃わず、金額差の理由が最後まで解けない（比較できない）
• 「やる範囲」が曖昧なまま進み、途中で追加費用や納期延長が発生する
  スコープ＝プロジェクトで対応する範囲。
• 期待する成果が言語化されず、完成後に「思っていたのと違う」が起きる
• 乗り換え時の移行（URL、フォーム、コンテンツ、計測）が漏れて、公開後にトラブルが出る
• 社内の承認が後出しになり、手戻りでスケジュールと費用が崩れる

経営者・事業責任者の意思決定で重要なのは、「何にいくら投資し、いつまでに、どんな成果を、どのリスクを許容して狙うか」を説明できることです。RFPはその説明材料を、発注前に一枚の基準に落とし込むための道具になります。

目的とKPIと優先順位を先に固める

要件定義＝目的達成に必要な機能や条件を具体化し合意すること。RFPの品質は、要件定義の初期精度でほぼ決まります。特にBtoBサイトでは、営業・採用・広報・情報システムなど関係部門がまたがるため、早めに「目的」と「優先順位」を合意しておくほど後工程が軽くなります。

KGI＝事業の最終目標を表す指標。KPI＝目標達成度を測る指標。KGIとKPIを分けると、経営層の視点（最終成果）と現場の視点（途中指標）が接続し、RFPが「成果の設計図」になります。

KPIは「問い合わせ数」だけで終わらせず、意思決定に使える粒度まで揃えるのが安全です（例：問い合わせのうち商談化した件数、採用応募のうち面接設定に至った数など）。ただし、測定できない指標を掲げると運用で形骸化します。現状の計測体制で追える指標に寄せ、追加で必要な計測がある場合はRFPに明記します。

予算についても、発注前に「考え方」を揃えておくとブレません。TCO＝導入後の運用費も含めた総コスト。初期費用だけで判断すると、保守・更新・改善の費用が別枠になり、結果的に運用が止まることがあります。RFPでは、想定レンジとともに「費用に含めたい範囲（例：保守、軽微改修、運用設計、計測設定）」を言語化しておくと、提案の比較がしやすくなります。

優先順位付けは、次の3点セットで決めると社内合意が取りやすくなります。

• 成果インパクト：目的にどれだけ効くか
• 期限：いつまでに必要か（例：展示会、採用期、製品リリース）
• 制約：法務・セキュリティ・ブランドなど絶対条件

ここで重要なのは、制作会社に「作り方」を丸投げしないことです。みやあじよの制作方針でも、デザインは問題解決であり、先に目的を具体化してからコンセプトとターゲットを設計することを重視しています。

コンセプト＝サイトで一貫して伝える中核メッセージ。

また、サイトはページ単体ではなく全体のストーリーで信頼を作ります。初見で伝えたいメッセージが通る構成かを、RFP段階から意識しておくと提案の質が上がります。

Web制作RFPテンプレートの全体像

RFPは、長ければ良いわけではありません。比較に必要な情報が揃い、提案の粒度が揃うことが目的です。最低限、次のブロックで構成するとブレが減ります。

• 背景・現状：なぜ今やるのか、現状の課題は何か
• 目的・KPI：成功の定義と測り方
• 対象範囲：対象ページ、機能、移行対象、やらないこと
• 要件：機能要件＝実現したい機能の条件、非機能要件＝速度や安全性など機能以外の品質条件
• 体制・進め方：社内の意思決定、会議体、レビュー方法
• スケジュール：希望時期、マイルストーン＝節目となる計画上の通過点
• 予算感：上限ではなく「想定レンジ」と前提（段階発注も含む）
• 提案依頼内容：提案に含めてほしいもの（構成案、進行案、概算、体制）
• 評価基準：何を重視して選ぶか（配点まで決めると比較しやすい）
• 契約・条件：検収＝成果物が条件を満たしているか確認し受け取る手続き、保守範囲、追加作業の扱い

RFPに入れるべき要素を「誰が判断するか」まで落とし込んだチェックリストを置きます。まずは空欄を埋めるだけでも、社内の論点が揃います。

項目	記載する内容	判断材料	関係者
背景・狙い	実施理由、現状課題、期待効果	事業計画、営業/採用課題	経営・事業責任者
目的	売上/問い合わせ/採用などの優先度	KGI、重点領域	経営・事業責任者
KPI	測定可能な指標と目標の置き方	現状値、計測手段	事業・Web担当
対象範囲	対象サイト/ページ/言語、やらない範囲	現行サイト棚卸し	Web担当・関係部門
移行対象	URL、コンテンツ、フォーム、計測	現行構成、運用実態	Web担当・情シス
必須要件	絶対に必要な機能/制約	法務・セキュリティ要件	情シス・法務
運用要件	更新フロー、権限、公開手順	運用体制、頻度	Web担当・広報
体制	社内責任者、承認者、窓口	組織図、決裁ルート	経営・各部門
期限	公開希望日と理由、優先度	施策カレンダー	事業責任者
評価基準	価格/体制/品質/運用など配点	重視事項の合意	経営・事業責任者

情シス＝情報システム部門（社内のIT運用を担う部署）。RFPを整えるほど、ベンダーは提案に時間を使えるようになり、見積の不確実性も下がります。結果として「比較しやすさ」と「納得感」が上がり、社内の決裁も通しやすくなります。

要件の書き方ガイド 現状整理から範囲と条件まで

RFPでつまずきやすいのは「要件が曖昧で、提案の粒度が揃わない」ことです。要件が比較可能な形に整っていれば、見積も提案も判断しやすくなります。

現状整理は「ページ」と「業務」で棚卸しする

まず現行サイトを、ページ単位と業務単位に分けて棚卸しします。ページ単位では、全ページ一覧、URL、役割（何のためのページか）、更新頻度、担当部署、流入経路を並べます。業務単位では、問い合わせ対応、資料請求、採用応募、掲載依頼など、サイトが関わる社内フローを洗い出します。ここが抜けると、公開後に「運用できない」「更新が止まる」リスクが上がります。

現状課題は事実ベースで書ける形にします。例として、問い合わせの質が低い、採用の応募が偏る、製品情報が探しにくい、更新が属人化している、などです。みやあじよの制作方針でも、表現を先に決めず、目的と現状の把握から設計することを重視し、構成案では初見で伝えたいメッセージの流れも確認します。

スコープを「必須・任意・対象外」で三分割する

スコープ＝プロジェクトで対応する範囲。スコープは「やる／やらない」を明確にしないと、提案も見積も揃いません。そこで、要望を次の3つに分類します。

• 必須：今回の投資判断に直結し、外せないもの
• 任意：予算やスケジュール次第で採用するもの
• 対象外：今回やらない（ただし将来の拡張は想定する）

この三分割をRFPに入れると、各社が提案で「優先順位」と「代替案」を出しやすくなります。任意要件は、段階導入で後回しにする提案が出ることも多く、投資判断の幅が広がります。

要件は「目的→利用者→機能→判断基準」の順で書く

要件を機能の羅列から始めると、成果につながらない機能が増えがちです。実務上は、目的から逆算して書くとブレにくくなります。

• 目的：何を増やす／減らすための要件か
• 利用者：誰が、どんな状況で使うか
• 機能：そのために必要な仕組み
• 判断基準：できたと言える条件（受け入れ条件）

受け入れ条件＝成果物が要件を満たすかを判断する基準。例えば「お問い合わせフォームを作る」だけではなく、「必須入力の未入力時はエラー表示」「自動返信メールの文面は編集可能」「スパム対策を実装」など、曖昧さを減らす表現にします。経営層が見るRFPでは、細かい仕様の全列挙よりも、判断基準が揃っていることが重要です。

非機能要件と移行条件を先に書く

非機能要件＝速度や安全性など機能以外の品質条件。ここは後回しにするとトラブルになりやすい領域です。最低限、次の観点はRFPに含めます。

• セキュリティ：管理画面の権限、操作履歴、弱点への対策方針
• 障害時対応：復旧手順、バックアップ
• 表示速度：重いページの改善方針（画像最適化など）
• アクセシビリティ：高齢者や障害のある方にも配慮した設計指針
  アクセシビリティ＝利用者の特性に左右されず情報に到達できる状態。
• 運用性：更新フロー、承認、権限設計

移行は、URLの引き継ぎ、リダイレクト＝旧URLから新URLへ自動転送する設定、フォームの再構築、計測設定の引き継ぎが中心です。SEO＝検索結果で上位表示を狙う施策の観点でも、移行条件は早期に合意しておくほど安全です。

費用と見積比較の観点 内訳と前提条件の揃え方

経営判断で困るのは「見積の比較ができない」状態です。RFPで前提条件を揃えると、費用差の理由が説明可能になります。

見積の前提条件をRFPで固定する

見積の前提は、できるだけ言語化して揃えます。例えば、ページ数の数え方（テンプレートで増えるページの扱い）、CMS＝専門知識がなくても更新できる管理機能、対応言語、フォーム数、外部ツール連携（例：CRMやMA）などです。CRM＝顧客情報を管理し営業活動に活用する仕組み。MA＝見込み顧客の育成を自動化する仕組み。

また、コンテンツ制作を誰が担うか（社内で書くのか、外注するのか）、写真撮影や取材の有無も、費用と納期に直結します。曖昧だと、見積が後から膨らむ原因になります。

見積の「抜け」を防ぐ観点

比較時に抜けやすいのは、進行管理、テスト、移行、公開後の安定化、運用引き継ぎです。提案依頼の段階で「含めてほしい作業」を明示すると、各社が同じ土俵で提案しやすくなります。

費用項目	含まれる作業範囲	比較ポイント	注意点
要件定義・設計	目的整理、構成案、仕様整理	合意プロセスの明確さ	範囲が浅いと後で追加になりやすい
デザイン	主要ページのデザイン、画面設計	制作物の範囲と修正回数	ページ数の数え方で差が出る
実装・CMS	表示部分の実装、管理機能構築	更新権限、拡張性	共通化の度合いで工数が変わる
移行・リダイレクト	コンテンツ移行、URL転送	移行対象の定義と検証	SEOや計測の影響が大きい
テスト・品質保証	動作確認、表示確認、受入支援	テスト観点と担当分担	担当が曖昧だと抜けが出る
進行管理・コミュニケーション	進行管理、会議運営、課題管理	体制、連絡頻度、議事管理	軽視すると納期と品質が崩れやすい
運用設計・引き継ぎ	更新フロー、マニュアル、教育	誰が運用できる状態にするか	公開後に更新が止まる原因になりやすい

体制と進め方 役割分担とスケジュール管理

ベンダー選定の前に、社内体制を決めておくと、提案の質とスピードが上がります。特に「意思決定が遅い」「レビューが増える」ことが、納期と費用を押し上げます。

役割分担をRACIで明確にする

RACI＝担当（Responsible）、最終責任（Accountable）、相談（Consulted）、共有（Informed）を整理する枠組み。例えば、経営者は最終責任、事業責任者は判断の窓口、Web担当は要件整理とレビュー、情シスはセキュリティとサーバー等の基盤、制作会社は進行と実装、のように置きます。

「誰が決めるか」をRFPに書いておくと、制作会社は提案時点から会議体やレビュー回数を現実的に設計できます。結果として、提案の比較がしやすくなります。

スケジュールは成果物ベースで管理する

スケジュールは、日付だけでなく成果物で管理します。例として、構成案の承認、主要ページデザインの承認、仕様確定、移行計画確定、テスト完了、公開判定などです。検収＝成果物が条件を満たしているか確認し受け取る手続きも、どのタイミングで何を見て判断するかを決めておくとトラブルが減ります。

また、社内で準備が必要なタスク（原稿作成、資料準備、写真手配、法務確認）は、制作会社の工程とは別のボトルネックになりやすいので、RFPで「社内作業の前提」を明記しておくと安全です。

リスクとトラブル予防 品質とSEOとセキュリティと移行

リニューアルやベンダー変更で最も避けたいのは「公開したのに成果が落ちた」「トラブル対応で現場が疲弊した」です。RFPで先に手当てすべき代表的なリスクは、だいたい次の4つに集約されます。

1 SEOの下落リスクを設計で抑える

SEO＝検索結果で上位表示を狙う施策。リニューアルで順位や流入が落ちる主因は、URL変更・内部リンクの崩れ・コンテンツの削減・表示速度の悪化・計測不備などです。RFPには「移行で守りたいもの」を明確に書きます。

• URL方針：原則維持するのか、整理するのか
• リダイレクト＝旧URLから新URLへ自動転送する設定：誰が、どの粒度で、いつ検証するか
• 既存コンテンツ：残す／統合する／削除する基準
• タイトル・見出し・構造：ページの役割を保つ（単に短くしない）
• 表示速度：画像最適化、不要な機能を入れすぎない方針

「順位を上げる」より前に、「落とさないための条件」をRFPで揃えるのが経営判断として堅実です。

2 品質は「テスト計画」と「受け入れ条件」で守る

テスト＝想定通りに動くか確認する工程。品質は制作会社の技量だけでは決まりません。確認の観点と責任分担が曖昧だと、抜けが起きます。RFPで以下を固定すると、提案が揃いやすくなります。

• テスト範囲：フォーム、検索、スマホ表示、主要ブラウザ、管理画面
• 受け入れ条件＝できたと言える判定基準：重大不具合の定義、修正期限
• 体制：誰が確認し、いつ承認するか（レビュー回数も含む）

3 セキュリティは「責任分界」と「運用」をセットで書く

セキュリティは機能の追加よりも、権限・運用ルールの曖昧さで崩れがちです。RFPでは、制作中だけでなく公開後まで含めて、最低限これだけは明確にします。

• 管理画面の権限設計：部署別に何ができるか
• 操作ログ＝誰が何をしたかの履歴：必要性と保存期間
• アカウント運用：退職者や異動時の変更手順
• 外部連携（フォーム通知、CRM連携など）の扱い

情シスが関与する場合は、ホスティング（サーバー等の稼働環境）やアカウント管理の分担をRFPに書くと、提案や見積が現実的になります。

4 移行は「対象の棚卸し」と「検証」が勝負

移行トラブルは、想定外の運用が埋まっていることが原因になりやすいです。RFPでは「移行対象」と「検証方法」をセットで書きます。

• 移行対象：ページ、PDF、フォーム、メール文面、計測、リダイレクト
• 検証：公開前後で何を照合するか（主要ページ、主要導線、フォーム送信、計測）

「問題解決のために何が最善か」を前提に、表現や手段に固執しない姿勢は、リスク整理にも直結します。

ベンダー選定の評価基準と、提案を揃える依頼文

ベンダー選定で重要なのは「価格の安さ」より、「条件が揃った提案を比較し、将来の運用まで含めて説明できる状態」です。RFPの評価基準は、提案の質を上げるためのガイドにもなります。

評価基準は「配点」と「確認方法」まで決める

評価軸だけだと、最終的に印象勝負になりがちです。配点（重み）と確認方法をセットにすると、意思決定が速くなります。

評価軸	重み	確認方法	メモ
目的/KPIの理解と提案の筋	25	提案書の構成、課題整理、優先順位	要望の受け身か、狙いまで踏み込むか
体制/進行管理	20	担当者の役割、会議体、課題管理方法	社内負担の見込みが現実的か
品質/リスク対応	20	テスト計画、移行計画、SEO配慮	「落とさない」設計になっているか
費用の妥当性	20	見積内訳、前提条件、追加時の扱い	TCO視点で比較できるか
運用設計と改善提案	15	更新フロー、改善サイクル、計測設計	公開後に成果が伸びる道筋があるか

点数は例で、社内の優先順位に合わせて調整します。特に経営層が納得しやすいのは「費用の妥当性」と「リスク対応」が、提案の中で具体的に説明されているかです。

提案を揃えるための依頼文テンプレート

同条件で比較するために、RFPに「提案に必ず含めてほしい内容」を明記します。以下は依頼文の骨子例です（そのままコピペして整えられる形）。

• 依頼背景：リニューアル/ベンダー変更の理由、現状課題
• 目的・KPI：優先順位（例：問い合わせの質、採用応募、信頼性向上）
• 対象範囲：対象ページ/機能、やらないこと、移行対象
• 提案に含めてほしい成果物：
  • 進め方（工程、会議体、社内の役割分担案）
  • 概算見積（内訳と前提条件、追加時の扱い）
  • リスクと対策（SEO、移行、セキュリティ、品質）
  • 公開後の運用案（更新フロー、改善の回し方）
• スケジュール：提案期限、質疑期限、打ち合わせ日程、公開希望時期
• 評価基準：配点と重視事項
• 連絡方法：窓口、返信ルール、資料の提出形式

「ストーリーが初見で伝わる構成か」を継続的に確認する姿勢は、提案内容の比較でも効きます。

発注後の更新と改善 乗り換え後に成果を出す運用の考え方

発注がゴールになると、公開後に更新が止まり、投資が目減りします。BtoBサイトは、製品情報・事例・採用情報など「鮮度」が信頼に直結するため、運用設計までRFPで地ならししておくのが安全です。

運用設計で決めるべき最小セット

運用設計＝公開後に更新・改善を回すための体制と手順を決めること。最低限、次を合意しておくと「止まる原因」を減らせます。

• 更新の種類：軽微修正、ページ追加、コンテンツ更新、改善施策
• 申請フロー：誰が依頼し、誰が承認するか
• 公開ルール：いつ公開し、誰が最終確認するか
• 権限：誰が編集でき、誰が公開できるか
• 計測：KPIをどの頻度で見て、改善をどう決めるか

改善は大掛かりな改修だけではありません。導線の見直し、コンテンツの追加、フォームの改善など、小さく回すほど結果に繋がりやすくなります。そこで、制作会社に運用を委託する場合でも、社内に最低限の判断者を置き、意思決定が止まらない形にすることがポイントです。

当社の提供領域（要件定義支援、Web制作・リニューアル、PM支援、運用設計）で言えば、RFPの段階から「比較できる提案条件」と「公開後に回る運用」を同時に整えることで、乗り換えの失敗確率を下げやすくなります。

まとめ

Web制作のRFPは、制作会社に丸ごと任せるための資料ではなく、「同条件で提案を揃え、意思決定を速くし、公開後まで成果を出す」ための基盤です。ポイントは次の通りです。

• 目的とKPIを先に固め、優先順位を言語化する
• スコープを必須・任意・対象外に分け、見積前提を揃える
• SEO・品質・セキュリティ・移行のリスクをRFPに組み込む
• 評価基準は配点と確認方法まで決め、比較可能にする
• 公開後の運用設計まで見据え、更新と改善が止まらない形にする