【イベントレポート】【Claude Code】世界のスタートアップが必死に求める「GTMエンジニア」とは

営業でもマーケターでもなく、プロダクトを作る開発者とも少し違う。海外のAIスタートアップを中心に、「GTM（Go-to-Market）エンジニア」という職種が急速に広がっています。

AIの進化でプロダクトを作るハードルが下がり、企業の関心は「どう作るか」から「どうやって市場に届け、使ってもらうか」へ移りつつあります。一方で日本では、GTMエンジニアが具体的に何をしているのかをイメージできる人はまだ多くありません。

2026年9月29日に開催したOffers Deep Diveには、#GTMLab主宰のなかむら まこと様と、株式会社LayerX 執行役員 バクラク事業VPoPの飯沼 広基様が登壇しました。進行は株式会社overflow 取締役CTOの大谷 旅人です。

前半はおふたりのLT、後半はディスカッションと質疑応答です。GTMエンジニアは何をエンジニアリングするのか、なぜエンジニア出身が向いているのか。当日の内容をお届けします。

Go-to-Marketは「売上を生むプロセス全体」を指す

プロセスは「戦略策定」と「実行」に分かれる

The Modelのどこに手を入れれば、売上につながるか

GTMエンジニアは、収益創出エンジンをAIと自動化で実装する

プロセスとデータを回すところを、エンジニアリングする

意識したいのは「リードタイム」と「クオリティ」

LayerXが選んだのは「開発する型」のGTMエンジニア

GTMエンジニアには「ツールをつなぐ型」と「開発する型」がある

狙うのは効率性ではなく、生産性

社内受託から、「まだ誰も頼んでいないもの」を作る側へ

一番売れている営業の横に座る

事例：営業の「スカウター」で商談のアサインを精緻化する

手元で試して、社内アプリで全員に届ける

向いているのは技術力7割、好奇心3割のエンジニア

向いているのは営業出身か、エンジニア出身か

――大谷：1つ目のテーマは「GTMエンジニアに向いているのは営業出身かエンジニア出身か、エンジニアだから出せるバリューとは」です。飯沼様からは先ほど「エンジニア出身」という答えが出ていましたが、なかむら様は海外の動きを見ていていかがでしょうか。

なかむら様：どれぐらいの配分かまでは調べきれていないのですが、Clayは、Zapierのようなツールを使えば本格的なエンジニアでなくてもできる、という領域でもあると言っています。そのレベル感にもよるのではないでしょうか。

とはいえ、しっかりやっていくとなるとエンジニア出身の方がいいと考えています。営業やマーケは、結果がどうなったかは気にしていても、その結果を生み出すために自分がどうしているかを言語化できていないケースが多いです。

言語化できればプロンプトに置き換えて、個人レベルで効率化はできます。ただ、それをプロセスに落とし込んでワークフロー化するとなると、エンジニアのシステム思考や、アーキテクチャをどうするかという思考が非常に必要になってきます。

――大谷：飯沼様には、エンジニアだから出せるバリューをもう少し深掘りしてお伺いしたいです。技術の引き出しの差が出た場面はありましたか。

RAGを作っただけでは、営業は使えない

飯沼様：恥ずかしい話になるのですが、社内のいろいろなドキュメントを検索してAIが回答するRAGのチャットボットを、私がバイブコーディングで実装したことがありました。正答率がだいたい65%で、3回に1回は間違える状態でした。

コストがかかってもよいならRAGではなくエージェンティックサーチにした方がいい、LLMのモデルをどう試してゴールデンセットを作るか。そういったことを自分は何もやっておらず、実装しただけの機能が多かったんです。

営業はお客様に連絡するので、最終的な内容の責任は営業自身が持たなければいけません。インサイドセールスでもマーケティングでも同じです。

AIのアウトプットを信頼できるレベルまで少しずつ上げていくには、エンジニアのバックグラウンドが必要です。そこに、エンジニアだからこそ出せるバリューがあると感じています。

効率化で終わらせないために、まず「作らないもの」を決める

――大谷：2つ目のテーマは「単なる効率化で終わらせず、成果（売上）に繋げる思考法とは」です。効率化で終わるものと売上につながるものは、作り方がどう違うのでしょうか。

飯沼様：何を作るかの前に、何を作らないか。こちらの方が大事な考え方です。私が効率化ばかりやってしまったのを失敗だと認識した後、効率化の開発はやりませんと宣言しました。

上がってくる要望の大半は、時間を削減するものです。それをまずやめると全員にアナウンスしたのが、一番大事でした。GTMのエンジニアリングもプロダクトとして捉えれば、何をやって何をやらないかを決めるのは大事です。

そうすると、「確かに工数は削減するかもしれないけれど、売上は上がらないかもしれないですね」というSlackのスレッドがたくさん生まれるようになりました。

売上につながるものだけをやると組織にアナウンスしたことが、一番効きました。LayerXに限らず、いろいろな会社で同じやり方ができるはずです。

なかむら様：飯沼様の話につなげると、少し引きで見るということだと思います。個別の作業の自動化は個人レベルでやればいい。

ただ、それが売上を生むプロセスの中で次のプロセスにつながっているのか、品質よく回せるのか、リードタイムを短く回せるのか。引きで見る思考法が必要だと、お話を聞いていて思いました。

電話の「待ち時間」に目を付けて、商談数を増やす

――大谷：視聴者から「効率性ではなく生産性が上がった事例には、具体的にどんなものがありましたか」という質問が来ています。

飯沼様：先ほどの案件アサインも、売上が上がったものです。他には、電話で商談を取るインサイドセールスの事例があります。動きを観察してみると、電話に向き合っている時間のうち、実際に話している時間はわずかでした。

サボっているわけではなく、非常に頑張って働いています。ただ、電話の応答待ちの時間がかなりあるんです。つながっても「担当に確認しますね、お待ちください」と言われ、待った末に不在だったりします。

そこで、応答があったタイミングで電話の情報を判定し、すぐに人間が出られるようにする機能を作りました。人間が使う時間に対するアウトカムを最大化するという意味で、生産性が上がり、1人あたりの獲得商談数が増えています。

御用聞きにならず、最初の一歩を小さく出す

――大谷：3つ目のテーマは「社内受託的にならないためにはどうすればいい？」です。エンジニアが御用聞きになってしまう会社とそうならない会社は、何が違うのでしょうか。

なかむら様：難しいですよね。営業プロセスが分からない中で御用聞きにならないのは難しく、要望を聞かないと作れない状態になりかねません。The Modelの書籍や、今年出ているGTM戦略の書籍を読んで、知識レベルをある程度合わせていくのが1つです。

もう1つは、エンジニアの得意な領域を生かすことです。営業やマーケは感覚で仕事をしている人が多いので、営業の横について、その感覚を言語化してあげる。

データから「こういうことなんじゃないですか」と示し、それをベースに自動化やAIを組み込んだプロセスを作っていく。それがエンジニアならではのバリューです。

最初は小さな要望を素早く出して、信頼を得る

――大谷：4つ目のテーマは「データ整備から入ると重すぎる？GTMエンジニアリングの『最初の一歩』とは」です。Xの感想でも、どこから手を付けたらいいか分からないという声が来ていました。

飯沼様：データ整備から入ると果てしないんですよね。それに、GTMエンジニアというポジションに人を置くのは、ほとんどの会社が初めてです。

組織的に早く何かしらの成果を出した方がいいので、最初は信頼を得るために、社内受託でもいいので要望の中から簡単なものを次々に出していく方が進みやすいでしょう。

最終的にはデータ整備をやった方が絶対にアウトカムが出やすいので、開発を止めてでも裏側で整備する期間は必要です。ただ最初の一歩だけは、「こういうことをやってくれるんだ」という仕事の理解も含めて、社内受託的に動いてみる期間を設けるといいと思います。

なかむら様：グローバルでAIの効果が出ているのは、リードをマーケティングクオリファイド、セールスクオリファイドへと上げていく前段の部分です。そこから始めると効果が出やすいでしょう。

営業そのものを効率化しようとすると、言語化できていないものを言語化するのに時間がかかる可能性があります。まずはできるところからです。

質疑応答

効果測定のためのモニタリングは、どう摩擦なく続けているか

――大谷：「効果測定のために適切なモニタリングが必要だと思いますが、エラーやデータ入力の追加工数といった摩擦があると推察します。どのように取り組んでいますか」という質問です。

飯沼様：生産性に明確に効くものは、たとえば案件のアサインなら、ロジックを作らなかった場合と作った場合のシミュレーションで、売上がどれぐらい変わるかをモニタリングしています。

AIが自動で入力したり業務を代行したりする機能で、ハルシネーションや営業の意図と違う動きがあった場合については、先ほどのEvalをちゃんとやっているかどうかでしょう。

データ入力のビフォーアフターは、トラッキングできるように保存してあります。ただ人数が少ないので、全機能でゴールデンセットを作ってEvalをやりきれているわけではなく、機能によってグラデーションがあるのが実態です。

BizOpsとは何が違うのか

――大谷：「BizOpsとはどう違うのでしょうか。SalesforceのAdminのような仕事もするのでしょうか」という質問です。

なかむら様：BizOpsやRevOps（レベニューオペレーション）もありますし、場合によってはBizOpsの中にエンジニアがいて、AIを使った自動化プロセスを組んでいく、という部署の配下に入るケースもあるかもしれません。

SalesforceのAdminのようなこともするかもしれません。その幅は、会社によって異なるのではないでしょうか。

――大谷：ちなみに私はRevOpsもGTMエンジニアのようなこともやっていますが、SalesforceのAdminもやっているので、本当に会社によってそれぞれだと思います。

課題の探索から社内アプリを出すまでのリードタイム

――大谷：「課題を探索するところから社内アプリケーションを作り出すまで、リードタイムは最低でもどれくらいかかっていますか」という質問です。

飯沼様：入社したタイミングや組織へのキャッチアップの状態によって全然違います。私の場合、変えた方がいいと思ったものをコーディングエージェントですぐ変えてもらうことは日常的です。

入社2カ月目のメンバーの直近の事例では、フィールドセールスからカスタマーサクセスへの引き継ぎデータをAIで作るところの精度が悪い、という課題を渡して、探索から開発までやってもらいました。

渡してから3週間ぐらいでモックアップができ、実運用を試すフェーズに入っています。だいたい1カ月で大きな機能が1つできている状態です。

営業が主導するGTMエンジニアリングに、エンジニアはどう関わるべきか

――大谷：「営業がAIを使ってGTMエンジニアリングをやるぞと意気込んでいるのですが、エンジニアリング力が乏しく、どのように関わってもらうのがよいでしょうか」という質問です。

なかむら様：僕だったら、まず現状のプロセスの計測から始めます。認知がどれだけ取れているかはいろんなところで指標が取れますし、営業プロセスのどこがボトルネックになっているかも数値で分かるはずです。まず計測して可視化し、どこから始めるかを決めていくのがいいのではないでしょうか。

飯沼様：私は営業の後にプロダクトマネージャーをやっていたので、システムの理解力はある程度ありました。プロダクトマネージャーをやっていない状態で同じことをしようとしていたら、おそらくプロジェクトは失敗していたでしょう。

いろいろな人の力を借りて一旦仕切り直し、エンジニア主導のプロジェクトに変えた方がいい気がします。最終意思決定者が営業側にあると、無理やりいろいろなものを作るプロジェクトになりそうなので、手綱を握るのは必ずエンジニアにした方がいいと考えています。

登壇者からのメッセージ

なかむら様：#GTMLabで発信しているのは、営業・マーケ・カスタマーサクセスといったGTMの人たちがどんなことをやっているか、です。最近はGTMエンジニアへの興味関心も高まっていると感じるので、そういった情報も発信していくつもりです。コラボしたい方がいらっしゃいましたら、ぜひお声がけください。

飯沼様：僕はエンジニアの人が好きなので、販売のプロセスまで入り込んで新しいことにチャレンジしてくれるGTMエンジニアという職種は、ものすごく流行ると思っています。エンドユーザーの近くに行って自分でものを作ってみたいという方には、非常に向いている仕事です。

自分の会社でGTMエンジニアというポジションを作ってみるのでもいい。販売プロセスには、まだテクノロジーが入っていないところがたくさんあり、やりがいのある領域です。ぜひチャレンジしていただけると嬉しく思います。

GTMエンジニアが作るのは、売上を生むプロセスそのものです。なかむら様はそれを計測・データ・意思決定まで含めた「地図」として描き、飯沼様は、一番売れている営業の横に座って言語化し、手元で試して全員に届けるという現場のやり方で示しました。

効率化の要望に応え続けるのではなく、作らないものを決め、まだ誰も頼んでいないものを作る。プロダクト開発で培った設計と評価の力は、販売の現場でも大きなレバーになりそうです。