FDEとは何をする職種なのか。エンジニアやコンサルと何が違うのか
概要
記事内容
FDEとは何かを、Palantirなど海外企業の定義を踏まえて解説。SIerやソフトウェアエンジニア等との違い、実務で担う役割を整理します。
筆者の概要
松尾研究室発のELYZAにて2019年より従事し、KDDIによる買収までの5年間の中でJRや ENEOSなどの大規模DXを担当。
独立後は自治体やスタートアップとの共同開発にて
、ビジネス/マーケティング/AIを横断した役割として企画設計実装を遂行。
また、自治体やベンチャー企業の中に、業務部の当事者が高度なDXを牽引できる人材やチームを生み出す支援をしています。
.
.
.
まとめ
いくつかの論点ごとに書いていますが、全体をまとめるとこういった整理をしています。
FDEの定義
Forward Deployed Engineer（FDE）という職種を目にする機会が増えてきました。
もともとはPalantirという海外企業での発信をきっかけに広く知られるようになった役割ですが、現在ではOpenAIやAnthropicをはじめ、多くのAI企業が同様の職種を募集しています。
ソフトウェアエンジニアのようでもあり、
コンサルタントのようでもあり、
プロジェクトマネージャーのようでもあり、
カスタマーサクセスにも少し近い。
実際、既存の職種だけでは少し説明しづらい役割です。
OpenAIはForward Deployed Engineerを次のような役割として説明しています。
戦略的な顧客と直接協力しながら、課題の発見（Discovery）、技術スコープ、システム設計、構築、本番展開までを一貫して担い、その成果を実際の利用状況やワークフローへの影響、評価（Eval）を通じて測る役割。
ここで面白いのは、「システムを作ること」がゴールになっていないことです。
本番で利用されること。
仕事の進め方が変わること。
そして、その知見がプロダクトやモデルの改善へ返っていくこと。
そこまで含めて一つの役割として定義されています。
Palantirでも、
Forward Deployed Engineerは顧客の現場へ深く入り込み、自社の技術を実際の業務へ適用しながら、顧客固有の課題を解決していく存在
として位置付けられています。
共通しているのは、プロダクトを作ることでも、要件通りに開発することでもなく、顧客の現実で成果を成立させることに重心が置かれている点です。
ソフトウェアエンジニアとの違いは何か。
SIerとの違いは何か。
カスタマーサクセスやプロジェクトマネージャーとの違いは何か。
そのあたりを一つずつ整理しながら、FDEという役割の輪郭をもう少し具体的に見ていきます。
.
.
.
FDEと他職種の違い
既存の職種との違いを整理していきます。
ソフトウェアエンジニアとの違い
ソフトウェアエンジニアは、ソフトウェアを設計し、実装し、品質を維持することが主な役割です。
もちろん顧客を理解することもありますが、基本的には「何を作るか」が決まったあとに、それを良い形で実現することが中心になります。
FDEはもっと前の段階から関わります。顧客が本当に困っていることは何か。何を作るべきなのか。今の仕事はそのままで良いのか。
そうした問いから始まり、必要であれば自ら実装まで行います。
つまり、
ソフトウェアエンジニアが「どう実現するか」を強く担うのに対して、FDEは「何を実現するべきか」まで含めて考える場面が多いです。
SIerとの違い
日本では、FDEはSIerに近いと感じる人も多いかもしれません。
確かに、仕事の流れはよく似ています。
ただ、大きな違いの一つは、プロダクトとの距離です。SIでは、個別案件としてシステムを作ることが多くなります。
一方で、多くのFDEは自社プロダクトを持つ企業に所属しています。
そのため、顧客ごとの学びを、プロダクトの改善、共通機能、モデルの改善、評価手法へ戻していくことも役割の一部になります。
顧客のために作るだけではなく、その経験を次の顧客にも活かせる形へ変えていく。この循環は、FDEの特徴の一つと言えます。
カスタマーサクセスとの違い
カスタマーサクセスも、「顧客の成果」を重視する職種です。
そのため、FDEと目指している方向はかなり近いように思います。
違いがあるとすれば、FDEは必要であれば自らコードを書き、システムを作り、技術的な変更まで行う点です。
カスタマーサクセスは、「製品をどう使えば成果が出るか」を支援することが中心です。
FDEは、「成果が出るようにシステム自体を変える」ところまで踏み込みます。
プロジェクトマネージャーとの違い
プロジェクトマネージャーも、顧客と開発チームをつなぐ重要な役割です。
スケジュールを管理し、関係者を調整し、品質やコストを管理しながら、プロジェクト全体を前に進めます。
FDEも、多くの関係者とやり取りしながら仕事を進めます。
しかし、中心にある責任は少し違います。プロジェクトマネージャーは、プロジェクトを成立させることに責任を持ちます。
FDEは、顧客の現実で成果が成立することに責任を持ちます。
そのためには、調整だけでなく、設計もし、実装もし、必要ならプロダクト側の改善提案まで行います。
FDEは「間」にいる職種
こうして整理してみると、FDEはどれか一つの職種を置き換えるものではないように思います。
ソフトウェアエンジニアのように実装し、
SIerのように現場へ入り、
カスタマーサクセスのように成果を考え、
プロジェクトマネージャーのように関係者を巻き込みながら進める。
もちろん企業によって期待される役割は少しずつ違います。
ただ、共通しているのは、顧客の現場と、自社の技術やプロダクトをつなぐ存在として期待されている点。
.
.
.
FDEの仕事内容
職務の流れ
おおよそこのような流れの仕事がどこのFDEでも行われることが多いです。
一見すると、ごく普通のプロジェクトにも見えますが、この6つを構造的でシステムを含めた視点で一貫して担うことが、FDEの特徴と言えます。
① 顧客の現状を理解する
FDEは、まず顧客がどのように仕事を進めているかを理解します。
使っているシステム。業務の流れ。データ。判断基準。関係者。
ここでは「どんなAIやシステム使うか」よりも、「仕事の中で、何が起きているか」を理解することが重要になります。
② 課題を定義する
本当に解決すべき課題は何なのかを整理します。
「AIチャットを作りたい」という相談でも、実際には情報が整理されていないことが問題かもしれません。
あるいは、評価方法が存在しないことが原因かもしれません。ここでは、技術よりも問題設定が重要になります。
③ 解決策を設計する
どのような仕組みなら現場で機能するかを設計します。
ここでは、AIを使うのか、ワークフローを変えるのか、データ構造を見直すのか、人の役割を変えるのか、などを組み合わせて考えます。解決策は、必ずしもAIとは限りません。
④ 実装・導入する
FDEは、自らコードを書くこともあれば、社内のエンジニアと協力することもあります。
重要なのは、「設計したものを実際に動かす」ところまで責任を持つことです。
⑤ 利用状況を確認する
現場で本当に使われているか。期待した効果が出ているか。品質は維持できているか。
必要であれば評価方法を追加し、改善を繰り返します。
OpenAIが求人でEval（評価）を重視しているのも、このためです。
⑥ プロダクトへ知見を戻す
現場で得られた知見を、プロダクトの改善、共通機能、ドキュメント、ベストプラクティスとして蓄積し、次の顧客へ活かしていきます。
ここまでが、一つの循環です。
FDEの成果は「納品」ではない
この流れを見ていると、FDEが作っているものは、システムそのものではないことが分かります。
最終的な成果は、顧客の現場で、新しい仕事の在り方が自然に回り始めること。
そのために必要なことを、技術・業務・運用を横断して進める。
これが、FDEという役割の中心にある考え方だと捉えています。
.
.
.
FDEの必要性
本当に難しいのは、仕事の理解
顧客の現場へ入り、課題を理解し、設計し、実装し、運用まで伴走する。
これは各社に共通して見られる考え方だと言えると思います。
その仕事は、誰が、何を判断し、どんな情報を使い、何を成果としているのか。
それを理解しなければ、どれだけ優れたシステムやAIを導入しても現場では使われません。
仕事は回り続けることを正義として継ぎ足し醤油のように、各会社の中で当事者もわからないほどに発達しています。
だからこそ、FDEという職種を確立する必要性が製品を提供する事業会社にとっても必要な人員投資として確立されつつあります。
実装から、仕事の再設計へ
だからこそ、FDEが扱う対象も少しずつ広がっているのではないでしょうか。
最初は、システムを作る役割だったものが、業務で使えるようにする。へと広がった。
さらに現在では、「顧客の仕事そのものを設計し直す。」ことまで求められ始めています。
ソフトウェアだけを見ているわけでもない。
業務だけを見ているわけでもない。
顧客の現実を理解し、それを技術へ落とし込み、現場へ定着させ、また改善する。
技術と現実を何度も往復しながら、少しずつ仕事を作り変えていく。
そういう仕事だと感じています。
