BtoBサイトの情報設計——担当者・技術者・決裁者の読む順序を分ける

製品を探し始めた担当者は、まず自社の課題に合うかを知りたい。技術者は既存環境との接続や動作条件から確かめたい。決裁者は費用と導入後の責任を先に見たい。同じ製品を検討していても、読む順序は違う。

ここで「担当者向け」「技術者向け」「決裁者向け」の三つにサイトを切り分けると、別の問題が生まれる。同じ仕様や価格条件が複製され、片方だけ更新される。利用者向けには簡単さ、技術者向けには性能、決裁者向けには効果だけを強調し、前提が食い違うこともある。入口を分けた結果、社内でURLを持ち寄ったときに、どれが現行の事実か分からなくなる。

BtoBサイトの情報設計では、読む順序は分けても、判断対象と事実は分けない。製品・サービスを中心に、短い答え、根拠、仕様、費用と責任、次の行動を重ねる。役割別ページは情報の複製先ではなく、必要な深さへ入る近道にする。

三人を別の入口へ分けても、同じ判断にはつながらない

担当者、技術者、決裁者という呼び名は、固定した三人のペルソナではない。小さな会社では一人が三つの役割を兼ねる。大きな案件では、利用部門、情報システム、セキュリティ、法務、調達、経営が加わる。役職ではなく、その時点で何を確認するかを表す仮の名前である。

しかも、検討は一人で完結しない。Googleが2024年に公開したBtoBマーケティングの記事は、GoogleとBainの調査を基に、現在の購買委員会には部門をまたぐ関係者が平均17人いると説明している。[7] 調査対象や質問を超えて「すべての案件に17人いる」とは言えない。ただ、サイトを一人が最初から最後まで一本道で読む前提より、検索、営業、会議、資料共有の途中で複数の人が出入りする前提の方が現実に近い。

入口は複数あってよい。避けたいのは、入口ごとに事実を作り直すことだ。たとえば「既存システムに接続できる」という説明が、担当者向けページには条件なしで書かれ、技術資料には対応版と制約があり、見積資料には追加費用がある。この三つは別情報ではなく、一つの判断を異なる深さから見た情報だ。

BtoBコンテンツマーケティングの記事では、複数の役割が同じ事実を社内判断に使えるようにする考え方を扱った。サイトの情報設計ではその事実をどこへ置き、どの入口から辿り着けるようにするかが次の仕事になる。

最初に決めるのは三人分のページではない。「この製品を採用できるか」という共通の判断対象である。そのうえで、誰がどこから入っても、同じ製品名、版、仕様、価格条件、制約、更新日へ戻れる構造にする。

組織図ではなく、買い手が確かめる順序から始める

企業サイトは社内で情報を持つ部署に引かれやすい。製品情報は営業、仕様は開発、セキュリティは管理部、導入後の支援はサポートという具合である。運営上の責任分担には必要でも、そのままメニューへ出すと、訪問者は自分の問いを社内組織へ翻訳しなければならない。

英国政府のService Manualは、利用者が達成したいことからニーズを捉え、意見や提案を未検証の仮説として扱うよう求めている。[1] また、良いサービスは利用者に内部組織の知識を要求せず、内部構造を不必要に見せず、途中に行き止まりを作らないとしている。[2] 政府サービスの原則を民間企業へそのまま移すことはできない。それでも、「営業部のページを探す」のではなく「自社に合うか確認する」という利用者の仕事から分類する視点は、BtoBサイトにも使える。

サイトマップを作る前に、顧客が実際に止まった問いを集める。検索語、サイト内検索、営業の質問記録、失注理由、サポート履歴、顧客インタビューを使い、次のような「動詞のあるタスク」へ直す。

• 製品が自社の課題と規模に合うか知る
• 既存環境と接続できるか確かめる
• 導入費用と追加条件を比べる
• セキュリティ、契約、運用分担を確認する
• 試す、見積もる、技術相談をする、社内へ共有する

次に、各タスクの開始点と終了点を書く。「技術者が仕様ページを見る」ではまだ粗い。「技術者が現行版の対応OSとAPIの制約を確認し、検証へ進めるか判断する」まで書けば、必要な情報と次のリンクが見える。

GOV.UKの別の手引きは利用者視点の旅程から、行き止まり、似た手続きの混同、重複する内容、オンラインとオフラインの断絶を探すよう勧める。[3] BtoBサイトなら、商談で渡されたURLから仕様へ進めない、資料とWebの価格条件が違う、セキュリティの説明から問い合わせ先へ行けない、といった断絶が対象になる。

一つの判断対象を、要約・根拠・仕様・調達条件へ重ねる

タスクを並べたら、ページを増やす前に共通の判断骨格を作る。最低限、次の五層を一つの製品・サービス名の下へ置く。

• 対象と適合：何で、誰のどの課題を、どの条件で解くのか
• 根拠：事例、検証、比較、成果が成り立つ条件、対象外
• 仕様と接続：動作条件、互換性、版、API、データ、移行
• 費用と責任：価格、契約、セキュリティ、運用分担、支援
• 次の行動：試用、見積、技術相談、資料共有、問い合わせ

担当者は一層目から入り、根拠を読んで相談へ進みやすい。技術者は三層目から入り、対象の版や運用責任を確認する。決裁者は二層目と四層目から入り、専門的な確認を担当者へ渡す。順序は違っても、参照する仕様や条件は同じである。

各ページの冒頭では、何に答えるページか、対象製品と版、更新日、誰が次に何を判断できるかを示す。米国政府のDigital.govは、本文をすべて読まなくても要点をつかめるよう、正確で内容を説明する見出しを使うよう勧めている。[4] 「詳細」「詳しくはこちら」ではなく、「対応OSと版を確認する」「価格と追加費用を見る」のように、リンク先で完了する確認を書く。

Amazon EC2の公式サイトを2026年10月22日に確認すると、一つの製品名の下に概要、機能、価格、インスタンスタイプ、FAQ、開始方法、資料が並ぶ。[8] ドキュメント側では利用ガイド、インスタンスタイプ、開発者ガイド、API、移行、ワークロード、ベストプラクティスへ分かれる。[9] これはAWSの構造が成果を生んだ証拠ではない。ただ、「製品は一つ、必要な深さへの入口は複数」という実装を観察できる例である。

すべてを一枚へ詰め込む必要もない。技術コンテンツの記事で扱ったように、顧客が判断できる単位へ専門知を編集する。概要ページは適合と全体像、事例は条件付きの根拠、仕様ページは現行条件、セキュリティページは責任分担、価格ページは費用の前提を担う。分ける基準は部署ではなく、答える問いと更新単位である。

役割別導線は、共通情報の複製ではなく近道にする

「技術者向け」「経営者向け」という入口自体が悪いわけではない。役割名を手掛かりにする人もいる。その先に仕様や価格をコピーして閉じ込めず、役割別の入口には基準にする更新元への短い説明とリンクを置く。

たとえば技術者向け入口なら、「仕様」「対応環境」「API」「セキュリティ」「移行」「技術相談」を並べる。ここに仕様本文を複製せず、製品ごとの現行仕様へ接続する。決裁者向け入口なら、「導入効果」「事例」「費用」「契約」「運用責任」「支援体制」へつなぐ。担当者向け入口なら、「対象課題」「選択肢」「事例」「試用」「社内共有用の要約」へつなぐ。

入口は役割別ランディングページだけではない。グローバルナビ、製品ページの目次、関連記事、資料一覧、サイト内検索、営業が送るリンクのどこから入ってもよい。米国Web Design Systemの手引きは、検索や外部リンクから下層ページへ直接入る可能性があるときにパンくずを使い、パンくずとページタイトルの文言をそろえるよう勧めている。[5]

同じ機能にはページをまたいで予測できる名前を使う。米国Web Design Systemのサイドナビゲーション検査も、ナビゲーションが各ページで同じ場所と順序に現れ、現在位置を明示するかを確認項目にしている。[6] 見積依頼を、あるページでは「相談」、別のページでは「お問い合わせ」、別のページでは「商談予約」と呼び替えると、同じ行動なのか判断しにくい。行き先が同じなら基本の名前をそろえる。行き先が違うなら、「技術要件を相談する」「見積を依頼する」のように違いを明示する。

基準にする更新元には、内容だけでなく管理情報を持たせる。製品・サービス名、対象版、適用地域、公開日、最終確認日、更新責任者、参照する原資料を記録する。技術広報の運営体制の記事で整理した編集者の役割は、ここでも有効だ。部署から原稿を集めるだけでなく、複製、矛盾、欠落、古い条件を横断して見つける。

情報設計は、探したページ数より判断完了で測る

サイトを公開したら、PVや滞在時間だけで情報設計を評価しない。役割ごとに代表タスクを一つずつ用意し、初見の人が答えと次の行動へ到達できるかを確かめる。

計測では、タスク完了率、完了までの時間、行き戻り、サイト内検索語、ゼロ件検索、問い合わせ前に残った質問、営業が補足した資料を見る。同じ会社から複数ページが読まれたことは手掛かりになるが、それだけで社内合意を証明しない。営業や顧客へ、「どの情報が足りず、何を別資料で補ったか」を確認する。

最初の監査はサイト全体の作り直しから始めなくてよい。重要な製品を一つ選び、担当者、技術者、決裁者の三つのタスクを実行する。行き止まり、名称の揺れ、古い複製、更新日のないページを記録する。次に、基準にするページを決め、入口からのリンクを直す。新しいページを作るのは、既存ページでは問いや更新単位を分けられないと分かったときである。

情報設計の成否は、三人分のページがそろったかでは決まらない。異なる順序で入った人が同じ事実を確かめ、前提へ戻り、次の判断へ進めるかで決まる。入口は分ける。事実は一つに戻す。その状態を代表タスクで確かめる。