BtoBサイトのリニューアルが失敗する主因は、デザインの質だけではありません。「何を作るか」は決まっていても、「どの顧客の、どの判断を助け、何をもって完成とするか」が決まらないまま進むことです。
結論から言うと、BtoBサイトリニューアルの要件定義は、ページ一覧や機能一覧を作る作業ではありません。事業課題→顧客の意思決定→サイト上で果たす役割→実装要件→受入基準→公開後に見る数字を一本につなぐ作業です。
このつながりがあれば、制作会社との認識差、リニューアル後のSEO流入減少、計測漏れ、「公開したが商談につながらない」という問題を減らせます。本記事では、情報設計そのものの作り方ではなく、情報設計・CMS・コンテンツ・SEO・計測を機能させるための要件定義に絞って解説します。
BtoBサイトリニューアルの要件定義とは
要件定義とは、納品物に求める条件を、関係者が同じように判断できる形にすることです。したがって「先進的なデザイン」「使いやすいCMS」「SEOに強いサイト」といった表現だけでは要件になりません。解釈が人によって異なり、完成判定もできないためです。
BtoBでは、一人の訪問者をすぐ問い合わせへ送るだけでは不十分です。実務担当者は自社課題への適合を確かめ、技術担当者は仕様や連携条件を確認し、決裁者は投資対効果と導入実績を検討します。サイトは、それぞれが社内で説明・比較・合意するための材料を提供する必要があります。
要件定義書では、要望を次の順に変換します。
- 「サイトを新しくしたい」
- 「見込み顧客がサービスの違いを理解できず、商談前に比較対象から外れている」
- 「用途別ページ、比較材料、導入プロセス、技術・セキュリティ情報へ到達できる導線が必要」
- 「該当ページが公開され、主要導線・計測・アクセシビリティ・検索移行の確認を通過したら受け入れる」
このように、主観的な希望を検証可能な条件に置き換えることが重要です。
リニューアル前に確認したい：本当に全面改修が必要か
「問い合わせが少ない」ことだけを理由に全面リニューアルを決めるのは早計です。原因が一部ページの訴求、フォーム、広告流入との不整合、営業フォローにあるなら、改善対象を絞った方が速く、リスクも小さくなります。
一方、次のような問題が複数重なるなら、構造から見直す価値があります。
- 事業やサービスの増加に対して、ナビゲーションとサイトマップが継ぎはぎになっている
- 営業がサイトを使わず、個別のPDFや説明資料を毎回送っている
- 新しいページを公開するたびに開発工数がかかり、キャンペーンやコンテンツ施策が止まる
- フォーム送信は計測できても、流入元・閲覧内容・リード品質を商談まで追えない
- URL変更、コンテンツ統合、CMS移行を予定しており、検索流入を守る移行設計が必要になる
- 表示、操作、更新の品質にばらつきがあり、個別修正では再発する
全面改修か部分改善かを判断するには、現サイトの課題を「デザイン」「情報」「コンテンツ」「運用」「計測」「技術」に分けます。問題が特定のページや導線に閉じるなら改善施策、複数領域にまたがるならリニューアル要件として扱う、という切り分けが実務的です。
BtoBサイトリニューアルの要件定義を進める7ステップ
1. リニューアルの目的を「顧客が進めない判断」で定義する
最初に決めるべきは、作るページ数でもCMSでもありません。顧客が現在のサイト上で進められない判断です。
たとえば「認知を広げる」は事業上の意図であって、制作要件にはなりにくい表現です。次のように分解すると、必要なコンテンツと導線が見えてきます。
- 顧客の状況：初回比較、導入検討、稟議準備、技術評価のどこで困っているか
- 止まる理由：対象業種への適合、費用対効果、導入体制、連携仕様、信頼性のどれが不足するか
- サイトが担う仕事：理解、比較、社内共有、相談開始のどれを助けるか
- 事業成果：有効問い合わせ、商談化、営業工数の削減、コンテンツ更新速度など、何を改善したいか
ここでのポイントは、KPIを先に固定しすぎないことです。事業成果を確認するために、どの中間行動を測るべきかは、顧客の判断プロセスと導線を設計してから決めます。
2. 現サイトの基準値と資産を、公開前に保存する
リニューアル後に「成果が上がったか」を判断するには、比較対象が必要です。公開前の状態を保存せずにサイトを入れ替えると、改善なのか季節性・施策差なのかを判別できません。
最低限、URL単位で次を棚卸しします。
- 検索流入、主な検索クエリ、外部リンク、インデックス状況
- 閲覧数だけでなく、CTAクリック、フォーム開始、送信などの導線データ
- 問い合わせ後の有効判定、商談化、失注理由などCRM側の結果
- 残す・統合する・廃止する・新規作成するコンテンツの判断
- 現行CMS、フォーム、MA、CRM、タグ管理、同意管理などの連携構成
比較期間は、事業の季節性と営業サイクルを考慮して決めます。月次の問い合わせだけで比較すると、展示会や広告出稿の影響をリニューアル成果と誤認しやすいためです。
コンテンツの残存・統合・廃止を決める際は、検索流入だけで判断しないことも重要です。検索流入は少なくても、商談中の顧客が閲覧する導入事例や技術資料の説明ページは、営業・購買の意思決定に寄与することがあります。より詳しい棚卸しの考え方は、BtoBコンテンツ監査のやり方も参考にしてください。
3. 購買委員会ごとに「必要な証拠」と「次の行動」を整理する
BtoBサイトでは、ペルソナを属性だけで作ると、制作物が抽象的になりがちです。「誰が」「どの判断で」「何を根拠に」「次に何をしたいか」を整理してください。
たとえば、現場責任者は導入後の業務変化、技術担当者は連携要件やセキュリティ、決裁者は投資妥当性や導入実績を確認します。同じサービスページでも、全員に同じ説明を長く見せるより、判断材料へ到達できる構造にした方が機能します。
この整理は、サイトマップだけでなく、CTA設計にも影響します。情報収集段階の技術担当者へ、いきなり「お問い合わせ」を一つだけ置いても行動しにくい場合があります。仕様資料、導入プロセス、相談、事例といった選択肢を、ページの役割に応じて分ける必要があります。情報設計の具体的な組み立て方は、BtoBサイトの情報設計で解説しています。
4. 要望を「要件・優先度・受入基準・責任者」に変換する
要件定義書の核は、要望リストではなく、判断できる要件の一覧です。特にBtoBサイトでは、コンテンツ、CMS、連携、検索移行、品質保証の責任範囲を曖昧にしないことが欠かせません。
| 領域 | 曖昧な要望 | 要件と受入基準の例 |
|---|---|---|
| 情報設計 | サービスを分かりやすくしたい | 用途・業種・サービス別に到達経路を設計し、主要ページから関連する証拠ページへ内部リンクで移動できる |
| コンテンツ | 事例を増やしたい | 業種、課題、実施内容、成果、導入体制を入力項目として持ち、一覧・詳細・関連表示に再利用できる |
| CMS | 更新しやすくしたい | 担当者が定義済みコンポーネントでLPを作成でき、公開前レビューと権限管理を行える |
| 計測 | GA4を入れたい | CTA、フォーム開始、送信、資料請求などをイベントで取得し、流入・ページ種別・CTA配置で分析できる |
| CRM連携 | リードを連携したい | フォーム種別・流入情報・閲覧文脈を定義した形式でCRMへ渡し、営業の確認項目と重複しない |
| SEO移行 | 順位を落としたくない | 旧URL・新URL・移行理由・転送方式・確認結果を一覧化し、重要URLは公開前後に検証する |
| 品質 | 安心して使えるサイトにしたい | 対象ブラウザ・端末・アクセシビリティ基準・テスト対象ページ・不具合の修正判断者を事前に定義する |
さらに各要件には、優先度、前提条件、実装担当、承認者、検証方法を加えます。「重要」と書くだけでは優先順位になりません。未実装なら公開を止める要件、代替手段があれば公開できる要件、公開後に改善する要件を分けることで、終盤の意思決定が速くなります。
5. CMS要件は「ページを作る機能」ではなく「運用の再現性」で決める
CMS選定では、機能の多さよりも、更新業務を安全に繰り返せるかを見ます。とくにBtoBでは、サービス追加、導入事例公開、セミナー告知、資料更新、キャンペーンLP作成が継続的に発生します。
そのため、ページ単位のデザインではなく、再利用する情報と部品を定義します。たとえば導入事例なら、見出し・企業属性・課題・支援内容・成果・引用・関連サービスを構造化します。自由記述だけで作ると、一覧表示、絞り込み、関連コンテンツ表示、将来の改修でコストが増えます。
CMS要件で確認したいのは次の4点です。
- どの担当者が、どのコンテンツを、どの承認経路で更新するか
- 編集可能な範囲と、ブランド・アクセシビリティを守るために固定する範囲はどこか
- コンポーネントの利用ルール、変更履歴、プレビュー、ロールバックをどう扱うか
- 制作会社への依頼が必要な変更と、社内で完結できる変更をどう分けるか
「誰でも自由に編集できる」は運用性ではありません。更新スピードと品質維持の両立が、CMS要件の本来の目的です。
6. 計測要件は、GA4・CRM・営業判断を分けて設計する
サイトリニューアル時に「GA4を設置する」だけでは、改善に必要なデータはそろいません。GA4は匿名行動、CRMは個人・企業情報と営業結果、営業は案件の実態を扱います。それぞれの役割を分け、つながるキーと責任者を決めます。
まず、サイト側で測るイベントを、改善判断に必要な粒度に絞ります。例として、cta_click、form_start、form_submitを設計し、cta_id、placement、page_type、offer_typeのような分析用パラメータを付けます。パラメータを送るだけではレポートで使えないケースがあるため、GA4側で必要なカスタム定義も要件に含めてください。
一方で、GA4のイベントやURL、UTMパラメータに氏名、メールアドレス、電話番号、自由入力の問い合わせ内容を送らない設計が必要です。個人を特定できる情報の扱い、同意取得、CRMへ渡すデータは、法務・セキュリティ方針と合わせて決めます。
CTAの表示から商談化までを分解する考え方は、BtoBサイトのCTA改善方法もあわせて確認してください。
7. 公開後の確認ではなく、公開前に受入基準を合意する
受入基準は、完成後のテスト項目ではありません。制作中に「どこまで作れば完了か」を判断するための基準です。要件ごとに、確認環境、確認手順、合格条件、証跡、最終承認者を決めます。
公開判定では、少なくとも次を確認対象に含めます。
- 顧客体験：主要な閲覧・比較・資料取得・問い合わせの導線が、対象端末で完了するか
- コンテンツ：重要な主張に根拠があり、旧コンテンツの残存・統合・廃止が台帳どおりか
- SEO移行：URLマッピング、恒久転送、canonical、内部リンク、XMLサイトマップ、robots設定を確認したか
- 計測：本番環境でイベント、フォーム、CRM連携、重複送信、テストデータ除外を確認したか
- 品質：アクセシビリティ、表示、操作、エラー時の案内、管理画面の更新手順を確認したか
URLを変更するリニューアルでは、旧URLを一律にトップページへ送るのではなく、内容的に対応する新URLへ移すことが原則です。統合して代替ページがない場合は、無理な転送をせず適切なエラー応答を返す判断も必要です。公開後は検索・アクセス・コンバージョンだけでなく、404、フォームエラー、CRM連携エラー、主要ページの表示不良を継続監視します。
要件定義で見落とされやすい3つの論点
「デザイン要件」と「コンテンツ要件」を分けない
訴求が弱いことをデザインで補おうとすると、情報量の多いヒーローエリアや、説明の少ない抽象表現になりやすくなります。誰に何を納得してほしいか、何を証拠として示すかを先に決めると、デザインは判断を助ける役割に戻ります。
SEOを公開直前のチェック作業にしない
SEOはmeta descriptionや見出しを整える工程だけではありません。残すべきコンテンツ、URL構造、内部リンク、構造化された情報、リダイレクト、公開後の監視にまたがります。とくに統合・廃止判断は、ワイヤーフレーム完成後ではなく、コンテンツ棚卸しの段階で決めるべきです。
完成を「公開日」で定義しない
サイトは公開日が終点ではなく、仮説を検証できる状態になった日がスタートです。公開後に見る数字、確認頻度、改善を起案する担当、CMSコンポーネントを追加・廃止する判断基準まで決めて初めて、リニューアル投資を運用に接続できます。
まとめ：要件定義書は、制作の発注文書ではなく改善の設計図
BtoBサイトリニューアルの要件定義では、見た目や機能の希望を集めるだけでは不十分です。顧客が進めたい判断、営業が必要とする情報、マーケティングが改善したい数字、運用チームが継続できる制作ルールを結び付ける必要があります。
まずは、現サイトの基準値とURL資産を保存し、「誰が、どの判断で、何の証拠を必要とするか」を整理してください。その上で、要件を受入基準と責任者まで落とし込めば、デザイン・CMS・SEO・計測を別プロジェクトにせず、成果につながる一つのサイト運用基盤として設計できます。
