FDEが流行っている。昔、それを「できるSE」と呼んでいた。

2026.10.08

最近、IT業界で「FDE」という言葉をよく目にします。

FDE：Forward Deployed Engineer。
顧客の現場に深く入り込み、課題を見つけ、解決策を考え、自ら作り、本番環境まで持っていくエンジニア。

なんとも強そうな名前です。

正直、最初はこう思いました。

それ、昔から「できるSE」がやっていなかっただろうか。

顧客のところへ行く
業務担当者と話す
現場を見る
「それなら、こうした方がいい」と提案する
必要なら自分で設計し、作り、問題が起きれば直す

特に名前はありませんでした。

SEでした。

「SE」より「FDE」と名乗った方が、なんだか高く売れそうです。

IT業界には、昔からあった仕事も英語にすると、
少し未来から来たように見えるという便利な性質があります。

ところが、FDEについて調べていくと、どうもそれだけではありません。

似ているのは、現場にいるところまでなのかもしれません。

FDEって、昔のできるSEじゃないのか

FDEは、渡された仕様書を実装するだけのエンジニアではありません。

顧客と話し、業務を理解し、
「そもそも何を解くべきなのか」から考える。

必要ならプロトタイプを作り、使ってもらい、違えば直し、本番で動くところまで持っていく。

つまり「それは仕様にありません」と言って帰る人ではありません。

実際、OpenAIは現在、東京でもForward Deployed Engineerを募集しています。

OpenAI

ChatGPTなどのAI技術・サービスを開発するAI企業。

東京で募集するFDEについて、
顧客へのデリバリーとコアプラットフォーム開発の交点に位置する役割として説明しています。

担当範囲は、次の流れを一気通貫で担います。

顧客との課題発見（discovery）
技術的なスコープの設定
システム設計・構築
本番展開

さらに、現場で得た知見を再利用可能なツールやパターンにし、ResearchやProductへフィードバックすることも役割に含まれています。

出典：OpenAI「Forward Deployed Engineer – Tokyo」

ここまで読むと、やはり昔のできるSEによく似ています。

顧客の話を聞く
問題を考える
設計する
作る
動かす

では、なぜ今になって、わざわざFDEという名前が必要なのでしょうか。

「仕様書にしにくい技術」がやってきた

システムが大規模化するにつれ、ITの仕事は分業されてきました。

営業が顧客の話を聞く
コンサルタントが課題を整理する
業務担当者が要件を決める
PMが管理する
アーキテクトが方式を決める
エンジニアが実装する
テスト担当者が検証し、運用担当者が引き取る

大規模なシステムを安定して作るには、合理的な進化だったと思います。

ただ、その結果、顧客の問題を最初から最後まで見ている人が、だんだん見えなくなった。

「なぜ、この機能が必要なのですか」
「業務部門からの要件です」

「実際に使われていますか」
「運用部門に聞いてください」

「そもそも、この業務は必要ですか」
「そこは今回のスコープではありません」

誰も間違っていません。

それぞれ、自分の担当範囲をきちんと守っています。

そして全員が担当範囲をきちんと守った結果、全体について答えられる人がいなくなる。

そこへ生成AIがやってきました。

たとえば「社内文書を参照して問い合わせに回答するAI」を作るとします。

「質問に回答する」という機能だけなら簡単です。

問題は、その先です。

どの程度の回答なら業務で使えるのか
誤回答をどこまで許容するのか
どの文書を参照させるのか
根拠をどう示すのか
答えない方がよい質問は何か
どこから人間へ引き継ぐのか

こうしたことは、仕様書を作ればすべて決まるとは限りません。

実際のデータを入れる
利用者に使ってもらう
想定外の回答が出る
プロンプトを変える
参照データを変える
評価方法そのものを見直す

要件を決めるために、まず作ってみる。

そんな順序が普通に起こります。

決めてから作るだけではなく、作りながら「何を決めるべきだったのか」が見えてくる。

そうなると、

「私は要件定義までです」
「私は実装担当です」
「業務要件はユーザー側で決めてください」

という境界を往復するたびに、仕事が止まります。

FDEが顧客のすぐそばで、業務と技術の両方を見る理由がここにあります。

「同じ現場」に立ちながら、持って帰るものが違う

それでも、ここまでは昔のできるSEとよく似ています。

違いが見えてくるのは、その先です。

昔のできるSEも、顧客の現場で多くのことを学びました。

「この業界では、こういう処理が必要になる」
「このデータは、こう持った方がいい」
「この業務は、ここで事故が起きやすい」

そして、その知見を顧客のシステムへ実装しました。

FDEも現場へ行きます。

しかし、そこで問題を解いて終わりではありません。

「これは、この会社だけの問題なのか」
「別の顧客でも起きるのではないか」
「プロダクト側で吸収できないか」
「次の顧客では、個別に作らずに済まないか」

と考える。

同じように現場へ行く。
しかし、持って帰るものが違う。

この構造を理解するうえで、Palantirの考え方が興味深いです。

Palantir Technologies

政府機関や企業向けに、データ統合・分析、AI活用のためのソフトウェアプラットフォームを提供する米国企業。

Forward Deployed Engineeringを特徴的に展開してきた企業の一つで、
自社プラットフォームも、この方法論によって継続的に開発されていると説明しています。

PalantirはFDEの役割を、非常に面白い言葉で表現しています。

“the human equivalent of backpropagation”

直訳すれば、

「人間版のバックプロパゲーション（誤差逆伝播）」

です。

エンジニアが顧客の問題へできるだけ近づく
そこで何がうまくいき、何がうまくいかなかったのかを拾う
そのフィードバックをコアの開発チームへ戻し、新しい機能として送り出す

出典：Palantir Technologies「Forward Deployed Engineering」関連公式資料

これは、FDEという仕事の特徴をかなり端的に表していると思います。

FDEは、単に「顧客の近くにいるエンジニア」ではない。

現場を、プロダクトが学習するための場所にするエンジニアでもある。

こう考えると、昔のできるSEとの違いが見えてきます。

顧客に近づく。でも、受託会社にはならない

一見すると、不思議な話です。

プロダクト企業なら、完成した製品をできるだけ多くの顧客へ売った方が効率がよさそうです。

ところがFDEは、その逆方向へ動きます。

エンジニアを顧客の現場へ送り込み、

個別の業務を見る
個別のデータを見る
個別の問題を解く

かなり「受託開発」に近づいていきます。

しかし、そこで止まらない。

一社で10の個別対応をして、次の一社でもまた10、その次も10。
それでは、プロダクトとしてのレバレッジが効かなくなるからです。

だから、一社の現場で発見した問題を、次の100社でも使える能力へ変換する必要がある。

顧客に深く入り込む。
しかし、その顧客だけの会社にはならない。

個別最適の最前線に立ちながら、共通化できるものを探す。

FDEには、この一見矛盾した仕事が求められています。

考えてみると、「Forward Deployed」という少々物々しい名前も、案外よくできています。

経験は、いつ「会社の資産」になるのか

ただし、ここで「だからプロダクト企業が優れている」という話にはしたくありません。

FDEを見ていて興味深いのは、プロダクトそのものよりも、現場で得た知見を、その会社が何に変換しているのかという点です。

プロダクト企業なら、製品やプラットフォームへ
SIerなら、設計パターンや標準部品、開発方法へ
コンサルティング会社なら、問題の捉え方、判断基準、方法論へ

蓄積先は違います。

共通しているのは、一社で学んだことを、一社で使い切らない。ということです。

何百件のプロジェクトを経験していても、
その知見が担当者の頭の中にしかなければ、次の案件ではまた一から考えることになります。

経験年数は増えている。
実績件数も増えている。
でも、次の案件ではまたゼロから始める。

それを「会社として経験が蓄積している」と呼べるのでしょうか。

経験したこと自体は、まだ資産ではありません。

プロダクトにする
設計パターンにする
判断基準にする
方法論にする
「この条件なら、この問題を疑う」という組織の勘所にする

次の仕事で再利用できる形になって、初めて経験は会社の資産になる。

FDEは、高く売れる名前なのか

最初、FDEという言葉を見たときには、少し意地悪なことを考えました。

「SEより、FDEのほうが高く売れそうだ。」

昔からあった仕事に、新しい名前を付けただけではないか。

確かに、仕事内容の一部だけを見れば、昔のできるSEによく似ています。

顧客の仕事を理解する
何が問題なのかを一緒に考える
技術で解く
動くところまで責任を持つ

しかしOpenAIやPalantirのFDEを見ていくと、少し違うものが見えてきます。

顧客のすぐそばまでエンジニアを送り込みながら、そこで得た知見を、その顧客だけのものにしない。

現場から学び、それを次の現場で使えるものへ変換する。

FDEの新しさは、現場に行くことではないのかもしれません。

現場と、組織の学習をつないだこと。

そこにあるように思います。

そしてこれは、FDEやAIだけの話でもありません。

プロダクトを持つ会社でも、持たない会社でも、最後に残る問いは同じです。

現場で得た知見を、次に何が残る形へ変換しているか。

FDEが流行っている。
昔、それを「できるSE」と呼んでいた。
最初はそう思いました。

似ているのは、現場にいるところまででした。

この記事を書いた人について

谷尾薫: オーシャン・アンド・パートナーズ株式会社　代表取締役
協同組合シー・ソフトウェア（全省庁統一資格Aランク）代表理事

富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。