第1章：Webサイトリニューアルの「不都合な真実」…なぜうまくいかないのでしょうか？
1.デジタル資産の危機：7割のプロジェクトが座礁する理由
Webサイトは、営業、マーケティング、採用、顧客サポート、そしてブランドそのものを作り上げる、極めて重要な「戦略的資産」です。
多くの企業が、この大切な資産を守り、さらに価値を高めるために、数年に一度のビッグイベントとして「Webサイトリニューアル」に取り組みます。
しかし、その成功率は驚くほど低いのが現実です。一般的な統計では、約7割から8割のプロジェクトが、当初期待していた成果（KGIやKPIの達成）を得られないまま終わってしまうか、公開後に大きなトラブルを抱えていると言われています。
なぜ、これほどまでに失敗してしまうのでしょうか？
多くの経営者様やご担当者様は、その原因を「制作会社選びを間違った」「制作会社が作ったデザインが悪かった」「制作会社の技術力が足りなかった」あるいは「予算が少なかったから」と考えがちです。
しかし、私たちリヌーボデザインが提唱する「Web再生」の視点で数多くの失敗事例を分析してみると、本当の原因はデザインや技術といった表面的な部分ではなく、もっと手前の「プロジェクトの構造的な欠陥」にあることが見えてきます。
今のサイトは「ダメなもの」ではない
多くの企業様は、Webサイトが古くなったり使いにくくなったりすると、ついつい「スクラップ・アンド・ビルド（壊して作り直す）」という方法を選んでしまいます。今のサイトを「ダメなもの」としてすべて白紙に戻し、ゼロから作り直そうとするんです。
でも、長年運営してきたサイトには、検索エンジンからの信頼（SEO資産）や、蓄積されたコンテンツ、ユーザーからの認知といった「目に見えない資産」がたくさん詰まっています。
これらを無意識にリセットして更地にしてしまうのは、実は会社の歴史と資産を捨ててしまうような、とても「もったいない」ことなのです。
この構造的な失敗は、大きく分けて次の3つのパターンで起こります。
数字に表れる失敗
これは経営にとって一番痛い失敗です。
リニューアルした途端にアクセス数が激減したり、検索順位が圏外に飛んでしまう「SEOの死の谷」に落ちたり、お問い合わせ（コンバージョン）が半減してしまうケースです。
これは、既存サイトが持っていた価値を正しく評価せず、SEOの引き継ぎやユーザーの動線を無視して刷新してしまった結果です。
「見た目」を変えることに夢中になって、「数字」を守ることを忘れてしまうと、こういう失敗が起きます。
使い勝手とブランドの失敗
「デザインは今風でおしゃれになったけど、何屋さんなのか分からなくなった」「強みや特徴が伝わらない」「必要な情報が見つからない」「トップページでかっこいい動画が流れるけど、何を伝えたいのか不明」といった状態です。
これは、ユーザーの心理や行動を無視して、表面的な装飾（Art）ばかりを追求し、課題解決としてのデザイン（Design）を置き去りにした結果です。
独りよがりなデザインは、ユーザーを混乱させ、せっかくの信頼を損なってしまいます。
プロジェクト進行の失敗
「作っている途中で追加費用が発生した」「納期が大幅に遅れた」「制作会社と喧嘩別れした」といったトラブルです。
これらはすべて、プロジェクトが始まる前の「再定義（Re:Think）」や「合意形成」が足りなかったことが原因です。
「言った・言わない」の水掛け論は、プロジェクトの空気を悪くし、クオリティも下げてしまいます。
そして、これら全ての失敗を引き起こす「真犯人」とも言えるのが、発注側から制作会社へ渡すRFP（提案依頼書）がない、あるいは中身がスカスカであることなのです。
RFPなしでプロジェクトを始めるのは、地図を持たずに砂漠を歩き出すようなものです。遭難してしまうのは、残念ながら時間の問題と言えるでしょう。
2.RFP（提案依頼書）って何？ただの「仕様書」ではありません
RFP（Request For Proposal：提案依頼書）とは、Webサイトを作ったりリニューアルしたりする時に、発注する企業側が制作会社に対して、「こういう課題を解決したいので、良い提案をください」とお願いするための公式な書類です。
でも、日本の多くの企業では、RFPを「欲しい機能のリスト」や「作りたいページの箇条書き」、あるいは単なる「見積もり依頼書」として軽く扱ってしまう傾向があります。実は、この認識のズレが失敗への第一歩なんです。
RFPの本質は、経営課題をWebという手段で解決するための「戦略設計図」であり、パートナーとなる制作会社への「ラブレター（熱意と要望を伝える手紙）」でもあります。
しっかりとしたRFPには、次の3つの大事な役割があります。
役割1：社内の意見をまとめて「合意」を作る
RFPを作るプロセスは、社内のいろんな部署（営業、広報、人事、経営層など）でバラバラになっている要望を集めて、矛盾を整理し、優先順位をつけて言葉にする作業そのものです。
営業部は「もっと集客したい！」と言い、広報部は「ブランドイメージを大事に！」と言い、人事は「採用のエントリーを増やしたい！」と言います。
これらを調整せずに制作会社に丸投げしたら、「船頭多くして船山に登る」状態になってしまいますよね。RFPを作ること自体が、社内の合意形成（Re:Think）を強力に進めるきっかけになるんです。
役割2：提案の質を揃えて「正解」を見つける
「かっこいいサイトにしたい」「集客を増やしたい」といった曖昧な依頼だけでは、制作会社も曖昧な提案しかできません。
具体的で論理的なRFPがあって初めて、制作会社は自分たちの強みを活かした「課題解決策」を提案できます。
条件が揃うことで、相見積もりやコンペの際にも各社を同じ基準で公平に比較できるようになり、単なる価格競争ではなく「価値の競争」を生み出すことができるのです。
役割3：トラブルを防ぐ「リスク管理」
「言った・言わない」のトラブル、想定外の追加費用、納期の遅延…プロジェクト中のこうした問題の大半は、RFPの「書き方が曖昧」だったり「責任範囲が不明確」だったりすることが原因です。
RFPは契約の土台になる文書であり、プロジェクトの憲法のようなものです。「何を作るのか」「何を作らないのか」「誰が責任を持つのか」。これらをハッキリ書いておくことで、トラブルのリスクを劇的に減らすことができます。
3.「雰囲気リニューアル」の罠…RFPがないとどうなる？
もしRFPを作らなかったり、不十分なRFPのままスタートしたりすると、どんな悲劇が待っているのでしょうか？
最もよくあるのが「雰囲気リニューアル」という罠です。
明確なビジネスの目的（KGI）や数値目標（KPI）がRFPに書かれていないと、打ち合わせの話はどうしても「主観的なデザインの好み」になってしまいます。
「もっとシュッとさせてほしい」「部長の好みは青色なんです」「競合のA社みたいな動きをつけて」といった、根拠のない感覚的な意見が会議室を支配してしまいます。
制作会社としても、ビジネス的な成果（Re:Value）に責任を持てないので、「クライアントが喜ぶ見た目」を作ることに全力を注ぐしかなくなります。
その結果、見た目はすごく綺麗でおしゃれなんだけど、ターゲットのお客様には全く響かない、お問い合わせボタンがどこにあるか分からない、中身が空っぽのWebサイトができあがります。
これは「手段が目的化」してしまった典型例で、投資したお金が無駄になってしまう最悪のシナリオです。
また、RFPがないと、制作会社はリスクを見込んで見積もりを高く設定するか（バッファを積む）、逆に要件を軽く見積もって安く出し、あとから莫大な追加請求をするかのどちらかになります。
どちらに転んでも、発注する皆様にとっては損でしかありません。
第2章：Web再生の哲学「4つのRe:」をRFPに落とし込む
私たちリヌーボデザインが大切にしている「4つのRe:プロセス（Re:Think, Re:Design, Re:Build, Re:Value）」を軸に、Webサイトリニューアルを成功に導くための「RFP作成術」を丁寧にお伝えします。
失敗の元凶を断ち切り、Webサイトを「稼ぐ資産」へと再生・刷新するためのノウハウを持ち帰ってください。
1.Re:Think（再定義）：ビジネスの目的と価値をもう一度合わせる
RFP作成の最初の一歩であり、一番時間を使っていただきたいのがこの「Re:Think（再定義）」です。「なぜリニューアルするのか？」という問いへの答えを、極限まで明確にするプロセスです。
よく「デザインが古いから」「スマホ対応していないから」という理由を聞きますが、それはリニューアルの「きっかけ（症状）」であって、「目的」ではありません。目的とは、リニューアルを通じて達成したいビジネス上の成果のことです。
現状の悩みと理想の姿のギャップ
単に「アクセスが少ないんです」と書くだけでは足りません。「特定の商品ページの直帰率が80%を超えていて、せっかくの広告費が無駄になっている」「資料請求は来るけれど、そこからの商談化率が低くて困っている」といった、具体的で数字に基づいた悩みを分析しましょう。
RFPには、Googleアナリティクスのデータや、営業現場からの生の声などを盛り込んで、現状の課題を立体的に伝えることが大切です。
経営戦略とKGI/KPIの設定
Webサイトは経営戦略を映す鏡です。「今後3年間で海外売上の比率を20%に引き上げたい」という経営目標があるなら、Webサイトの多言語化や海外向けのSEO対策は絶対に外せませんよね。
RFPには必ず経営計画や事業の方向性を書き、制作会社にビジネスの本質を理解してもらいましょう。
その上で、KGI（最終ゴール）としての「売上高」「問い合わせ数」と、KPI（中間指標）としての「PV数」「CVR（コンバージョン率）」「滞在時間」を明記します。
ペルソナとカスタマージャーニーの再定義
昔決めたターゲット設定が、今も正しいとは限りません。時代が変わればお客様も変わります。「誰に」「何を」伝えるべきか、ターゲットユーザーの心理（インサイト）をRFPでハッキリさせることで、「独りよがりなデザイン」を防げます。
できれば、具体的な「ペルソナシート（架空の顧客像）」や「カスタマージャーニーマップ（顧客の行動地図）」を資料として添付し、ユーザーがどんな気持ちでサイトを訪れるのかを制作会社に共有しましょう。
2.Re:Design（再設計）：ユーザーの心理と行動を整える
「Re:Design（再設計）」は、単に見栄えを良くすることではありません。ユーザーが迷わずに目的を達成できるような「導線」と「体験（UX）」を設計することです。
失敗するRFPは「参考サイト」としてビジュアルの好みばかりを並べ立てますが、成功するRFPは「ユーザーにどんな体験をしてほしいか」を語ります。
迷わせない情報設計（IA）
ユーザーが欲しい情報にすぐたどり着けるサイト構造（情報アーキテクチャ）を求めましょう。
「トップページを開いた瞬間に会社や商品に興味を持ってもらえるようにしたい」「3クリック以内にすべての製品情報に行けるようにしたい」「関連する記事を読みたくなるようなリンク構造にしてほしい」といった具体的な基準を設けます。
今のサイトのナビゲーションメニューの使いにくい点なども伝えると良いですね。
モバイルファーストとレスポンシブの本質
スマホ対応は今や当たり前ですが、PCサイトをただ小さくしただけでは不十分です。スマホユーザーがどんな状況で使うか（移動中に片手で操作する、通信が遅い場所かも…など）を想像した設計が必要です。
メニューボタン（ハンバーガーメニュー）の押しやすさや、文字の読みやすさなど、スマホでの体験の質を担保する要件を盛り込みましょう。
ブランドらしさの表現
自社の強み（USP）をどうやってデザインや言葉で表現するか。RFPにはロゴデータやブランドのガイドラインを添付して、イメージの統一を図ります。
「信頼感」「革新性」「親しみやすさ」といったキーワードを、デザインとしてどう表現するか、制作会社からの提案を期待しましょう。
3.Re:Build（再構築）：資産を活かして技術で支える
「スクラップ・アンド・ビルド」の弊害が一番出るのがここです。
「Re:Build（再構築）」の考え方では、今ある資産（コンテンツ、ドメインの強さ、データ）を最大限に活かしながら、必要な部分だけを最新技術で刷新します。
SEO資産の継承と「死の谷」回避
RFPで一番忘れられがちで、かつ一番怖いのがSEOの移行計画です。
「今の全URLから新しいURLへの301リダイレクト（転送）設定を完璧に行うこと」を必須条件にしないと、リニューアルした当日に検索からのアクセスがゼロになる「SEOの死の谷」に落ちてしまいます（これ、本当に怖いんですが、伝えておかないとやってくれない制作会社が多いです）。
既存コンテンツ（資産）の有効活用についても制作会社からの提案を期待しましょう。
また、Google Search ConsoleへのXMLサイトマップの送信や表示速度の改善、滞在時間を伸ばす工夫、基本的なSEO施策の漏れのない実施など、技術的なSEO要件もしっかり書いて、制作会社の実力を測りましょう。
無理のないCMS（更新システム）選定と運用体制
新しいCMS、高機能すぎるCMS、独自のCMSは、現場の負担になり、更新が止まってしまう原因となることが多いです。
RFPでは「誰が」「どのくらいの頻度で」「どのくらいのスキルで」更新するのかを正直に書き、それに合ったCMS（WordPressなど）の提案を求めましょう。「社内のWeb知識がない担当者でもニュースの更新を5分以内でできること」といった運用ルールを決めるのがおすすめです。
セキュリティと表示速度
Googleが重視している表示速度（Core Web Vitals）の基準クリアも要件に入れましょう。
また、セキュリティ対策（セキュリティプラグイン、WAFの導入、SSL化など）も定義して、安全安心なサイト環境を作ることも忘れずに。
4.Re:Value（再価値化）：成果を生む運用へ
リニューアルはゴールではなく、スタートです。
「Re:Value（再価値化）」は、サイト公開後に継続的に価値を高めていくプロセスです。
RFPには「作って終わり」にしないための条項が必要です。
公開後のサポートとPDCA
トラブル対応などの保守だけでなく、定期的なアクセス解析レポートや、改善提案（PDCA）を契約に含めるかどうかを明確にします。
作って終わりではなく、一緒にサイトを育ててくれるパートナーかどうかを見極めましょう。
データが見える環境づくり
GA4（Googleアナリティクス）の設定や、コンバージョン計測の設計もお願いしましょう。
どのボタンが押されたか、どこまで読まれたかといったデータを取れるようにして、勘ではなくデータで判断できる環境を作ります。
第3章：失敗事例から学ぶ「RFPの落とし穴」
成功するRFPを作るには、他社の失敗から学ぶのが一番の近道です。
ここでは、RFPの不備が招いた具体的な失敗ケースを物語形式でご紹介します。これらは決して他人事ではありませんよ。
ケーススタディ1：「目的迷子」で予算オーバー＆機能不全の悲劇
企業の状況
ある中堅メーカーのA社。Webサイトが10年近く放置されていて、社長から「とにかく業界で一番かっこいい、先進的なサイトにしろ！」と号令がかかりました。
RFPの致命的ミス
担当者が作ったRFPには、「かっこいい、先進的なイメージ」「スマホで見やすく」というふんわりした要望だけが書かれていました。予算は「提案を見て決める」とあやふやにし、機能についても「現状通り」としか書いていませんでした。
結末
コンペで選ばれたのは、最新技術で動きまくるリッチなデザインを提案したX社。経営陣も「これなら勝てる！」と即決しました。
しかし、いざ作り始めると問題が続出。A社の古いサーバーをそのまま使うことができず、サーバー移転費用が追加に（既存システムも移行が必要）。さらに途中から営業部が「製品在庫を表示したい」と言い出し、仕様変更で追加料金も発生。予算は当初の2倍に膨れ上がりました。
できあがったサイトは、動画やアニメーションが多すぎて表示に時間がかかったり、スマホ（4G回線）では重かったり、何を伝えたいのか分からない（情報が伝わってこない）状態に。
教訓
- 「かっこいい」は禁句
「かっこいい」の定義は人それぞれです。「信頼感を高めるための重厚感」「技術力を伝えるための精緻なデザイン」など、ビジネスの目的に紐づいた言葉にしましょう。 - 事前の技術調査
今のサーバー環境やシステムの仕様は、RFPを作る前に調べておくことが必須です。 - 予算の上限を決める
予算を隠すと、制作会社は松竹梅の提案が作れません。「上限1000万円」など目安を出すことで、その中で最高の提案を引き出せます。
ケーススタディ2：「SEO忘れ」で売上が蒸発した悪夢
企業の状況
ECサイトを運営するB社。システムが古くなったのでフルリニューアルを決断。目的は「使いやすくして売上アップ」でした。
RFPの致命的ミス
機能やデザインの要望は細かく書かれていましたが、SEOについては「SEO対策を行うこと」というたった一行だけ。具体的な指示はありませんでした。
結末
制作会社Y社は、「SEO対策＝タイトルタグや見出しタグ、メタタグの設定をすること」と解釈して実装しました。
リニューアルでURLの形が完全に変わりましたが、旧URLから新URLへの「転送（リダイレクト）」設定が全く行われませんでした。
公開から一週間、悲劇が起きます。Google検索からのアクセスが90%ダウン。主力商品の検索順位が圏外に飛び、お客様がブックマークしていたページはすべて「ページが見つかりません」のエラーに。月商数百万円の損失が出てしまいました。
制作会社は「RFP通り、基本のSEO対策は実施した」「RFPにリダイレクトの指示がなかったので…」と主張し、泥沼のトラブルに。
教訓
- SEO要件は具体的に
リニューアルにおいて「移行」は最重要です。「現行サイトの全ページのURL対照表を作り、301リダイレクトを実装すること」と明記しないと伝わりません。 - 責任範囲を決める
誰がリストを作るのか、誰が確認するのか、役割分担をRFPで決めましょう。
ケーススタディ3：「全部入り」CMSで運用崩壊
企業の状況
サービス業のC社。Web未経験の総務担当者がWeb運用を兼任することになり、「誰でも簡単に更新できるサイト」を目指しました。
RFPの致命的ミス
RFPに「将来的にすべてのページを社内で更新したい」「外注費をゼロにしたい」という過剰な要望を書いてしまいました。
結末
制作会社Z社はRFPの要望通り、トップページのスライダーからバナー、商品ページや会社概要に至るまで、Webの知識が一切無くてもすべてのテキスト情報や画像を管理画面からいじれるシステムを構築しました。
しかし、できあがった管理画面は入力項目が数百個もある複雑なものに。マニュアルも200ページ超え。担当者様は「どこを触ればいいか分からない」「更新作業が面倒で非常に時間がかかる」と更新がおろそかになってしまい、サイトは「更新されない廃墟」と化しました。
教訓
- 運用の現実を見る
「誰が」「どのくらいの頻度で」やるかを考えましょう。たまにしか更新しないページまでシステム化する必要はありません。 - 本当にシステム構築が必要か見極める
WordPressなどの一般的なCMSは、担当者が少し学習すれば簡単に更新できるようになるので、過剰なシステムを構築する必要はありません。マニュアルとレクチャーがあれば、更新できるようになる場合が多いです。
第4章：成功に導くRFPテンプレート解説
ここからは、実際にリヌーボデザインが推奨している、より専門的かつ網羅性の高いRFPの構成要素を解説します。
一般的なテンプレートでは省略されがちな「非機能要件」や「運用設計」まで踏み込んで記述することで、トラブルの9割を未然に防ぐことができます。
この章をコピー＆ペーストして、不要な部分を削るだけで、プロ顔負けの最強RFPが完成します。
1.プロジェクト全体像
制作会社が「自社が手を挙げるべき案件か」を判断するための基本情報です。
| 項目 | 詳細記述のポイント・具体例 |
| プロジェクト名称 | 「株式会社〇〇 コーポレートサイトリニューアル計画」 |
| 背景・課題（Why） | 【定量課題】 ・直近1年のCVRが0.5%から0.3%へ低下。 ・スマホからの直帰率が85%と高い。 ・ページの表示速度（モバイル）がGoogleスコアで30点。 【定性課題】 ・デザインが5年前のもので、競合と比較して古臭く信頼性に欠ける。 ・更新作業が属人化しており、担当者不在だとニュース一本出せない。 ・更新システムが使いにくく、タイムリーな情報発信ができていない。 ・営業資料とWebサイトで訴求内容にズレが生じている。 【技術課題】 ・現行サーバーのOSサポート期限切れが迫っている。 ・サーバー環境が古いので、既存システムを含めて移行したい。 |
| プロジェクトの目的（What） | 【ビジネス目的】 ・Web経由の商談数を月間20件へ引き上げる。 ・Webサイトを「デジタル営業マン」化し、リード獲得数を倍増させる 【ブランディング目的】 ・「技術力のある会社」から「未来を創るパートナー」へ認知を変える。 ・「伝統ある企業」から「革新的なパートナー」へ、ブランドイメージを再定義する 【採用目的】 ・採用エントリーの質を向上させ、ミスマッチを減らす。 ・求める人材像（自律型人材）への訴求力を高め、エントリーの質を向上させる。 |
| KGI / KPI（Goal） | 【KGI（最終ゴール）】 ・年間売上貢献額：1億円 ・商談化数 月30件 【KPI（中間指標）】 ・月間PV数：50,000PV → 100,000PV ・CVR（問い合わせ率）：1.0% ・CVR（資料請求）：1.0% ・検索順位「〇〇 メーカー」で3位以内。 ・自然検索流入数：前年比150%増 ※「リニューアル後6ヶ月時点で達成」「リニューアル後1年時点で達成」など期限も設ける。 |
| ターゲット（Who） | 【メインターゲット】 下記の例のように具体的に。 ・属性：年商5億以上の製造業の生産管理部長（40〜50代男性）。 ・インサイト（悩み）：「コスト削減よりも、品質安定を求めている」「失敗できないプレッシャーがある」 ・属性：中堅・中小企業の経営企画室長またはマーケティング責任者（30〜40代）。 ・インサイト（悩み）：「DXを進めたいが何から手をつければいいか分からない」「失敗したくないので実績のあるパートナーを探している」 【サブターゲット】 ・就職活動中の理系大学院生。 |
| プロジェクト体制 | 【発注側体制】 ・プロジェクトオーナー（最終決裁）：代表取締役 ・プロジェクトリーダー（進行責任者）：広報課 課長 ・技術担当：情報システム部（インフラ・セキュリティ要件の確認のみ参加） |
2.マーケティング・戦略要件
Webサイトを「ただの箱」にしないための戦略的な要求事項です。
| 競合・ベンチマーク | 【競合サイト】 A社、B社（ビジネス上のライバル、差別化したいポイントも明記） 【デザイン参考】 C社（業界は違うが、信頼感のあるデザイン）、D社（採用サイトの動きが理想） 【NG参考】 E社（派手すぎて使いにくい） |
| SEO・コンテンツ戦略 | 【狙いたいキーワード】 「〇〇 製造」「〇〇 委託」などのビッグワードだけでなく、「〇〇 小ロット 短納期」「〇〇 比較」「〇〇 事例」などのロングテールキーワードの戦略提案を求める。 【コンテンツ制作】 サイトの原稿は「自社で用意」か「制作会社にライティングまで依頼」か。あるいは「構成案までは制作会社、執筆は自社」などの役割分担。 【コンテンツSEO】 コラムやブログ記事の設計・制作が含まれるか（制作会社に記事執筆まで依頼するか、箱だけ作るか）を明記。 |
| マーケティングツール連携 | 【計測ツール】 Google Analytics 4 (GA4)、Google Search Console、Google Tag Manager (GTM) の導入・設定。 Google Analytics (GA4) のイベント設定設計（コンバージョン地点の定義など）を含めるかどうかも明記。 【ダッシュボード】 Looker Studio等でのレポート環境構築の要否。 【MA/SFA連携】 HubSpot、Salesforce、Marketo等のフォーム埋め込みやAPI連携の有無。 |
3.クリエイティブ・UX要件
「かっこいい」「おしゃれ」という曖昧な言葉を使わず、論理的かつ具体的に指示します。
| トーン＆マナー（トンマナ） | 【キーワード】 誠実、堅実、先進的、温かみ、ミニマルなど。 【ブランド規定】 ロゴの使用規定、コーポレートカラー（#XXXXXX）、指定フォントの有無。 【禁止事項】 ポップすぎるイラスト、フリー素材の多用、原色の多用、表現方法。 |
| UI/UX・ユーザビリティ | 【マルチデバイス対応】 レスポンシブWebデザイン（PC / Tablet / SP）。ブレイクポイントの指定があれば記載。 【アクセシビリティ】 2024年4月の障害者差別解消法改正（合理的配慮の義務化）を踏まえ、「JIS X 8341-3 レベルAA準拠」または「配慮」を求めるか。 【導線設計】 全ページから3クリック以内でCV（問い合わせ）ページへ到達できること。パンくずリストの全ページ設置。 |
| 素材（写真・原稿）の調達 | 【写真撮影】 制作会社によるプロカメラマンの手配が必要か、自社で支給するか。 【原稿作成】 ライティングはどちらが担当するか。 「原稿作成シート」への記入は自社、リライトは制作会社など役割分担を明確に。 |
4.システム・機能要件
「何ができるか」を定義します。ここが曖昧だと追加費用の温床になります。
| CMS（コンテンツ管理システム）要件 | 【推奨システム】 WordPress、ヘッドレスCMS（MicroCMSなど）など指定があるか、提案を求めるか。 【更新対象】 お知らせ、ブログ、導入事例、採用情報、社員インタビュー。 【機能】 ブロックエディタ：HTMLを知らない担当者でも見たまま編集できること。 承認フロー：作成者→承認者→公開 のワークフロー機能が必要か。 プレビュー機能：公開前にスマホ/PCでの表示確認ができること。 予約投稿：日時指定での公開・非公開機能。 |
| フロントエンド機能 | 【フォーム】 問い合わせ、資料請求、ホワイトペーパーダウンロード（自動返信メール、CSVダウンロード、スパム対策 reCAPTCHA v3またはCloudflare Turnstile※推奨）。 【検索機能】 サイト内キーワード検索、カテゴリ・タグによる絞り込み機能。 【多言語対応】 英語・中国語ページの要否（自動翻訳ツールの導入か、ディレクトリを分けた静的ページ制作か）。 |
| 外部サービス埋め込み | Googleマップ、YouTube動画、SNSフィード（X, Instagram）の表示。 |
5.非機能要件
【最重要】 ユーザーの目には見えませんが、サイトの品質と安定性を決める項目です。失敗の多くはここをおろそかにすることで起きます。
| インフラ・サーバー要件 | 【サーバー環境】 現行サーバー利用か、AWS/GCP/Azure等のクラウドへ移行か。Xserver等のレンタルサーバーか。 【ドメイン・DNS】 ドメイン管理の移管有無。DNS切り替え作業の責任分界点（自社か制作会社か）。 【CDN】 画像や動画が多い場合、CloudFrontなどのCDN利用を想定するか。 |
| パフォーマンス要件 | 【表示速度目標】 Google PageSpeed Insightsでのモバイルスコア目標（例：緑色ゾーン、または50点以上）、Core Web Vitals（LCP 2.5秒以内）の考慮。 |
| セキュリティ要件 | 【SSL】 常時SSL化（Let’s Encrypt等の無料SSLか、企業認証SSLか） 【WAF/IPS】 Webアプリケーションファイアウォールの導入要否。 【バックアップ】 日次バックアップ（ファイル・DB）、保存期間（例：過去14日分）、リストア（復旧）手順の確立。 【脆弱性対策】 WordPressの場合、本体・プラグインの最新版利用、納品前のセキュリティ診断（脆弱性スキャン）の実施。 |
| 法規制・コンプライアンス対応 ※2025年トレンド | 【改正電気通信事業法（外部送信規律）】 Cookie利用に関するポップアップバナー（CMPツール）の導入、またはプライバシーポリシーへの詳細記載。 【個人情報保護法】 フォーム通信の暗号化、Pマーク/ISMSに準拠したデータ取り扱い。 |
| 対応ブラウザ・OS | 【対象範囲】 Google Chrome, Safari, Edge, Firefoxの最新版および1つ前のメジャーバージョン。iOS/Androidの最新およびマイナス2バージョンまで。 【IE対応】 Internet Explorerは「非対応」と明記（コスト削減のため）。 |
6.運用・保守・移行要件
公開後のトラブルを防ぐための「守り」の要件です。
| 移行（マイグレーション）要件 | 【301リダイレクト】 旧URLと新URLの対照表（マッピングリスト）作成と、.htaccess等によるサーバーサイドリダイレクトの実装。これは必須です。 【データ移行】 過去のブログ記事1,000件の移行（手動か、プログラムによる自動移行か）。 |
| 運用・保守サポート（SLA） | 【保守契約】 サーバー監視、障害対応、CMSアップデート代行が含まれるか。 【SLA（サービス品質保証）】 障害時の連絡体制（平日10:00-18:00、緊急時は24時間など）。 復旧目標時間（RTO）。 【契約不適合責任（旧：瑕疵担保責任）】 検収後、隠れたバグが見つかった場合の無償修正期間（通常は6ヶ月〜1年）。 |
| 教育・トレーニング | 担当者向けのCMS操作レクチャー会の実施。 操作マニュアル（動画またはPDF）の作成・納品。 |
7.予算・スケジュール・納品物
| 予算感 | 「イニシャル（構築費）：800〜1,000万円」「ランニング（月額保守）：3〜5万円」など分離して記載。 |
| スケジュール | ・RFP配布：〇月〇日 ・質問締切：〇月〇日 ・提案書提出締切：〇月〇日（※最低2〜3週間は確保） ・プレゼン選考：〇月〇日 ・キックオフ：〇月〇日 ・サイト公開：〇月〇日 |
| 納品物リスト（成果物） | ・要件定義書、サイトマップ、ワイヤーフレーム ・デザインデータ一式（Figma / XD / PSD） ・コーディングデータ一式（HTML / CSS / JS / 画像 / 納品時のバックアップデータ一式） ・ドキュメント類（基本設計書、詳細設計書、テスト仕様書・報告書、リダイレクト対照表、操作マニュアル） |
8.評価・選定プロセス
公平な審査を行うための評価シートの項目例です。
| 評価カテゴリ | 評価項目（詳細） | 配点（例） |
|---|---|---|
| 1. 提案力・戦略性 | 課題を正しく理解し、独自の解決策が提示されているか。 競合他社に勝てる差別化戦略があるか。 | 30点 |
| 2. デザイン・表現力 | ブランドイメージを向上させるクオリティか。 ターゲットユーザーに響くUX設計か。 | 20点 |
| 3. 技術力・信頼性 | CMSの提案は適切か。セキュリティや表示速度への配慮はあるか。 類似案件の実績は豊富か。 | 20点 |
| 4. 運用・サポート | 公開後の支援体制（PDCA）は具体的か。 担当者のコミュニケーション能力や熱意は十分か。 | 20点 |
| 5. コスト・見積り | 予算内か、または費用対効果（ROI）が見合っているか。 見積もりの項目は詳細で透明性があるか。 | 10点 |
| 合計 | 100点 |
第5章：RFP作成のコツ～「書けない」を解決する～
項目は分かっても、ゼロから書くのは大変ですよね。効率よく良いRFPを作るためのステップをご紹介します。
ステップ1：社内ヒアリングと現状分析（ネタ集め）
いきなり書き始めずに、まずは材料集めです。
- インタビュー
社長には「将来のビジョン」を、営業には「お客様からの要望」を、サポート担当には「よくあるクレーム」を聞きましょう。現場の声にこそヒントがあります。 - 健康診断
Googleアナリティクスで数字を見て、どのページが読まれているかを確認します。サイトの現状分析に外部のプロの視点を入れるのもおすすめです。
ステップ2：優先順位を決める（MoSCoW分析）
要望を全部盛り込むと予算オーバーになります。ランク付けをしましょう。
- Must（必須）
これがないと困る機能（CMS、スマホ対応、問い合わせフォーム、SNS連携、検索機能など） - Should（推奨）
できれば欲しい機能（MAツール連携、顧客管理、チャットボット、動画など） - Could（あれば良い）
予算があればやりたい（EC機能など） - Won’t（今回はやらない）
次はやるかも（多言語対応、AI導入など）
ステップ3：下書きと事前相談（RFI）
テンプレートを埋めて下書きを作ります。技術的なことや予算感がわからない場合は、信頼できる制作会社に「情報提供依頼（RFI）」を出して、概算や技術的な可能性を聞いてみるのも手です。これでRFPの精度がグッと上がります。
ステップ4：社内承認と配布
RFPができたら社内の承認を得て、制作会社へ配ります。この時、「質問受付期間」を設けて、出た質問と回答は参加する全社に共有しましょう（公平にするためです）。
第6章：良い提案を見抜く「選定眼」を養う
RFPを出して、各社から提案書が来たらどう選べばいいでしょうか？失敗しないパートナー選びのポイントです。
1.「安さ」だけで選ばない
極端に安い見積もりには理由があります。「要件を見落としている」「テストを省いている」「新人を担当にする」など。後で高くつくことが多いので注意です。
2.「イエスマン」より「Noと言えるプロ」を
何でも「できます！」と言う会社は危険です。真のプロは、お客様の要望でもリスクがあれば「それはおすすめしません。なぜなら〜だからです。代わりにこうしませんか？」と代替案をくれます。前提を疑ってより良いゴールへ導いてくれるパートナーを選びましょう。
3.担当者との「相性」と「熱量」
リニューアルは長い旅です。担当者（ディレクター）との相性はとても大事。
- レスポンスは早いですか？
- 専門用語を使わず分かりやすく説明してくれますか？
- 私たちのビジネスに興味を持って熱く語ってくれますか？
4.評価シートで採点する
感情で選ばないように、評価シートを作ってチーム全員で採点しましょう。
| 評価項目 | 評価ポイント | 点数（内訳例） | A社 | B社 |
| 会社・体制 | 経営の安定性、セキュリティ、担当者のスキル | 10 | ||
| 理解度・戦略 | 課題を分かっているか、戦略は鋭いか | 25 | ||
| デザイン・UX | クオリティ、使いやすさ | 20 | ||
| 技術・機能 | CMSやSEOの技術力 | 20 | ||
| 運用・サポート | 公開後の支援体制 | 15 | ||
| コスト | 見積もりの透明性、コスパ | 10 | ||
| 合計 | 100 |
結論：RFPは「Web再生」へのパスポートです
Webサイトリニューアルの失敗は、運が悪かったから起きるのではなく、準備不足、つまりRFPの欠如や不備から必然的に起こります。
「そのRFPが失敗の元凶だった！」なんてことにならないように、今回ご紹介したテンプレートと「4つのRe:（Re:Think, Re:Design, Re:Build, Re:Value）」の視点を使って、戦略的なRFPを作ってください。
良いRFPは、良いパートナーを引き寄せ、社内の意識を統一し、Webサイトを単なる情報の羅列から、利益を生み出し続ける「最強のビジネス資産」へと生まれ変わらせてくれます。
もし、「自分たちだけでRFPを作るのは難しそう…」とか「今のサイトの本当の課題がわからない」という場合は、リヌーボデザインにもご相談ください。
あなたの会社のWebサイトには、まだ見ぬ可能性が眠っています。正しい設計図（RFP）で、その価値を解き放ちましょう。
