Skip to content
Published on

FDE(Forward Deployed Engineer)とは何か — 顧客の現場に配置されるエンジニア

シェア
Authors

突然どこにでもある肩書き

最近の求人票を眺めていると、見慣れない肩書きが目につくようになりました。Forward Deployed Engineer、略してFDE。Palantirが作った職種で、いまはOpenAIがサンフランシスコ・ニューヨーク・東京を含む複数の都市で採用しており、AnthropicもApplied AI組織の下に同じ名前のポジションを開いています。ライフサイエンス専任FDE、半導体専任FDEのように、産業別に切り分けた求人まで出てきています。

ところが、この肩書きを日本語や韓国語で検索しても、まとまった情報はほとんど出てきません。カタカナのまま漂っていて、セールスエンジニアやコンサルタントと何が違うのかという当然の疑問への答えは散らばったままです。この記事はその空白を埋めるFDE完全ガイドシリーズの第1回です。定義から始めて、スキルマップ、オンボーディング、障害診断、顧客コミュニケーション、PoC運営、キャリア転換、面接準備まで、全8回で続きます。

定義 — 顧客の現場に配置されるエンジニア

まず名前から解きます。forward deployedは前方展開を意味する軍事用語です。部隊を本拠地ではなく前線の近くに置くこと。その比喩のまま、FDEは本社のオフィスではなく顧客の現場に配置されるエンジニアです。物理的に常駐することもあればリモートで張り付くこともありますが、本質は場所ではなく向きです。仕事の座標系が自社のコードベースではなく、顧客の環境だということです。

Palantirの公式ブログは、この職種をプロダクトエンジニアとの対比で定義しています。プロダクトエンジニアが一つの機能を多くの顧客に届ける人だとすれば、FDEは一人の顧客に多くの機能を届ける人です。日々の仕事を並べるとこうなります。顧客のデータとインフラに自社製品をつなぐ統合コードを書き、その環境でだけ起きる障害を診断し、「動かないんです」という言葉をエンジニアリングの要求仕様に翻訳し、現場で繰り返し目にするパターンを製品チームに送り返す。成果物はデモのスライドではなく本番で動くコードであり、成功の物差しは契約書のサインではなく、顧客の実業務が製品の上で回っているかどうかです。

隣接する四つの職種と何が違うのか

FDEを初めて聞いた人は、たいてい既に知っている職種のどれかに還元しようとします。その直感は半分正しく、半分間違っています。境界は会社ごとに違うという前提の上で、傾向を表で切り分けるとこうなります。

職種コードが残る場所関与のタイミング成功の物差し関係の長さ
FDE顧客環境内の本番コード契約の前後すべて実業務が製品の上で回るか数か月から数年
ソリューションアーキテクト(SA)リファレンス設計と例導入設計の段階アーキテクチャの採用設計の期間が中心
セールスエンジニア(SE)デモとPoCレベル契約前契約の成立締結まで
コンサルタント提言と納品ドキュメントプロジェクト単位納品の完了プロジェクト終了まで
サポートエンジニア再現環境問題の発生後チケットの解決チケット単位

基準線は二つです。第一に、顧客の本番環境に残るコードを書くかどうか。SEのデモは契約が決まれば捨てられ、コンサルタントの提言は文書として残るだけですが、FDEの書いた統合コードは顧客のシステムの中で動き続けます。第二に、契約の後も関係が続くかどうか。FDEは売って去る仕事ではなく、動かして守り続ける仕事です。だからThe Pragmatic Engineerの分析が言うように、FDEはソフトウェアエンジニアリング、セールス支援、プラットフォームエンジニアリングが一人の中に混ざった形になります。

なぜAI製品の時代に急浮上したのか

この職種が2020年代半ばに急に熱くなったのには、構造的な理由があります。完成したSaaSにFDEは要りません。サインアップして設定をいくつか選べば終わる製品には、現場エンジニアの立つ場所がないからです。FDEが必要になるのは、製品が未完成のプラットフォームであるときです。汎用能力の塊はあるのに、それが特定の顧客のデータ・権限体系・業務フローに接続されて初めて価値が出る製品。いまのLLMがまさにそれです。モデルは汎用ですが、価値は顧客ごとに違う形で組み立てる必要があり、その組み立てはインストールではなく工事に近い。

ここから核心の論理が出てきます。製品が未完成であるほど、現場のエンジニアリングが製品の一部になります。顧客が体験するのはモデルそのものではなく、自分の業務の上で動く組み立ての結果であり、その組み立てをやり切る人がいなければ、製品は事実上存在しないのと同じです。Palantirがこのモデルの元祖です。オントロジー基盤のプラットフォームを政府や大企業に売りながら、一時期はプロダクトエンジニアより現場のFDEの方が多かったほど、この職種に会社を賭けました。そしてLLMの時代が来ると、OpenAIとAnthropicが同じ構造をそのまま持っていきました。売っているものが未完成のプラットフォームだという条件が同じだからです。

副次効果も大きい。FDEは製品チームが絶対に見られないものを見ます。実際の顧客データの汚さ、セキュリティチームが拒否する理由、現場ユーザーが本当に欲しいもの。この観察が製品フィードバックループに乗ってロードマップになれば、FDE一人が営業支援と製品リサーチを兼ねたことになります。高くつく職種が成立する理由です。

この仕事が合う人、合わない人

正直な適性の話で締めます。FDEに向いているのは、曖昧さに耐えられる人です。ドキュメントのないシステム、初めて見るインフラ、言うことが食い違うステークホルダーの間で素早く地図を描く仕事が業務の半分を占めます。説明することを楽しめる人、技術的な深さと対人コミュニケーションのどちらも手放したくない人には、めったにない良い席です。

逆に、一つのコードベースを深く掘ることに喜びを感じる人、邪魔されない没入時間が生産性のすべてだという人には、つらい仕事です。顧客ミーティングと障害対応がカレンダーを絶えず刻み、出張や常駐が混ざることも多い。報酬については、会社と地域による振れ幅が大きいということだけが正直に言えることで、具体的な数字は求人票とオファーで直接確かめるのが正確です。シリーズの次回からは、この職種を実際に準備する側に入ります。まずはスキルマップです。

手を動かして練習する

読むだけでは育たない感覚があります。このブログにはFDEの訓練用インタラクティブツールが二つあります。

  • FDEエンジニア育成RPG — 未知の顧客環境で時間・信頼度・アクセス権を配分し、障害の原因を診断する意思決定ゲームです。31の現場ミッション、6つの点検シナリオ、8ドメインのレベルがあります。
  • FDEカリキュラム ロードマップ — 10ドメイン65スキルをセルフチェック基準と共に追跡する学習チェックリストです。

FDE完全ガイドシリーズ

参考資料