第4章 GTMエンジニアリングとは何か

4-1 定義――GTM戦略を完遂し、グロースさせる手段

前章の最後に投げかけた問いから始めたい。GTM戦略の7つの工程、とりわけ欠落しがちな02から05を、人力と気合だけで構築し、回し続けることは可能なのか。

答えは否である。データは放置すれば日々劣化する。企業は社名を変え、人は異動・転職し、昨日正しかったレコードは今日には古くなる。組織は変わり、部門間の引き渡し基準は形骸化する。市場は動き、有効だったシグナルやメッセージは競合の模倣とともに効力を失う。つまりGTM戦略は、一度作って終わる「プロジェクト」ではなく、動き続ける市場と組織に合わせて更新し続ける「システム」なのである。

この認識に立つと、GTMエンジニアリングは次のように定義できる。

GTMエンジニアリングとは、GTM戦略の7つの工程を、テクノロジーとAIで標準化し、自動化し、精度を上げ続けることで、完遂し、グロースさせる手段である。

GTM戦略が「何を、どの順番で整えるか」を計画し、GTMエンジニアリングがそれをテクノロジーとAIで実現して、成果につなげる。計画のないテクノロジーは道具の寄せ集めにとどまり、テクノロジーのない計画は人手の限界で止まる。GTMエンジニアリングの守備範囲は7つの工程すべてに及ぶが、その重心は、多くの企業で欠落している02から05にある。

3つの点を強調したい。

第一に、これは職種論ではなく機能論である。海外では「GTMエンジニア」という職種の急成長が注目を集めているが（第2章）、本質は肩書きではない。この機能を、専任者で持つか、既存チームの役割拡張で持つか、外部パートナーで持つかは組織の規模と成熟度による。重要なのは、ターゲットと施策の間にある工程に、明確なオーナーと技術力を与えることである。

第二に、対象はアウトバウンドの自動化に限らない。海外の文脈ではコールドアウトリーチの自動化が語られがちだが、それはGTMエンジニアリングの一断面にすぎない。インバウンドのリード管理も、ナーチャリングも、部門間ハンドオフも、受注後のデータ統合も、すべてが対象である。むしろ日本企業にとっての本丸は、派手な自動化より先にある「一意なデータ構造の確立」だ。

第三に、動詞は「導入する」ではなく「設計し続ける」である。ツールの購入や初期設定はGTMエンジニアリングの入口にすぎない。第2章で見た先行企業に共通していたのは、ツールを買ったことではなく、業務そのものを設計し直し、改善のループを回し続けていることだった。

ここで求められる姿勢は、要件を固めてから一気に作り込むウォーターフォール型ではなく、小さく作って回しながら直していくアジャイル型である。市場も組織も動き続ける以上、完璧な設計を時間をかけて作るより、素早く形にして検証と修正を繰り返すほうが、結果として正解に早く近づく。そしてこのスピードを支えるのは、いかに取り回しの利く構造・ツールにしておくかという設計判断である。

この点は、日本企業の現場で実際に起きている問題と直結する。たとえば、SFA（Salesforceなど）の作り込みが重厚になりすぎ、その改修の重さに全体が引きずられて、本来は高速で回さなければならないマーケティング側の施策変更が遅延する——という事態は頻繁に見られる。堅牢なガバナンスを効かせる領域と、高速に試行錯誤する領域は、要求されるスピードが異なる。ガバナンス（統制・品質・整合性）とオペレーション（現場の実行速度）をどう両立させるかは、GTMエンジニアリングの設計における中心的な論点のひとつである。すべてを固く作るのでも、すべてを緩く作るのでもなく、どこを固めどこを軽くするかを見極めることが、「設計し続けられる」構造を生む。

4-2 近接概念との違い――RevOps・MOps／SalesOps・従来のツール運用

新しい概念が登場すると、必ず既存概念との混同が起きる。GTMエンジニアリングの輪郭を明確にするため、近接する概念と比較する。

RevOpsとの違い。 RevOps（Revenue Operations）は、マーケ・営業・CSを横断して収益プロセス全体を統括する考え方であり、GTMエンジニアリングと目的を共有する。違いは重心である。RevOpsの重心が「プロセスの定義・KPI設計・部門調整」というオペレーション設計にあるのに対し、GTMエンジニアリングの重心は「それを実際に動くシステムとして構築する技術的実装」にある。「引き渡し基準をどう定義すべきか」はRevOpsの問い、「その基準をどう自動判定させ、名寄せ精度をどう上げるか」はGTMエンジニアリングの問いである。両者は対立概念ではなく、RevOpsが描く設計をGTMエンジニアリングが実装する補完関係にあり、実際、海外では両機能の統合が進むという予測が多い。

AI SDR・MOps／SalesOpsとの違い。 海外の文脈では、リスト精査・文面生成・送付といったSDRの実行業務を自動化する「AI SDR」との対比が語られる。ただしSDR（インサイドセールスによる新規開拓）という分業が浸透していない日本では、この対比はあまり実感を持って響かない。国内でむしろ注意したいのは、MOps（マーケティングオペレーション）やSalesOps（セールスオペレーション）との混同である。MOpsはマーケ部門内の、SalesOpsは営業部門内の業務・ツール・データの最適化を担う。いずれも重要だが、その視野は基本的に「自部門の中」に閉じている。これに対しGTMエンジニアリングは、マーケ・営業・CSを貫く収益プロセス全体を対象とし、部門ごとに最適化されたMOps・SalesOpsをまたいで、一意なデータ構造の上に接続し直す点に本質がある。言い換えれば、MOps・SalesOpsが「各部門の部分最適」を担うのに対し、GTMエンジニアリングは「部門をまたいだ全体最適」を担う。第3章で見た症状——部門ごとに最適化された結果としてのサイロ化——は、まさにMOps・SalesOpsだけでは埋まらない断絶であり、そこにGTMエンジニアリングの役割がある。

従来のMA/SFA運用支援との違い。 従来の運用支援は、既に導入されたツールの設定・保守・レポーティングという「ツール単位」のスコープに留まりがちだった。GTMエンジニアリングのスコープは「収益プロセス単位」である。個々のツールが正しく動いているかではなく、ツールとデータとプロセスの全体が、一意なデータ構造の上で収益に向かって接続されているかを問う。この違いは、担い手に求められるスキルの違いにも表れる――ツールの操作知識に加えて、データモデリング、API連携、AI活用、そして事業指標（LTV/CAC）の理解までを跨ぐ、ハイブリッドな能力である。

4-3 GTMエンジニアリングを構成する4つのレイヤー（次章への導入)

では、この手段は具体的に何を構築するのか。本書では、GTMエンジニアリングの構築対象を4つのレイヤーに整理する。

データ基盤レイヤー――一意なアカウント/ピープル構造とSSOTの構築・維持。すべての土台
シグナルレイヤー――顧客の行動・変化の兆候を捕捉し、「今アプローチすべき理由」をデータとして定義する層
AIレイヤー――リサーチ、パーソナライズ、スコアリング、エージェントによる実行の自動化
プロセスレイヤー――部門間ハンドオフの自動化と、KPI・定義の共通言語化

4つのレイヤーは、7つの工程とこう対応する。データ基盤レイヤーは工程04を担い、シグナルレイヤーは工程05のコンテキストの材料をつくる。プロセスレイヤーは、工程02で決めた定義と引き渡しの基準をシステムに組み込み、工程07の改善を回す。AIレイヤーは特定の工程に閉じず、すべての工程で標準化・自動化・精度向上を担う。

この4層は独立ではなく、下から順に積み上がる依存関係にある。データ基盤が崩れていればシグナルは誤検知し、シグナルが曖昧ならAIは誤った相手に精巧な文面を送り、プロセスが未定義なら、どれだけ良いリードも部門の狭間で消える。第2章で紹介した「分断された12のツールより、深く統合された4〜5のツール」という知見は、この積み上げ構造の別表現である。

次章では、この4レイヤーを1層ずつ、日本企業の実務に即して解説する。