Offers_DeepDive 20260929 LayerXのGTMエンジニアリングについて

1. #Offers_DeepDive LayerXのGTMエンジニアリングについて 株式会社LayerX 執⾏役員 バクラク事業 VPoP 飯沼 広基
2. ⾃⼰紹介 略歴 飯沼 広基 • ハードウェアエンジニア • • • 第二新卒でスタートアップへ 事業開発 マーケ・IS・FS・CS幅広に • • 法人営業 プロダクトマネージャー 株式会社LayerX 執⾏役員 バクラク事業 VPoP 営業出⾝の⽴場から、GTMエンジニアと⼀緒に営業組 織をつくっています バックグラウンド ハードウェア エンジニア ⾊々 BizDev 営業 PdM （PdM、BizDev、CS やったり、社内の⽣産性 を上げたり） LayerX⼊社後（営業 → PdM → 現職） 2
3. AI Native GTMの本質：The Inversion（反転） 従来のSaaS GTM AI Native GTM（2026） ⼈間がシステム、AIが機能 AIがシステム、⼈間はレビュアー • ⼈間がフローを設計‧実⾏する • エージェントが業務本体を回す • AIは⽂章ドラフトや要約を補助 • ⼈間は意思決定とレビューに専念 • ボトルネックは常に⼈員数とMTG • ボトルネックは「センス」とデータ • 採⽤と組織拡⼤が成⻑の前提 • 組織が⼩さいまま売上が伸びる Jason Lemkin（SaaStr）：「The agent is the system. The human is the optional reviewer. That inversion is the whole ballgame.」 3
4. GTMエンジニアには、2つの型がある ⾔葉はClayが広めたこともありマーケ寄りの印象が強いが、実際には2つのやり⽅がある ツールをつなぐ型 やり⽅ 開発する型 Zapierなどで既存ツールをつなぐ やり⽅ エンジニアが⾃ら開発し、営業の進め ⽅を変える ⽬的 作業を減らす（効率性） 経営への影響 ⼩さい。作業時間が削減される ⽬的 売上を伸ばす（⽣産性） 経営への影響 ⼤きい。売上の向上が⾒込める LayerXは「開発する型」。GTMエンジニアは全員ソフトウェアエンジニアバックグラウンドがある フロントエンドエンジニア ＋ PdM マーケティング ＋ ソフトウェアエンジニア データエンジニア ＋ ソフトウェアエンジニア 5
5. AIの使い⽅は、効率性と⽣産性の2軸 同じ「AI活⽤」でも、どちらを狙うかで売上へのつながり⽅がまったく違う 効率性 / Efficiency 定義 同じ成果を、より少ないインプット（時間 ⽣産性 / Productivity 定義 ‧⼯数）で出す 同じインプットから、より多くのアウトカ ム（売上）を⽣む 指標 ◯◯時間削減‧⼯数削減‧処理件数 指標 営業1⼈あたり売上‧受注額‧勝率 性質 ⽿障りは良い。だが売上とは切り離されて 性質 売上を伸ばせる いる 世の中の⼤半のAI活⽤は効率性。LayerXでも過去効率性ばかりを⾼めたが、⽣産性が上がらなかったた め、現在は⽣産性を上げる（＝売り上げを上げる）開発にシフト 4
6. 社内Opsとの違いは「頼まれて作るか」どうか 社内Ops GTMエンジニア 頼まれたものを作る まだ誰も頼んでいない ものを作る 現場からの依頼を受けて、既存の業務をラク にする 成果：効率化 売れる理由を⾃分で⾒つけにいき、営業の進 め⽅そのものを変える 成果：⽣産性の向上 6
7. 仕事の進め⽅：⼀番売れている営業の横に座る 営業の知識は最初からなくていい。できる⼈の動きをプロダクトに落とし込む STEP 1 STEP 2 STEP 3 横に座る 観察する 再現する 突出して成果を出してい 何をしているか、何に時 ⾃社開発と既存ツールの る営業の隣で、仕事を⼀ 間を使っているかを把握 組み合わせで、全員がで 緒に⾒る する きるようにする できる⼈の動きを、全員が使えるプロダクトにする 7
8. 事例：営業商談のアサインの精緻化 8
9. 要はドラゴンボールのスカウターの世界を営業に作った 営業の戦闘⼒を数値化 「受注⼒」「複数製品 併売⼒」という2つのパラメータを⽤ 意し、それぞれのベクトルでモデリング 顧客の意向に合わせたアサインの最適化を実施 9 引用：鳥山明 ドラゴンボールより
10. やってみて⾯⽩かったこと 通常、営業の評価は絶対評価（売上がいくらだったか？） 今回のケースでは、営業毎の営業⼒を可視化して、案件の期待値の計算とともにアサインをすることで、相対評価が可能 になった。技術でビジネスの流れそのものが変わるケース。思想としても正しく営業のがんばりが評価される世界に近づ いている 例： 1. そもそも難しい案件をアサインされる（＝案件の期待受注額が⼩さい） 2. アサインされた営業が期待受注額を超えた結果を出す 3. 営業⼒/併売⼒のパラメーターが再計算し直される このサイクルを回せるように初めてなった。技術がなかったらできなかったことができるようになった 10
11. 試すのはShepherd、全員に届けるのはSales Portal ⼀⼈の⼿元で動いたものを、営業組織の全員が使えるものにする Shepherd Sales Portal 社内のAI活⽤基盤 営業向けの社内Webアプリ 売上 最初のアプリケーションはここで 効果が⾒えたものを汎⽤化してデ 使う⼈が増えるほど、でき 作って試す プロイ る⼈の動きが組織に広がる • Coding Agentの環境構築 • 営業全員が迷わず使える画⾯ • MCP Gateway • 商談記録などAIに渡す情報を • Guardrails • スキルの定期実⾏ 整える • 使う⼈を増やす 11
12. 向いているのは、エンジニア出⾝だと思っている 営業出⾝の⾃分がやってみて、出した結論 採⽤で⾒ているバランス 営業の現場は、⾒に⾏けば覚えられる 横に座れば、知識は増やせる 技術⼒ 7 好奇⼼ 3 好奇⼼ ＝営業を知ろうとする姿勢（営業への興味、知ろうとする 気持ち） 技術の引き出しは、すぐには増えない 例：⼤量の商談の会話データを、AIが扱え る形に圧縮する 営業出⾝ではGTMエンジニアにはなれない。 技術を⾝につけるには、相当な時間の投資が必要になる。 営業の現場にはいくことができるので、知⾒がなくとも⾒て学ぶことができる 12
13. ⽇本には、エンジニアが活躍できる余⽩が⼤きい 海外のRampとほぼ同じやり⽅ • エンジニアを営業の現場に⼊れる • 既存のシステムも組み合わせて使う ただし、そのままは持ち込めない • 商習慣や組織⽂化も違うので、海外のプラ クティスを参考にしつつ、新しいものを作 る必要と、やりがいがある ⽇本の組織に合わせて作れるエンジニアに、⼤きなチャンスがある 13
14. まとめ：GTMエンジニアは、売れる動きをプロダクトにする⼈ 作業を減らすのではなく、売上を上げる 誰にも頼まれていないものを作る ⼀番売れている営業の横に座る できる⼈の動きを観察し、エンジニアリングで再現する ⼿元で試し、組織のアプリで全員に届ける Shepherdで試作し、Sales Portalで広げる LayerXはGTMエンジニアを募集しています 採用応募URL 13