「聞いたことがある人は？」に挙がった手は、約1割
「GTMエンジニアって聞いたことがあるという方、いらっしゃったら挙手いただいてもよろしいですか」。パネルの冒頭、モデレーターを務めたギアソリューションズ代表取締役の道家俊輔氏が会場に問いかけると、手が挙がったのは約1割にとどまった。裏を返せば、9割近くにとって初めて聞く職種名である。
だが、名前を知らないだけで、その「仕事」はすでに現場で動き出している。本連載でこれまで見てきたとおり、AIによって「作る」ことはコモディティ化し、差別化の場所はプロダクトの外側へ移った。基調講演で主催プロデリア・パートナーズの吉澤和之氏が「PMMの本質は越境である」と説いたその越境を、GTM（Go-To-Market、市場に届けて売上をつくる一連の活動）の実装・自動化という形で体現するのがGTMエンジニアだ。
PMMが「どの課題なら勝てるか」を見極め、勝ち筋を設計する職種だとすれば、GTMエンジニアはその勝ち筋を、AIとデータで動く仕組みとして実装する職種である。
収益プロセスを「プロダクト」として設計する
パネルのスライドには「Revenue as a Product」という言葉が掲げられていた。収益を生むプロセスそのものを、SaaSプロダクトのように設計・運用しよう、という発想である。
GTMエンジニアという概念を発信してきたClay（米国）で日本市場の立ち上げを担う服部摩耶斗氏は、その役割をこう定義した。
「GTMエンジニアは収益プロセス、社内の営業からマーケ、CS、その他の収益部門の活動を統合的に見て、そのプロセス自体をSaaSのプロダクトのようにAIとデータとワークフローを使って設計・実行・計画し、イテレーションをしていく人材」
要は、営業・マーケティング・カスタマーサクセスにまたがる収益活動を、1つの「系（システム）」としてつなぎ、高速で改善し続ける役割だ。
Clayはニューヨーク発のGTMインフラツールで、「GTMエンジニア」という言葉を2023年ごろから発信してきた。顧客にはOpenAIやAnthropic、Cursor、Lovableといった名が並ぶ。
海外では、この職種の実装がすでに数字を出し始めている。道家氏は事例を挙げた。
「Vercelでは、AIのセールスエージェントを使って、10人のSDR（反響型インサイドセールス）を1人に削減するようなことをやったり、Anthropicで言うと、プログラミング未経験の担当がFigmaなどと連携させながらコンテンツをめちゃめちゃ量産している」
求人市場でも注目は高く、「そのピークで言うとGTMエンジニアで19万ドルとか出ている」という。
服部氏はFigmaの事例を補足した。複数のデータベースを統合し、外部データソースから最新データを取得してクレンジングし、営業担当が現場で使いやすい形に落としてアクションにつなげる。「実際に役に立つ営業データが出来上がった」。作るのは機能ではなく、収益を生む仕組みそのものだという点が、従来のエンジニアリングと異なる。
現場の実装①：LayerX──要望収集を10倍に、商談差配を自動化
国内の現場ではどうか。LayerXのバクラク事業部でプロダクトマネージャー兼GTMエンジニアを務める守屋敬太氏は、エンジニアリング出身でプロダクトマネジメントを経てGTM組織支援に携わってきた。同氏は自らの役割を「GTMプロセスのボトルネックにエンジニアリングで連続的な変化を起こす」と表現する。これまでのルールベースの自動化にとどまらず、「人間の判断が必要となっているプロセス」まで踏み込んで自動化を進めるのが特徴だ。
具体例が鮮やかだ。従来、顧客からの要望は毎月2000件ほどを社内で手動共有していた。これを完全に自動化し、商談の中身から顧客のフィードバックが自動でチームに届くパイプラインを構築したところ、共有される要望は「これまでの7倍以上、1.5万件を超える」ようになった。
もう一つが商談の差配だ。営業マネージャーからの「もっと最適化できるのでは」というふわっとした相談を起点に、過去の商談データや担当者の動きを分析・数値化し、ベストなマッチングを自動提案する仕組みを作った。運用が始まり、「実際、売上が数パーセント向上する見込みが立っている」という。
守屋氏のチームは、プロセスの「頭からお尻まで一気通貫」で、原則1プロジェクトを1人のGTMエンジニアが見る。そして「どのようなものを作ってリリースするか」ではなく「アウトカム」に責任を持つ。作った機能の数ではなく、事業数値の変化で評価されるのだ。
その巻き込み方も示唆に富む。「問題をそのまま伝える、達成したいアウトカム、どの事業数値を上げたいのか、何がボトルネックになっているのか、という問題のところから巻き込んで話していく」。解決策ではなく問題から共有し、少人数で小さく始め、検証しながら前に進める。これが不確実性の高い自動化を回すコツだという。
現場の実装②：オープンエイト──SFAにかかる固定費を内製で断つ
もう一つの現場は、コスト構造そのものにメスを入れた。オープンエイトでデータスペシャリストを務める吉田陽亮氏は、セールス・マーケティング・カスタマーサクセスを横断してオペレーションを統括し、データをマネジメントする立場にある。従来型のRevOpsやCSOpsに加え、最近は「各現場でのAI駆動型のオペレーションへの組織変換」を進めているという。
同氏が問題視したのが、既製のSFA（営業支援システム）のコストだった。人員が増えるほど費用が比例して膨らみ、「例えるならば税金のような形で固定費がPLを圧迫していた」。しかも設計者が退職してブラックボックス化し、現場では既製SFAに収まらない「現場最適なスプレッドシート」が増殖していた。
そこで吉田氏は、SFAの内製化に踏み切る。「業務要件をある程度言語化していく中で、実装自体はもうAIに任せて、それを現場に落として、翌日には改善していく。このサイクルをぐるぐる回していく」ことで、全員が使える自前のSFAにたどり着いた。注目すべきは、吉田氏自身が「全然コードとかも書けない」と語る点だ。実装を担うのはAIで、人が担うのは要件の言語化と改善のサイクル設計である。
成果は数字に表れた。「年間でも数百万から数千万というところの固定費を削減」。しかも吉田氏は、削減で終わらせなかった。「下げた分のコストをちゃんと売上を作る施策に投資をする」ことで、売上目標の達成につなげたという。
だからこそ、と吉田氏は続ける。「コスト削減したものをどういうマーケ施策に落としていくのか、そこまで議論に入っていく」。コスト削減の先にあるPL責任にまで踏み込むことが、GTMエンジニアの立場の人が一番輝くべき環境だ、と。
肩書きは、後からついてくる
ここまで見た2つの実装に共通するのは、「GTMエンジニアという肩書きがあって人を採った」のではない、という順序だ。
守屋氏は明かす。「GTMエンジニアという肩書きが先にあって、それに合う人がアサインしたというプロセスではない」。先にエンジニアリングとプロダクトマネジメントの素地があり、営業プロセスに関与するうちに「こういうことができる人がもっと必要だ」と明らかになり、あとから「GTMエンジニアという名前で拡大していこう」と進んだ。
オープンエイトに至っては、まだ名前すらない。「私の会社、まだGTMエンジニアという言葉はないんですよ。『吉田がやっています』みたいな感じ」。コスト改善と業務効率化というミッションを追ううちに、「気づいたらやっていることが、いわゆるGTMエンジニアが見る役割を担ってきていた」。
道家氏はこう整理した。
「環境変化へのあり方を皆さんが模索された結果、GTMエンジニアという風に定義される企業もあれば、別の定義ではあるがその役割を強化している企業もある」（道家氏）
これは、本連載の前回（第2回）で見た「行為が先、名前が後」という職種論の、もう一つの実例である。PMMが勝ち筋を設計し、GTMエンジニアがそれを実装・自動化するという対の構図も、誰かが最初に設計図を描いたわけではない。作る力がコモディティ化し、事業のボトルネックが開発から市場投入へと移った結果、現場が必要に迫って生み出した役割に、あとから名前がついた。順序が逆なのだ。
では、勝ち筋を「設計する」PMMの側は、この越境をどう実践しているのか。そして名前のなかったこの職種は、いま何になろうとしているのか。
