ホームページ制作のRFPに必要な項目|提案依頼書の作り方
執筆・監修:株式会社AO
ホームページ制作を複数社へ依頼するとき、各社へ伝えた条件が違えば、提案内容や見積金額を公平に比較できません。RFP(Request for Proposal/提案依頼書)は、目的、対象範囲、前提、要件、成果物、進め方、回答方法、評価基準を一つにまとめる資料です。本記事では、中小企業のコーポレートサイト新設・リニューアルを想定し、未確定事項を無理に決め切らず、制作会社の提案余地を残したRFPの作り方を解説します。
この記事で分かること
- RFP、要件定義書、見積依頼書の役割の違い
- ホームページ制作のRFPに入れる12項目
- 既存サイト、コンテンツ、URL、アカウントを漏れなく渡す方法
- 提案内容と見積もりを同じ条件で比べる回答様式・評価表
- そのまま編集できるRFP構成テンプレートと提出前チェックリスト
RFPは「何を提案してほしいか」を同じ条件で伝える資料
RFPは完成済みの設計書ではありません。発注側が事業目的、制約、現在分かっている要件、提案してほしい論点を示し、候補会社が実現方法、体制、工程、費用、リスクを回答できる状態にするものです。未確定事項は隠さず、「提案を求める」「契約後に確定する」「対象外」のいずれかを記載します。
| 資料 | 主な役割 | 書く内容 |
|---|---|---|
| RFP(提案依頼書) | 候補会社へ同じ条件で提案を求める | 目的、範囲、要件、前提、回答様式、評価基準 |
| 要件定義書 | 作るもの・満たす条件を具体化する | 業務、機能、画面、データ、非機能、運用など |
| 見積依頼書 | 価格と前提条件の提示を求める | 費目、数量、期間、支払条件、見積有効期限など |
| 契約書・仕様書 | 合意した責任と条件を確定する | 業務範囲、成果物、検収、変更、権利、費用など |
ホームページ制作会社の選び方は依頼先を評価する観点、ホームページリニューアルの進め方は企画から公開後までの工程を扱います。本記事は、各社へ渡す依頼条件と、各社から受け取る回答形式を具体化することに絞っています。
デジタル庁の標準ガイドラインは政府情報システム向けのルールであり、民間企業のホームページ発注にそのまま義務付けられるものではありません。ただし、背景・目的・期待効果、要件、作業内容、成果物、体制、遵守事項、成果物の取扱いを整理する構成や、未確定要件をリスクとして明示する考え方は、民間のRFPでも参考になります。
ホームページ制作のRFPに必要な12項目
| 項目 | 記載する内容 | 確認できること |
|---|---|---|
| 1. 背景・目的 | 現状の課題、サイトの役割、公開後に実現したい利用者行動 | 提案が事業課題から逆算されているか |
| 2. 対象ユーザー | 顧客、採用候補、取引先など、優先する利用者と検討状況 | 情報設計・導線の前提が合っているか |
| 3. 対象範囲 | 対象サイト、ページ群、言語、サブドメイン、対象外作業 | 見積範囲の差を減らせるか |
| 4. コンテンツ | 想定ページ、原稿、写真、動画、資料、作成・承認担当 | 素材待ちや追加制作の責任が明確か |
| 5. 機能要件 | CMS、フォーム、検索、多言語、外部サービス連携など | 必須機能と提案機能を区別できるか |
| 6. 非機能要件 | アクセシビリティ、速度、セキュリティ、バックアップ、対応環境 | 「対応する」の確認方法が示されるか |
| 7. SEO・計測・移行 | URL方針、リダイレクト、メタ情報、構造化データ、GA4、Search Console | 公開時の検索・計測事故を防げるか |
| 8. 体制・役割分担 | 意思決定者、窓口、制作側の責任者、承認手順、会議頻度 | 誰の判断待ちになるか把握できるか |
| 9. 工程・希望時期 | 提案、契約、設計、制作、確認、公開の希望日と固定条件 | 実現可能な工程と依存関係が分かるか |
| 10. 成果物・検収 | サイト、データ、設計書、マニュアル、アカウント、検収条件 | 完了の定義と引き渡し内容が明確か |
| 11. 費用・契約条件 | 予算の有無、費目別見積、追加費用条件、保守、権利、再委託 | 初期費用以外の前提を比較できるか |
| 12. 提案・選定方法 | 質問期限、提出日、回答様式、プレゼン、評価項目、連絡方法 | 各社を同じ情報と尺度で比べられるか |
項目数を増やすことが目的ではありません。「必須」「希望」「提案を求める」「対象外」「未確定」を明記し、候補会社が前提を誤解せず、代替案を出せる粒度にします。特定のCMSや実装方法を理由なく固定すると、より適した提案を排除する場合があるため、手段ではなく必要な業務・利用者体験・確認条件から書きます。
RFPに添付する現状資料を先に棚卸しする
本文だけで現状を説明し切ろうとすると、RFPが長くなり、更新漏れも起きます。RFP本文には前提と参照先を書き、事実資料は別紙に分けます。候補会社全社へ同じ版を共有し、差し替えた場合は変更履歴を通知してください。
- サイト・URL一覧:現URL、ページ名、種類、維持・統合・削除の希望、流入や問い合わせへの重要度
- アクセス・検索データ:共有できる範囲のGA4、Search Console、フォーム実績。集計期間と定義を併記
- コンテンツ台帳:原稿、画像、動画、PDF、導入事例、利用許諾、更新担当
- システム・契約一覧:ドメイン、DNS、サーバー、CMS、フォーム、メール、計測、外部サービスの管理者
- ブランド資料:ロゴ、色、書体、表記ルール、写真方針。守るものと変更可能なものを区別
- 社内体制表:意思決定者、窓口、各部門の確認者、法務・個人情報・セキュリティの確認先
- 既知の制約:公開期限、使用必須の仕組み、社内ネットワーク、承認日程、契約上の制約
コピーして使えるRFP構成テンプレート
テンプレートを埋める前に、各項目の所有者を決めます。サイト担当者だけで決められない契約、個人情報、セキュリティ、採用、営業、広報の条件は、関係部門へ確認して「確認済み」「確認中」を記録します。
RFPを作る7ステップ
- 目的を一文にする:「リニューアルする」ではなく、誰が何を理解・判断・実行できるサイトにするかを書きます。
- 現状を事実で集める:URL、コンテンツ、アクセス、問い合わせ、契約、アカウント、運用作業を棚卸しします。
- 範囲と対象外を分ける:新規制作、移行、撮影、原稿、外部連携、保守について、今回含める作業を明記します。
- 要件へ優先度を付ける:必須、希望、提案、未確定、対象外に分類し、必須には確認方法を付けます。
- 社内の役割と承認日を決める:誰が何をいつ判断するかを工程に入れ、候補会社だけに日程リスクを負わせないようにします。
- 回答様式と評価表を作る:提案書の章立て、見積費目、前提・対象外・リスク欄を統一し、配布前に評価軸を決めます。
- 第三者視点で読み合わせる:初見の人が同じ範囲を想定できるか、矛盾、未定、機密情報、古い添付資料がないか確認します。
RFP配布後の質問と回答は、原則として全候補会社へ同じ内容を共有します。回答によって要件を変更したら、版番号、変更点、変更日を記録し、提出期限への影響も知らせます。
回答様式と評価表を先に決めて比較可能にする
自由形式だけで提案を求めると、デザイン案が詳しい会社、工程が詳しい会社、保守が詳しい会社を横並びに評価しにくくなります。提案の自由度を残しつつ、次の共通回答欄を指定します。
- 課題と目的の理解、提案方針、その根拠
- ページ・コンテンツ・機能・移行・計測の実施範囲
- 発注側に求める作業、資料、判断、期限
- 責任者、担当者、外部パートナーを含む体制
- 工程、確認回数、各工程の完了条件
- 成果物、納品形式、検収方法、公開後の支援
- 費目別金額、別途費用、利用料、前提条件、見積対象外
- 主要リスク、未確定事項、代替案、追加提案
| 評価軸 | 確認する内容 | 判断の記録例 |
|---|---|---|
| 目的理解 | 利用者と事業課題から提案が組み立てられているか | 根拠となるRFP項目と提案ページを記録 |
| 実現方法 | 必須要件、確認方法、代替案が具体的か | 必須適合、条件付き、非対応を分ける |
| 体制・工程 | 責任者、発注側の作業、承認、依存関係が現実的か | 担当名ではなく役割と稼働条件を確認 |
| 移行・品質 | URL、データ、テスト、公開、復旧の手順があるか | 成果物と合否判定方法を記録 |
| 費用・継続性 | 総額だけでなく範囲、追加条件、運用費、引継ぎが明確か | 比較期間と費用に含むものを統一 |
| リスク説明 | 不確実性や発注側の課題を具体的に説明しているか | 懸念、影響、回避策、残る判断を記録 |
点数だけで自動決定せず、必須条件、評価根拠、懸念、確認回答を残します。配点や重みを使う場合は提案受領前に決め、評価者間で「高評価」の定義を合わせてください。費用は重要ですが、作業範囲が違う総額同士は比較できないため、前提をそろえてから判断します。
リニューアルRFPにはURL・SEO・計測の移行要件を書く
デザインとページ制作だけをRFPに書くと、公開直前になってURL移行、計測、ドメイン、Search Console、フォーム通知の担当が不明になることがあります。既存サイトがある場合は、少なくとも次の作業について、実施者、成果物、確認方法を求めます。
- 旧URL一覧と新URL一覧を対応付けたURLマッピング
- URL変更が必要なページへのサーバー側の恒久的リダイレクト方針
- 新URLを指すcanonical、内部リンク、構造化データ、サイトマップの更新
- 開発環境で使ったnoindexやクロール制御を公開時に解除する確認
- GA4、Search Console、広告、タグ管理、コンバージョンの移行と権限確認
- フォーム送信、通知、エラー、主要端末、主要ブラウザ、404の公開前テスト
- 公開後のクロール、インデックス、流入、エラーを確認する期間と担当
Googleのサイト移行ガイドは、旧URLと新URLのマッピング、自己参照canonical、内部リンクとサイトマップの更新、サーバー側の恒久的リダイレクト、公開後の監視を案内しています。サイト構成を変更するRFPでは、「SEO対応」とだけ書かず、これらの成果物と確認方法を具体化してください。
RFP提出前チェックリスト
- サイト制作ではなく、事業・利用者の目的を一文で説明できる
- 対象サイト、ページ群、作業、対象外が分かれている
- 現状資料の作成日、集計期間、管理者、版が分かる
- 要件を必須・希望・提案・未確定・対象外に分類した
- 必須要件に確認方法または検収条件がある
- 原稿、画像、撮影、データ移行の担当と期限が決まっている
- 発注側と制作側の役割、意思決定者、承認日を示した
- URL、SEO、計測、フォーム、各種アカウントの移行を含めた
- 成果物、納品形式、権限、権利、保守終了時の引継ぎを示した
- 提案書の回答様式と見積費目を統一した
- 評価基準と必須条件を提案受領前に決めた
- 質問回答・変更履歴を全候補会社へ同条件で共有する手順がある
よくある質問
RFPは何ページ必要ですか?
決まった長さはありません。ページ数より、候補会社が対象範囲、前提、未確定事項、回答方法を誤解しないことが重要です。現状のURL一覧やコンテンツ台帳は別紙にし、本文は目的と判断条件を追いやすくします。
予算はRFPに書くべきですか?
社内方針によります。上限や想定範囲を開示する場合は、税込・税別、初期費用・運用費、外部サービス料を含むかを明記します。非開示でも、各社に同じ費目と前提で見積もりを求め、予算適合の確認方法を決めてください。
要件が固まっていなくてもRFPを出せますか?
出せますが、未確定項目を明示し、「提案を求める」「契約後の要件定義で確定する」など扱いを決めます。未確定のまま固定価格を求めると前提差が大きくなるため、要件整理の工程・成果物・費用を分ける方法も検討します。
デザイン案も提案時に作ってもらうべきですか?
必要性と評価方法を先に決めます。無償の完成デザインを前提にせず、課題理解、情報設計、制作後の検証方法も評価してください。デザイン案を求める場合は、対象画面、素材、利用範囲、採否後の取扱いを明記します。
RFPを送れば見積金額は完全にそろいますか?
完全にはそろいません。各社の方法、体制、品質管理、対象外が異なるためです。共通の回答様式と見積費目を指定し、前提条件、別途費用、発注側の作業、外部サービス料を確認して比較可能な状態にします。
