FDEと普通のエンジニアの違いは？責任範囲・技術水準・移行手順を実務で解説

FDEと普通のエンジニアの違いは？

通常のエンジニアは一機能を多数の顧客へ届け、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は、目の前の一顧客に張り付き、その顧客が抱える複数の課題を次々と機能として実装していきます。どちらもコードを書く職種ですが、SWEが「多数へ広く」なら、FDEは「一社に深く」入るという違いが起点になります。

この向きの差は、日々の判断基準にも表れます。SWEが機能を設計するときの物差しは「この機能は多くの利用者にとって汎用的か」です。特定の一社だけに都合のよい実装は、プロダクト全体の複雑さを増やすため避けられます。一方でFDEの物差しは「この顧客の課題が実際に解けるか」です。汎用性よりも、目の前の現場で成果が出るかどうかが優先されます。同じ「良い実装」という言葉を使っていても、指している中身が違うわけです。

判断の物差しが違えば、良し悪しの評価も食い違います。FDEが顧客の現場に合わせて書いた実装は、プロダクト側の視点からは「汎用性に欠ける」と見えることがあります。逆にSWEが汎用性を守るために切り落とした要件は、現場側からは「使えない」と映ることがあります。どちらかが間違っているのではなく、担っている向きが違うだけです。この前提を共有しておくと、FDEとSWEが同じ組織にいるときの摩擦も理解しやすくなります。

FDEはどこで生まれた職種？

FDEはPalantirで2010年代前半に生まれ、2016年頃までは通常のSWEより人数が多かったとされます。

FDEはこの職種の発祥であるPalantirで2010年代前半に生まれ、2016年頃までは通常のSWEより数が多かったと報じられています（The Pragmatic Engineer）。

Palantirは政府機関や大企業といった、要件が固まっていない難易度の高い現場へソフトウェアを届ける必要がありました。そのため、顧客の現場に深く入り込んで課題を捉え、その場で実装まで持っていく人材が中核になった、という背景があります。FDEという役割名がPalantir起点で広がり、近年はAnthropicなど他社の求人でも見られるようになっています。

出自を押さえておくと、FDEが「顧客対応もするエンジニア」ではなく「要件が固まらない現場で成果を出すための職種」だと理解しやすくなります。要件が最初から明確な案件であれば、わざわざ人を顧客の現場に張り付ける必要はありません。仕様が固まらないまま前へ進めなければならない領域だったからこそ、課題の発見と実装を一人が地続きで担う形が選ばれた、という順序です。この順序を取り違えると、FDEを「営業に近いエンジニア」と誤読することになります。

FDEの人数が通常のSWEを上回っていたという事実も、この順序を裏づけます。もし現場対応が補助的な役割であれば、プロダクトを作るSWEのほうが多いのが自然です。逆になっていたということは、顧客の現場で課題を解く行為そのものが事業の主戦場だったことを意味します。FDEを「例外的な人員配置」ではなく「その事業構造が必然的に要求した職種」として捉えるべき理由がここにあります。

責任範囲はどこが違う？

FDEの責任は顧客の成果まで及び、与えられた仕様の実装で完了するSWEより範囲が一段広くなります。 起点も成果物も、SWEとは異なります。

FDEとSWEの責任範囲を表で比較すると？

対象・起点・成果物・求められる力の4観点で並べると、FDEとSWEの差がはっきり見えます。

FDEは課題の発見・再定義から入り、顧客現場で動く実装と定着までを担います。一方SWEは、与えられた仕様や要件をもとに汎用プロダクトの機能を作り込みます。両者の違いを観点ごとに並べると、次のように整理できます。

表の「起点」と「成果物」に注目すると差が明確です。SWEは仕様が与えられた状態から始まりますが、FDEは「そもそも何を作るべきか」を顧客と探すところから始まります。そのため求められる力にも、実装・設計に加えて顧客折衝とドメイン理解が乗ります。

責任範囲が広いということは、失敗の定義も変わるということです。SWEにとっての失敗は、仕様どおりに動かない実装です。対してFDEにとっての失敗は、仕様どおりに動いていても顧客の現場で使われない状態です。動くものを作った時点で自分の仕事を終わりにできない——ここがFDEの責任範囲を最も端的に表しています。

この差は、仕事が終わるタイミングの違いとしても現れます。SWEはコードがマージされ、リリースされた時点で一区切りがつきます。FDEは、そこから顧客の現場で実際に使われ、成果が出るところまでが射程に入ります。同じ「完了」という言葉が、指す地点として一段先にあると考えるとわかりやすいはずです。

FDEが「スタートアップCTO的」と言われる理由は？

課題定義から実装、現場での定着までを少人数で丸ごと所有するため、CTOに近いと整理されます。

Palantirの定義では、FDEは少人数チームで高難度案件をend-to-endで所有する、スタートアップCTOに近い役割だと整理されています（The Pragmatic Engineer）。

スタートアップCTOに近いとされるのは、課題定義から実装、現場での定着までを少人数で丸ごと引き受けるからです。例えば、機能開発だけを担当するSWEとは違い、FDEは「この顧客の成果に責任を持つ」立場で全体を見ます。この「end-to-endで所有する」という点が、SWEとの責任範囲の差をもっとも象徴しています。

なお「CTO的」という表現は、肩書きの高さではなく意思決定の範囲を指しています。何を作らないかを決める、優先順位を組み替える、どこまで技術的な妥協を許容するかを判断する——こうした判断を、上流の誰かに委ねず自分の側で行うことになります。裁量が大きい代わりに、判断を誤ったときの影響も自分に返ってきます。責任範囲の広さは、権限の広さと表裏一体だということです。

裏を返せば、判断を委ねられる相手がいない状況を前提とした役割でもあります。仕様の妥当性を誰かが保証してくれるわけではなく、自分が現場で確かめた事実が判断の根拠になります。FDEに顧客折衝とドメイン理解が求められるのは、この判断の根拠を自分で調達しなければならないからです。

FDEに求められる技術水準は？

FDEはSWEの実装力を前提とし、その上に顧客対応力を重ねる職種で、技術水準は下がりません。 技術力が低い職種ではありません。

AnthropicのFDE求人は何を要件にしている？

AnthropicはPythonでの高い実装力に加え、LLMの本番運用経験とhigh agencyを要件に挙げています。

AnthropicのFDE求人では、Pythonでの高い実装力に加え、LLMの本番運用経験（高度なプロンプト設計やエージェント開発）、そして「曖昧さの中を進むhigh agency」や顧客とのdiscovery能力が要件に挙げられています（Anthropic公式求人）。

ここで重要なのは、これらが「技術力の代わり」ではなく「技術力に上乗せされる」要件だという点です。Pythonの高い実装力という土台があったうえで、LLMを本番で動かす経験や、要件が曖昧なまま前に進めるhigh agencyが求められます。つまりFDEは、SWEの技術水準を満たしたうえで、さらに顧客対応の力を重ねる職種だと言えます。

この積み上げの構造を理解しておくと、「FDEは技術が苦手でも顧客対応が得意なら務まる」という誤解を避けられます。求人票に顧客discoveryの項目が並んでいても、その手前にある実装力の要件が消えているわけではありません。順序としては、まず土台の実装力、その上にLLMの運用経験、さらにその上に曖昧さを扱う力、という三層になります。

FDEはコードを書く職種なのか？

FDEはコードを書きます。ワークフローを自ら設計・実装・テストし、顧客システム上に本番アプリを構築します。

FDEは打ち合わせや折衝だけを担う役割ではありません。顧客の課題を捉えた後、それを解くワークフローを自分で設計し、実装し、テストして、顧客のシステム上で動く本番アプリケーションにまで仕上げます。顧客折衝やドメイン理解が求められるのは、この実装の前提となる「何を作るか」を正しく定めるためであり、コードを書くこと自体はFDEの中核業務です。

言い換えれば、顧客対応はコードを書くための手段であって、コードを書かなくてよい理由ではありません。現場で何が起きているかを自分の目で確かめる過程が設計の精度を上げ、その設計を自分の手で実装するからこそ、顧客の反応を受けて素早く直せます。この「聞く」と「作る」が同じ人の中でつながっている点が、FDEの働き方の特徴です。

仮にこの二つが別々の人に分かれていると、現場で得た手触りが要件定義書という形に落ちる過程で必ず情報が欠けます。FDEが一人で両方を担うのは、その欠落を避けて反映までの距離を短くするためです。技術水準を下げてよい職種ではなく、むしろ実装力があるからこそ現場での対話が意味を持つ、という関係になっています。

SWEからFDEへ移るには？

SWEの実装経験はそのままFDEの土台になり、何を作るかを顧客と定義する経験を足せば移行できます。 ゼロからのやり直しではありません。

SWEの経験はFDEでどう活きる？

FDEはSWEの実装力を土台とする職種のため、プロダクト開発の経験は失われず前提として活きます。

すでに見たとおり、AnthropicのFDE求人でもPythonの高い実装力が要件です。したがって、SWEとして機能を設計・実装・テストしてきた経験は、FDEになっても失われず、むしろ前提として求められます。ワークフローを自分で組み立て、テストして本番に載せるという一連の動きは、SWEの現場でそのまま鍛えられてきたものです。

この点は転職を検討するうえで実務的な意味を持ちます。FDEへの移行は、これまで積んだ技術資産を捨てて別の職種へ移る「乗り換え」ではなく、既存の土台の上に担当範囲を積み増す「拡張」に近いからです。何をゼロから学び直す必要があるのかを見極める際も、まずは実装力が前提要件として残る点を出発点に置くと整理しやすくなります。

移行で足りないのはどの経験？

足りないのは技術ではなく、要件が固まる前から顧客と会話し、成果まで責任を持つ「幅」の経験です。

伸ばす余地があるのは技術そのものより、曖昧な課題を顧客と一緒に定義し、顧客の成果まで責任を持つという「幅」の部分です。例えば、要件が固まる前の段階から顧客と会話し、作るべきものを一緒に決める経験を積むと、移行がスムーズになります。仕様が降りてくるのを待つ立場から、仕様を顧客と作る立場へ移る——この一歩が、SWEとFDEを分ける実務上の境目です。

現職のままでも練習の余地はあります。要件定義の会議に実装者として同席する、顧客やユーザーのヒアリングに立ち会う、リリース後に現場で使われているかを自分で確認しに行く。いずれも「作る前」と「作った後」に自分の関心を伸ばす動きで、FDEが日常的に担っている範囲そのものです。

これらは転職の前に始められる点が利点です。ヒアリングに立ち会えば、顧客の言葉と実際の課題がずれる場面に何度も出会います。リリース後を見に行けば、動く実装が使われないという事態を自分の経験として持てます。この二つは、FDEの失敗の定義そのものに関わる感覚であり、面接で語れる素材にもなります。

FDEをさらに深く知るにはどの記事を読む？

役割の全体像は「FDEとは」、キャリアの始め方は「FDEのキャリア」でそれぞれ解説しています。

FDEという職種の輪郭をもう一段つかみたい場合はFDEとはを、SWEからの具体的なキャリアの入り方を知りたい場合はFDEのキャリアを参照してください。本記事で見た「一顧客に多くの機能を届ける」というFDEの特徴を前提に読むと、役割とキャリアの理解がつながりやすくなります。

また、FDEとコンサルタントの境界線が気になる場合は提案と実装の分かれ目を扱った記事を、現場で効くスキルの優先順位を知りたい場合はスキル面の記事を合わせて読むと、本記事で整理した「向きの違い」と「責任範囲の広さ」がより具体的な輪郭で見えてきます。

姉妹メディアの関連記事