RFPを書こうとすると、「どこまで細かく仕様を決めるべきか」「何を提案に残すべきか」で迷います。情報が少なすぎると提案の前提がそろわず、細かすぎると候補各社の知見を活かせません。

 

比較できるRFPに必要なのは、ページ数の多さではありません。背景と目的、対象範囲、必須条件、発注側と提案側の役割、未決事項、回答形式、評価軸が明確であることです。特にCMS選定では、「機能があるか」だけでなく、標準機能・設定・個別対応のどれで実現するか、公開後に誰が保守するかまで回答してもらう必要があります。

結論｜比較できるRFPの書き方
発注側で決める「背景・目的・対象範囲・必須条件」と、候補各社へ提案を求める「実現方法・体制・移行・運用」を分けます。さらに、提案書の章立て、見積もり内訳、回答形式、評価基準を指定すると、提案内容と費用を同じ土俵で比較できます。

この記事のポイント

  • RFPは、仕様を固定する部分と提案を求める部分を分けて書く
  • 対象範囲、成果物、役割分担、移行、公開後の保守を具体的に記載する
  • 機能回答は「標準／設定／外部連携／個別開発／非対応」で統一する
  • 評価項目と配点を先に決め、提案書・デモ・見積もりを同じ基準で採点する

INDEX

比較できないRFPの特徴

  • 目的が「サイトを新しくする」だけで、解決したい課題が分からない
  • 対象サイト・ページ・言語・フォーム・移行データの範囲が分からない
  • 必須条件と希望条件が混在している
  • 発注側が用意する原稿・素材と、制作会社へ依頼する作業が分からない
  • 提案書の構成と見積もり内訳が指定されていない
  • CMSの機能一覧だけが長く、利用者・運用方法が書かれていない
  • 評価基準がなく、プレゼン後に印象で判断する
  • 未決事項を隠し、候補各社が異なる前提で見積もる

RFPの推奨章立て

章

記載内容

1. 表紙・取扱条件

案件名、発行日、機密保持、問い合わせ先

2. プロジェクト概要

発注企業、主管部門、背景、目的、成功条件

3. 現行環境

サイト構成、ページ数、CMS、サーバー、外部サービス、運用体制

4. 対象範囲

対象・対象外、言語、コンテンツ、データ、外部システム

5. 基本方針

ターゲット、情報設計、コンテンツ、デザイン、アクセシビリティ、SEO

6. 必須要件

CMS、運用、セキュリティ、移行、公開日などの最低条件

7. 提案依頼事項

サイト構造、CMS活用、移行、運用、体制、改善の提案

8. 成果物・役割分担

設計資料、デザイン、原稿、撮影、実装、移行、研修

9. プロジェクト条件

体制、会議、レビュー、スケジュール、受入テスト、公開

10. 運用・保守

CMS・サーバー保守、問い合わせ、アップデート、改善支援

11. 費用・契約条件

見積もり区分、運用費、追加費用、支払、契約期間

12. 提出・評価

質問、提出期限、回答形式、プレゼン、評価項目、選定通知

本項目としては、次を押さえておくと比較しやすくなります。

 

  • プロジェクト概要
  • 背景と目的
  • 現行課題
  • 対象範囲
  • 必要な成果物
  • 必須条件
  • 希望スケジュール
  • 予算の考え方
  • 提出条件
  • 評価観点

 

ここでのポイントは、詳細を全部決めることではなく、提案の前提をそろえることです。予算も確定額でなく、想定レンジや考え方があるだけで提案の精度は上がります。

章ごとの書き方と例文

背景と目的

例文

現行サイトは20XX年に構築し、ニュース以外のページ更新を制作会社へ依頼している。広報、IR、採用の各部門が別々の運用を行っており、更新速度、デザイン統一、セキュリティ・保守の責任範囲に課題がある。

本プロジェクトでは、情報設計とコンテンツを見直すとともに、複数部門が安全に更新できるCMSへ刷新する。企業情報の到達性と発信速度を高め、公開後も継続的に改善できる運営体制を構築する。

 

対象範囲

例文

対象：コーポレートサイト本体（約800ページ）、ニュース、IR、採用情報、日本語サイトの問い合わせフォーム、主要PDF・画像。

対象外：英語サイト、会員サイト、採用応募システム。対象外サイトはデザイン・ナビゲーションの接続方法のみ提案対象とする。

移行対象の最終件数はコンテンツ棚卸し後に確定するため、見積もりはページ数別の単価・前提を明記すること。

 

必須要件

例文

広報、IR、採用の編集領域を分け、各部門がページ作成・公開申請を行えること。全体管理者はサイトを跨いで確認・承認できること。

CMS、サーバー、セキュリティ、アップデート、障害対応の責任範囲と問い合わせ窓口を明確にすること。

既存の主要流入URLは原則維持し、変更するURLには301リダイレクトを設定すること。URL移行台帳とテスト結果を納品すること。

 

提案依頼事項

例文

主要ターゲットが必要な情報へ到達しやすいサイト構造とグローバルナビゲーションを提案すること。

CMSの標準機能を最大限活用し、個別開発と公開後の保守負荷を抑える構成を提案すること。標準機能、設定、外部連携、個別開発を区分すること。

現行コンテンツの棚卸し、統合・削除・改稿の判断方法と、移行を安全に進める工程を提案すること。

発注側で決める項目と、提案を求める項目

発注側で明示する

候補各社へ提案を求める

背景、目的、優先順位、公開希望日

目的を実現する情報設計と制作アプローチ

対象サイト・対象外、既存契約の制約

フェーズ分け、段階移行、現実的なスケジュール

必須の運用・セキュリティ条件

CMS製品・構築方式と選定理由

原稿・素材を用意できる範囲

取材、執筆、撮影、移行の効率的な進め方

社内体制、承認者、レビュー条件

プロジェクト体制、会議、リスク管理

予算レンジ、見積もり条件

予算内で優先すべき範囲と代替案

CMSベンダーへの回答フォーマット

CMSの機能回答は、「対応可」だけでは比較できません。次の区分で回答を依頼すると、初期費用と公開後の保守負荷を判断しやすくなります。

回答区分

定義

回答に含めてもらうこと

標準機能

追加開発なしで契約範囲内に含まれる

利用条件、制限、操作方法、追加費用の有無

設定・運用

設定または運用ルールで対応する

設定担当、変更方法、運用上の制約

外部連携

別サービスと連携して対応する

サービス名、契約主体、データ、保守・障害時の責任

個別開発

独自実装が必要

開発費、期間、保守費、アップデート影響

代替提案

要件と異なる方法で目的を実現する

代替方法、メリット、制約、費用

非対応

実現できない、または推奨しない

理由、業務への影響、代替案

回答項目

回答内容の例

要件ID・要件名

F-03：部門別の編集権限と公開承認

対応区分

標準機能

実現方法

サイト・カテゴリ単位で編集範囲を設定し、編集者から承認者へ公開申請する

制約・前提

権限単位は契約・管理構成により確認。緊急公開フローは運用設計が必要

費用

標準利用料に含む／初期設定費に含む

デモ・確認方法

編集者でログインし、ページ編集・申請・差し戻し・予約公開を実演

見積もり条件をそろえる方法

  • 初期費用と月額・年額費用を分ける
  • 情報設計、デザイン、CMS、実装、移行、テスト、研修、PMを区分する
  • ページ数・テンプレート数・フォーム数・言語数の前提を明記する
  • 原稿作成、画像・動画、撮影、翻訳、データ入力の担当を明確にする
  • サーバー、CDN、WAF、SSL、監視、バックアップ、CMSアップデートを含むか確認する
  • 公開後サポートの受付範囲、時間、回数、追加費用を確認する
  • 要件変更時の単価、追加見積もり、スケジュール変更の条件を確認する
  • 3年または5年間の総費用を提示してもらう

提案評価表と配点例

評価項目

配点例

評価する内容

案件理解・課題設定

15

現状課題と目的を理解し、提案の前提が妥当か

情報設計・コンテンツ提案

15

ターゲットの導線、コンテンツ改善、SEO・AIOの考え方

CMS・システム適合性

20

標準機能、権限、承認、複数サイト、外部連携、非機能要件

移行・公開計画

15

コンテンツ・URL移行、テスト、リスク、公開切替の現実性

運用・サポート

15

公開後の更新、研修、問い合わせ、保守、改善支援

プロジェクト体制・実績

10

PM、担当者、類似実績、コミュニケーション方法

費用・契約条件

10

対象範囲、内訳、総費用、追加費用条件の妥当性

配点は案件の目的に合わせて変えます。CMS刷新が中心ならCMS・運用・非機能の配点を高くし、ブランド刷新が中心なら情報設計・コンテンツ・デザインの配点を高くします。価格だけを独立して評価せず、対象範囲と5年間の総費用を合わせて確認します。

RFP配布後の進め方

  • 候補各社へ同じ日にRFPと参考資料を配布する
  • 質問受付期間を設け、条件に影響する回答は全社へ共有する
  • 提案前に現行サイト・運用の説明会を実施する
  • 提案書に加えて、共通の操作シナリオでCMSデモを依頼する
  • 評価者ごとに独立採点し、その後に評価会議で理由を共有する
  • 見積もり前提と対象外を確認し、必要に応じて最終提案を依頼する
  • 選定後は、要件定義書・RFP・提案書の優先関係を契約書で明確にする

RFP公開前チェックリスト

  • 背景・目的・成功条件が一貫している
  • 対象サイト、対象ページ、対象外が分かる
  • 必須要件と希望要件が分かれている
  • 発注側と候補企業の役割分担が分かる
  • 未決事項と提案してほしい事項が明記されている
  • 移行対象とURL・リダイレクトの方針がある
  • CMSの回答区分とデモシナリオが指定されている
  • 見積もり内訳と運用費の回答形式がそろっている
  • 質問・提出・プレゼン・選定のスケジュールが現実的である
  • 評価項目、配点、選定体制が社内で合意されている
  • 機密情報、個人情報、資料の返却・削除条件を記載している

よくある質問

まとめ

比較できるRFPは、情報量の多い仕様書ではありません。発注側が決める背景、目的、範囲、必須条件と、候補各社へ提案を求める実現方法、体制、移行、運用を分けて記載します。

 

さらに、CMSの回答区分、提案書の章立て、見積もり内訳、デモシナリオ、評価項目と配点を統一します。未決事項も明示し、候補各社が同じ土俵で提案できる状態をつくることで、価格だけではなく、公開後まで持続できる運営基盤を選びやすくなります。