FDEと普通のエンジニアの違いは？役割で理解

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

通常のエンジニアが「一つの機能を多くの顧客へ」届けるのに対し、FDE（Forward Deployed Engineer）は「一つの顧客に多くの機能を」実装して課題を解決します。 同じくコードを書く職種でも、価値の届け方が逆向きです。

「一機能を多数の顧客」か「一顧客に多数の機能」か

Palantirの一次定義では、通常のDev（SWE）は “one capability, many customers”、FDE（社内呼称Delta）は “one customer, many capabilities” と説明されています（Palantir公式ブログ）。

この対比は、両者が向き合う「幅」と「深さ」の方向が反対であることを示します。SWEは一つの機能を磨き上げ、それを多数の顧客・ユーザーへ横展開してスケールを取ります。対してFDEは、目の前の一顧客に張り付き、その顧客が抱える複数の課題を次々と機能として実装していきます。どちらもコードを書く職種ですが、SWEが「多数へ広く」なら、FDEは「一社に深く」入るという違いが起点になります。

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

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

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

責任範囲はどこが違う？

FDEの責任は「顧客の成果」まで及び、与えられた仕様の実装にとどまる通常のSWEより範囲が広いのが違いです。 起点も成果物も、SWEとは異なります。

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

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

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

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

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

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

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

FDEは技術が前提で、その上に顧客対応力が乗ります。SWEとしての実装力がなければ、FDEとして現場で成果を出すことはできません。 技術力が低い職種ではありません。

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

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

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

FDEはコードを書くのか？

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

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

SWEからFDEへ移るには？

SWEのプロダクト開発経験はそのままFDEの強みになり、「何を作るか」を顧客と定義する経験を足せば移行がスムーズです。 ゼロからのやり直しではありません。

SWEの経験はどう活きる？

FDEはSWEの実装力を土台とする職種なので、プロダクト開発の経験はそのまま移行の資産になります。

すでに見たとおり、AnthropicのFDE求人でもPythonの高い実装力が要件です。したがって、SWEとして機能を設計・実装・テストしてきた経験は、FDEになっても失われず、むしろ前提として求められます。伸ばす余地があるのは技術そのものより、曖昧な課題を顧客と一緒に定義し、顧客の成果まで責任を持つという「幅」の部分です。例えば、要件が固まる前の段階から顧客と会話し、作るべきものを一緒に決める経験を積むと、移行がスムーズになります。

FDEを深く知るための内部リンクは？

役割の全体像とキャリアの始め方は、それぞれ専用ページで解説しています。

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