FDEとは何か──元Palantir FDEが語る、日本企業の3つの誤解

「Forward Deployed Engineer」、略して FDE という単語が、ここ1年の日本のスタートアップ業界で急速に広まっている。元になっているのは米 Palantir Technologies が掲げてきた職種で、顧客の現場に入り込み、業務課題と自社プロダクトの両方を見ながら結果を出すまで担う、というエンジニア像だ。

LayerX が AI ワークフォース事業部で FDE 職を立ち上げ、SIer や大手エンタープライズまでが「FDE モデルを参考に」と語るようになった。Strickland も Forward Deployed Engineering を標榜する立場として、この潮流自体は歓迎すべき動きである。

ただし、気になるのは「FDE」という単語だけが独り歩きしている感覚だ。100%常駐する超人エンジニア、と紹介されたり、コンサルとエンジニアの両方ができるスーパーマン、と語られたり。何かが少しずつ実態とずれている。

その違和感に対する一次証言が、Palantir Japan で実際に FDE を務めていた人物のインタビュー動画として公開されている。LayerX に「FDE ネイブラー」として参画した王子氏（敬称略）への、約30分のインタビューだ（元動画：FDEの本質とは？元Palantir社員と語るFDEモデル）。

本稿は、この動画で語られた一次証言を起点に、日本で起きている『FDE バブル』が見落としている本質を整理する。先に結論を書くと、日本企業が真に取り入れるべきは「FDE そのもの」ではなく、FDE を育てるメタ機能──『ネイブラー（Enabler＝育てる側）』である。

そもそも FDE とは何か

FDE とは、ビジネスサイド（顧客の課題）と自社プロダクトを結びつけて、結果を出すまでをやり切るエンジニアの総称である。Palantir 出身者の証言によれば、これが社内でも最も誤解の少ない定義になる。

つまり次の二つを同時に担う：

• 顧客の業務・課題の理解（コンサル的なヒアリングと設計）
• 自社プロダクトを使った実装・運用（エンジニアリング）

普通の会社では、この二つは別の人が担当する。営業が顧客の話を聞き、PM（プロジェクトマネージャー）が要件を整理し、エンジニアが実装する。FDE は、それを1人の責任者が一気通貫で担うという発想である。

ここで重要なのは、FDE は「コンサルとエンジニアの兼業」ではない、という点だ。両者を分断せず、最初から最後までやり切ることに最適化された役割として設計されている。インタビューで王子氏は「ぶち当たった壁をぶち抜く力が必要」という言葉で表現していた。

日本で広がる「FDE バブル」3つの誤解

誤解1：FDE は顧客のオフィスに 100%常駐する

Palantir においても、100%常駐型は標準ではない。王子氏自身が「いわゆる 100%常駐みたいな形は、そんなに取らないことが多い」と明言している。

「Forward Deployed」という単語の語感から、「現場に派遣される」「顧客先に常駐する」というイメージが先行している。だが実態は、必要に応じてヒアリングのために顧客先に行く、プロトタイプの使い心地を確認するために行く、という頻度の話でしかない。

判断軸は「結果を出すのに、その時間の使い方が適しているか」だけだ。プロジェクトによっては、複数案件を1人の FDE が並行で持つこともある。日本で時々耳にする「うちは FDE モデルだから常駐型で」という説明は、Palantir の実態を正しく写していない。

誤解2：FDE は GAFA 出身のスーパー人材しかなれない

FDE のバックグラウンドはきわめて多様で、共通項は「エンジニアであること」だけ。王子氏は「あえて共通項を上げるとしたら、エンジニアであることぐらい」と語る。

大学を出てそのまま Palantir に入る人もいれば、個人事業主・スタートアップを経て中途入社する人もいる。求められる素質を聞かれて返ってきた答えは、抽象度の高いものだった。

• 自分で考えられる
• そして、ちゃんと行動できる
• 最後までやり切る力（ぶち当たった壁をぶち抜く力）がある

これは「特殊スキルセット」ではなく「実行に対する執着」の話だ。GAFA 出身であることや Ph.D を持っていることが FDE の必須条件ではない。むしろ Palantir 退職者の進路として起業が多いという証言から逆算すると、FDE は「自分で事業を回す胆力がある人」と言い換えるほうが正確かもしれない。

誤解3：FDE 職を作りさえすれば、Palantir モデルが回る

これがもっとも危険な誤解である。Palantir で FDE が機能している前提には、Foundry（ファウンドリー）というデータ統合プラットフォームと、その背後にある 20年分のプロダクト成熟度がある。

王子氏は「私が在籍した約3年の間でも、最初の頃と退職前を比べると、プラットフォームとしての成熟度はかなり高くなった」と語っている。FDE が顧客プロジェクトで作ったカスタマイズを、プロダクトチームと擦り合わせながらプロダクト本体に取り込み、それが汎用機能として横展開される──この『個別最適 → プロダクト化 → 横展開』のループが、FDE モデルの収益性と再現性を支えている。

プラットフォームを持たない企業がいくら FDE 職を新設しても、それは「優秀なコンサル兼エンジニア」を抱えているだけで、Palantir モデルの本質には届かない。これは Strickland 自身も、Forward Deployed Engineering を掲げる以上、常に向き合うべき論点だ。

Palantir モデルが成立する本当の前提──プロダクトという土壌

ここまでで見たとおり、Palantir の FDE が回っているのは、Foundry というプロダクト基盤が下にあるからだ。

王子氏の言葉を借りれば、「プロダクトが強いと、シンプルにやりやすい、仕事しやすい。作りたいものがストレスなく作れる」。FDE は顧客現場で「ここをカスタマイズしたい」と思った時、ゼロから書き起こさなくていい。プラットフォーム上で改変するか、必要ならプロダクトチームに投げ込んで本体機能化してもらえる。

裏返せば、プラットフォームがない会社が FDE 職を作ると、毎案件ゼロから組み上げ続けることになる。短期的には属人的な優秀さで乗り切れるが、3年後・5年後にはモデル全体が破綻する。

日本のスタートアップが Palantir モデルを参考にするなら、まず「自分たちは Palantir の20数年のうち、どのフェーズにいるのか」を正しく見極める必要がある、と王子氏は警告する。プロダクトのないフェーズに、Palantir 後期の FDE モデルだけを輸入してはいけない。

生成AI 時代に、FDE の仕事はどう変わるか

ここ2〜3年の生成AI 普及で、FDE の役割は質的に変わった。

LLM（大規模言語モデル＝ChatGPT や Claude の中核技術）が実用化される以前、Palantir が扱うデータの主流は構造化データ（データベースに整形されたレコード）だった。それが LLM の登場により、非構造化データ（ドキュメント・スライド・議事録・メールなど）も同じ俎上で処理できるようになった。

結果、FDE が解けるユースケースは爆発的に増えた。「ビッグデータの集計と可視化」から「組織に散らばる暗黙知の構造化」まで、扱える領域が広がった。Palantir の株価がここ数年で急騰した背景には、この変化がある。

ただし、これはプロダクトを持つ Palantir の場合の話である。プラットフォームを持たない日本企業にとっても、生成AI の進化は「FDE 的働き方」の難易度を下げている。Claude や ChatGPT、各種ベクトルデータベース、エージェント基盤など、汎用プラットフォームの選択肢が揃ったことで、自社プロダクトがなくても FDE 的に働ける余地が生まれた。

これが、いま日本で FDE モデルが盛り上がっている隠れた背景でもある。プロダクトの代替を、生成AI プラットフォームで埋められる時代になった。ただし埋まるのは「ツール」の部分だけで、「組織として再現性を作る」部分は依然として別の解が必要になる──そこが次節の論点だ。

日本企業に必要なのは「FDE そのもの」ではない

ここまでの整理を踏まえて、本記事の独自テーゼを提示する。

日本企業が真に取り入れるべきは『FDE 職』そのものではなく、FDE を育てるメタ機能──『ネイブラー（Enabler）』である。

ネイブラーとは、英語の enable（〜できるようにする）の名詞形で、プレイヤー本人ではなく、プレイヤーが力を発揮できる土壌を作る役割を指す。Sales Enabler や DevOps Enabler という形で以前から使われてきた概念だ。

LayerX は今期、Palantir には存在しなかった「FDE ネイブラー」という役職を独自に新設した。王子氏自身がその第1号として参画している。仕事内容は次のようなものだ。

• FDE 組織の文化作り
• メンタリング・コーチング体制の設計
• Palantir 流の暗黙知を日本の業務文脈に翻訳して仕組み化
• FDE が育ち、力を発揮できる枠組み（同社では『FDE Blue』と呼ばれる仕組み）の構築

なぜ Palantir に存在しなかった役職が、日本企業には必要なのか。理由は3つある。

1つめ、OJT 文化の違い。Palantir では FDE 教育はマニュアル化されておらず、新人は OJT で学ぶ。だが日本企業では、明示的なメンタリングと言語化された手順がないと、人が育つ前に離脱する。

2つめ、プラットフォーム成熟度の差。Palantir には20年積み上げた Foundry がある。日本企業がスクラッチで FDE モデルを始めるなら、プラットフォームの代替（生成AI 基盤・社内ツール群）を併走で整える必要がある。これは個々の FDE が片手間で担う仕事ではない。

3つめ、再現性の問題。優秀な FDE を1人雇って案件を回しても、その人が抜けたら終わる。組織として再現する仕組み──採用基準・育成プロセス・ナレッジ蓄積──を作るのは、ネイブラー的なメタ役割の責務である。

つまり、FDE 職を新設する前に、ネイブラー機能を組織として持てるかを問うべきなのだ。これがないまま FDE 職を作ると、属人的なヒーローを1人雇って終わる『Palantir っぽい何か』が出来上がる。

では、何から始めるべきか

最後に、Forward Deployed 的働き方を組織に取り入れたい企業への示唆を整理する。

• 『FDE モデル』ではなく『FDE 的働き方』から始める。職種名を新設するより、既存のエンジニアが顧客現場に入り込み、業務理解から実装までを担う案件を1件作るほうが早い。
• プラットフォームを生成AI で代替する設計を意識する。自社プロダクトを持たないなら、Claude / ChatGPT / ベクトルデータベース / エージェント基盤を組み合わせて、FDE が毎案件ゼロから書かない構造を整える。
• ネイブラー機能を、いつ・誰が担うかを決める。創業期は経営者が兼ねるしかないが、3人目・5人目の FDE が入る前に「育てる人」を明確にする。これを後回しにすると組織として崩れる。

Strickland も Forward Deployed Engineering を標榜する以上、この3点は継続して問い続けている論点である。FDE は『人』ではなく、『組織として再現できる仕組み』を意味する──王子氏の証言から汲み取れる最大の教訓は、ここに尽きる。

よくある質問

Q. FDE と従来のコンサル・SIer の違いは何か？

顧客の課題を理解してソリューションに落とし込み、提供するまでを一気通貫で担う点は共通している。違いは『自社プロダクト／プラットフォームの有無』と『個別案件で作ったものをプロダクトに還流できる構造』だ。Palantir では FDE が現場で作った機能が Foundry 本体に取り込まれ、横展開される。これがない場合、FDE モデルは単なる優秀なコンサルになる。

Q. FDE になるには GAFA 出身や Ph.D が必要か？

必要ない。Palantir でも FDE のバックグラウンドは多様で、新卒もいれば個人事業主出身もいる。共通項は『エンジニアであること』と『自分で考え、最後までやり切る力があること』。Strickland も同様の採用観点を取っている。

Q. Palantir の FDE はプライシングをどう決めているのか？

王子氏いわく『ケースバイケース』。FDE と DS（Deployment Strategist＝案件の事前フィージビリティを判断するロール）の工数と、プラットフォームのコンピュートリソース使用量を複合的に見て、案件ごとに妥当な金額を提示する形が多い。固定のシート単価ベースではない。

Q. 日本企業が Palantir モデルを真似て、いきなりつまずく典型パターンは？

プラットフォームを持たない段階で FDE 職を新設し、属人的な優秀さで2〜3案件を回した後、その人が抜けて組織として何も残らない、というパターンだ。ネイブラー機能を先に作るか、生成AI 基盤でプラットフォームの一部を代替する設計を最初から組むことで、ある程度防げる。