FDEと普通のエンジニアの違いは？責任範囲・技術水準・移り方を実務比較
- one customer, many capabilities
- 単一顧客に深く入る
- 起点は顧客の課題発見・再定義
- 成果物は顧客現場で動く実装と定着
- 失敗＝動いていても現場で使われない
- one capability, many customers
- 多数の顧客・ユーザーに広く届ける
- 起点は与えられた仕様・要件
- 成果物は汎用プロダクトの機能
- 失敗＝仕様どおりに動かない
- 要件定義の会議に同席する実装者として作る前の議論に入り、課題の発見・再定義を経験する
- 顧客ヒアリングに立ち会う顧客の言葉と実際の課題のずれに触れ、顧客discoveryの感覚をつかむ
- リリース後の現場を確かめる使われているかを自分で確認し、現場での定着まで責任を持つ
FDEと普通のエンジニアの違いは？
FDEとSWEの違いは技術力の高低ではなく、価値を届ける向きにあります。SWEは多数の顧客へ広く届け、FDEは一顧客の中に深く入ります。
FDE（Forward Deployed Engineer）と通常のソフトウェアエンジニア（SWE）は、扱う技術や言語が重なります。違うのは仕事の起点と、価値の届け先です。「どちらの技術力が高いか」で比べると誤解が生まれます。「誰に、どの向きで価値を届けるか」で比べると整理しやすくなります。ここでは、その向きの違いと、FDEという職種が生まれた経緯を押さえます。
FDEとSWEでは価値の届け方がどう逆になる？
SWEは一つの機能を多数の顧客へ広げます。FDEは一顧客が抱える複数の課題を、次々と機能に変えていきます。
Palantirの一次定義では、通常のDev（SWE）は “one capability, many customers”、FDE（社内呼称Delta）は “one customer, many capabilities” と説明されています（Palantir公式ブログ）。
SWEは一つの機能を磨き上げ、多数の顧客・ユーザーへ広げることでスケールさせます。FDEは一顧客に張り付き、その顧客の課題を次々と実装していきます。「多数へ広く」と「一社に深く」。この向きの違いが、日々の判断基準の違いにもつながります。
| 観点 | FDE | 通常のSWE |
|---|---|---|
| 判断の物差し | この顧客の課題が実際に解けるか | この機能は多くの利用者にとって汎用的か |
| 優先するもの | 目の前の現場で成果が出ること | プロダクト全体の複雑さを増やさないこと |
| 起こりやすい見え方 | プロダクト側から「汎用性に欠ける」と見られやすい | 現場側から「使えない」と見られやすい |
同じ「良い実装」という言葉でも、FDEとSWEでは指す中身が違います。FDEが現場に合わせて書いた実装は、プロダクト側から見ると汎用性に欠けることがあります。SWEが汎用性を守るために削った要件は、現場から見ると使えないものに映ることがあります。どちらが正しいかではなく、担う向きが違うだけです。この前提を共有しておくと、同じ組織でFDEとSWEが働くときの摩擦も理解しやすくなります。
FDEはどこで生まれた職種？
FDEは2010年代前半にPalantirで生まれた職種です。2016年頃までは、通常のSWEより人数が多かったとされます。
FDEが2010年代前半にPalantirで生まれ、2016年頃までは通常のSWEより人数が多かったことは、The Pragmatic Engineerが報じています。
Palantirの顧客は政府機関や大企業で、要件が固まっていない難しい現場が中心でした。そのため、顧客の現場に深く入って課題をつかみ、その場で実装まで進める人材が事業の中核になりました。FDEという職種名はPalantirから広がり、近年はAnthropicなど他社の求人にも登場しています。
| 時期・出来事 | 内容 | 読み取れること |
|---|---|---|
| 2010年代前半 | PalantirでFDEが生まれる | 要件が固まらない現場に対応するための職種 |
| 2016年頃まで | FDEの人数が通常のSWEを上回る | 現場で課題を解くことが事業の主戦場だった |
| 近年 | Anthropicなど他社の求人にも登場 | Palantir以外にも職種として広がっている |
この経緯から、FDEは「顧客対応もするエンジニア」ではないとわかります。「要件が固まらない現場で成果を出すための職種」です。要件が最初から明確なら、エンジニアを顧客の現場に張り付ける必要はありません。仕様が決まらないまま前に進む必要があったから、課題の発見から実装までを一人が通して担う形になりました。FDEの人数がSWEを上回っていたことも、Palantirの事業構造からFDEという職種が生まれたことを裏づけています。
責任範囲はどこが違う？
FDEの責任は顧客の成果まで及びます。与えられた仕様を実装すれば完了するSWEより、一段広い範囲を担う職種です。
仕事の起点も、成果物も、失敗の定義もSWEとは異なります。表で比べると違いがはっきりします。
FDEとSWEの責任範囲を表で比較すると？
起点・成果物・失敗の定義・仕事の区切りで比べると、FDEはSWEより前の段階から始まり、後の段階で終わります。
FDEは、顧客の課題を見つけて定義し直すところから入ります。顧客の現場で実装が動き、定着するまでがFDEの担当です。SWEは、与えられた仕様や要件をもとに汎用プロダクトの機能を作ります。
| 観点 | FDE | 通常のSWE |
|---|---|---|
| 対象 | 単一顧客に深く入る | 多数の顧客/ユーザーに広く |
| 起点 | 顧客の課題発見・再定義 | 与えられた仕様・要件 |
| 成果物 | 顧客現場で動く実装・定着 | 汎用プロダクトの機能 |
| 求められる力 | 実装＋顧客折衝＋ドメイン理解 | 実装・設計 |
| 失敗の定義 | 動いていても現場で使われない | 仕様どおりに動かない |
| 仕事の区切り | 顧客の現場で成果が出たとき | コードがマージ・リリースされたとき |
| 例えるなら | スタートアップCTO的 | 機能開発の専門家 |
特に違いが大きいのは「起点」と「失敗の定義」の行です。SWEは、仕様が与えられた状態から仕事を始めます。FDEは「そもそも何を作るべきか」を顧客と一緒に探すところから始めます。そのため、FDEには実装・設計の力に加えて、顧客折衝とドメイン理解も求められます。
SWEにとっての失敗は、仕様どおりに動かない実装です。FDEにとっての失敗は、仕様どおりに動いていても現場で使われない状態です。SWEの仕事はリリースで区切れますが、FDEの仕事は現場で成果が出るまで終わりません。FDEにとっての「完了」は、SWEより一段先にあります。
FDEが「スタートアップCTO的」と言われる理由は？
FDEは課題の定義から実装、定着までを少人数で丸ごと引き受け、判断も自分で下すため、CTOに近い役割と言われます。
Palantirでは、FDEは少人数のチームで難しい案件をend-to-endで受け持つ、スタートアップCTOに近い役割と位置づけられています（The Pragmatic Engineer）。
「CTO的」が指すのは、肩書きの高さではなく意思決定の範囲です。FDEは次のような判断を上流の誰かに任せず、自分で下します。
- 何を作らないかを決める
- 優先順位を組み替える
- 技術的な妥協をどこまで許すかを判断する
裁量が大きい分、判断を誤ったときの影響も自分に返ってきます。仕様が妥当かどうかを保証してくれる人はいません。判断の根拠は、自分が現場で確かめた事実です。FDEに顧客折衝とドメイン理解が求められるのは、その根拠を自分で集める必要があるからです。責任範囲の広さと権限の広さは、セットになっています。
FDEに求められる技術水準は？
FDEにはSWEと同じ水準の実装力が前提として求められ、その上に顧客対応力を重ねます。技術水準が下がる職種ではありません。
「技術が苦手でも、顧客対応が得意ならFDEは務まる」というのはよくある誤解です。求人の要件を見ると、実装力が土台になっていることがわかります。
AnthropicのFDE求人は何を要件にしている？
AnthropicのFDE求人は、Pythonでの高い実装力を土台に、LLMの本番運用経験とhigh agencyを要件に重ねています。
AnthropicのFDE求人には、次の要件が挙げられています（Anthropic公式求人）。
- Pythonでの高い実装力
- LLMの本番運用経験（高度なプロンプト設計やエージェント開発）
- 曖昧さの中を進むhigh agency
- 顧客とのdiscovery能力
これらは技術力の代わりではなく、技術力の上に積み上がる要件です。三層に分けると次のようになります。
| 層 | 要件 | 位置づけ |
|---|---|---|
| 第3層 | 曖昧さの中を進むhigh agency・顧客discovery | 土台の上に乗る要件 |
| 第2層 | LLMの本番運用経験（プロンプト設計・エージェント開発） | 実装力があって初めて機能する |
| 第1層 | Pythonでの高い実装力 | すべての前提となる土台 |
求人票に顧客discoveryの項目があっても、実装力の要件がなくなるわけではありません。FDEは、SWEとしての技術水準を満たしたうえで、顧客対応の力も求められる職種です。
FDEはコードを書く職種なのか？
FDEはコードを書く職種です。ワークフローを自分で設計・実装・テストし、顧客のシステム上で本番アプリを作ります。
FDEの仕事は、打ち合わせや折衝だけではありません。顧客の課題をつかんだら、それを解くワークフローを自分で設計・実装・テストし、顧客のシステム上で動く本番アプリケーションに仕上げます。顧客折衝やドメイン理解は、「何を作るか」を正しく決めるための手段です。中心にあるのは、コードを書く仕事です。
「聞く」人と「作る」人が別だと、現場で得た感触の一部は、要件定義書にまとめる途中で抜け落ちます。FDEは両方を一人で担うことで、この抜け落ちを防ぎます。顧客の反応を受けて、その場で実装を直すこともできます。実装力があるからこそ、現場での対話が成果につながります。
SWEからFDEへ移るには？
SWEの実装経験は、そのままFDEの土台になります。顧客と一緒に何を作るかを決める経験を足せば、FDEへ移れます。
ゼロからやり直す必要はありません。何が活きて、何が足りないかを分けて考えると、準備がしやすくなります。
SWEの経験はFDEでどう活きる？
FDEはSWEの実装力を土台にする職種です。プロダクト開発の経験は無駄にならず、前提条件として活きます。
前章で見たとおり、AnthropicのFDE求人でもPythonの高い実装力が要件になっています。機能を設計・実装・テストして本番に出す一連の作業は、SWEの現場ですでに経験しているものです。
つまり、FDEへの移行は技術を捨てて別の職種に移る「乗り換え」ではありません。今の技術の上に担当範囲を広げる「拡張」に近いものです。学ぶことを考えるときも、実装力は前提として残ると押さえておくと整理しやすくなります。
移行で足りないのはどの経験？
足りないのは技術ではなく、要件が固まる前から顧客と話し、成果まで責任を持つという「幅」の経験です。
SWEとFDEを実務で分けるのは、仕様を受け取る立場か、顧客と一緒に仕様を作る立場かです。要件が固まる前から顧客と話し、作るべきものを一緒に決める経験を積むと、FDEへの移行はスムーズになります。この経験は、今の職場でも積めます。
| 練習の場面 | 具体的な動き | FDEの仕事とのつながり |
|---|---|---|
| 作る前 | 要件定義の会議に実装者として同席する | 課題の発見・再定義 |
| 作る前 | 顧客やユーザーへのヒアリングに立ち会う | 顧客discovery |
| 作った後 | リリース後に現場で使われているかを自分で確かめる | 現場での定着まで責任を持つ |
ヒアリングに立ち会うと、顧客の言葉と実際の課題がずれる場面に何度も出会います。リリース後の現場を見に行くと、動く実装が使われないという状況を自分で経験できます。どちらもFDEにとっての失敗の定義に直結する感覚で、面接で話せる材料にもなります。
FDEをさらに深く知るにはどの記事を読む？
役割の全体像は「FDEとは」、キャリアの入り方は「FDEのキャリア」で解説しています。目的に合わせて読んでください。
FDEの全体像をさらに知りたい場合はFDEとはを、SWEからFDEへのキャリアの入り方を知りたい場合はFDEのキャリアをご覧ください。提案と実装の境界が気になる場合はFDEとコンサルの違いを、現場で効くスキルの優先順位はFDEに必要なスキルを参照してください。本記事で整理した「向きの違い」と「責任範囲の広さ」を前提に読むと、理解がつながりやすくなります。
姉妹メディアの関連記事
職種の違いを押さえると、AI人材の要件定義や選考設計も整理しやすくなります。採用側の視点は姉妹メディアで解説しています。
