FDEって昔からいたよね？
FDEとは
最近、技術系のタイムラインで「FDE」という言葉をよく見かけるようになりました。
FDE(Forward Deployed Engineer)は、Palantirが2010年代初頭に職種として確立し、名前をつけて広めた役割だとされています。
社内ではNATOフォネティックアルファベット由来の「Delta(デルタ)」と呼ばれているそうです。
ざっくり言うと、FDEは顧客の現場に入り込んで仕事をするエンジニアです。
本社で製品を作って世に出すのではなく、顧客企業にembedして、業務理解からデータ統合、ソフトウェアの実装、本番運用までを一気通貫で担います。
オンサイトの比率は案件やチームによって幅があり、Palantirでは目安として25%程度、企業によっては最大50%とも言われます。
ずっと常駐というよりは、現場と自社を行き来しながら顧客のシステムの中で実際にコードを書く、という働き方のようです。
Palantirの整理が分かりやすいので紹介します。
製品エンジニア(Dev)は「one capability, many customers(1つの能力を多くの顧客へ)」、FDE(Delta)は「one customer, many capabilities(1人の顧客に多くの能力を)」。
つまり方向が逆なんですね。
製品エンジニアが汎用の機能を磨いて多くの顧客に届けるのに対して、FDEは特定の顧客に張り付いて、その顧客が成果を出すために必要なことを何でもやる。
評価も「顧客のビジネス成果が出たかどうか」で測られます。
2016年まで、Palantirは通常のソフトウェアエンジニアよりもFDEの方が多かったと言われています。
似た職種との違いもはっきりしています。
従来のソフトウェアエンジニアは社内製品の開発が中心、いわゆるソリューション系のエンジニアは匿名化・オフラインのデータでMVPやPoCを作るのが主で顧客の本番インフラ上に実コードを書くことは稀、コンサルタントは提言や報告書を出して去っていく。
これに対してFDEは、顧客の実システム・実データの上で自ら手を動かし、システムが本番で安定稼働するまで責任を持つ。
この「自分で実装して、本番まで面倒を見る」という点が、FDEを他と分ける核心です。
そして2024年にOpenAIがForward Deployed Engineeringチームの構築を始め、2025年に採用を加速させたあたりから、この職種は一気にバズワード化しました。
東京を含む各拠点で募集をかけ、2026年5月にはOpenAIが過半を持つ新会社「OpenAI Deployment Company」を立ち上げ、そこにTPG主導の投資家から40億ドル超の出資が集まったと報じられています(OpenAI本体の調達ではなく、新設子会社への外部出資です)。
Google Cloudもパランティア型のFDEを本格的に採用し始めていて、FDE関連の求人はLinkedIn上で2025年の1月から9月に800%以上増えたという求人分析の報道もあります。
(計測の対象や期間によって倍率の数字はかなり幅があるので、特定の数字というより「急増している」という傾向として受け止めるのが正しいと思います。)
完全にバズワードの仲間入りです。
昔からいたよね？
さて、ここからが本題です。
このFDEの説明を読んで、私が最初に思ったのはこれでした。
「これ、昔からいたよね？」
受託開発やSIerの現場には、要件定義から設計、システムの導入提案、そして実装まで、自分でコードを書いて回してしまうPMがいました。
一般にPMの主務は要件整理と進捗管理で、実装はエンジニアに委ねるケースが多い、というイメージかもしれません。
でも、そうではないPMが昔から一定数いたんです。
顧客の業務を自分で理解して、設計して、必要ならその場でコードまで書いて、本番まで持っていく。
マネジメントもするけれど、自分でもプレイヤーとしてコードを書く。いわゆる「プレイングマネージャー(PM)」ですね。
ちなみに略せば「PM」。ふつうのプロジェクトマネージャー(PM)と、奇しくも同じ略称になるのが面白いところです。
この「プレイングマネージャー」がやってきたことを並べてみると、〈現場に入り込み、自分で実装し、本番まで責任を持つ〉という働き方の輪郭は、FDEとよく重なります。
顧客の業務を理解して、課題を見つけて、自分の手で動かして、運用まで持っていく。
顧客の規模や本番責任の重さといった違いはありますが、働き方の核になっている部分はかなり近い、というのが私の見立てです。
要するにFDEに求められる人間像の核は、昔からいた「プレイングマネージャー」と地続きなんじゃないか、というのが私の率直な感想です。
もちろん、細かく見れば違いはあります。
正直に挙げておくと、FDEにはプレイングマネージャーと違う点もあります。
1つ目は、白紙からのスクラッチ開発ではなく、自社プロダクトを土台にして素早く組み上げること。
2つ目は、現場で得た知見を汎用機能としてプロダクトへ還流する「製品還元」のフェーズが組み込まれていること。
このあたりは、受託のプレイングマネージャーにはあまりなかった発想かもしれません。
ただ、そうは言っても、「課題設定から実装・運用まで自分で貫ける人材」という核は何も変わっていません。
道具が自社プロダクトと生成AIに変わった分、スキルの中身は更新されています。
それでも、求められる人間像の根っこは、現場に入り込んで自分でコードまで書くプレイングマネージャーと地続きです。
職種として制度化し、知見を自社プロダクトへ還流させる組織モデルはPalantir以降の新しさだと思いますが、中心にいる人間像そのものは、昔からそう変わっていない。
私には、結局そういう話に見えます。
一点だけ補足しておくと、日本だと「常駐」と聞くと反射的にSESを連想しがちですが、それとは別物です。
日本の客先常駐は、契約や商流の構造上、担当範囲や裁量が指示された工程に寄りやすく、評価も稼働で測られがちです。
もちろん、現場で課題定義から踏み込んで成果まで動くSESエンジニアもたくさんいます。
ただFDEは、課題を自分で定義して顧客のビジネス成果にコミットすることが、仕組みとして評価軸に組み込まれている。この制度設計の差は大きいと思います。
私が「昔からいた」と言っているのは契約形態の話ではなく、自分で手を動かして開発まで貫く、あのプレイングマネージャーという働き方のことです。
「常駐＝言われたことをやる人」と一括りにすると、本質を見誤ります。
FDEにだれでもなれるのか
では、そんなFDEに誰でもなれるのでしょうか。
結論から言うと、誰でもなれるものではないと思います。
もし誰でもなれるものなら、上流から実装まで一人で貫けるプレイングマネージャーが、とっくに世の中にあふれているはずです。
でも現実はそうなっていません。「DX人材不足」という言葉が何年も叫ばれていること自体が、その希少さを物語っています。
名前がFDEに変わったからといって、その希少性が急に消えてなくなるわけがありません。
理由は単純で、FDEに求められる条件の組み合わせが、そもそも稀だからです。
FDEに求められるものを見ると、ハードルの高さがよく分かります。
強いエンジニアであると同時に、大口の顧客関係を回せる高い対人スキルを併せ持つ必要があり、その組み合わせ自体が稀だと指摘されています。
Pythonを書けてモデルをデプロイできるエンジニアはたくさんいます。
でも、数ヶ月ごとに新しい業界や技術スタックに適応して、顧客の役員に説明して、深夜2時の本番トラブルで導入全体に責任を持てる人は、ぐっと少なくなります。
求人を1,000件分析した記事でも、多くが3〜5年以上の経験を求め、出張や本番運用の責任が前提になっていました。
その記事は「対人より技術に集中したいタイプなら、無理にFDEを目指さずコア開発で力を発揮する道もある」という趣旨のことも書いています(原文の言い回しはもっと直截ですが)。
技術力と対人共感力の両立という、けっこう稀な組み合わせが要求されるわけです。
これはまさに「プレイングマネージャーはそう簡単には増えない」という話と、同じことを言っています。
そしてここが私の一番言いたいところですが、FDEという“言葉”の持ち上げられ方は、かつての「誰でもエンジニア」的なバズり方とよく似ています。
フルスタックエンジニアという言葉も、本来の意味を超えて「一人で何でもできてお得」という期待だけが独り歩きしがちでした。
実際には、誰もが何でもできる万能選手になれるわけではありません。
DX人材という言葉も、定義が固まらないまま「ITが分かる人が欲しい」という幅広い話として広がった面があります。
IT業界は、実体以上に期待だけが先行するワードを、何度も何度も生み出してきました。
FDEも、職種としての実体はあるのに、日本では語感だけが先に広まりやすい――今まさに“言葉”が独り歩きしている段階だと思います。
それでもFDEが求められる理由
ここまで散々「昔からいた」「ワードの独り歩きだ」と言ってきましたが、一点だけ、私が認めることがあります。
それは、AIがコードを書くようになったから、エンジニアに求められることが変わった、という点です。
生成AIやエージェントによって、コードを書くこと自体のコストは大きく下がりました。
「コードを書くのは常に簡単な部分で、何を書くべきかを知ることが難しい部分だった」という言説が、いま業界で広く共有されています。
価値の重心が「コードを書くこと」から「顧客の業務課題を理解して、AIを現場で実際に機能させること」へ移った、というわけです。
それを裏付ける数字として、よく引かれるものがあります。
MIT NANDAのレポートによれば、企業の生成AIパイロットの約95%が、収益にはっきり表れる成果をほとんど出せていないとされます。
しかも原因はモデルの性能ではなく、デプロイ・統合・優先順位のミスアライメントにある、と指摘されています。
要するに、AIの難所が「モデルを作ること」から「現場で機能させること」へ移ったわけです。
モデルは勝手にはデプロイされません。
この「最後の一マイル」を埋める役割として、FDEが改めて必要とされている。
この需要は本物だと思いますし、ここは事実として認めます。
ただ、それでも私の結論は変わりません。
FDEという職種が浮上した背景も、それを制度化した組織モデルも、確かに新しい。
AIを前提にする分、求められるスキルの中身も更新されています。
でも、その中心にいる人間像――現場に入り込み、課題を定義し、自分で手を動かし、本番まで責任を持つ――は、昔からこの業界にいたプレイングマネージャーと地続きです。
新しいのは主に道具と文脈で、人間像の核そのものは、昔も今もそう変わっていない。
昔からいた希少な人材に、時代が新しい名前をつけて呼び直している。私には、そう見えます。
だからFDEを見るときは、ワードの新しさに踊らされず、中身を実態で評価する姿勢が大事だと思います。
名前は変わっても、難しいことが難しいままなのは、昔も今も変わりませんから。
