GTMエンジニアの採用方法——求人設計から面接評価まで

GTMエンジニアを採用したいなら、まず「何を採ろうとしているか」を正確に定義するところから始める必要がある。GTMエンジニアは、営業企画でもSalesOpsでもデータエンジニアでもない。GTMエンジニアとはで定義した通り、営業プロセスの構造的理解と技術実装力の掛け算を持つ、新しいカテゴリの人材だ。

既存の職種定義をそのまま流用した求人票では、欲しい人材は集まらない。本記事では、GTMエンジニアの採用プロセスを「求人設計→候補者プールの構築→スキル評価→面接→オファー」の一連の流れで解説する。

なぜGTMエンジニアの採用は難しいのか

GTMエンジニアの採用が難しい理由は3つある。

第一に、職種自体の認知度が低い。 日本市場において「GTMエンジニア」という肩書きで求職活動をしている人はほぼいない。Gartnerの調査では、Revenue Operations関連の人材需要は2023年から2025年にかけて3倍以上に増加しているが、供給は需要の30%程度に留まっている。「GTMエンジニア 求人」と検索しても、まだまとまった情報は出てこないのが現状だ。

第二に、求めるスキルセットが二刀流である。 GTMエンジニアに必要なスキルセットで詳述したが、この職種にはCRM設計やAPI連携などの技術力と、営業プロセスの設計力という異なる領域の能力が同時に求められる。営業企画の経験者は技術力が足りず、エンジニアは営業ドメインの知見が足りない。両方を兼ね備えた人材はまだ市場にほとんどいない。

第三に、既存の職種分類に当てはまらない。 求人媒体の職種カテゴリには「GTMエンジニア」がない。「営業企画」に分類すればエンジニアが見つからず、「エンジニア」に分類すれば営業プロセスに興味のある人材が見つからない。SalesOpsとGTMエンジニアの違いを理解した上で、適切なポジショニングが必要になる。

求人票の設計——「何を採るか」を明確にする

GTMエンジニアの求人票では、具体性が全てだ。「営業DXの推進」のような曖昧な表現では、候補者は自分がフィットするか判断できない。以下の要素を明記する。

必須で書くべき項目

職務概要: 営業プロセス（リード獲得〜クロージング〜カスタマーサクセス）の技術基盤を設計・構築・運用する。CRMを中心としたデータアーキテクチャの設計、ツール間連携の実装、営業KPIのダッシュボード構築を担う。

具体的な業務内容例:

• CRM（HubSpot / Salesforce）のオブジェクト設計・パイプライン設計
• SQLによる営業データの抽出・分析・レポーティング
• API連携やn8n/Zapierを使ったワークフロー自動化の設計・実装
• リードスコアリングロジックの構築と運用
• LLM APIを活用した営業プロセスのAI化（商談要約、リード分類等）
• 営業チームとのコミュニケーション・要件定義

必須スキル（MUST）:

• CRMプラットフォーム（HubSpot / Salesforce）の設計・実装経験1年以上
• SQLでの営業データ分析経験
• REST APIの基本理解

歓迎スキル（WANT）:

• Python / TypeScriptでのスクリプティング経験
• 営業企画・営業推進の実務経験
• iPaaS（n8n / Zapier / Make）での自動化構築経験
• AI/LLM APIの活用経験

避けるべき書き方

求人票で以下のような表現を使うと、GTMエンジニアとしての人材は集まらない。

• 「営業DX推進担当」— 範囲が広すぎて何をするのか不明
• 「セールステック導入担当」— ツールの導入だけが仕事ではない
• 「SalesOps」— SalesOpsの限界で論じた通り、設計と実装を分離する思想はGTMエンジニアの対極にある
• 「年収応相談」— 相場が定まっていない職種だからこそ、レンジを明示することで本気度が伝わる

候補者プールの構築——どこで探すか

GTMエンジニアの候補者は、大きく4つのプールに分かれる。

プール1: 営業企画 × テクノロジー志向

営業企画や営業推進の経験者で、CRMの設計やデータ分析に強い関心を持つ層。GTMエンジニアになるにはで紹介した「営業企画からの転職ルート」に該当する人材だ。SQLやAPIの基礎は入社後にキャッチアップできるため、営業プロセスの深い理解があれば十分にポテンシャル採用の対象になる。

アプローチ方法: ビズリーチやLinkedInで「営業企画」「営業推進」「Revenue Operations」の経歴を持つ人材にスカウトを送る。求人タイトルは「営業プロセスエンジニア」や「Revenue Operationsエンジニア」のように、営業職との接点を感じさせるワーディングが有効。

プール2: SE・SIer × 営業ドメインへの関心

SE・SIer出身で、BtoB営業の領域に興味を持つ層。技術力は高いため、営業ドメインの理解を補えばすぐに戦力化できる。CRM導入プロジェクトやMA導入プロジェクトの経験者は特に親和性が高い。

アプローチ方法: 転職ドラフトやFindyなどエンジニア特化の媒体で「CRM」「SaaS連携」「営業データ」をキーワードに訴求。面談では「営業チームと直接対話しながらプロダクトを作る」というGTMエンジニアの魅力を伝える。

プール3: データエンジニア × ビジネスサイド志向

データエンジニアやデータアナリストで、ビジネスインパクトに直結する仕事を求めている層。SQLとPythonの実力は申し分ないため、営業プロセスの理解とCRM固有の設計パターンを学べば即戦力になる。

プール4: 社内異動

最も見落とされがちだが、実は最も効率の良い調達手段だ。営業企画部門の中で技術志向の強いメンバーに、6ヶ月の学習ロードマップを提供して社内育成する。自社の営業プロセスをすでに熟知しているため、外部採用よりも圧倒的に立ち上がりが早い。

スキル評価の設計——何をどう見極めるか

GTMエンジニアの選考では、「営業プロセスの理解」と「技術実装力」の両軸を評価する必要がある。どちらか一方だけを見ると、SalesOpsかエンジニアの焼き直しを採用してしまう。

評価マトリクス

評価軸	ジュニア合格ライン	ミドル合格ライン	シニア合格ライン
CRM設計	基本オブジェクトの理解	パイプライン設計を自走	複雑なカスタムオブジェクト設計
SQL	SELECT / JOIN / GROUP BY	サブクエリ・ウィンドウ関数	パフォーマンスチューニング
API連携	REST APIの基本理解	Webhook + iPaaSで自動化構築	カスタムインテグレーション開発
営業プロセス	ファネルの基本構造を説明可能	KPI設計・ボトルネック分析	GTM戦略全体の設計・実行
コミュニケーション	営業チームと要件を聞ける	要件定義を主導できる	経営陣への提案・交渉

技術テストの設計

書類選考を通過した候補者には、以下のような実技テストを課すことを推奨する。

課題例: 架空のBtoB SaaS企業（ARR 5億円、営業10名、リード月500件）のCRM設計とワークフロー自動化の提案書を作成してください。以下の要素を含めること。

• オブジェクト関連図とパイプラインステージの設計
• リードルーティングの自動化ロジック
• 営業チームに提供するダッシュボードのKPI設計

制限時間: 3日間（副業候補者に配慮し、十分な時間を確保する）

この課題は、技術力だけでなく「営業プロセスをどう構造化するか」という思考力を同時に評価できる。CRMデータ設計ガイドやリードスコアリング設計で解説した内容を、候補者がどの程度の深さで理解しているかが見える。

面接での見極めポイント

面接では、以下の3つの軸で候補者を評価する。

軸1: 課題発見力——「何を作るべきか」を見極められるか

GTMエンジニアの最大の価値は、営業チームが言語化できていない課題を発見し、技術で解決する力にある。面接では以下のような質問が有効だ。

• 「営業チームから『CRMが使いにくい』と言われたら、最初に何を確認しますか？」
• 「営業のリード対応速度を改善してほしいと依頼されました。どのようなデータを見て原因を特定しますか？」
• 「前職で、自分で課題を発見して改善した経験を教えてください」

優秀な候補者は、いきなり解決策を語るのではなく、「まず現状のデータを見る」「営業チームにヒアリングする」「ボトルネックを特定する」というプロセスを語れる。

軸2: 設計力——全体最適を考えられるか

個別のツール操作ができるだけでは不十分だ。GTMエンジニアのキャリアパスで示した通り、この職種にはリード獲得からクロージングまでの一気通貫の視点が求められる。

• 「CRMのパイプラインステージを設計するとき、何を基準にステージを分けますか？」
• 「マーケティングチームとの連携で、MQLの定義をどう設計しますか？」
• 「ツール選定で、HubSpotとSalesforceのどちらを推奨するか、判断基準を教えてください」

軸3: 対話力——営業チームと信頼関係を築けるか

どれだけ技術力が高くても、営業チームと円滑にコミュニケーションできなければGTMエンジニアとしては機能しない。この点は履歴書やスキルテストでは見えにくいため、面接で重点的に評価する。

• 「エンジニアではない営業メンバーに、技術的な制約をどう説明しますか？」
• 「営業チームがCRMにデータを入力してくれない場合、どうアプローチしますか？」

入力してくれない営業チームへのアプローチを問う質問は、候補者の営業現場への理解度を如実に表す。「入力を強制する」と答える候補者より、「入力負荷を下げる仕組みを作る」「入力することで営業自身にメリットがある設計にする」と答える候補者の方が、GTMエンジニアとしての適性が高い。

年収レンジとオファー設計

GTMエンジニアの報酬設計は、GTMエンジニアの年収のデータを踏まえつつ、自社の予算と市場競争力のバランスで決める。

レベル	年収レンジ（2026年目安）	想定経験
ジュニア	500万〜700万円	CRM設計1-2年、SQL基礎、営業組織での実務経験
ミドル	700万〜1,000万円	CRM設計3-5年、API連携・自動化構築の実績複数
シニア	1,000万〜1,500万円	GTM戦略の設計・実行、チームマネジメント経験

注意すべきは、GTMエンジニアの市場価値は急速に上昇しているということだ。McKinsey & Companyの分析によれば、Revenue Operations人材の報酬は過去2年で平均15%上昇しており、この傾向は当面続く。低い年収で採用しようとすると、優秀層は他社やフリーランスに流れてしまう。

オファー時には年収だけでなく、以下の要素も提示すると競争力が上がる。

• テクノロジー投資の自由度: 新しいツールの導入権限やPoCの予算
• 営業チームとの直接的な接点: 間接部門ではなく営業組織のコアメンバーとしてのポジション
• スキルアップ支援: カンファレンス参加費、資格取得補助、学習時間の確保

採用後のオンボーディング設計

採用は内定承諾で終わりではない。GTMエンジニアのオンボーディングには、通常のエンジニア職とは異なる配慮が必要だ。

最初の2週間: 営業チームの商談に同席させる。技術出身の人材は特に、営業の現場感覚を掴むことが最優先。CRMのデータを触るだけでは見えない「営業の温度感」を体で理解してもらう。

1ヶ月目: 既存のCRM・ツール環境のアーキテクチャを把握させる。ドキュメントがなければ、本人にアーキテクチャ図を書いてもらうのが最も効率的だ。書く過程で課題が見つかる。

2-3ヶ月目: 小さな改善プロジェクトを1本任せる。リード通知の自動化、レポートの自動生成など、1-2週間で完結するスコープのタスクが最適。成果が出れば営業チームからの信頼が得られ、以降の大きなプロジェクトが進めやすくなる。

GTMエンジニアの採用は、単なる「人を増やす」行為ではない。営業組織の技術基盤を誰が設計・運用するかという、事業戦略上の意思決定だ。求人票の精度、評価基準の設計、面接での見極め——全てのプロセスで「営業プロセスの理解×技術実装力」という二軸を意識し続けることが、採用成功の鍵になる。