仕上げは AI との協働でやっています。事実と表現は著者本人が確認しています。
スタートアップ界隈で FDE (Forward Deployed Engineer) と GTM (Go-To-Market) エンジニアという呼称を目にする機会が増えた。どちらも「客先に張り付いて動くエンジニア」を指すように見えるが、よく聞くと役割が違う。
両方とも日本ではまだ職種としての輪郭が薄く、求人票では「ソリューションエンジニア」「カスタマーサクセスエンジニア」「セールスエンジニア」あたりにまとめられがちで、結果として候補者と企業の期待がすれ違う場面がある。今回はこの2つの違いを、起源と役割の差から整理する。
起源の違い
両者は同じ「客先に出るエンジニア」でも、生まれた文脈が違う。
| 項目 | FDE | GTM Engineer |
|---|---|---|
| モデルの確立 | Palantir Technologies | Clay 周辺で 2023 年頃から呼称が定着・Stripe / Vercel 等の求人で採用 |
| 主な所属 | プロダクト組織または専門部隊 | 営業組織 (GTM team) |
| 報酬構造 | 基本給ベース (エンジニア準拠) | 営業 OTE (基本給 + Variable) に近い |
| 評価軸 | 顧客の課題解決完了率・実装品質 | パイプライン貢献・受注金額 |
| 主な接点 | エンドユーザー (現場担当者) | 意思決定者 (CTO / VPoE) + 開発者 |
「Forward Deployed」という語自体は前線派遣を意味する軍事用語が由来だが、これをエンジニアの働き方として確立・普及させたのが Palantir だ。「機密データを扱う顧客に対して、コンサルではなくエンジニアを派遣する」というモデルで、現場での実装が主戦場になる。一方の GTM Engineer は SaaS の self-serve モデルが頭打ちになった時期に「営業プロセスにエンジニアリングを組み込む」必要から生まれた職種で、呼称としては 2023 年頃から Clay 周辺で広まり、Stripe・Vercel・Ramp などのスタートアップ求人で採用されたことで定着していった。Demo 構築・PoC 実装・統合事例の量産が主戦場になる。
両者が「客先に張り付くエンジニア」と一括りにされる理由は、どちらも 製品をそのまま売るのではなく、顧客の文脈に合わせて変形させる という共通点を持つから。違いは「何を変形させるか」と「誰に対して責任を持つか」にある。
FDE の仕事の中身
FDE が日々やっていることを Palantir 系の元従業員ブログから読み解くと、ざっくり以下の流れになる。
[顧客のオフィスに常駐 or 高頻度訪問]
↓
顧客固有のデータパイプラインを実装
↓
顧客固有のダッシュボード / アラート / ワークフローを構築
↓
顧客チームに使い方をレクチャー + 運用引き継ぎ
↓
新しい要望を吸い上げて、製品本体のロードマップに反映
特徴的なのは 「製品本体に反映する」フィードバックループを持っていること。一般的な SI ベンダーは「顧客 A 向けにカスタマイズ → 終わり」で完結するが、FDE は顧客 A での発見を製品チームに戻して、次の顧客 B が同じ課題を踏まないようにする。これが Palantir が「コンサルではなくエンジニアの会社」と自称する根拠になっている。
GitHub の awesome-fde 系リポジトリや、元 Palantir エンジニアの note を読むと、FDE は 「目の前の顧客の課題」と「製品の汎用性」を両立させる中間管理職的な動き を要求される、と書かれていることが多い。技術力だけでなく、顧客の業務理解と社内交渉が同程度に効く職種。
GTM Engineer の仕事の中身
GTM Engineer は営業組織に紐づくため、KPI が営業寄りになる。
[Sales が引いてきた商談]
↓
顧客の技術スタックに合わせた Demo を構築
↓
PoC (Proof of Concept) 実装 — 数日〜数週間
↓
契約後の初期統合 (Onboarding) をリード
↓
営業に「次に売れる構成」「事例として打ち出せる構成」をフィードバック
FDE が「契約後・運用フェーズ」が長いのに対して、GTM Engineer は 「契約前・検討フェーズ」での技術的な引っかかりを取り除く ことに比重が置かれる。Stripe や Vercel など GTM Engineer を採用する企業の求人を見ると、「Demo 1本の品質が受注を左右する」「セールスサイクルを短縮する」という言葉が頻繁に出てくる。
報酬構造が営業寄り (Variable が大きい) のは、KPI が「受注に効いたか」で測られるため。エンジニアとしての実装力よりも、短時間で動く Demo を作る力 + 顧客の技術判断者と対話する力 の比重が高い。
どちらが向いているか
職種選択の話に落とすと、選び方は以下の3問で判定できる。
問い1: 1人の顧客と何ヶ月付き合えるか?
- 半年〜数年付き合いたい → FDE
- 数週間〜数ヶ月で次の顧客に移りたい → GTM
FDE は顧客の業務に深く入り込むため、同じ顧客と長く付き合う。GTM は商談数をこなすため、1顧客あたりの時間は短い。
問い2: 製品本体に手を入れる責任を持ちたいか?
- 顧客からの発見を製品 PR にしたい → FDE
- 顧客対応に集中したい (製品は別チーム責任) → GTM
FDE は製品チームとの境界が曖昧で、自分の書いたコードが製品本体にマージされることもある。GTM は基本的に製品本体は触らず、Demo・統合コードに留まる。
問い3: 報酬の Variable をどう感じるか?
- 安定した基本給を重視 → FDE
- 営業成果に応じた Variable を歓迎 → GTM
GTM は OTE (On-Target Earnings) のうち Variable が 20-35% 程度を占めるのが一般的で、シニアやエンタープライズ寄りのロールではさらに比率が上がることもある。受注に貢献すれば年収が跳ねるが、外せば下がる。FDE は基本給ベースで予測可能。
日本での扱われ方の現状
日本のスタートアップ求人を見ると、FDE / GTM Engineer という呼称はまだ少数派で、似た役割が以下のラベルで募集されている。
- 「ソリューションエンジニア」: FDE 寄り (実装ガッツリ)
- 「セールスエンジニア」: GTM Engineer 寄り (Demo + PoC)
- 「カスタマーサクセスエンジニア」: FDE と CSM の混合
- 「テクニカルアカウントマネージャー (TAM)」: 既存顧客向け FDE
日本だと「営業と開発の中間」という職種は受け入れられづらく、開発キャリアの本流とは見られにくい (= 評価制度がエンジニア組織の本流に乗っていないケースが多い) というのが現状の課題になっている。一方で、AI/SaaS の伸びに伴って「現場に出るエンジニア」のニーズは高まっているため、今後 FDE / GTM Engineer という呼称が浸透していく可能性はある。
候補者として声がかかった時の確認事項
求人で「FDE」「GTM Engineer」「ソリューションエンジニア」と書かれていたら、面接の前に以下を確認するのが安全。
| 確認項目 | 質問例 |
|---|---|
| 評価制度 | エンジニア組織と営業組織のどちらの評価レンジに乗るか |
| 報酬構造 | Variable の比率は何% か / OTE と Base の比率 |
| 製品本体への寄与 | 顧客対応で見つけた課題を製品 PR にする経路はあるか |
| 顧客対応の長さ | 1顧客あたり平均何ヶ月か |
| 出張・常駐の頻度 | 月何日くらい客先か |
求人タイトルだけで判断すると、入ってから「FDE と聞いて入ったのに、実態は GTM Engineer (受注インセンティブ強め) だった」「逆もまた然り」が起きうる。