第5章 誰に届けるかを見える化する ―― 購買グループが見えるデータベース（Step1〜4）

5-1. 目指す姿 ―― 6階層が1枚で見えるデータベース

第4章までで、購買グループの定義は揃った。本章から実装に入る。最初に決めるべきは、ゴールの姿である。

購買グループを設計するとは、突き詰めれば、自社のデータベースを「グループが見える構造」にすることである。当社はこのゴールを、左から右へ解像度が上がる6つの階層で描いている。

第1階層は、**データベース全体の統合（SSOT）**である。すべての個人・企業データが一意に管理され、外部データベースによるエンリッチメント（法人番号・業種・売上規模）が添えられている状態。

第2階層は、アカウント群である。データベースの中に、既存顧客が何社あって何人が紐づいているのか、休眠顧客が何社・何人か、まだ取引のない未取引顧客が何社・何人か。この区分ができているか。

第3階層は、アプローチ分類である。アカウント群のそれぞれについて、戦略的にアプローチする対象か、育成する対象か、それ以外か。

第4階層は、グループ単位である。前章で定義した、部門・プロジェクト・エリアの単位で、アカウントの中が切り分けられているか。

第5階層は、役割である。グループの中の関与者が、着火役・旗振り役・門番・金庫番の4タイプに分けられているか。

第6階層は、接点状態×活性度である。その人は営業がタッチしている顧客なのか、マーケティングのリードなのか、匿名なのか。そして、いま動いている（活性）のか、動いていない（非活性）のか。

この6階層が1枚で見えるとき、第1章の3つの症状は消える。リストの先が設計され（第3〜5階層）、誰が動いているかが見え（第6階層）、営業に渡す単位が組織とロールになる（第4〜5階層）。以降の章は、この絵を完成させる手順である。

5-2. 7ステップの全体像

当社は、この絵を完成させる手順を7つのステップで示している。

• Step1　個人の属性情報の整備
• Step2　アカウントの一意化（SSOT）
• Step3　データの補完・強化
• Step4　役割マッピングとグループ定義
• Step5　価値設計
• Step6　グループ単位の施策設計と営業連携
• Step7　データアーキテクトの構築（AI活用）

Step1〜4は「誰に届けるか」を見える化する工程であり、本章で扱う。Step5は「何を伝えるか」（第6章）、Step6は「どう届けるか」（第7章）、Step7は「仕組みにして回し続ける」（第8章）である。

先に、この7ステップの結論を述べておく。グループの単位を定め、役割を推定し、それを維持し続けることを、人手で回し切ることは現実的に不可能である。最終的にはAIを使う。ただし、AIが判定するための材料――個人の属性、一意なアカウント、正しい紐付け――は、人が設計しなければ生まれない。だからStep1〜4は、AIに何を判定させるかの前提を整える工程でもある。

5-3. Step1：個人の属性情報の整備 ―― 買えないデータを、資産にする

第一歩は、個人の属性情報である。

本書は第1章以来、「点ではなく面で」と繰り返してきた。にもかかわらず最初のステップが個人の情報であることに、違和感を覚える読者もいるだろう。だが、面はどこまでも点の集合である。点の情報が貧しければ、面は描けない。

ここで言う個人の情報とは、接点データ（何を見た、何に参加した）のことではない。接点データはすでにあるものとして扱う。それよりも重要なのが、所属部門・事業所・役職といった個人の属性情報である。

一枚の名刺を思い浮かべてほしい。「株式会社サンプル　情報システム部　部長　山田太郎　◯◯事業所　〒000-0000……」。この名刺には、購買グループを見える化するための手がかりがすべて載っている。部門は、グループの手がかりである。役職は、役割の手がかりである。住所は、事業所の割り当ての手がかりである。

ところが、多くの企業のデータベースでは、この手がかりが揃っていない。理由は、これまでの運用にある。リードジェネレーションの時代、Webフォームの項目は「削る」ものだった。入力の手間を減らして獲得数を増やすために、部署は任意項目に、あるいは選択式の大分類に、住所は取らない、役職は「その他」で済ませる。名刺管理ツールから取り込んだデータは、名刺に印字された部門名の揺れをそのまま持ち込む。結果として、接点データは豊富なのに、その人が「どの部門の、どの拠点の、どの立場の人か」が分からない。

購買グループの設計は、この運用を反転させる。フォームは削るものではなく、精度を高めるものになる。部門は正式名称で取る。エリアが検討単位として重要な商材であれば、拠点の住所を取る方法を設計する。役職は、後述する役割推定の根拠になる粒度で取る。「いかにリードを取るか」から「いかに情報を取るか」への切り替えである。

ここで、データを2種類に分けて捉えると設計が明確になる。

買えるデータは、法人番号、業種、売上規模といった企業の情報である。データ提供企業から取得でき、外部データベースで補完できる。

買えないデータは、個人の属性、商談履歴、自社との接点である。これは自社の中にしか存在しない。個人の所属や役職が外部から購入できることは、日本ではまずない。名刺は、お金では買えない自社だけの資産である。

そして買えないデータには、鮮度という敵がいる。名刺を交換した時点では情報システム部の課長だった人が、いまは部長かもしれない。異動して別部門にいるかもしれない。「名刺が最も正しい」と考えがちだが、名刺は交換した瞬間の接点にすぎず、古い名刺がそのまま登録されていることも多い。最新の情報が最高である。買えないデータを資産にするとは、取得の精度を高めることと、鮮度を保ち続ける仕組みを持つことの両方を意味する（鮮度の維持は第8章で扱う）。

5-4. Step2：アカウントの一意化（SSOT） ―― 入口を塞ぐ

第二歩は、個人を企業に、企業をアカウントに正しく紐付け、「単一の真実（Single Source of Truth）」を作ることである。

ABC商事株式会社、（株）ABC商事、ABCショウジ――データベースの中に複数の表記で存在する同一企業を、法人番号で1つに括る。業種タグ、売上レンジを付与する。ここは、前段のStep1と異なり、ある程度お金で解決できる領域である。外部データベースとの照合サービス、名寄せツール、法人番号の付与――手段は揃っている。

ただし、法人番号を付与するだけでは一意にならない。これが実務上の最大の落とし穴である。SFAには日々、新しいレコードが入ってくる。営業が手入力で取引先を作る。名刺ツールが取り込む。基幹システムから連携される。付与した瞬間はきれいでも、翌日には新しい重複が生まれている。一度の名寄せでは終わらないのである。

だから、一意化の本質は「入口を塞ぐ」ことにある。汚染源を特定し、そこを止血しなければ、名寄せは永遠に終わらない。

汚染源はどこにあるか。当社の経験では、MAはそれほど汚染源にならない。MAはメールアドレスをキーにするため、同一人物の重複は構造的に起きにくい。MA側で起きるのは、顧客自身によるフォームのでたらめな入力（「あああ」「テスト」）と、インポートによる先祖返り――古いリストを取り込んだ瞬間に、部長が課長に戻る――の2つが中心である。

汚染データの多くは、SFA側から流れてくる。営業による手入力。基幹システムからの逆流――基幹システムが汚いから、連携した結果SFAが汚れ、SFAが汚いからMAまで汚れる、という連鎖は非常に多い。API連携からの流入。一意化の機能を持たない名刺ツールからの取り込み。そして無用なインポート。SFAはメールアドレスをキーにしないため、同一人物・同一企業が別レコードとして増殖しやすい。結果として、SFAはMAより汚くなるケースが多い。

したがって、Step2で行うべきことは2つである。第一に、既存データの名寄せ。第二に、汚染源ごとの入口の統制――手入力時の照合、基幹連携時の法人番号キーの強制、名刺ツールの選定基準、インポートの承認プロセス。『AI Ready Playbook』で述べたシングルパーソン／シングルアカウントの設計原則は、購買グループを見える化するための前提条件そのものである。データが一意になっていない状態では、次のStep3以降で行う「同じ企業の中の関係性を読む」ことが、構造的にできない。

5-5. アカウント群とアプローチ分類 ―― 9象限で、どこを攻めるかを決める

データが一意になると、初めてアカウントの全体像を数えられる。ここで、目指す姿の第2階層と第3階層を作る。

まず、アカウント群である。データベースの中に、既存顧客が何社あって何人のリードが紐づいているのか。休眠顧客が何社・何人か。未取引顧客が何社・何人か。この区分がされていない企業は多い。「顧客リスト」と「リード」が別々に管理され、その間に休眠という概念がない。

次に、アプローチ分類である。それぞれのアカウントを、戦略的にアプローチする対象か、育成する対象か、それ以外かに分ける。既存顧客の中にも、A社は戦略的アプローチ対象だがB社は育成対象、C社はそれ以外だがポテンシャルはある、という差がある。

この2軸を掛け合わせると、9つの象限ができる。当社はこれをターゲットアカウントマトリクス9象限と呼び、どの象限を攻めるかを決める枠組みとして用いている。

ここで強調したいのは、ABMは新規獲得のためだけの手法ではない、ということである。購買グループの考え方は、既存顧客にも休眠顧客にも適用できる。既存顧客の中に、まだ取引のない部門・拠点・プロジェクトがあるなら、それは購買グループの空白である。休眠顧客の中で誰かが再び動き始めたなら、それは再活性のシグナルである。どの象限にどれだけのアカウントとリードがあるかを数えることが、限られたリソースをどこに向けるかの判断材料になる。

5-6. Step3：データの補完・強化 ―― 関係性をAIで読み解く

第三歩から、AIが登場する。

ここまでで、個人の属性が揃い（Step1）、アカウントが一意になり（Step2）、どの象限を攻めるかが定まった（5-5）。次に必要なのは、同じアカウントの中にいる複数の人物の間の「関係」を読み解くことである。

具体例で示す。あるA社について、データベースには山田太郎（情報システム部　部長、◯◯事業所、シグナルなし）が保有されていた。ここに新たに、田中花子（情報システム部　一般職、◯◯事業所、資料ダウンロード）が追加された。

この2人のデータから、何が読み取れるか。同じ部門、同じ事業所、そして役職差（部長／一般職）。ここから、田中は山田の部下であると推察できる。さらに、田中はシグナルを発している――検討の起点にいる。山田は部長職であり、社内を動かす立場にある。したがって、田中は着火役、山田は旗振り役と推定でき、2人は同じ検討に関わる1つの購買グループである、と読み解ける。

これは、外部からデータを買ってきて付け足す従来のエンリッチメントとは異なる。すでに持っているデータの「関係」から意味を読み解く、内向きのエンリッチメントである。そしてこれは、推察である。絶対ではない。AIの判定には根拠（同部門・同事業所・役職差・シグナル）を添え、項目として持ち、後から人が確認・修正できる形にしておく。

重要なのは、この推察が成り立つ条件である。部門が正式名称で取れていること（Step1）。事業所が割り当てられていること（Step1）。役職が取れていること（Step1）。そして2人が同じアカウントに正しく紐づいていること（Step2）。Step1とStep2を飛ばして「AIでグルーピングしよう」と始めても、AIには読み解く材料がない。ソースがなければ、推察は成り立たない。順序は飛ばせない。

5-7. Step4：役割マッピングとグループ定義

第四歩で、目指す姿の第4階層と第5階層が完成する。

Step3で読み解いた関係性をもとに、部門・役職・行動データから4役割を推定し、「同じ検討に関わっている人の集合」をグループとして定義する。A社の情報システム部の◯◯事業所において、田中（着火役）と山田（旗振り役）が1つの購買グループを構成している。この時点で、門番と金庫番はまだ見えていない。

ここで、視点を1つ変えたい。「役割未特定」は、データの欠損ではない。まだ会えていない役割の発見である。

購買グループに4役割が揃っていることが分かっているなら、着火役と旗振り役しか見えていない状態は、「門番と金庫番に、まだ接点を持てていない」という事実を示している。これは営業にとって、次に誰に会うべきかを示す極めて具体的な情報である。「この案件、決裁ラインの人に会えていますか」という問いに、データで答えられる。役割の空白を可視化することが、Step4の最大の価値である。

グループの定義に使う情報は、3つの経路から集まる。

第一に、人が入れる情報。名刺、フォーム、営業の入力。Step1で精度を高めた属性情報がこれにあたる。

第二に、AIが推察する情報。Step3で述べた、関係性からの役割推定、住所からの事業所割り当て、接点データからの関与関係の推定。

第三に、人を経由して聞き取る情報。インサイドセールスや営業が、電話や面談で得る情報である。「実はこの方、旗振り役ではなく門番でした」「情報システムだけでなく、現場部門も絡んでいます」「部署名が変わりました」「異動されました」――こうした情報は、聞くことでしか取れない。第4章で述べたプロジェクト単位のグループは、この経路でしか捉えられないことが多い。

この3経路の情報を、ひとつのデータベースに格納する。ここが、購買グループ設計の実務上の最大のポイントである。マーケティングの持つMA、営業の持つSFA、インサイドセールスの架電メモ、名刺ツール――情報が別々の場所にある限り、グループは見えない。人が入れた情報も、AIが推察した情報も、聞き取った情報も、同じアカウント・同じパーソンのレコードに集約され、根拠とともに参照できる状態にする。『GTM Engineering Playbook』で述べた、すべてをアカウントとパーソンという2つの基軸に紐づけるという原則は、ここで購買グループという第3の構造を支える土台になる。

これで、「誰に届けるか」が見える化された。データベースの中に、アカウントがあり、その中にグループがあり、グループの中に役割を持った人がいて、誰が動いているかが分かる。だが、データが整っただけでは、グループは動かない。届ける価値が設計されていなければ、見えるようになった相手に何を言えばよいのかが分からない。次章では、役割ごとに「何を伝えるか」を設計する。