第4章 GTM Engineeringとは何か
4-1 定義――「戦術と実装」を継続的に担う機能
前章の最後に投げかけた問いから始めたい。GTM設計の5階層のうち、欠落しがちな「戦術」と「実装」の2層を、人力と気合だけで構築し、維持し続けることは可能なのか。
答えは否である。データは放置すれば日々劣化する。企業は社名を変え、人は異動・転職し、昨日正しかったレコードは今日には古くなる。組織は変わり、部門間の引き渡し基準は形骸化する。市場は動き、有効だったシグナルやメッセージは競合の模倣とともに効力を失う。つまり戦術と実装は、**一度作って終わる「プロジェクト」ではなく、動き続ける市場と組織に合わせて更新し続ける「システム」**なのである。
この認識に立つと、GTM Engineeringは次のように定義できる。
GTM Engineering（GTMエンジニアリング）とは、GTMの戦術・実装層――データ基盤、シグナル、AI、部門横断プロセス――を、データとテクノロジーの力で設計・構築し、継続的に維持・進化させる機能である。
3つの点を強調したい。
第一に、これは職種論ではなく機能論である。海外では「GTMエンジニア」という職種の急成長が注目を集めているが（第2章）、本質は肩書きではない。この機能を、専任者で持つか、既存チームの役割拡張で持つか、外部パートナーで持つかは組織の規模と成熟度による。重要なのは、戦略でも実行でもない「間の2層」に、明確なオーナーと技術力を与えることである。
第二に、対象はアウトバウンドの自動化に限らない。海外の文脈ではコールドアウトリーチの自動化が語られがちだが、それはGTM Engineeringの一断面にすぎない。インバウンドのリード管理も、ナーチャリングも、部門間ハンドオフも、受注後のデータ統合も、すべてが対象である。むしろ日本企業にとっての本丸は、派手な自動化より先にある「一意なデータ構造の確立」だ。
第三に、動詞は「導入する」ではなく**「設計し続ける」**である。ツールの購入や初期設定はGTM Engineeringの入口にすぎない。第2章で見た先行企業に共通していたのは、ツールを買ったことではなく、業務そのものを設計し直し、改善のループを回し続けていることだった。
ここで求められる姿勢は、要件を固めてから一気に作り込むウォーターフォール型ではなく、小さく作って回しながら直していくアジャイル型である。市場も組織も動き続ける以上、完璧な設計を時間をかけて作るより、素早く形にして検証と修正を繰り返すほうが、結果として正解に早く近づく。そしてこのスピードを支えるのは、いかに取り回しの利く構造・ツールにしておくかという設計判断である。
この点は、日本企業の現場で実際に起きている問題と直結する。たとえば、SFA（Salesforceなど）の作り込みが重厚になりすぎ、その改修の重さに全体が引きずられて、本来は高速で回さなければならないマーケティング側の施策変更が遅延する——という事態は頻繁に見られる。堅牢なガバナンスを効かせる領域と、高速に試行錯誤する領域は、要求されるスピードが異なる。ガバナンス（統制・品質・整合性）とオペレーション（現場の実行速度）をどう両立させるかは、GTM Engineeringの設計における中心的な論点のひとつである。すべてを固く作るのでも、すべてを緩く作るのでもなく、どこを固めどこを軽くするかを見極めることが、「設計し続けられる」構造を生む。
4-2 近接概念との違い――RevOps・MOps／SalesOps・従来のツール運用
新しい概念が登場すると、必ず既存概念との混同が起きる。GTM Engineeringの輪郭を明確にするため、近接する概念と比較する。
RevOpsとの違い。 RevOps（Revenue Operations）は、マーケ・営業・CSを横断して収益プロセス全体を統括する考え方であり、GTM Engineeringと目的を共有する。違いは重心である。RevOpsの重心が「プロセスの定義・KPI設計・部門調整」というオペレーション設計にあるのに対し、GTM Engineeringの重心は「それを実際に動くシステムとして構築する技術的実装」にある。「引き渡し基準をどう定義すべきか」はRevOpsの問い、「その基準をどう自動判定させ、名寄せ精度をどう上げるか」はGTM Engineeringの問いである。両者は対立概念ではなく、RevOpsが描く設計をGTM Engineeringが実装する補完関係にあり、実際、海外では両機能の統合が進むという予測が多い。
AI SDR・MOps／SalesOpsとの違い。 海外の文脈では、リスト精査・文面生成・送付といったSDRの実行業務を自動化する「AI SDR」との対比が語られる。ただしSDR（インサイドセールスによる新規開拓）という分業が浸透していない日本では、この対比はあまり実感を持って響かない。国内でむしろ注意したいのは、MOps（マーケティングオペレーション）やSalesOps（セールスオペレーション）との混同である。MOpsはマーケ部門内の、SalesOpsは営業部門内の業務・ツール・データの最適化を担う。いずれも重要だが、その視野は基本的に「自部門の中」に閉じている。これに対しGTM Engineeringは、マーケ・営業・CSを貫く収益プロセス全体を対象とし、部門ごとに最適化されたMOps・SalesOpsをまたいで、一意なデータ構造の上に接続し直す点に本質がある。言い換えれば、MOps・SalesOpsが「各部門の部分最適」を担うのに対し、GTM Engineeringは「部門をまたいだ全体最適」を担う。第3章で見た症状——部門ごとに最適化された結果としてのサイロ化——は、まさにMOps・SalesOpsだけでは埋まらない断絶であり、そこにGTM Engineeringの役割がある。
従来のMA/SFA運用支援との違い。 従来の運用支援は、既に導入されたツールの設定・保守・レポーティングという「ツール単位」のスコープに留まりがちだった。GTM Engineeringのスコープは「収益プロセス単位」である。個々のツールが正しく動いているかではなく、ツールとデータとプロセスの全体が、一意なデータ構造の上で収益に向かって接続されているかを問う。この違いは、担い手に求められるスキルの違いにも表れる――ツールの操作知識に加えて、データモデリング、API連携、AI活用、そして事業指標（LTV/CAC）の理解までを跨ぐ、ハイブリッドな能力である。
4-3 GTM Engineeringを構成する4つのレイヤー（次章への導入)
では、この機能は具体的に何を構築するのか。本書では、GTM Engineeringの構築対象を4つのレイヤーに整理する。
- データ基盤レイヤー――一意なアカウント/ピープル構造とSSOTの構築・維持。すべての土台
- シグナルレイヤー――顧客の行動・変化の兆候を捕捉し、「今アプローチすべき理由」をデータとして定義する層
- AIレイヤー――リサーチ、パーソナライズ、スコアリング、エージェントによる実行の自動化
- プロセスレイヤー――部門間ハンドオフの自動化と、KPI・定義の共通言語化
この4層は独立ではなく、下から順に積み上がる依存関係にある。データ基盤が崩れていればシグナルは誤検知し、シグナルが曖昧ならAIは誤った相手に精巧な文面を送り、プロセスが未定義なら、どれだけ良いリードも部門の狭間で消える。第2章で紹介した「分断された12のツールより、深く統合された4〜5のツール」という知見は、この積み上げ構造の別表現である。
次章では、この4レイヤーを1層ずつ、日本企業の実務に即して解説する。
