GTMエンジニアチームの立ち上げ方——1人目の採用から3人チームまで

GTMエンジニアチームの立ち上げで最も重要なのは、1人目の人選だ。この1人が、組織のGTMエンジニアリング文化を定義し、2人目以降の採用基準を決め、営業チームとの信頼関係の土台を作る。逆に言えば、1人目を間違えると、チーム全体の立ち上がりが1年以上遅れる。

本記事では、GTMエンジニアとはで定義したこの職種を、0人の状態から3人チームに育てるまでの実践的なロードマップを解説する。各フェーズで「何を優先し、何を捨てるか」の判断基準を明確にしていく。

なぜ「チーム」が必要なのか——1人の限界

まず前提として、GTMエンジニアは1人で十分に価値を出せる職種だ。CRM設計、ワークフロー自動化、データ分析基盤の構築——これらを1人で回しているGTMエンジニアは米国でも珍しくない。では、なぜチームを組む必要があるのか。

理由は3つある。

第一に、営業組織の規模拡大に伴うオペレーション負荷の増大。 営業10名の組織と50名の組織では、CRMの複雑性、データ品質の維持コスト、ワークフローの分岐条件が指数関数的に増える。1人のGTMエンジニアが対応できる営業組織の規模には上限があり、それはおおよそ営業20〜30名だ。

第二に、「設計」と「運用」の分離が必要になるタイミングが来る。 初期は同じ人間が新しいワークフローを設計し、日常のデータクレンジングも行い、営業チームからの問い合わせにも対応する。しかし運用タスクが増えると、設計に割ける時間がゼロになり、改善が止まる。SalesOpsの限界で論じた「運用に飲まれて戦略が消える」現象が、GTMエンジニアにも起こりうる。

第三に、スキルセットの幅が広すぎる。 GTMエンジニアに必要なスキルセットで整理した通り、この職種には営業企画力、データ設計力、技術実装力、AI活用力の4領域が求められる。全領域をシニアレベルでカバーできる人材は極めて稀であり、チームで補完し合う方が現実的だ。

フェーズ1: 1人目の採用——「誰を採るか」が全てを決める

1人目のGTMエンジニアは、チームの基盤を作る人材だ。GTMエンジニアの採用方法で詳述した通り、この職種の採用は難易度が高い。だからこそ、1人目の採用基準を明確にしておく必要がある。

1人目に求めるべきプロファイル

1人目は「フルスタック型」であるべきだ。CRM設計からAPI連携、営業チームとのコミュニケーションまで、80点レベルで幅広くこなせる人材が理想になる。特定の技術に深い専門性を持つスペシャリストよりも、営業プロセス全体を俯瞰できるジェネラリストの方が、この段階では価値が高い。

具体的に最も重視すべき能力は以下の3つだ。

1. 営業チームとの対話力: 営業メンバーが言語化できていない課題を引き出し、技術で解決できる形に翻訳する力。これがないと、どれだけ技術力があっても営業組織に受け入れられない
2. 課題発見力: 「CRMが使いにくい」という漠然とした不満から、「リードのルーティングロジックに問題がある」という具体的な課題を特定する力
3. CRM設計の実務経験: HubSpotまたはSalesforceで、オブジェクト設計からパイプライン設計まで一通り経験していること。CRMデータ設計ガイドの内容を自ら実行できるレベルが最低ラインだ

1人目の配置と権限設計

1人目のGTMエンジニアは、営業VP（またはCRO）の直轄に配置する。IT部門への配置は推奨しない。理由は単純で、営業チームとの物理的・組織的な距離が遠いと、課題のキャッチアップが遅れるからだ。

権限面では、以下を初日から付与する。

• CRM（HubSpot / Salesforce）の管理者権限
• iPaaSツール（n8n / Zapier）のアカウントと構築権限
• 営業ダッシュボードの編集権限
• 営業定例会議への参加権（発言権付き）

「まず様子を見てから権限を渡す」というアプローチは、GTMエンジニアの立ち上がりを致命的に遅らせる。権限がなければ課題の調査すらできない。

1人目の最初の90日

入社後90日間のロードマップを事前に設計しておく。

Day 1-14: 営業チームの商談に同席し、営業プロセスの実態を把握する。CRMの現状をアーキテクチャ図に起こし、課題の仮説リストを作成する。

Day 15-30: 課題リストから最もインパクトが大きく、かつ1-2週間で完結するプロジェクトを1本選び、実行する。リード通知の自動化、レポートの自動生成、パイプラインの再設計など。この「クイックウィン」で営業チームの信頼を獲得する。

Day 31-90: 中期的な改善ロードマップを策定し、営業VPに提案する。ここで「2人目が必要になるタイミング」の見通しも含めて提示できると理想的だ。

フェーズ2: 2人目の採用——「補完」の設計

1人目のGTMエンジニアが成果を出し始めると、次の課題が見えてくる。「やりたいことは山ほどあるが、手が足りない」——これが2人目を採用するシグナルだ。

2人目を採用すべきタイミング

以下の3つの兆候のうち、2つ以上が当てはまれば2人目の採用を開始すべきだ。

1. 運用タスクが週の50%以上を占めている: データクレンジング、ワークフローの修正、営業チームからの問い合わせ対応に時間を取られ、新しい施策の設計・実装に着手できない
2. 営業チームから「あれもこれも」の要望が増えている: 1人目の成果が認知され、営業チームからの依頼が処理能力を超え始めている。これは良いサインだが、放置するとバックログが溜まり信頼を失う
3. 新しい営業チャネルやプロダクトラインの追加が決まっている: 事業拡大に伴い、既存の営業プロセスでは対応できない新たな設計が必要になる

2人目のプロファイル——1人目の「逆」を採る

2人目の採用で最も避けるべきは、1人目と同じタイプの人材を採ることだ。2人目は「補完型」でなければならない。

1人目が営業企画出身のジェネラリストであれば、2人目はデータエンジニアリングやAPI連携に強いテクニカル志向の人材を採る。逆に、1人目がエンジニア出身であれば、2人目は営業プロセス設計やKPI分析に強い人材を採る。

1人目のタイプ	2人目に採るべきタイプ	補完される領域
営業企画出身・ジェネラリスト	データエンジニア・テクニカリスト	データパイプライン、カスタム開発、AI実装
エンジニア出身・テクニカリスト	営業企画出身・ビジネスサイド	営業チームとの対話、KPI設計、施策企画
CRM専門家	自動化・インテグレーション専門家	ワークフロー設計、ツール間連携、API戦略

2人目の役割定義

2人目が入った時点で、役割分担を明文化する。暗黙の分担は必ず衝突を生む。

推奨する分担モデルは以下の2パターンだ。

パターンA: 設計/運用分離型

• 1人目（リード）: 新規プロジェクトの設計・実装、営業VPへのレポーティング、ロードマップ策定
• 2人目: 既存ワークフローの運用・改善、データ品質の維持、営業チームからの問い合わせ対応

パターンB: ドメイン分離型

• 1人目: インバウンド営業プロセス（リード獲得〜MQL〜SQL）
• 2人目: アウトバウンド営業プロセス＋カスタマーサクセス連携

どちらを選ぶかは、営業組織の構造と課題に依存する。インバウンドとアウトバウンドで営業プロセスが大きく異なる場合はパターンB、営業プロセスは統一されているが運用負荷が高い場合はパターンAが適している。

フェーズ3: 3人目の採用——専門分化と組織化

3人チームは、GTMエンジニアリングが「個人の努力」から「組織の機能」に変わる転換点だ。このフェーズでは、チームとしてのケイパビリティを設計する必要がある。

3人目を採用すべき組織規模の目安

3人チームが投資対効果に見合うのは、おおよそ以下の規模だ。

• 営業組織: 50名以上
• ARR: 5億円前後
• CRM上のアクティブなワークフロー: 30本以上
• 連携ツール数: 10以上

これ以下の規模で3人を抱えると、GTMエンジニア1人あたりのROIが下がり、経営陣からの投資正当化が難しくなる。

3人チームの役割設計

3人チームでは、以下の3つの専門領域に分化させるのが最も効率的だ。

1. GTMアーキテクト（リード）

• CRM・データ基盤の全体設計
• 技術ロードマップの策定
• 営業VP/CROへのレポーティング
• チームマネジメント

2. インテグレーションエンジニア

• API連携・ワークフロー自動化の設計・実装
• ノーコード自動化ツールの運用
• 新ツールの評価・導入
• 営業プロセスの自動化の推進

3. データ/AIエンジニア

• データパイプラインの構築・運用
• リードスコアリングのモデル設計
• ダッシュボード・レポーティング基盤
• AI活用による営業プロセスの高度化

この3人が機能すると、営業組織は「データに基づく意思決定」「自動化されたオペレーション」「AIによる予測と最適化」の3つの武器を同時に手に入れることになる。

チーム運営のフレームワーク

3人チームを機能させるために、以下の運営ルールを導入する。

週次スプリント: 月曜に今週の優先タスクを3人で合意し、金曜に成果をレビューする。営業チームの要望は全てバックログに入れ、スプリント計画でトリアージする。場当たり的な対応は品質を下げる。

営業チームとの定例: 週1回、営業マネージャーとの定例を設け、「何が困っているか」「今週何が変わったか」を共有する。GTMエンジニアチームが営業現場から離れた瞬間に、チームの価値は急落する。

ドキュメンテーション: CRMの設計思想、ワークフローの一覧、データモデルのER図、ツール間連携の構成図——これらを常に最新化する。3人チームになると「あの設定は誰が作ったんだっけ」という属人化リスクが顕在化する。

よくある失敗パターンと回避策

GTMエンジニアチームの立ち上げで繰り返し見られる失敗パターンがある。事前に知っておくことで回避できる。

失敗1: 「ツール導入」から始めてしまう

GTMエンジニアチームの立ち上げを「CRM導入プロジェクト」と同義に扱うケースだ。ツールはあくまで手段であり、営業プロセスの構造化が先にないと、導入したCRMが半年で形骸化する。1人目のGTMエンジニアには、まず営業プロセスの現状把握と課題特定から始めさせる。

失敗2: 1人目をIT部門に配置してしまう

前述の通り、GTMエンジニアをIT部門に配置すると営業現場との距離が生まれる。IT部門の優先順位は全社システムの安定運用であり、営業プロセスの改善は後回しにされがちだ。

失敗3: 2人目を「1人目の分身」として採用する

同じスキルプロファイルの人材を2人採ると、得意領域が重複して不得意領域が放置される。GTMエンジニアに必要なスキルセットの4領域マップを使い、1人目がカバーできていない領域を特定した上で2人目のプロファイルを決める。

失敗4: 採用を急ぎすぎる

「営業DXを加速したい」という経営層の期待に押されて、1人目が成果を出す前に2人目を採用してしまうパターンだ。1人目が営業チームの信頼を獲得し、改善の実績を積んでからでないと、2人目の受け入れ体制が整わない。焦りは最大の敵だ。

3人の先——スケーリングの判断基準

3人チームが安定稼働した後、さらに拡大するかどうかの判断基準にも触れておく。

4人目以降を検討する条件:

• 営業組織が100名を超え、複数のプロダクトライン/地域を持つ場合
• GTMエンジニアリングの対象がカスタマーサクセスやマーケティングオペレーションに拡張される場合
• データ基盤が複雑化し、専任のデータエンジニアが必要になった場合

この段階では、GTMエンジニアチームは「Revenue Operations」部門として組織化されるのが一般的だ。RevOpsとGTMエンジニアの違いで解説した通り、RevOpsは上位概念であり、GTMエンジニアチームはその実行部隊として位置づけられる。

大切なのは、人数を増やすこと自体を目的にしないことだ。GTMエンジニアリングの価値は「営業プロセスの改善速度」であり、人数ではない。3人で十分な改善速度が維持できているなら、無理に拡大する必要はない。ツールの進化、特にAIによる自動化の進展は、少人数チームの生産性を飛躍的に高めている。自社の営業組織の規模と課題に合わせて、最適なチームサイズを見極めてほしい。