第10章 GTMエンジニアリングの必要性 ―― AI時代のCRMを、誰がつくり、動かすのか

ここまで、AI時代のCRMCRMCustomer Relationship Management顧客との関係と取引履歴を管理する仕組み。GTMの4レイヤーでは、SFA・MAと並ぶ業務アプリケーション層に位置づけられる。用語集で見る →に必要なものを述べてきた。顧客を一つにするSSOTSSOTSingle Source of Truth項目ごとに「どこが正か」が一意に定まった状態。全データを1箇所に集めることを意味しない。用語集で見る →、データ構造と定義、購買グループ購買グループユニット企業内部にある検討の単位。所属と行動の同一性から認定する。BtoBの購買は一人では決まらないため、リードではなくこの単位で捉える。用語集で見る →、コンテキストコンテキストその顧客が今どんな状況にあり、なぜそれを求めているのかを説明するための情報。業種や規模と違い一社ごと・一人ごとに異なり、シグナル・自社接点・購買グループを組み合わせて組み立てる。用語集で見る →とWhy You NowWhy You Now「なぜ貴社に（Why You）」「なぜ今（Why Now）」「なぜ私たちが（Why Us）」の3つの問いへの答え。データから導かれる接触の根拠であり、営業を動かすのはリードの数やスコアではなくこの理由である。用語集で見る →、4つのデータソース、ユースケース、そして大規模組織のガバナンス。最後に残る問いは一つである。これらを、誰がつくり、誰が動かし続けるのか。

10-1. ツールを入れても、CRMは完成しない

本書で述べてきたことの大半は、ツールの話ではなく、設計の問題である。

何をSSOTに置き、何を各システムに残すか。接点接点タッチポイント顧客と自社の間で起きる相互作用のすべて。マーケティング接点・営業接点・カスタマーサクセス接点・パートナー接点があり、商談も接点の一つである。用語集で見る →・活動・商談をどう定義するか。購買グループをどう持つか。シグナルシグナル顧客企業に起きた変化を示す情報。経営方針・組織・キーパーソン・採用・投資と業績・事業・導入ツールと体制・外部環境の変化があり、多くは公開されている情報から得られる。用語集で見る →の観点を自社の提供価値からどう逆算するか。誰が動くかを顧客の関心でどう決めるか。いずれも、SFASFAセールスフォースオートメーション営業の実行と管理のための業務アプリケーション。用語集で見る →やMAMAマーケティングオートメーションマーケティングの実行と管理のための業務アプリケーション。用語集で見る →を導入しただけでは決まらない。ツールは、設計されたものを動かす道具であって、設計そのものではない。

多くの企業が、ツールの導入をもってCRMが完成したと考える。導入後に「使われない」「データが揃わない」「成果が見えない」という状態になるのは、何をどう記録し、誰がどう使うかを決めないまま、ツールだけを先に動かしたからである。AI時代のCRMは、設計の比重がさらに高い。AIに何を読ませ、何を抽出させ、何を生成させるかは、すべて設計で決まる。

10-2. 誰の仕事でもない領域がある

では、その設計は誰が行うのか。ここに、組織の構造的な空白がある。

マーケティングは施策を担う。ウェビナーを企画し、メールを配信し、リードを獲得する。営業は商談を担う。顧客に会い、提案し、受注する。情報システムはシステムを担う。ツールを選定し、導入し、保守する。それぞれが自分の領域を最適化している。

だが、本書で述べてきた設計は、この3つのどれにも収まらない。接点の定義を決めるには、マーケティングと営業の両方が合意しなければならない。SSOTの設計には、営業の業務と情報システムの技術の両方の知識が要る。購買グループの構造は、マーケティングと営業と情報システムのすべてに関わる。つまり、これらの設計は複数の部門にまたがっており、どの部門も単独では決められない。そして、複数の部門にまたがる仕事は、どの部門の仕事にもならない。誰も担わないまま、ツールだけが導入される。

第9章で述べたMOpsMOps／SalesOpsマーケティングオペレーション／セールスオペレーションMOpsはマーケ部門内、SalesOpsは営業部門内の業務・ツール・データの最適化を担う機能。視野が自部門に閉じる点で、部門をまたいで一意なデータ構造の上に接続し直す RevOps とは役割が違う。用語集で見る →は、この空白の一部を埋める機能である。MOpsは、MAをはじめとするマーケティングのテクノロジースタックと業務プロセスを整備・運用し、マーケティング活動の基盤を支える。全社のプラットフォームとデータを管理し、決められたルールを運営する。だが、MOpsの守備範囲はマーケティングの基盤である。営業のプロセスや情報システムの領域にまたがる設計、たとえば商談の定義やSSOTの構成を、MOpsが単独で決めることはできない。また、MOpsが運営するプラットフォームとルールを、そもそも誰が設計するのか。その設計を、事業の戦略とどうつなげるのか。ここには、MOpsとは別に、部門を横断して計画し、その実現までを担う機能が要る。

10-3. GTM戦略とは、7つの工程すべてを計画すること

当社は、事業を市場に届け、収益につなげる営み（GTMGTMGo-To-Market製品・サービスを市場に届けて収益化するまでの一連の設計。日本語圏では Google Tag Manager と略称が重なるため、文脈に注意が要る。用語集で見る →：Go-To-Market）を、次の7つの工程で捉えている。

1. 顧客理解と把握：誰に届けるかを決める。ターゲットとする市場と企業、購買グループと役割を定める。ターゲット策定にあたる工程である
2. プロセス・目標設計：どの順番で、どう収益につなげるかを決める。顧客の購買心理変容購買心理変容8フェーズ買い手の心理が購買に至るまでの変わり方を、8つの段階で捉えたもの。各段階の心理状態・次へ移るきっかけ・売り手のとるべきアプローチを定義し、役割との掛け合わせで「いつ・何を届けるか」を決める。用語集で見る →と自社の売り方の型を定義し、そのうえでレベニューサイクルレベニューサイクルリード獲得から受注後の拡大・再購買までを、一つながりの循環プロセスとして捉える収益モデル。用語集で見る →、接点・商談の定義、KGIKGI／KPIKey Goal Indicator／Key Performance IndicatorKGIは達成すべき最終目標、KPIはその達成度を測る中間指標。単価と歩留まりが揃うと、積み上げの願望から逆算の設計に変わる。用語集で見る →とKPI、目標を達成するためのチャネルを設計する
3. ツール選定：設計したプロセスを動かすためのツールを選ぶ
4. データ基盤：顧客の情報を一つにし、データ構造を整える
5. コンテキスト：シグナルや接点の記録から、顧客の状況と理由を説明できる状態をつくる
6. 施策実行計画：誰に、いつ、どの接点で、何を届けるかを計画する
7. 運用・改善：施策の結果を見て、各工程を見直す

本書では、この7つの工程すべてを計画することを「GTM戦略GTM戦略事業を市場に届け収益につなげる営みを、顧客理解と把握・プロセスと目標設計・ツール選定・データ基盤・コンテキスト・施策実行計画・運用と改善の7つの工程で捉え、そのすべてを計画すること。用語集で見る →」と呼ぶ。GTM戦略は、ターゲットを決めることだけを指すものではない。ターゲット策定から、プロセス・目標設計、データ基盤、コンテキスト、施策、運用・改善までを一続きで計画することである。

本書で述べてきたことの多くは、このうち2から5の工程にある。接点・活動・商談の定義、レベニューサイクル、SSOT、データ構造、購買グループ、シグナルの観点、アサインの原則。いずれも、ターゲット策定の後、施策より前に決まっているべきものである。

ところが多くの企業では、ターゲットを決めた後、いきなりツールの導入と施策に進む。ターゲットは決めた、ツールも入れた、施策も打っている。だが、2の工程、つまり購買心理変容と売り方の型を定め、収益までの流れと目標を設計する工程が抜けている。データ構造も定義もレベニューサイクルも決まらないまま、ツールと施策が動く。

この状態で施策を打つと、成果が出ても出なくても、理由が分からない。どの接点が効いたのか、どの購買グループが動いたのか、なぜ商談が止まったのか。それを読み解くためのデータ構造と定義がないからである。プロセス・目標設計を飛ばした実装は、ブラックボックスになる。成果は偶然に左右され、同じ成果を繰り返し出すことができない。

10-4. GTMエンジニアリングとは何か

GTM戦略を計画しても、それを人手だけで実行し続けることは難しい。第7章で述べたとおり、扱うデータは量が多く、更新は速く、その多くが文章や音声である。数千社の顧客について、一社ごとにコンテキストを組み立て、Why You Nowを導き、届け続けることは、人の努力では追いつかない。

GTMエンジニアリングGTM EngineeringGo-To-Market Engineeringマーケティング・営業・カスタマーサクセスに分断されたBtoBの収益プロセスを、データとテクノロジーで一本の再現可能な仕組みとして設計し直す取り組み。用語集で見る →とは、GTM戦略を実行し、目標を達成するために、テクノロジーとAIを使って手段を講じることである。

具体的には、GTM戦略で計画したことを、標準化し、自動化し、精度を高める。SSOTを構築し、名寄せ名寄せ同一の企業・人物を指す複数のレコードを特定し、統合する処理。用語集で見る →と顧客台帳の更新を自動にする。営業接点をAIで記録する。公開情報からシグナルを集めて構造化する。コンテキストからWhy You Nowと下書きを生成する。顧客の関心に応じて、動くべき部門と担当者を示す。いずれも、計画したことを、属人的な作業に頼らず、続く仕組みとして実現するための手段である。

GTM戦略とGTMエンジニアリングの関係は、次のように整理できる。GTM戦略が「何を、どの順序で整えるか」を計画する。GTMエンジニアリングが、それをテクノロジーとAIで実現し、成果につなげる。計画がなければ、テクノロジーは何に使えばよいかが定まらない。手段がなければ、計画は一部の顧客、一部の担当者にしか届かない。本書が提案するAI時代のCRMは、この2つを実践することで実現する姿である。

GTMエンジニアリングは、マーケティングでも営業でも情報システムでもない。3つの部門のどれにも属さず、3つにまたがる仕組みを実現し、3つをつなぐ。第9章で述べたMOpsがマーケティングの基盤を整備・運用する機能であるのに対し、GTMエンジニアリングは、マーケティング・営業・情報システムにまたがるGTM戦略を、テクノロジーとAIで実現する。MOpsは、そのうちマーケティングの基盤にあたる部分を日々動かし、GTMエンジニアリングはMOpsが動かした結果を受けて、仕組みを更新する。

GTMエンジニアリングの考え方と方法は、当社の「GTM Engineering Playbook」で詳しく述べた。本書では、AI時代のCRMを実現するうえで、この考え方がなぜ欠かせないかに絞って述べる。

10-5. GTM戦略の計画からGTMエンジニアリングでの実現までを担う4つの仕事

AI時代のCRMの文脈で、GTM戦略を計画し、GTMエンジニアリングで実現するまでに担う仕事は、4つに整理できる。

全体設計と現状診断。 自社のCRMが、本書で述べた要件をどこまで満たしているかを診断する。顧客は一つになっているか、定義は揃っているか、購買グループは捉えられているか、コンテキストは組み立てられているか。診断をもとに、何から手をつけるかの全体設計を描く。

レベニュープロセスの設計。 第4章で述べたデータ構造と定義、レベニューサイクルの循環、第9章で述べたアサインの原則とガバナンスを、自社の事業に合わせて設計する。これが、7つの工程のうち2の工程、プロセス・目標設計の中心である。

テーマ横断の実装と運用。 設計したものを、SFA、MA、企業データベース、Webリサーチのツール、AIを組み合わせて実装する。SSOTの構築、名寄せの仕組み、営業接点のAI記録、シグナルの収集と構造化、Why You Nowの生成。いずれも単一のツールでは完結せず、複数のツールをまたぐ。実装した後は、施策の結果を見ながら運用し、改善する。

社内への移管。 GTM戦略の計画もGTMエンジニアリングによる実現も、外部に永久に依存するものではない。設計の考え方、実装の方法、運用の手順を社内に移し、自社の機能として定着させる。MOpsの立ち上げは、この移管の一つの形である。

10-6. 移行と定着：一度に切り替えず、段階的に

AI時代のCRMへの移行は、一度にすべてを切り替えることでは実現しない。既存のSFAとMAには、蓄積されたデータと、それを使っている現場がある。それを止めずに、段階的に変えていく。

順序。 最初に取り組むのは、企業の識別である。法人番号法人番号国税庁が全法人に付番する13桁の番号。企業の名寄せに使える公的キー。用語集で見る →を軸に既存のデータを名寄せし、顧客が一つに見える状態を作る。次に、接点・活動・商談の定義を揃え、システムに実装する。その上で、購買グループの構造を加え、営業接点のAI記録を始める。シグナルの収集とWhy You Nowの生成は、これらが整ってから乗せる。順序を逆にすると、コンテキストを組み立てようとしても、もとになるデータが揃っていない。

範囲。 全社・全顧客で始めるのではなく、一つの事業部、あるいは主要顧客の数十社から始める。そこで設計を検証し、成果を示し、範囲を広げる。第9章で述べた合意形成も、この段階的な進め方の中で行う。

定着。 定着とは、現場が入力するようになることではない。第2章で述べたとおり、入力に頼る限り定着しない。定着とは、記録が自動で集まり、コンテキストが自動で組み立てられ、営業とマーケティングがそれを日常的に使っている状態である。使われるから、データが正しく保たれる。データが正しいから、さらに使われる。この循環に入ったとき、CRMは定着したと言える。

10-7. 内製と外部パートナーの組み合わせ

GTM戦略を計画し、GTMエンジニアリングで実現する機能を、最初から社内に持っている企業は少ない。ターゲット策定からプロセス・目標設計、データ基盤の実装までをつなぐ人材は、マーケティングにも営業にも情報システムにもいないことが多い。

現実的な進め方は、外部のパートナーと組んで始め、社内に移していくことである。外部のパートナーが全体設計と初期の実装を担い、社内の担当者がそれを学びながら運用を引き継ぐ。運用が定着したら、設計の更新も社内で行えるようにする。最終的に、GTM戦略の計画とGTMエンジニアリングによる実現は、社内の機能になる。

このとき、外部のパートナーに求めるのは、ツールの導入ではない。GTM戦略を計画し、テクノロジーとAIで実現し、社内に移管できることである。ツールの導入だけを行うパートナーと組むと、10-1で述べた「ツールを入れても完成しない」状態が繰り返される。

AI時代のCRMは、GTM戦略として7つの工程を計画し、それをGTMエンジニアリングで実現し続けることで成立する。本書が最後に述べておきたいのは、この2つの必要性である。

E P I L O G U E