GTMエンジニアになるには？
職種別ロードマップと学習ガイド

前提: GTMエンジニアとは

GTM（Go-To-Market）エンジニアは、企業の収益パイプラインを技術で設計・構築するエンジニアだ。プロダクトのコードではなく、営業・マーケ・CSを横断する自動化基盤を作る。詳しくは「GTMエンジニアとは何か」を参照してほしい。

この記事では「GTMエンジニアが何者かは理解した。で、どうやってなるのか？」に答える。

3つの入口 — あなたはどこから来たか

GTMエンジニアへのルートは出身職種によって大きく異なる。すでに持っているスキルによって、補うべき領域と所要時間が変わる。

パターンA: ソフトウェアエンジニアからの転身

パターンB: Sales Ops / RevOps からの転身

パターンC: SDR / 営業からの転身

6ヶ月ロードマップ

以下は、ソフトウェアエンジニア経験者を基準にした6ヶ月のロードマップだ。Sales Ops出身なら前半を短縮でき、SDR出身なら前半を延長する。

Clayに依存しないリードスコアリングの設計

GTMエンジニアリングの記事を読むと「Clay」が頻出する。Clayは優れたツールだが、Clayがなければスコアリングできない、という状態は設計として脆い。料金改定、API制限、サービス終了のリスクがある。特定ツールへのロックインを避け、自分でスコアリングの仕組みを構築できることがGTMエンジニアの本質的な価値だ。

アプローチ1: SQL + CRMデータで自前スコアリング

最もシンプルで堅牢なアプローチ。CRM（HubSpot / Salesforce）に蓄積されたデータだけで、リードの優先度を判定する。

-- CRMデータから過去の受注パターンを分析し、スコアを算出
SELECT
  contact_id,
  company_name,
  -- 属性スコア（Firmographic）
  CASE
    WHEN employee_count BETWEEN 50 AND 500 THEN 30
    WHEN employee_count > 500 THEN 20
    ELSE 10
  END
  -- 行動スコア（Behavioral）
  + CASE WHEN pricing_page_views > 0 THEN 25 ELSE 0 END
  + CASE WHEN demo_requested = true THEN 40 ELSE 0 END
  + CASE WHEN email_opened_count >= 3 THEN 15 ELSE 0 END
  AS lead_score
FROM contacts
WHERE lifecycle_stage = 'lead'
ORDER BY lead_score DESC;

ポイントは属性スコア（その企業はターゲットか）と行動スコア（興味を示しているか）の2軸で判定すること。この設計はClay有無に関係なく適用できる。

アプローチ2: n8n + 外部API で無料エンリッチメント

Clayの代わりに、無料または低コストのAPIを組み合わせてエンリッチメントを自前構築する。

アプローチ3: LLMベースの動的スコアリング

ルールベースのスコアリング（if文の塊）には限界がある。条件が増えるほどメンテナンスが困難になる。LLMを使えば、自然言語でICP（理想顧客像）を定義し、各リードをその定義に照合するアプローチが取れる。

import anthropic

client = anthropic.Anthropic()

icp_definition = """
理想顧客像（ICP）:
- 従業員数 50-500名の B2B SaaS企業
- シリーズA以降の資金調達済み
- CRM（HubSpot or Salesforce）を導入済み
- 営業チームが5名以上
- 直近6ヶ月以内に営業関連の求人を出している
"""

def score_lead(lead_data: dict) -> dict:
    response = client.messages.create(
        model="claude-sonnet-4-5-20250514",
        max_tokens=500,
        messages=[{
            "role": "user",
            "content": f"""
以下のICP定義に対して、このリードの適合度を0-100で評価してください。
スコアと理由をJSON形式で返してください。

ICP定義:
{icp_definition}

リード情報:
{lead_data}

出力形式: {{"score": 数値, "reason": "理由", "next_action": "推奨アクション"}}
"""
        }]
    )
    return json.loads(response.content[0].text)

このアプローチの利点はICPの定義を自然言語で更新できること。営業チームが「最近、製造業のリードが好調」と言えば、ICP定義を1行書き換えるだけでスコアリングロジックが変わる。if文を修正する必要がない。

どのアプローチを選ぶか

学習リソース一覧

無料リソース

有料リソース

ポートフォリオの作り方

GTMエンジニアの転職・副業で最も重視されるのは「何を構築し、どんな成果を出したか」だ。資格よりもポートフォリオが語る。

載せるべき内容

1. 課題 — どんなビジネス上のペインポイントがあったか
2. 設計 — どんなワークフローを設計したか（図解付き）
3. ツールスタック — 使用したツールとその選定理由
4. 実装 — コードやワークフローのスクリーンショット
5. 成果 — Before/Afterの定量データ（時間削減、転換率改善、コスト削減）

面接で聞かれること

GTMエンジニアの面接は、技術面接とビジネスケースの両方が問われる。以下は頻出の質問と準備のポイント。

「エンジニアか、営業か」ではなく「両方」

GTMエンジニアは「エンジニアが営業をやる」仕事ではない。「営業の仕組みをエンジニアリングする」仕事だ。

コードを書いたことがある人なら、このキャリアパスは想像以上に近い。社内ツールやSlack Botを作った経験、CRMのデータを整理してダッシュボードを作った経験、営業チームのために「ちょっとしたスクリプト」を書いた経験。それらはすべて、GTMエンジニアリングの延長線上にある。

違いは、それを体系的・戦略的に行い、収益への直接的なインパクトを測定するという点だけだ。