FDEの仕事内容とは？現場から定着まで担うロールの全体像

FDEという職種を「フォワード・デプロイド・エンジニア（Forward Deployed Engineer）」と正確に説明できる人はまだ多くない。ソフトウェア企業Palantirが世界に広めたこのロールは、日本においても徐々に認知が広がりつつある。

採用する側も、なりたい側も、まず問うのは同じことだ——FDEは実際に何をする人なのか。

FDEとは何者か——コンサルでも開発者でもない理由

FDEの定義を一文で言うと、顧客の現場に入り、業務課題の特定から実装・定着まで一気通貫で担う職種だ。

コンサルタントは課題を分析して提言書を出す。エンジニアはシステムを実装する。プロダクトマネージャーは要件を整理してロードマップを引く。FDEはその三つをひとりで、あるいは小さなチームでこなす。スコープが広い分、担当者に求められる幅も必然的に大きくなる。

FDEの独自性は「現場に物理的に入ること」にある。オフィスやチャットの外から指示するのではなく、顧客の業務フローの中に身を置き、ボトルネックを自分の目で確認する。見えないものは言語化できない、という前提がこの職種の出発点にある。

スコープを整理すると、次の四工程になる。

1. 課題の特定——ヒアリングと観察で業務上の摩擦を発見する
2. 要件の言語化——「何を解きたいか」を開発可能な粒度に落とす
3. 実装——プロトタイプまたは本番環境への組み込みを行う
4. 定着支援——ユーザーが自走できる状態になるまで伴走する

ITベンダーが「業務課題」を解けない構造的な理由でも触れたように、納品物に最後まで責任を持つ存在がいなければ、現場への定着は難しい。FDEはその「最後まで」を担うロールとして機能する。

現場に入ってから定着まで——FDEの一日の動きと工程

典型的なFDEの一日は、午前中が現場の観察・ヒアリングで始まり、午後が実装や設定作業に充てられる。夕方に短い振り返りを挟み、翌日の優先順位を整理するサイクルが多い。

特徴的なのは「調査と実装が同じ日に起きる」点だ。従来の開発プロジェクトでは要件定義フェーズが終わってから開発が始まる。FDEは現場で得た気づきをその日のうちにコードや設定に反映し、翌朝には担当者に触ってもらう。仮説と検証のループが非常に短い。

要件が完成してから動くのではなく、動かしながら要件を完成させていく——FDEの仕事はその繰り返しだ。

このアプローチは、現場の担当者にとっても「自分たちの言葉が実装に反映されていく」実感を生む。ドキュメントを渡して終わりではなく、画面が変わることで理解が深まる。それが定着率の差になって現れる。

FDEとアジャイルの関係——手法ではなくロールとして見る

「FDEとアジャイルはどう違うのか」という問いは、両者を同じ軸で比べようとするために生まれる。

整理すると、アジャイルは開発手法であり、FDEはロール（職種）だ。アジャイルのスプリント構造はFDEの働き方と相性が良く、FDEがアジャイルチームの中で機能することも多い。ただしFDEはアジャイルチームの外にいることもある——既存の運用チームに一時的に入り込み、ツールを設定しながら課題を整理する形もFDEの仕事だ。

アジャイルが「チームをどう動かすか」の設計であるのに対し、FDEは「誰が現場と実装の橋渡しをするか」という役割の答えだ。両者は対立しない。

---

FDEに近い動き方を外部に委ねるなら、現場への入り方から実装・定着までをひとつの流れとして設計しているDX伴走支援「しぼる」が参考になる。また、外部CxOは中小企業のDX責任者不足を埋められるかで整理したように、外部から入るロールには複数の形態がある。FDEはそのなかでも「実装まで手を動かす」点で固有のポジションを持つ。

職種として雇う場合も、ロールとして外部に委ねる場合も、まず「課題の特定から定着まで誰が通しで担うか」を問うことが出発点になる。