SLG時代のGTMエンジニアとは -- 営業が売れる仕組みを技術で作るエンジニア像

Phase 1に入る

ここまでの5本の記事で、GTMエンジニアリングの海外事例を掘り下げてきた。State of GTME 2026の228名調査データ、Clay社の$3.1B評価額の裏にある技術戦略、Palantir FDSEの年収$486Kの働き方、Vercel COOのSDR10人→AI+QA1人への転換、4層技術スタックの全体像。

Phase 0は「海外ではこうなっている」という翻訳・紹介だった。Phase 1からは「日本市場でGTMエンジニアはどう機能するか」を独自に定義し、実践していく。

この記事はその起点となる。テーマはSLG（Sales-Led Growth）におけるGTMエンジニアの定義だ。

PLG vs SLG: 2つの成長モデル

GTMエンジニアリングを語る前に、PLGとSLGの違いを整理しておきたい。この区別がGTMエンジニアの役割をかなり左右する。

PLG（Product-Led Growth）

プロダクト自体がユーザー獲得・活性化・収益化の手段となるモデル。

PLGでは「プロダクトの使いやすさ」「バイラル係数」「フリーミアムの設計」が成長のドライバーだ。営業チームが介在しなくても、ユーザーがプロダクトを触って価値を感じ、自発的に拡大する。

PLG型のGTMエンジニアリングは、プロダクト内のオンボーディングフロー改善、利用データに基づくアップセルトリガー、セルフサーブの課金フロー最適化といった領域で機能する。

SLG（Sales-Led Growth）

営業チームが顧客を獲得し、拡大するモデル。SLGでは「営業チームの生産性」「商談の質と速度」「顧客との関係構築」が成長のドライバーだ。プロダクトの価値を顧客に届けるのは、プロダクトUIではなく営業担当者の提案力になる。

日本のBtoB SaaSはSLG寄りである

日本のBtoB SaaS市場を見ると、SLGが主流になる必然性がある。調べた限り、以下の4つの構造的な理由がある。

商習慣の問題

日本企業の購買プロセスは関係性ベースだ。既存の取引先からの紹介、展示会での名刺交換、業界団体経由の接点が商談の起点になる。コールドメール1通で商談化するPLG的なアプローチは、特にエンタープライズ領域では効率が悪い。

意思決定プロセスの問題

日本企業の意思決定は合議制が基本だ。現場担当者がプロダクトを触って「良い」と思っても、部長→本部長→役員→稟議という承認プロセスを経る必要がある。この過程で「なぜこのツールなのか」「ROIはいくらか」「既存システムとの連携は」といった質問に答えられるのは、営業担当の提案力に依存する。

稟議文化の問題

稟議書には「導入背景」「比較検討結果」「費用対効果」「リスク分析」を記載する。セルフサーブで始めたツールに月額100万円以上の予算を通すには、営業が稟議書作成を支援するか、稟議に耐える資料を提供する必要がある。

カスタマイズ要望の問題

「うちの業務フローに合わせてほしい」という要望は日本企業で頻繁に出る。標準機能のみで完結するPLG的な使い方よりも、営業・SE・CSが一体となって顧客固有のニーズに対応するSLGの方が契約金額も継続率も高くなる傾向がある。

日本のBtoB SaaS企業（Sansan、freee、SmartHR、マネーフォワード等）は、エンタープライズ領域に拡大するにつれてSLG色を強めている。この構造的現実が、日本でのGTMエンジニアの役割を左右する。

SLGにおけるGTMエンジニアの定義

SLG型GTMエンジニアとは、営業が売れる仕組みをコードで構築するエンジニアである。

「営業が売れる仕組み」とは

GTMエンジニアが作るのは営業ツールではない。営業プロセス全体を加速する仕組みだ。

営業担当の1日を分解すると:

• リサーチ・情報収集: 2-3時間
• 事務作業（CRM入力、報告書作成、議事録整理）: 1-2時間
• メール/Slack対応: 1時間
• 顧客との対話（商談、提案、フォロー）: 2-3時間

営業が最も価値を出すのは「顧客との対話」の部分だ。しかし、1日8時間のうち顧客と向き合える時間は2-3時間しかない。残りはリサーチと事務作業で消えている。

GTMエンジニアの仕事は、このリサーチ・事務作業にかかる時間を圧縮し、顧客との対話に使える時間を増やすこと。さらに、顧客との対話の質を上げるための武器（カスタムデモ環境、ROI試算ツール、提案書自動生成）を提供すること。

「コードで構築する」という部分

ノーコードツールの設定やSaaSの導入は、RevOps（Revenue Operations）やセールスオペレーションの仕事だ。GTMエンジニアが差別化されるのはコードを書く点にある。

なぜコードが必要か:

1. 既存ツールでは対応できない日本固有の要件がある: 帝国データバンクとCRMの連携、日本語のIR資料解析、稟議書テンプレートの自動生成。これらはClay/HubSpotの標準機能では実現できない
2. 複数システムの統合にカスタムロジックが必要: kintone + HubSpot + Slack + Claude API を繋ぐワークフローは、GUIツールだけでは限界がある
3. パフォーマンスの最適化: 数千件のリードを一括処理する際のバッチ制御、APIレート制限のハンドリング、エラーリトライは、プログラマティックな制御が不可欠

成果の測定

GTMエンジニアの成果は「何件のバグを直したか」「何画面を実装したか」ではなく、以下のメトリクスで測定される:

プロダクトエンジニアの成果が間接的（ユーザー体験向上→利用率向上→収益増）であるのに対し、GTMエンジニアの成果は営業パイプラインに直結する。

3つのGTMエンジニアタイプ

State of GTME 2026ではInternal型とForward Deployed型の2タイプが紹介されている。ここではSLGの文脈で3つ目のタイプを加え、日本市場での役割を定義する。

タイプ1: Internal GTM Engineer

所属: 自社のセールス/マーケ組織内

役割: 社内の営業基盤を構築・自動化する。Clay社内のGTMエンジニアリングチームがこのモデルの代表。

SLGでの具体的な仕事:

• リードスコアリングパイプラインの構築
• CRMのカスタムフィールド設計と自動更新ロジックの実装
• 営業向けダッシュボードの構築（パイプライン速度、コンバージョン率、ボトルネック可視化）
• メールシーケンスの自動化とA/Bテスト基盤
• 商談前リサーチの自動生成パイプライン

日本での適用:

BtoB SaaS企業のセールス組織内に配置される。日本企業の場合、「セールスエンジニア」や「セールスオペレーション」の延長として始まることが多い。ただし、既存のSE職とは「コードで仕組みを作る」点が決定的に異なる。

typescript
// Internal GTMエンジニアが構築する例: 商談前リサーチの自動生成
import Anthropic from '@anthropic-ai/sdk'

interface DealResearch {
  companyName: string
  industry: string
  challenges: string[]
  recentNews: string[]
  competitorUsage: string[]
  proposedApproach: string
}

async function generateDealResearch(
  companyUrl: string,
  dealContext: { productName: string; targetPersona: string }
): Promise<DealResearch> {
  const anthropic = new Anthropic()

  // 企業情報の収集（IRページ、ニュース、採用ページ）
  const companyData = await collectCompanyData(companyUrl)

  const message = await anthropic.messages.create({
    model: 'claude-sonnet-4-5-20250514',
    max_tokens: 2048,
    messages: [{
      role: 'user',
      content: `以下の企業情報をもとに、${dealContext.productName}の提案に必要なリサーチを生成してください。

企業名: ${companyData.name}
業種: ${companyData.industry}
従業員数: ${companyData.employeeCount}
直近IR要約: ${companyData.irSummary}
直近ニュース: ${companyData.recentNews.join('\n')}
採用ページから推定される技術スタック: ${companyData.techStack.join(', ')}
ターゲット担当者ペルソナ: ${dealContext.targetPersona}

出力形式:
1. 推定される経営課題（3つ）
2. 直近の注目ニュース（トリガーイベント）
3. 競合プロダクトの利用状況（推定）
4. 提案アプローチの方向性`
    }]
  })

  return parseDealResearch(message.content[0].text)
}

タイプ2: Forward Deployed GTM Engineer

所属: 自社に籍を置きつつ、顧客先に入り込む

役割: Palantir FDSEがこのモデルの原型。顧客の業務環境に入り、自社プロダクトと顧客業務のギャップをコードで埋める。

SLGでの具体的な仕事:

• 顧客のデータを使ったカスタムデモ/POC環境の構築
• 既存システム（基幹系、CRM、ERP）との連携実装
• 顧客固有の業務ワークフロー自動化
• データ移行ツールの構築
• オンボーディングの技術支援

日本での適用:

日本のSIer/コンサル出身エンジニアには、この働き方と親和性が高い。ただし従来のSE職との違いは、要件をまとめて開発チームに投げるのではなく、自分でコードを書いてその場で解決する点だ。

商談中に「このデータ連携はできますか?」と聞かれたとき:

• 従来のSE: 「持ち帰って確認します」→ 2週間後に回答
• Forward Deployed GTM Engineer: 「今から30分で動くプロトタイプを作ります」→ その場で確認

この速度差が商談サイクルの短縮に直結する。

タイプ3: Product-Embedded GTM Engineer（新定義）

所属: プロダクト開発チーム内

役割: 自社プロダクトの中に営業支援機能を組み込むエンジニア。Internal型が営業チーム向けの外部ツールを構築するのに対し、Product-Embedded型はプロダクト自体をSLGの武器にする。

この3つ目のタイプは、海外のGTMエンジニアリングの文脈ではまだ明確に定義されていない。ただ日本のSLG型BtoB SaaS企業においては最も有効なタイプだと自分は考えている。

例1: マルチテナントSaaSの管理画面にヘルススコアダッシュボードを組み込む

SaaS管理者（顧客企業の情報システム部門）が見る管理画面に、利用状況の可視化ダッシュボードを組み込む。CSチームはこのダッシュボードを見ながら「利用率が下がっているチームがある」と気づき、先回りしてフォローできる。

これは「CSツールを別途導入する」のではなく、プロダクト内に組み込むアプローチだ。

typescript
// Product-Embedded GTMエンジニアが構築する例:
// SaaSの管理画面に組み込むヘルススコアAPI

import { Hono } from 'hono'
import { z } from 'zod'

const app = new Hono()

const HealthScoreSchema = z.object({
  tenantId: z.string(),
  period: z.enum(['7d', '30d', '90d']).default('30d'),
})

app.get('/api/admin/health-score', async (c) => {
  const query = HealthScoreSchema.parse(c.req.query())

  const metrics = await calculateHealthMetrics(query.tenantId, query.period)

  // ヘルススコアの算出（0-100）
  const score = computeHealthScore({
    loginFrequency: metrics.dailyActiveUsers / metrics.totalUsers,
    featureAdoption: metrics.usedFeatures / metrics.totalFeatures,
    apiUsage: metrics.apiCallTrend,       // 増加傾向: +, 減少傾向: -
    supportTickets: metrics.ticketTrend,   // 増加は悪化シグナル
    dataVolume: metrics.dataGrowthRate,    // データが増えている = 定着
  })

  return c.json({
    score,
    trend: metrics.scoreTrend,   // 前期比
    riskFactors: identifyRiskFactors(metrics),
    recommendations: generateRecommendations(metrics),
    // CSチーム向け: 次のアクション提案
    suggestedActions: suggestCSActions(score, metrics),
  })
})

例2: CRM連携APIを自社プロダクトに実装する

顧客のCRM（HubSpot, Salesforce, kintone）と連携するAPIを自社プロダクトに組み込む。営業チームが「このお客さんの利用状況をCRMで確認できる」状態を作る。

typescript
// CRM連携の抽象化レイヤー
interface CRMAdapter {
  syncDealData(tenantId: string, dealData: DealData): Promise<void>
  syncUsageMetrics(tenantId: string, metrics: UsageMetrics): Promise<void>
  fetchContactInfo(tenantId: string): Promise<ContactInfo>
}

class HubSpotAdapter implements CRMAdapter {
  async syncDealData(tenantId: string, dealData: DealData): Promise<void> {
    const hubspotClient = new HubSpotClient(await getCredentials(tenantId))
    await hubspotClient.deals.update(dealData.dealId, {
      properties: {
        product_usage_score: String(dealData.healthScore),
        last_login_date: dealData.lastLoginDate,
        active_users: String(dealData.activeUserCount),
        feature_adoption_rate: String(dealData.featureAdoptionRate),
      }
    })
  }
  // ...
}

class SalesforceAdapter implements CRMAdapter { /* ... */ }
class KintoneAdapter implements CRMAdapter { /* ... */ }

// ファクトリーパターンで顧客のCRMに応じてアダプターを切り替え
function createCRMAdapter(crmType: 'hubspot' | 'salesforce' | 'kintone'): CRMAdapter {
  const adapters = {
    hubspot: new HubSpotAdapter(),
    salesforce: new SalesforceAdapter(),
    kintone: new KintoneAdapter(),
  } as const
  return adapters[crmType]
}

例3: 稟議書に使えるレポート自動生成機能をプロダクト内に組み込む

日本のBtoBでは、トライアル後の本契約に稟議が必要だ。プロダクト内から「稟議書に添付できるPDF形式の利用レポート」をワンクリックで出力できる機能は、受注率を直接的に向上させる。

これはプロダクト機能でありながら、その設計意図は完全にSLGのためのGTMエンジニアリングだ。

3タイプの比較

Product-Embedded型のいちばんの利点はスケーラビリティだと思う。Internal型は営業チームの効率化、Forward Deployed型は個別案件の受注率向上に寄与するが、Product-Embedded型はプロダクトの機能として全顧客に提供される。一度構築すれば、顧客数に比例して価値が増大する。

SLG営業フェーズ x GTMエンジニアの介入ポイント

SLGの営業プロセスを6つのフェーズに分けて、各フェーズでの介入ポイントを示す。

フェーズ1: リード獲得

営業の課題: ターゲット企業のリストアップ、担当者の特定、アプローチ優先度の判断に時間がかかる。

GTMエンジニアの介入:

[データエンリッチメント]
  企業DB（帝国DB/SPEEDA）→ IRスクレイピング → 採用ページ分析
  → Claude APIで構造化 → リードスコアリング（0-100）
  → CRMに自動登録（スコア70以上は即通知）

[トリガーイベント検知]
  プレスリリース監視 → 「AI投資」「DX推進」「基幹システム刷新」等のキーワード検知
  → Claude APIで商談機会の評価
  → 該当企業をCRMの優先リードに自動昇格

成果メトリクス: 営業1人あたりのリサーチ時間 3時間/日 → 30分/日

フェーズ2: 商談準備

営業の課題: 商談相手の企業・人物情報を調べ、課題仮説を立て、提案の切り口を考える作業が属人的。

GTMエンジニアの介入:

[AI企業リサーチ]
  商談確定 → ターゲット企業のURL入力
  → IR/ニュース/採用ページ/SNSを自動収集
  → Claude APIで1ページサマリー生成
    - 経営課題の推定（3つ）
    - 直近のトリガーイベント
    - 競合プロダクトの利用状況（推定）
    - 提案アプローチの方向性

[提案書ドラフト自動生成]
  テンプレート x 企業リサーチ結果 x 自社プロダクト情報
  → 提案書のドラフトをMarkdown→PDF生成
  → 営業が微調整して完成

成果メトリクス: 提案書作成時間 4時間 → 45分

フェーズ3: デモ/PoC

営業の課題: 汎用デモでは刺さらない。顧客のデータや業務フローに合わせたデモ環境の構築に、開発チームへの依頼→数週間待ちが発生する。

GTMエンジニアの介入:

[カスタムデモ環境]
  顧客の業種/規模/課題に応じたデモデータの自動生成
  → マルチテナント環境でデモ用テナントを即座にプロビジョニング
  → 顧客のロゴ・データ構造に合わせたUI調整

[POC環境の自動セットアップ]
  顧客のサンプルデータをインポート
  → 本番に近い環境を数時間で構築
  → 顧客が自社データで評価できる状態を即座に提供

成果メトリクス: デモ環境構築 2週間 → 2時間

フェーズ4: 提案/稟議

営業の課題: 稟議を通すためのROI試算、導入効果シミュレーション、比較検討資料の作成が重い。

GTMエンジニアの介入:

[ROI試算ツール]
  顧客の従業員数/売上/現在のコスト構造を入力
  → 導入後の効果を自動シミュレーション
  → PDF出力（稟議書添付用）

[導入効果シミュレーション]
  同業他社の導入事例データ × 顧客の規模パラメータ
  → 「御社規模の場合、年間○○時間の削減が見込めます」
  → 具体的な数値でROIを提示

[稟議書テンプレート自動生成]
  顧客の稟議フォーマットに合わせた文書生成
  → 導入背景、比較検討、費用対効果、リスク分析を自動記入

成果メトリクス: 稟議通過率 40% → 60%、稟議期間 3週間 → 1.5週間

フェーズ5: 受注後/オンボーディング

営業の課題: 受注したのに使い始めるまでに時間がかかる。初期設定が煩雑で、顧客が離脱する。

GTMエンジニアの介入:

[自動セットアップ]
  契約情報 → テナント自動作成
  → 初期設定ウィザード（業種別テンプレート適用）
  → 既存データのインポートツール
  → セットアップ完了通知 → CSチームに引き継ぎ

[データ移行ツール]
  旧システムからのデータエクスポート→変換→インポートを自動化
  → CSV/Excel/API経由でのデータ取り込み
  → データ品質チェック（重複、欠損、形式不一致の検出・修正）

成果メトリクス: オンボーディング完了日数 30日 → 7日

フェーズ6: エクスパンション

営業の課題: 既存顧客のアップセル/クロスセルの機会を見逃す。解約の兆候に気づくのが遅い。

GTMエンジニアの介入:

[ヘルススコア]（Product-Embedded型の領域）
  ログイン頻度 × 機能利用率 × API呼び出し量 × サポート問い合わせ傾向
  → ヘルススコア（0-100）を算出
  → スコア低下時にCSチームへ自動アラート

[利用状況可視化]
  管理画面にアクティブユーザー数、利用機能、データ量の推移グラフを表示
  → 顧客自身が「うちの会社はこう使っている」を把握できる
  → CSミーティングの事前準備が不要に

[エクスパンション機会の自動検知]
  利用量が上限に近づいている → プランアップグレードの提案
  特定部署だけが使っている → 他部署展開の提案
  新機能の適用可能性が高い → 機能紹介メールの自動配信

成果メトリクス: Net Revenue Retention 105% → 120%、チャーンレート 5% → 2%

日本でのGTMエンジニアのキャリアパス

GTMエンジニアという職種は、日本ではまだ確立されていない。ただ、現在のキャリアからGTMエンジニアリングの領域に踏み込むパスはいくつかある。

フリーランスエンジニアがGTMエンジニアリングを付加価値にする

フリーランスのフルスタックエンジニアが最も参入しやすいと思う。理由は3つある。

1. 既にコードが書ける: TypeScript/React/Node.js等のスキルをそのまま活かせる
2. 複数クライアントの業務を知っている: SIer/フリーランスで複数企業に入った経験が、業種横断の知識になる
3. 成果報酬に馴染みがある: GTMエンジニアリングの成果（商談数、受注率）を報酬に紐づける交渉がしやすい

自分がやるなら:

• 既存クライアントの営業チームの課題をヒアリングする
• CRM（HubSpot無料プラン）のAPI連携を1つ構築して見せる
• 「営業の定型作業をコードで自動化する」提案をする

フリーランスの場合、月額単価にGTMエンジニアリングの価値を上乗せできる。「フロントエンド開発 + 営業パイプライン自動化」というスキルセットは、2026年時点で競合がほぼいない。

BtoB SaaS企業内でのGTMエンジニアポジション

BtoB SaaS企業（特にSLG型）には、GTMエンジニアのポジションが生まれる素地がある。

なぜ今このポジションが必要か:

• 営業チームは常に「もっと商談が欲しい」「リサーチに時間がかかる」と言っている
• CSチームは「解約の兆候を早く知りたい」「ヘルススコアが欲しい」と言っている
• しかし、プロダクト開発チームのバックログはプロダクト機能で埋まっており、営業支援ツールの優先度は低い

GTMエンジニアは、プロダクトチームとは別の予算・目標で動くことで、この構造的な問題を解決する。

社内での提案方法:

1. 営業/CSチームの定型作業を1つ自動化する（小さな成果を出す）
2. その自動化が商談数や受注率にどう影響したかを数値で示す
3. 「GTMエンジニアリング」としてチーム化/役割化を提案する

SIer/コンサルからの転身

SIer/ITコンサルの経験は、GTMエンジニアリングに直結するスキルセットを含んでいる:

• システム統合の経験: CRM、ERP、基幹システムの連携は日常的にやっている
• 顧客折衝力: 顧客の業務を理解し、技術で解決する力がある
• 稟議・意思決定プロセスの理解: 日本企業の購買プロセスを肌で知っている

従来のSIer/コンサルとGTMエンジニアの違いを整理すると:

SIer出身のエンジニアが「人月ビジネスから抜け出したい」と思うなら、GTMエンジニアリングは有力な選択肢だ。

使用技術スタック

4層モデルの記事で示した海外スタックを、日本市場の実情に合わせて再構成する。

TypeScript（フルスタック）

GTMエンジニアリングの実装言語としてTypeScriptを推奨する理由:

1. フルスタックで統一: フロントエンド（React/Next.js）→ バックエンド（Hono/Node.js）→ エッジ（Cloudflare Workers）→ スクリプト（Bun）まで1言語で完結
2. 型安全: CRM APIのレスポンス、AI生成テキストのパース、ワークフローの中間データ。型があることでパイプラインの信頼性が上がる
3. エコシステム: npm/JSRに営業系APIのSDKが揃っている（HubSpot, Salesforce, Slack, etc.）
4. AI開発ツールとの相性: Cursor/Claude CodeのTypeScript支援は成熟度が高い

フルスタック構成:
  フロントエンド: React + Next.js（ダッシュボード、管理画面）
  バックエンド:   Hono（API、Webhook受信）
  エッジ:        Cloudflare Workers（データ処理パイプライン）
  バッチ:        Bun + TypeScript スクリプト
  IaC:          SST / Pulumi（TypeScriptでインフラ定義）

AI API（Claude API / GPT API）

営業プロセスの知的労働を自動化するコアエンジン。

CRM API

日本のGTMエンジニアは、HubSpot/Salesforce と kintoneの両方に対応できることが差別化になる。技術スタック記事で述べた通り、kintoneは日本市場特有のCRMだ。

オーケストレーション

n8nとClaude Code Agent Teamの使い分け:

• n8n: 定型化されたワークフロー。条件分岐が明確で、毎日同じ処理を繰り返すもの
• Agent Team: 判断を伴う処理。企業リサーチのように入力ごとに調査範囲が変わるもの

GTMエンジニアのアーキテクチャ全体像

┌─ SLG営業フェーズ ──────────────────────────────────────────────┐
│                                                                │
│  リード獲得 → 商談準備 → デモ/PoC → 提案/稟議 → 受注 → 拡大   │
│     ↑           ↑          ↑          ↑         ↑       ↑     │
└─────┼───────────┼──────────┼──────────┼─────────┼───────┼─────┘
      │           │          │          │         │       │
┌─────┴───────────┴──────────┴──────────┴─────────┴───────┴─────┐
│                   GTMエンジニアリング層                          │
│                                                                │
│  [Internal]          [Forward Deployed]    [Product-Embedded]  │
│  リードスコアリング   カスタムデモ環境      ヘルススコア          │
│  リサーチ自動化       POC構築              CRM連携API           │
│  提案書生成          データ移行            稟議書レポート        │
│  パイプラインダッシュ  システム統合          エクスパンション検知  │
│                                                                │
├────────────────────────────────────────────────────────────────┤
│                   技術スタック                                   │
│                                                                │
│  TypeScript (React/Next.js → Hono → Cloudflare Workers)       │
│  Claude API / GPT API                                         │
│  HubSpot / Salesforce / kintone API                           │
│  n8n / Claude Code Agent Team                                 │
└────────────────────────────────────────────────────────────────┘

PLG→SLG転換期の企業にGTMエンジニアが効く

多くのBtoB SaaS企業はPLGで成長を始め、エンタープライズ市場に進出する段階でSLGを追加する。この転換期が、GTMエンジニアが特に大きな価値を出せるタイミングだ。

PLG→SLG転換期の典型的な課題:

1. プロダクトのセルフサーブ利用データはあるが、営業がそのデータを使えていない
2. 無料ユーザーの中にエンタープライズ案件の種があるが、発見できていない
3. 営業チームが立ち上がったばかりで、ツール基盤が整っていない

GTMエンジニアは、PLG時代に蓄積された利用データを営業活動に接続する。具体的には:

• 無料ユーザーの利用パターンからエンタープライズ見込みを自動検知
• セルフサーブ→営業商談へのハンドオフを自動化
• プロダクトの利用データをCRMに同期し、営業が商談時に参照できるようにする

---

この記事で書いた3タイプの定義と6フェーズの介入ポイントは、あくまでも自分の経験の範囲から整理したものだ。実際には会社や営業組織の成熟度によって、どこから着手するかはかなり変わってくると思う。

次回: GTMエンジニアの技術選定フレームワーク -- TypeScript/Hono/Claude APIを軸に、SLG営業パイプラインを構築する際の技術選定の判断基準を整理する。

---

参考資料

• The 2026 State of GTM Engineering
• How Clay built the GTM engineering function
• Forward Deployed Engineer Guide 2026 - Rocketlane
• What world-class GTM looks like 2026 - Lenny's Podcast
• Vercel AI Sales Agent - Tomasz Tunguz
• GTM Engineer vs Other GTM Roles - Metaflow
• Do you need a GTM engineer? - Growth Unhinged
• Offers GTMエンジニア職種追加 - PR Times