Forward Deployed Engineer

なぜ今、FDEなのか

背景には、身も蓋もない数字がある。MITのNANDA Initiativeが公開されたAIプロジェクト300件を調べたところ、企業のAIパイロットの95%が、測定可能なビジネスインパクトを生めていないという結果が出た。原因はモデルの品質ではない。汚れたデータ、文書化されていない業務、レガシーな社内システム、コンプライアンス要件──要するに「実装」でつまずいている。

従来のソフトウェアはリリースすれば安定して動く。しかしAIは確率的に振る舞い、production環境でじわじわと精度が落ち、ユーザーの信頼を静かに削っていく。この「デモは動くのに本番で使えない」という溝を、現場に飛び込んで埋めるのがFDEだ。

需要の伸びは異常なほどで、FDEの求人は2025年1月から9月のあいだに800%以上増加した。OpenAIは2024年にFDEチームを立ち上げて急拡大し、AnthropicもApplied AIグループを拡張。両社にとってFDEは、いまやエンタープライズ売上の主要チャネルになっている。

そもそもFDEとは何か

FDEの発祥は、20年近く前のPalantirにさかのぼる。政府機関や金融機関のような、複雑なインフラと厳しいコンプライアンスを抱える顧客に、エンジニアを送り込んだ。社内では「Delta（デルタ）」と呼ばれ、なんと2016年頃までPalantirは、通常のソフトウェアエンジニアよりもDeltaの人数のほうが多かった。普通のエンジニアとFDEの違いを一言で表すと、こうなる。

通常の開発者は「1つの機能を、多くの顧客へ（one capability, many customers）」。 FDEは「1つの顧客に、多くの機能を（one customer, many capabilities）」。

FDEは顧客のインフラ上で直接コードを書き、現場に足を運び（就業時間の25〜50%）、時には商談のクロージングにも関わり、そこで得た学びをコアプロダクトに還元する。役割の感覚としては「顧客企業ごとに配置された小さなスタートアップのCTO」に近い。デリバリーが終われば去っていく従来のコンサルタントとは、この点が決定的に異なる。

FDEは万能薬ではない。導入を検討すべきサインは明確だ。プロダクト自体は完成度が高いのに、エンタープライズ商談が「POC止まり」で本契約に進まない。顧客ごとにデータ構造や業務が違いすぎて、セールスエンジニアだけでは要件をさばききれない。そして、成約の鍵が「機能の説明」ではなく「顧客の業務に合わせた作り込み」にある──こうした状況なら、FDEが効く。

また、FDEは「T字型人材」だ。ある領域に深い専門性を持ちつつ、フルスタックで広く手を動かせる。求められる要件は各社おおむね共通している。エンジニアリング／技術導入の経験5年以上、PythonとJavaScriptでのフルスタック実装力、そしてRAGパイプライン・評価（eval）フレームワーク・エージェントワークフローといった実戦的なAIスキル。加えて、仕様が定まっていない曖昧な状況で問題を分解できる力と、技術者にも非技術者にも通じる対話力が要る。
見極め方で最も重要なのは、アルゴリズムのコーディング試験では測れないという点だ。多くの企業が「分解（decomposition）ラウンド」を課す。いきなりコードを書かせるのではなく、曖昧な課題に対して質問を重ねてスコープを明確にしていくプロセスを見る。これが実際のデプロイ現場の動きそのものだからだ。採用マネージャーが最も重視するシグナルは「production向けのコードを書き切った実績」と「セールス台本なしで顧客ヒアリング（ディスカバリー）を回せること」の2つだった。

FDEを単なる採用ポジションと捉えると、本質を見誤る。これはAI時代のGo-To-Market（市場投入）戦略そのものだ。プロダクトが良ければ売れる時代は終わり、顧客の泥臭い現場に飛び込んで「動く成果」を作れるかどうかが、エンタープライズ売上を分ける。

スタートアップにとっての問いはシンプルだ。自社のプロダクトは、顧客の現場で本当に「刺さって」いるか。POCの先へ進めているか。もしそこに溝があるなら、FDEという役割──あるいは少なくともその発想──は、真剣に検討する価値がある。業界の78%のチームが2027年に人員2倍以上を見込んでいる。波はもう来ている。

参考：Pragmatic Engineer, The New Stack (MIT NANDA調査), Paraform, Perspective AI「State of Forward Deployed Engineering 2026」ほか