第6章 日本企業への実装論――米国の前提と、日本の現実解

ここまで解説してきた方法論は、その多くが米国市場で体系化されたものである。しかし第2章で述べた通り、海外のベストプラクティスをそのまま持ち込んでも日本では機能しない。組織の作り方が違い、購買の進み方が違い、すでに動いているツールが違うからだ。本章では、日本企業がGTMエンジニアリングGTM EngineeringGo-To-Market EngineeringGTM戦略の7つの工程を、テクノロジーとAIで標準化し、自動化し、精度を上げ続けることで、完遂し、グロースさせる手段。多くの企業で欠けている、ターゲットと施策の間の工程を仕組みにする。用語集で見る →を実装する際に踏まえるべき「前提の違い」を組織・購買文化・ツールの3点で整理し、それぞれに対する現実解を示す。あわせて、制約の裏側にある「日本ならではの優位性」を論じる。

6-1 前提の違い①――組織：分業なき現場にどう実装するか

米国のGTMGTMGo-To-Market製品・サービスを市場に届けて収益化するまでの一連の設計。日本語圏では Google Tag Manager と略称が重なるため、文脈に注意が要る。用語集で見る →エンジニアリングはSDRSDRSales Development Representative見込み客への初期接触と商談化を担う役割。インサイドセールスのうち、新規開拓側を指すことが多い。用語集で見る →・AE・CSM・RevOpsRevOpsレベニューオペレーション部門を横断して、レベニューサイクル全体のデータとプロセスに責任を持つ機能。用語集で見る →という職種分業を前提に組み立てられている。「マーケからSDRへ、SDRからAEへ」というハンドオフハンドオフマーケティングから営業へなど、部門をまたいでリードや案件を引き渡すこと。条件を決めずに運用すると、取り逃しと差し戻しが起きる。用語集で見る →の自動化は、そもそもハンドオフする部門が存在して初めて意味を持つ。一方、日本では営業が初回接点接点タッチポイント顧客と自社の間で起きる相互作用のすべて。マーケティング接点・営業接点・カスタマーサクセス接点・パートナー接点があり、商談も接点の一つである。用語集で見る →から受注、フォローまで一気通貫でカバーする企業がいまだ主流であり、分業の土台自体がない。

現実解は、「分業を先に作ってから自動化する」のではなく、「一気通貫のままでも機能するデータ構造から始める」ことである。営業個人が全工程を担っていても、アカウント/ピープルの一意性とデータ集積の仕組み（レイヤー①）は実装できるし、その効果はむしろ大きい。属人化した営業活動がデータとして可視化されることが、将来の分業設計の判断材料そのものになるからだ。組織を米国型に変えることは前提条件ではなく、データが揃った後の選択肢である。

6-2 前提の違い②――購買文化：稟議と関係性の市場で「シグナル」をどう読むか

日本のBtoB購買には、複数階層の稟議による合議制、既存ベンダーとの長期関係の重視、リスク回避を優先する組織文化が根強い。意思決定は「個人の判断」ではなく「組織の合意形成プロセス」であり、営業サイクルは長く、関与者（DMUDMUDecision Making Unit／意思決定関与者群一つの購買に関わる複数人の集合。購買グループとほぼ同義で用いる。用語集で見る →）は多い。

この前提は、シグナルシグナル顧客企業に起きた変化を示す情報。経営方針・組織・キーパーソン・採用・投資と業績・事業・導入ツールと体制・外部環境の変化があり、多くは公開されている情報から得られる。用語集で見る →設計とアプローチ設計の両方に設計変更を要求する。第一に、シグナルは「個人の興味」だけでなく「組織の合意形成の進行」を捕捉する必要がある。同一アカウント内の複数人が資料を閲覧し始めた、情報システム部門の人物が加わった――こうした「関与者の広がり」こそ、日本市場で商談確度を示す最重要シグナルであり、これを検知できるかどうかは、まさにアカウントとピープルの関係構造（レイヤー①）の設計にかかっている。第二に、アプローチの設計。米国流の大量コールドメールは、業界によっては「失礼」と受け取られ、ブランド毀損に直結する。日本での実務解は、コールドの物量ではなく、展示会・セミナー・紹介・既存名刺といった「一度接点を持った関係」の中でシグナルを検知し、最適なタイミングで再接触する設計である。自動化すべきは送信の物量ではなく、検知と準備（リサーチ・文脈生成）なのだ。

6-3 前提の違い③――ツールとデータ：すでに動いているSaaSをどう扱うか

米国の方法論は、Salesforce・HubSpot・ClayClay企業やパーソンについて外にある情報を集め、AIで判断し、文面を作り、MA・SFAに書き戻す、営業・マーケティング向けのデータ処理ツール。画面は表計算ソフトに似ており、1行が1社または1人、1列が1つの問いに対応する。米国のClay Labs社が提供する。用語集で見る →・Outreachといった英語圏ツールの接続を前提に書かれている。しかし日本企業の現場には、Sansanで管理される名刺データ、kintoneで運用される顧客管理、国産MAMAマーケティングオートメーションマーケティングの実行と管理のための業務アプリケーション。用語集で見る →など、米国ベンダーが想定しないSaaSがすでに稼働している。さらに人物・企業データの商用データベースの厚みも英語圏とは異なる。

現実解は3つある。

第一に、国産SaaSを「排除して置き換える」のではなく、SSOTSSOTSingle Source of Truth項目ごとに「どこが正か」が一意に定まった状態。全データを1箇所に集めることを意味しない。用語集で見る →アーキテクチャの中に位置づける。 たとえば過去数年分の名刺データを起点に、ICPICPIdeal Customer Profile受注・継続の実績から定義される、理想顧客像。ターゲットアカウント選定の基準になる。用語集で見る →に合致する企業・人物を抽出し、外部データでエンリッチし、CRMCRMCustomer Relationship Management顧客との関係と取引履歴を管理する仕組み。GTMの4レイヤーでは、SFA・MAと並ぶ業務アプリケーション層に位置づけられる。用語集で見る →上の一意なレコードに統合する――「米国ノウハウ×国産SaaS」の組み合わせが日本の実務では効く。海外製に統一しなければ始まらない、という話ではない。

第二に、ただし「すでに入っているツールなら何でもよい」わけではない。判断基準はひとつであり、いま手元にあるツール群で、SSOTという観点からデータ統合が可能かどうかである。 満たすべき要件は2つある。

要件①：一意性が担保され、複数の基軸から同じ顧客を見られること。 具体的には、次の3つのビューが同一のデータ構造の上で成立する状態を目指せるかを問う。

• シングルパーソンシングルパーソン／シングルアカウント同じ人物・同じ企業が、データベース上で必ず1レコードに収まっている状態を指す設計原則。購買グループを見える化する前提になる。用語集で見る →ビュー――一人の人物を開いたとき、その人がどの企業に所属し、どのような活動と接点（Web閲覧、メール、セミナー参加、名刺交換、商談）を積み上げてきたかが辿れる
• シングルアカウントビュー――一社を開いたとき、その企業にどのような人物が存在し、誰がどの商談に関与し、部門横断でどのような活動が起きているかが辿れる
• シングルチャネルビュー――ひとつのチャネル（展示会、セミナー、広告、Webフォーム）を開いたとき、そこから入ってきたのはどの企業のどの人物で、それがどの商談・受注につながったかが辿れる

この3つは別々の機能ではなく、同一の一意キーで結ばれたアカウント/ピープル構造を、どの基軸から見ているかの違いにすぎない。逆に言えば、3つのうちどれかが原理的に描けないツール構成は、一意性が担保されていない証拠である。選定で見るべきは機能一覧の多寡ではなく、この「基軸を切り替えても同じ顧客実体に行き着くか」である。

要件②：MAとSFASFAセールスフォースオートメーション営業の実行と管理のための業務アプリケーション。用語集で見る →がシームレスに接続されること。 これは譲れない条件として強調しておきたい。マーケが見るMA上の人物と、営業が見るSFA上の取引先責任者。両者が別のIDで管理され、別の定義を持ち、片方向のバッチでしか同期しないなら、上記の3つのビューはどれも成立しない。求められるのは、同一の一意キーによる双方向の同期と、双方が同じ人物・同じ企業を同じ粒度で指していることである。MAとSFAが同一ベンダーの製品である必要はないが、この水準の接続が実現できない組み合わせは、個々の機能がどれだけ優れていてもGTMエンジニアリングの土台にはならない。

第三に、日本の公開データを一意性担保の武器にする。 法人番号法人番号国税庁が全法人に付番する13桁の番号。企業の名寄せに使える公的キー。用語集で見る →という国が付与する一意キー、EDINET（有価証券報告書）やgBizINFOといった公的データベースは、名寄せ名寄せ同一の企業・人物を指す複数のレコードを特定し、統合する処理。用語集で見る →とエンリッチメントエンリッチメント外部データベースとの接続により、属性情報を自動で付与すること。用語集で見る →の基盤として英語圏より恵まれた条件ですらある。加えて個人情報保護法をはじめとする法規制への配慮は、データ設計の初期段階から組み込むべき要件となる。

6-4 見落とされがちな日本の優位性

前提の違いは制約として語られがちだが、視点を変えれば日本固有の優位性が3つある。

第一に、名刺文化という資産。 日本企業は展示会・商談・挨拶を通じて、長年にわたり質の高い人的接点データを蓄積してきた。多くの企業でこの資産は「デジタル化された名刺の山」のまま眠っているが、レイヤー①の実装によって一意なアカウント/ピープル構造に統合すれば、コールドリストとは比較にならない質のターゲット基盤に変わる。米国企業が高額なデータベンダーデータベンダー企業・パーソンの属性情報（業種、規模、所在地、法人番号、役職、連絡先など）を持ち、提供する事業者。得意な地域・業種・企業規模がそれぞれ異なる。Clayは情報そのものを持たず、複数のベンダーから取り出して組み合わせる。用語集で見る →から買うものを、日本企業はすでに持っているのである。

第二に、公開データの充実。 前述の法人番号・EDINET・gBizINFOに加え、適時開示や中期経営計画など、日本の上場企業は投資テーマや組織変更を構造化された形で公開している。「企業の変化シグナル」の材料が、公的に、無償または低コストで手に入る。

第三に、後発の利。 米国は物量アウトバウンド時代の技術的負債（乱立したツール、疲弊した買い手）を抱えながら転換を進めている。日本はその失敗と教訓を踏まえ、最初から「一意なデータ基盤→シグナル→AI」という正しい順序で構築できる。第2章で述べた12〜18ヶ月の時差は、正しく使えばショートカットの猶予である。

6-5 日本版GTMエンジニアリングの要諦

本章の議論を一文に集約すればこうなる。日本企業のGTMエンジニアリングは、「コールドの物量を自動化する装置」ではなく、「すでに持っている接点と信頼を、データ構造によって収益プロセスに接続し直す装置」として設計すべきである。これを実務に降ろすと、要諦は4つになる。

要諦①：組織の改編を待たない。 分業体制が整うまでデータ整備を先送りする企業は、いつまでも着手できない。米国型の職種分業はGTMエンジニアリングの前提条件ではなく、データが揃った後で選べる選択肢である。営業が一気通貫で担っているいまの姿のまま、アカウント/ピープルの一意性という一点から着手する。これまで属人的だった活動がデータとして見えるようになった時点で、初めて「どの工程を誰に分けるべきか」を事実に基づいて議論できる。順序は、データが先、組織が後である。

要諦②：自動化するのは送信ではなく、検知と準備。 稟議と関係性で動く市場に物量を流し込んでも、返るのは反応率ではなくブランド毀損である。自動化を向けるべきは、展示会・セミナー・紹介・既存名刺という「すでに接点を持った関係」の中から、いま動いている兆候を拾い上げる検知と、接触前のリサーチや文脈生成という準備の工程だ。人が担うのは、準備が整った状態での対話そのものに絞る。自動化の価値は量を増やすことではなく、限られた良質な接点を取りこぼさないことにある。

要諦③：ツールは「何を入れるか」ではなく「SSOTが組めるか」で選ぶ。 国産か海外かという区分は、判断の本質ではない。機能一覧の多寡も同様である。問うべきは2点だ。第一に、一人の人物・一社の企業・ひとつのチャネルという複数の基軸から、同じ顧客実体に行き着く構造が作れるか。第二に、MAとSFAが同一の一意キーでシームレスに接続され、双方が同じ人物・同じ企業を同じ粒度で指しているか。この2点を満たさない構成の上に、シグナルやAIを積み上げることはできない。ツール選定は機能比較ではなく、データ構造の設計判断である。逆に言えば、この2点を満たせるなら、いま動いている国産SaaSを起点に組み上げてまったく構わない。

要諦④：日本の資産を、全社の資産に変える。 名刺・展示会・既存取引・紹介――日本的な営業文化が積み上げてきた接点は、GTMエンジニアリングと対立しない。ただし、それが個人の手帳や部門のファイルに留まっている限り、資産は担当者のものであって会社のものではない。一意なデータ基盤の上に載せ直したとき、その接点は初めて誰が見ても辿れる全社の資産となり、シグナルとAIが働きかけられる対象になる。足りないのはデータではなく、それを一意に束ねる構造である。

問題はやり方であって、文化ではない。 日本のBtoB営業の慣習を米国型に置き換える必要はない。置き換えるべきは、その慣習が生み出したデータの持ち方である。