第3章 SSOT（単一の真の情報）の重要性 ―― 顧客を一つにする、とは何をすることか

第2章の終わりで、全社が参照する一つの正しい顧客台帳をSSOTSSOTSingle Source of Truth項目ごとに「どこが正か」が一意に定まった状態。全データを1箇所に集めることを意味しない。用語集で見る →（Single Source of Truth：単一の真の情報）と呼んだ。本章では、なぜSSOTが必要なのか、そして顧客を一つにするとは具体的に何をどうすることなのかを述べる。SSOTは、どのシステムに置くかで決まるものではない。何を正とし、どう保つかで決まる。

3-1. SSOTとは何か

SSOTとは、顧客について「これが正しい」と全社が参照する、一つのデータである。

同じ顧客について、営業はSFASFAセールスフォースオートメーション営業の実行と管理のための業務アプリケーション。用語集で見る →を見て、マーケティングはMAMAマーケティングオートメーションマーケティングの実行と管理のための業務アプリケーション。用語集で見る →を見て、経理は基幹システムを見る。それぞれに顧客の情報があり、それぞれが少しずつ違っている。会社名の表記が違う。担当者の部署が古い。取引の有無が反映されていない。この状態では、「この顧客は誰で、今どんな関係にあるのか」という問いに、部門ごとに違う答えが返ってくる。

SSOTは、この問いに一つの答えを返すための仕組みである。企業と担当者について、正しい情報はここにある、と全社が合意した一つの場所。各システムはそこを参照し、そこから供給を受ける。逆に、各システムで新しく分かったことは、そこに反映される。

重要なのは、SSOTが必ずしも「すべてのデータを一か所に入れること」を意味しない点である。SSOTが持つのは、顧客の識別と基本属性、そして関係の状態である。メールの開封履歴やWebの閲覧ログをすべてSSOTに入れる必要はない。それらはMAに置いたままでよい。ただし、その履歴が「誰の」ものかを示す識別子は、SSOTと一致していなければならない。SSOTは顧客を識別するための共通の基準であり、各システムはその基準に沿って、それぞれの接点接点タッチポイント顧客と自社の間で起きる相互作用のすべて。マーケティング接点・営業接点・カスタマーサクセス接点・パートナー接点があり、商談も接点の一つである。用語集で見る →の記録を紐付けていく。

3-2. 顧客を一つにすることで得られる4つの価値

顧客を一つにすると、何が変わるか。価値は4つある。

第一に、顧客を企業・購買グループ購買グループユニット企業内部にある検討の単位。所属と行動の同一性から認定する。BtoBの購買は一人では決まらないため、リードではなくこの単位で捉える。用語集で見る →・パーソンの単位で一つに見られる。 ある企業に、自社の誰が、いつ、どの接点で関わったかが一本の線でたどれる。ある事業部の営業が会っている担当者と、別の事業部のウェビナーに参加した担当者が同じ企業の同じ部門の人だと分かる。第2章で述べた重複アプローチは、ここで初めて防げるようになる。

第二に、検討から受注、活用、再検討までの循環を一気通貫で計測できる。 マーケティングの接点から営業の商談、受注後の利用状況までが同じ顧客に紐づいていれば、どの接点がどの成果につながったかを追える。数字は部門ごとに分断されず、顧客を軸にした一続きのものになる。

第三に、部門間で同じ数字を語れる。 リード数と引き合い数が合わない、商談化商談化リードが営業の対応する案件になること。ここで購買グループの関心・懸念が一人分に縮むと、以降の設計が効かなくなる。用語集で見る →率の分母が違う、という第2章の弊害は、顧客の識別が揃うことで解消の前提が整う。定義の統一は第4章で扱うが、定義を揃えても顧客の識別が揃っていなければ数字は合わない。SSOTは、その前提である。

第四に、AIが顧客を理解できる。 第1章で述べたとおり、AIが相手の状況を正しく説明するには、もとになるデータが揃っている必要がある。顧客の情報が四か所に散らばっていれば、AIは断片的なデータから、誤った説明を導いてしまう。同じ顧客の情報が一つにまとまって初めて、AIはその顧客について一貫した説明を導ける。AI時代のCRMCRMCustomer Relationship Management顧客との関係と取引履歴を管理する仕組み。GTMの4レイヤーでは、SFA・MAと並ぶ業務アプリケーション層に位置づけられる。用語集で見る →において、SSOTはAIの前提条件である。

3-3. 一つのシステムで持てるなら、それが最も望ましい

顧客の情報を一つにする最も分かりやすい方法は、一つのシステムの中で、企業・人物・商談・接点を同じテーブルで管理することである。MAとSFAが同じプラットフォーム上にあり、同じ顧客のレコードをマーケティングも営業も直接見ている状態であれば、同期の必要もなく、顧客は最初から一つである。実現できるのであれば、これに越したことはない。

ただし、多くの企業では、それをすぐに実現できない事情がある。受注後の取引を記録する基幹システムは、MAやSFAと同じシステムには移せない。事業部ごとに既に別のSFAが使われていて、全社で一つに切り替えるには年単位の移行が必要になる。MAとSFAが別の製品で、それぞれの機能を手放せない。こうした状況で、すべてのデータを一つのシステムに移すことを前提にすると、移行が終わるまで顧客は一つにならない。

そのような場合は、複数のシステムがあることを前提に、顧客を一つにする設計を行う。何をどのシステムで持ち、どのシステムの値を正とし、どうつなぐかを決めることである。一つのシステムで持てる部分は一つのシステムで持ち、持てない部分は、次に述べる仕組みで一つの状態に保つ。

SSOTに置くべきものは、顧客の識別と、頻繁には変わらない基本属性、そして関係の状態である。具体的には、企業の識別子と正式名称、業種、規模、所在地、グループ関係。担当者の識別子と氏名、所属、役職。そして取引の有無、契約の状態、自社との関係の深さを示す情報である。

一方、メールの開封、Webの閲覧、商談の会話記録、サポートのやり取りといった接点の詳細は、それが生まれたシステムで持つ。量が多く、その部門の業務の中で使われることがほとんどだからである。ただし、それぞれのシステムに閉じたままでは、他の部門からは見えない。そこで必要になるのが、システム間の同期である。この点は後で述べる。

この考え方は、リレーショナルデータベースの仕組みに基づいている。リレーショナルデータベースでは、情報を一つの大きなテーブル（表）に詰め込むのではなく、企業のテーブル、担当者のテーブル、接点のテーブルというように役割ごとのテーブルに分け、それぞれのテーブルを「識別子」でつなぐ。企業のテーブルには企業を一意に示す識別子があり、担当者のテーブルには「この担当者はどの企業に属するか」を示す企業の識別子が入っている。接点のテーブルには「この接点は誰のものか」を示す担当者の識別子が入っている。テーブルは分かれていても、識別子をたどれば、ある企業の、ある担当者の、すべての接点を一続きに取り出せる。

SSOTとは、この構造における企業と担当者を、全社で一つにすることである。ただし、それは企業と担当者のテーブルを一か所だけに置き、他のシステムがそこを見に行く、という意味ではない。MAにもSFAにも、それぞれの業務で使うための企業・人物・商談のテーブルがある。SSOTの考え方では、これらのテーブルが同じ識別子を持ち、システム間で同期され、同じ状態に保たれる。

たとえば、SFAにある商談のレコードは、SFAの中の企業と人物のレコードに紐づいている。そして、SFAの企業・人物・商談の情報は、MAにある企業・人物・商談のテーブルと同期しており、同じ状態にある。営業がSFAで商談のステージを更新すれば、MAの側でもその人物が商談中であることが分かる。MAで人物がウェビナーに参加すれば、その接点の要約がSFAの人物にも反映される。どちらのシステムを開いても、同じ企業、同じ人物、同じ商談が、同じ状態で見える。識別子が一致し、同期されていれば、システムが分かれていても顧客は一つに見える。識別子が一致していなければ、同期しようにも、同じ顧客であることすら判別できない。

ただし、システム同士を個別に、自前で組んだ連携の処理で同期し、SSOTの状態を保ち続けるのは、実際には相当に大変である。MAとSFAの2つだけであれば同期の経路は一本で済むが、そこに基幹システム、CSツール、事業部ごとのSFA、企業データベースが加わると、同期の経路は組み合わせの数だけ増える。経路が増えるほど、どのシステムの値を正とするかの判断が複雑になり、同期の失敗や食い違いも起きやすくなる。一つのシステムを更新したら、どこまで反映されたかを誰も把握できない、という状態に陥る。

いずれにしても、顧客の情報を一つに集約する場所は必要になる。各システムのデータを一か所に集め、そこで名寄せ名寄せ同一の企業・人物を指す複数のレコードを特定し、統合する処理。用語集で見る →と統合を行い、統合した結果を各システムに戻す。システム同士を一本ずつつなぐのではなく、すべてのシステムが一つの集約の場所とつながる形にする。この集約の場所が、データ基盤である。データ基盤があれば、同期の経路は「各システムとデータ基盤」の本数で済み、どの値を正とするかの判断もデータ基盤の側で一元的に行える。

つまりSSOTの設計とは、どのデータをどのテーブルで管理し、どの識別子でつなぎ、何をどこに集約するかを決めることである。考え方の順序は次のとおりである。

• 一つのシステムで持てる部分は、そのシステムで持つ。 同期の必要がなく、最も確実である
• システム間のテーブルを標準の機能で相互に連携できる場合は、それを使う。 SFAとMAの間で、企業・人物・商談のテーブルを製品が標準で備える連携機能によって双方向に同期できるのであれば、自前で連携の処理を組むより、はるかに安定して同じ状態を保てる
• それでも持てない部分は、データ基盤に集約する。 基幹システムや事業部ごとのシステムなど、標準の連携機能ではつなげないものは、データ基盤に集める

そのうえで、どの項目はどのシステムの値を正とするのか（企業の基本属性はデータベンダー、取引の有無は基幹システム、商談の状態はSFA、といった具合に）、どの方向に、どの頻度で同期するのかを決める。この整理ができていれば、システムが複数に分かれていても、顧客に関するあらゆるデータを一人の顧客のもとに寄せることができる。

3-4. 企業を確定する：法人番号を共通キーにする

顧客を一つにするうえで、最初に取り組むべきは企業の確定である。同じ企業が、システムによって別の企業に見えている状態を解消する。

その共通キーとして最も有効なのが、法人番号法人番号国税庁が全法人に付番する13桁の番号。企業の名寄せに使える公的キー。用語集で見る →である。国税庁が付番する13桁の法人番号は、日本国内のすべての法人に一意に振られており、公開されている。社名が変わっても、表記がゆれても、法人番号は変わらない。この番号を軸に、SFAの企業情報、MAの企業情報、基幹システムの取引先コード、データベンダーの企業コードを紐付ける。それによって、四か所に散らばっていた同じ企業が、一つの法人番号のもとに集約される。

法人番号を軸にする利点は、社内のどのシステムにも属さない、中立的なキーだという点にある。SFAの企業IDを共通キーにすると、SFAを使わない部門との連携が難しくなる。基幹システムの取引先コードを共通キーにすると、取引のない見込み客に番号が振れない。法人番号は、取引の有無にかかわらず、すべての法人に最初から存在している。

3-5. データベンダーが提供するもの：キーに加えて、アカウントの静的情報

社名だけでは、企業について何も分からない。たとえば「アクセス」という名前の会社は、日本国内に数百社存在する。「アクセス社の担当者から資料請求があった」という情報だけでは、それがどのアクセス社なのか、自社の取引先なのか、どんな事業をしている会社なのか、何一つ確定しない。法人番号を紐付けて初めて、どのアクセス社かが確定する。

だが、法人番号で「どの会社か」が確定しても、それだけでは「どんな会社か」はまだ分からない。業種は何か、規模はどれくらいか、どのグループに属するのか。これを知るには、属性情報が要る。

ここで役立つのが、企業データベースを提供するデータベンダーである。代表的なものに、Sansan（Sansan Data Hub）やuSonar（LBC）がある。これらのベンダーは、法人番号や独自の企業コードといった識別のキーに加えて、企業の静的な属性情報を提供している。業種、売上規模、従業員数、所在地、上場区分、グループ関係、事業の特徴。いずれも頻繁には変わらない、恒久的な情報である。

この静的情報は、2つの役割を果たす。

1つは、自社の顧客台帳を補完することである。営業が入力しなくても、企業の基本情報は外部から自動で埋まる。第2章で述べた「台帳の更新を自動化する」ことの、最初の具体的な手段がこれである。

もう1つは、全社で顧客を同じ基準で比べられるようになることである。事業部ごとに業種の分類が違えば、全社で顧客を比較できない。外部の統一された分類を使えば、どの事業部の顧客も同じ物差しで見られる。当社では、企業の規模や業種、自社との取引状況などをもとに顧客企業を9つの区分に分類し、どの企業にどれだけの資源を投じるかを決める枠組みを「ターゲットアカウントターゲットアカウントABMで狙いを定めた企業。選定した「その先」にいる誰に何をいつ届けるかを設計するのが購買グループの考え方。用語集で見る →マトリクス9象限」と呼んでいる。このような、企業を分類して優先順位をつける枠組みは、どの企業も同じ物差しで測れることが前提になる。法人番号によって企業が一意に確定し、揃った属性によって企業の性質が同じ基準で分かる。この両方があって初めて、全社で機能する。

3-6. データベンダーの品質は「紐付けロジック」で決まる

データベンダーを比較する際、多くの企業は保有件数を見る。何百万社のデータを持っているか。だが、実務で品質を決めるのは件数ではない。自社のCRMに既にあるデータを、どれだけ正確に紐付けられるかである。

自社のCRMには、表記ゆれと重複を含んだデータが既に入っている。「株式会社〇〇」と「（株）〇〇」と「〇〇（株）」。旧社名のまま残っている企業。支店名や事業所名で登録されている企業。合併や分社を経て、今は別の法人になっている企業。データベンダーの価値は、こうした不揃いなデータに対して、どう判別し、どの企業に紐付け、どこまで正確性を担保できるかにある。

評価すべき観点は次のとおりである。

• 判別の広さ：完全一致だけでなく、旧社名、略称、支店・事業所名、英文表記をどこまで扱えるか
• 履歴への対応：合併、分社、社名変更の履歴を持ち、過去の名称からも現在の法人にたどり着けるか
• 根拠と確度の提示：紐付けの根拠と確からしさが示され、自動で採用するものと人が確認するものを分けられるか
• 誤紐付けの検知と修正：間違った紐付けを発見し、修正し、その修正が以降の処理に反映されるか

ベンダー選定では、自社のCRMデータの一部を実際に渡し、紐付けの精度を検証することを勧める。保有件数が多くても、自社のデータの半分しか紐付かないベンダーは、自社にとっては半分の価値しかない。

もう一つ、選定で重視したいのが、自社が使っているSFAやMAとの連携のしやすさである。主要なデータベンダーは、SFAやMAに対して標準のコネクター（連携機能）を提供しており、企業情報の補完や更新をシステム間で自動で行える。コネクターがあれば、第2章で述べた「台帳の更新を自動化する」ことが、追加の開発なしに実現できる。逆にコネクターがなければ、データを取り出し、加工し、取り込む処理を自社で組み、保守し続けることになる。精度が同等であれば、自社のSFA・MAに標準で連携できるベンダーを選ぶ方が、運用の負荷は大きく下がる。

3-7. 法人番号だけでは足りない領域

法人番号は強力な共通キーだが、万能ではない。法人番号は法人単位に振られるため、法人より細かい単位を識別できない。

大手企業を顧客とする場合、この限界は無視できない。同じ法人の中に、複数の事業所、複数の事業部、複数の工場がある。それぞれが独立した予算と決裁権を持ち、実質的には別の顧客として動いている。法人番号で一つに集約してしまうと、「同じ企業の別の事業部への提案」が「既存顧客への追加提案」として扱われ、購買グループも接点も混ざってしまう。

では、事業所や部門をどう管理するか。事業所や部門を独立したテーブル（マスタマスタその目的において正とするデータの置き場所。目的別に定義する。用語集で見る →ー）として持とうとすると、管理は一気に複雑になる。事業所の新設や統廃合、部門の名称変更や組織改編が起きるたびに、マスターを更新し続けなければならないからである。

現実的なのは、事業所や部門のテーブルを持たず、人にぶら下げることである。企業のテーブルは法人単位で持ち、法人番号で識別する。事業所や部門は、パーソンの属性として「どの事業所の、どの部門に所属しているか」を持たせる。こうしておけば、同じ法人に属するパーソンを、事業所ごと、部門ごとにまとめて一覧にできる。「同じ企業の別の事業部への提案」と「既存の事業部への追加提案」も、パーソンの所属で区別できる。

「法人」と「実質的な顧客の単位」は別である。ただし、その違いは事業所や部門のマスターを作って表すのではなく、法人と、そこに属するパーソンの所属情報の組み合わせで表す。これが、管理の複雑さを抑えながら大手企業を相手にするための構造である。

逆方向の階層も必要である。法人の上には、グループがある。親会社と子会社、持株会社と事業会社。グループ全体を一つの顧客として見たい場面と、個別の法人として見たい場面の両方がある。データベンダーのグループ情報を使い、法人番号をグループに紐付けておくことで、両方の見方が可能になる。

3-8. パーソンの名寄せ

企業が確定したら、次はパーソンである。人については法人番号のような公的な共通キーはない。だが、名寄せの難度はむしろ企業より低い。BtoBでは、一人ひとりが勤務先のメールアドレスを固有に持っていることが多く、そのメールアドレスが実質的な共通キーとして機能するからである。名刺、Webフォーム、ウェビナー登録、営業のメールのやり取り。いずれもメールアドレスを含んでおり、それを軸に同じ人物を一つに寄せられる。

ただし、例外となる業界がある。公共機関、金融機関、病院などでは、個人のメールアドレスが付与されていない、部署の共有アドレスで運用されている、あるいはセキュリティ上の理由で外部とのメールが制限されている場合がある。こうした業界を顧客とする場合は、氏名・所属・役職の組み合わせや名刺情報を軸にした名寄せが必要になり、難度は上がる。

メールアドレスをキーにした運用では、氏名の表記が漢字であれ、カタカナであれ、英文であれ、システムは同じメールアドレスを持つ人物を同一人物として扱う。結婚などで姓が変わっても、メールアドレスが同じであれば同じ人物として扱われ、新しい氏名で情報が更新される。つまり、氏名の表記ゆれは、人物の識別にとっては大きな問題にならない。

それでも、扱うべき問題が2つある。

第一に、異動である。同じ人物が、部署を移り、役職が変わり、時には関連会社に出向する。異動によってメールアドレスが変わることもあり、その場合はキーそのものが切り替わる。SFAに登録された当時の所属のままでは、その人が今どこにいて、どんな立場かが分からない。名刺管理サービスとの連携や、メールの署名からの自動更新は、この問題に対する現実的な手段である。

第二に、重複である。同じ人物が、展示会で名刺交換したときと、Webから資料請求したときと、営業が登録したときで、3つのレコードになっている。

ここで、MAとSFAでは重複への対処が異なる点を押さえておきたい。MAは、メールアドレスをキーにして同じ人物を一つに寄せることを主機能の一つとして備えている。展示会、Webフォーム、ウェビナー、メール配信といった多数の施策から流入する人物の名寄せは、MAに任せるのが合理的である。MAを経由させることで、マーケティング接点から入ってくる人物は、MAに登録される時点で一人に揃う。

一方、SFAはメールアドレスをキーにしていない。営業担当者が担当者を登録する際、既に同じ人物が登録されているかどうかは、システムが自動で判定してくれるとは限らない。同じ人物が営業担当者ごとに別々に登録され、重複が積み上がる。したがってSFA側では、重複が発生しないようにするための厳密なルールが必要になる。登録前に既存の担当者を検索する手順、メールアドレスを必須項目にする設定、MAから連携された担当者を正とし、営業が新規登録した担当者は定期的に突き合わせる運用。こうしたルールを決め、システムの設定と運用の両方で守らせることが、SFA側の名寄せである。

パーソンの名寄せは、第5章で扱う購買グループの前提でもある。誰と誰が同じ企業の同じ部門にいて、どんな役割で関わっているかを把握するには、まずその「誰」が一人として確定していなければならない。

3-9. SSOTをどこに置くか：構成の3類型

SSOTを何にするかが決まったら、それをどこに置くかを決める。構成には大きく3つの類型がある。

類型①　SFA一体型。 SFAの企業・担当者情報をSSOTとし、MAやCSツールはそれを参照する。既にSFAが全社で使われており、営業接点が顧客関係の中心にある企業に向く。第2章で述べたとおり、SFAの中の企業情報が台帳を兼ねること自体は間違っていない。ただし、台帳の更新を営業の手入力に頼らず、外部データや他システムからの自動更新で保つ仕組みが要る。

類型②　MA・SFA統合プラットフォーム型。 MAとSFAが同じプラットフォーム上にあり、顧客情報を最初から共有している構成。マーケティング接点と営業接点が同じ顧客レコードに自然に集まるため、SSOTの実現は比較的容易である。一方で、基幹システムやCSツールとの連携は別途設計が必要になる。

類型③　DWHDWHデータウェアハウス複数システムのデータを蓄積・統合・加工するためのデータ基盤。用語集で見る →併用型。 SFA、MA、基幹システム、CSツールのデータをDWH（データウェアハウス）に集め、そこで名寄せと統合を行い、統合した結果を各システムに戻す構成。システムが多く、事業部ごとに異なるツールを使っている大手企業に向く。構築の負荷は最も大きいが、どのシステムにも縛られずにSSOTを設計できる。3-3で述べたとおり、複数のシステムがある企業では、個別の同期で一つの状態を保つことは難しく、いずれはこのようなデータ基盤による集約が必要になる。

どの類型を選ぶかは、事業の構造、データの量、既存システムの資産、組織の体制、そしてAIとの接続のしやすさで決まる。重要なのは、類型の選択がSSOTの本質ではないという点である。どの類型でも、何を正とし、どう自動で保つかが設計されていなければ、SSOTは機能しない。

3-10. データ品質を保ち続ける仕組み

SSOTは、一度作れば終わるものではない。企業は合併し、担当者は異動し、社名は変わる。何もしなければ、SSOTは作った日から古くなり始める。

品質を保ち続けるには、3つの仕組みが要る。

1つ目は、更新の自動化である。データベンダーからの定期的な属性更新、基幹システムとの取引状態の同期、名刺や議事録やメールからの担当者情報の更新。第2章で述べた「台帳の更新を自動化する」とは、この仕組みを指す。

2つ目は、品質の可視化である。法人番号が紐付いていない企業の割合、重複が疑われるパーソンの件数、最終更新から一定期間が過ぎた担当者の数。これらを常に見える状態にし、品質の低下を早期に捉える。

3つ目は、責任の明確化である。SSOTの設計と維持を誰が担うのかが決まっていなければ、品質は誰のものでもなくなる。これは営業でもマーケティングでもない、横断的な役割である。その役割については第10章で述べる。

SSOTが整うと、顧客は一つになる。だが、一つになった顧客について何を記録し、どう構造化するかは、まだ決まっていない。次章では、MAとSFAが持つべきデータ構造と、接点・活動・商談の定義を扱う。