「GTMエンジニアリング」という言葉を、求人票や海外のSaaS企業のブログで見かける機会が増えてきました。ただ、日本語でその定義を一文で説明した資料はまだ多くありません。営業代行なのか、営業コンサルなのか、それともAI開発なのか。この記事では、GTMエンジニアリングの定義と、隣り合う支援との違い、担い手である職種の整理、そして始める順番までを1本で書きます。読者として想定しているのは、BtoB SaaSの営業をこれから立ち上げる、あるいは立ち上げの途中で止まっている経営者と営業責任者です。

GTMエンジニアリングの定義

GTMエンジニアリングとは、営業戦略を起点に、売上を生み出し続けるGTM（Go-to-Market）の仕組みを設計・実装・定着させることです。

GTMは、商品を市場に届け、売れる状態をつくるまでの一連の活動を指します。その活動を担当者の勘と気合いに委ねず、データとAIで動く仕組みへ変えていく。ここまでが定義の前半にあたります。後半の「設計・実装・定着」には、順番があります。

段階	何をするか
設計	営業戦略を起点に、営業プロセスを分解し、人とAIの役割を決める
実装	AI・データ・CRM・業務フローを組み合わせて、現場に置く
定着	現場で成果が出るまで改善し、顧客自身が運用できる状態にする

見落とされやすいのは3段目です。仕組みを作って終わりにせず、顧客の組織の中で回り続ける状態までを含めて、はじめてGTMエンジニアリングと呼べます。

なぜ「エンジニアリング」なのか

営業という言葉に、なぜエンジニアリングが付くのか。理由は、営業の成果が出るまでの工程が、ソフトウェア開発と同じ性質を持ちはじめたからです。

かつての営業は、一人の担当者の中に戦略・実行・記録のすべてが入っていました。誰に、何を、どう伝え、どこで諦めるか。全部が本人の経験則です。この形は、その担当者がいる間しか成果が出ません。

いま起きているのは、その工程の分解です。ターゲットの条件を定義し、接触の経路を設計し、記録の形式を決め、AIに任せる部分と人が判断する部分を分ける。分解された工程は、設計図として書けます。書けるものは、実装できます。実装されたものは、改善できる。営業がこの性質を持ちはじめたとき、それを扱う仕事にエンジニアリングという名前が付きました。

営業代行・営業コンサル・RevOpsとの違い

GTMエンジニアリングは、隣り合う支援のどれか単体ではない。違いは2点に絞れます。何が成果の源泉か。そして、支援が終わったあとに何が残るか。

観点	営業代行	営業コンサル	RevOps支援	GTMエンジニアリング
主に提供するもの	営業活動の実行	戦略・提言	ツールと運用の整備	営業活動の実行＋仕組みの構築
成果の源泉	担当者の経験と稼働	提言の質	ツールの設定	人材＋データ＋AI＋標準化
現場に入るか	入る	入らないことが多い	部分的	入る
支援終了後	活動が止まりやすい	提言が実行されずに残ることがある	ツールは残るが運用が続かないことがある	顧客社内で運用・改善できる
顧客に残るもの	活動の結果、ノウハウ	資料	設定済みのツール	プロセス、データ、AI基盤、判断基準

営業代行との違いを一文にすると、こうなります。営業の成果を「人の稼働」から「仕組みの稼働」へ移す。 営業代行は、支援会社の担当者が動くことで成果を出します。GTMエンジニアリングも営業活動を実行しますが、同時にその活動をプロセス・データ・AIワークフローとして顧客企業に残していきます。支援が終わったあとに、売り方の型とそれを回す仕組みが手元に残っているかどうか。ここが分かれ目です。

営業コンサルとの違いは、現場に入るかどうかです。戦略を描いて終わる支援では、描いた戦略が現場で実行されたかどうかを確かめる手段がありません。GTMエンジニアリングは、実行まで担うことで、戦略と現場のずれをその場で直します。

誰が担うのか：GTMエンジニア、FDAE、FDE

担い手の呼び名には、いくつかの系統がある。先に整理しておけば、求人票や海外の事例を読むときに迷わない。

GTMエンジニア（GTM Engineer） は、営業戦略の設計から現場の実行、組織への仕組み化までを一本で貫く職種です。米国ではClay社のような企業を起点に、専門職として定着しはじめました。営業の理解と、データ・自動化・AIを組み合わせる実装力の両方を持つ職種。もともとは自社のGTMを作る社内の役割として生まれました。

FDAE（Forward Deployed Account Executive） は、顧客の営業組織に入り込み、ICP（理想顧客の条件）の定義から商談までを担いながら、売上目標を背負う営業職です。米国のMonaco社が自社の中核職種として定義しました。顧客にとっての「社外CRO」として伴走する、と説明されます。

FDE（Forward Deployed Engineer） は、顧客の環境に入って実装を担う技術職です。CRMやAPIへの接続、AIエージェントの現場でのチューニングを引き受けます。Palantir社の職種として知られ、国内でも採用する企業が出てきました。

三者の関係は、こう捉えると早い。GTMエンジニアを顧客側へ前方展開したものがFDAEとFDEです。営業側へ展開した姿がFDAE、実装側へ展開した姿がFDE。売上目標を持つのはFDAEだけで、FDEとGTMエンジニアは持ちません。

	GTMエンジニア	FDAE	FDE
誰のGTMを作るか	自社	顧客	顧客のシステム
売上目標（Quota）	持たない	持つ	持たない
顧客との距離	自社内	顧客の会議体に入る	顧客の環境に入る
必要なもの	営業理解＋データ・自動化	営業力＋GTM設計力	開発力＋AI実装

日本では、この3つを1人が兼務している支援会社がほとんどです。兼務は1社ごとの関与を深くしますが、担当できる社数に上限を作ります。分業が進むほど、1人のGTMエンジニアが支えられる顧客の数は増えていきます。

顧客に何が残るのか

GTMエンジニアリングの成果物は、受注の数だけではない。支援が終わったあとに顧客の手元に残るものを、4つに分けて書きます。

1. プロセス：誰に、どの順で、何を届けるかの手順。営業戦略のハンドブック、ターゲットの定義、トークの型
2. データ：商談の記録が「入力せずとも最新で、記録漏れがない」状態で溜まる仕組み。とくに「決めたのに実行されなかった」という記録は、CRMにも汎用AIにも残らない
3. AI基盤：リードの判定、商談の要約、次の一手の提案を、顧客のCRMにつながった形で動かすワークフロー
4. 判断基準：有効商談とは何か、どの案件を追い、どれを手放すか。数字を見て決めるための物差し

この4つが残っていれば、支援会社が離れても営業は止まりません。逆に、どれか1つでも支援会社の頭の中にしか無いなら、それは営業代行に近い形です。

始める順番

営業の立ち上げで多くの企業が止まるのは、道具の選定でも人の採用でもなく、順番です。GTMエンジニアリングは、次の順で進めます。

1. 営業戦略を定める：誰に売るか（ICP）、何を言うか（USP）、どの経路で会うか、目標からの逆算式。ここが起点で、道具はあとです
2. プロセスを再設計する：営業の工程を分解し、人が判断する部分とAIが担う部分を決める。CRMは「入力」から設計せず、「記録が自然に残る」形から設計します
3. 実行と検証を回す：実際に商談を動かしながら、戦略と現場のずれを直す。ここは2と往復します
4. 顧客組織に定着させる：運用のルールと判断基準を顧客の側に置き、支援会社が居なくても回る状態にする

2と3は、一度で終わりません。何度か往復して、ようやく型になります。営業の立ち上げは、順番を守った会社から仕組みになる。道具と人の話は、そのあとです。

---

GTMエンジニアリングは、営業代行・営業コンサル・AI開発・RevOps支援のどれとも重なりますが、どれか単体ではありません。営業戦略を起点に、設計し、実装し、定着させる。この3段を一気通貫で担い、成果の源泉を人の稼働から仕組みの稼働へ移す。ここまでを含めて、はじめてこの名前で呼べます。

日本には、まだこの職種の担い手がほとんどいません。だからこそ、言葉の定義を先に置いておく。営業の立ち上げで止まっているなら、道具を選ぶ前に、何を残したいのかを決めてみてください。残したいものが決まれば、順番は自然と決まります。

本記事の見解はWeaveXによるものであり、引用元各社の見解を代表するものではありません。