FDEとは?顧客現場で課題定義から事業推進まで担う職種を解説

- 課題発見顧客現場に入り込み、表面的な要求の奥にある本質的課題を掘り起こす
- 要件定義仕様書を待たず、顧客と同じ現場で「何を作るべきか」を定義する
- 実装生成AIも活用し、その場で素早く形にして顧客と目線を合わせる
- 事業推進機能の完成で終わらせず、顧客の課題解決・事業成果まで前に進める
- 起点は与えられた仕様・要件
- 実装が業務時間の大半
- 顧客とはPM等を経由して間接的に関わる
- 成果は機能の完成・品質で測る
- 起点は顧客現場での課題発見
- 実装は業務時間の半分未満
- 顧客現場に直接常駐・伴走する
- 成果は顧客の課題解決・事業成果で測る
FDE(Forward Deployed Engineer)とは?
FDEとは、顧客現場に常駐して課題発見から実装・事業推進までを一気通貫で担う、Palantir発の越境型エンジニアです。
FDE(Forward Deployed Engineer)は、オフィスで仕様書が届くのを待つエンジニアではありません。顧客の業務現場に入り込んで本当の課題を掘り起こし、ソフトウェアで解決します。本記事でいう「越境型」とは、実装だけで終わらず、課題の発見・要件の定義・事業としての推進までを一人で横断して担うことを指します。
多くのソフトウェア開発は分業を前提にしています。顧客の要望をいったん要件書に落とし込み、それを受け取ったエンジニアが実装する流れです。FDEはこの分業の壁を取り払い、顧客と同じ場所で課題を見て、その場で解決策を組み立てます。そのためFDEは、エンジニアでありながらコンサルタントや事業担当者に近い動き方をします。
FDEの語源と定義は?
FDEはForward Deployed Engineerの略で、顧客現場に常駐する「前線配備エンジニア」を意味します。
「前線」は顧客の業務現場そのものを、「配備」はそこにエンジニアが常駐して伴走することを指します。FDEは開発チームの後方で仕様を受け取る存在ではなく、顧客と同じ現場に身を置き、課題の最前線に立ちます。
FDEが向き合うのは、あらかじめ整理された要件ではなく、現場に埋もれたままの未整理な課題です。「現場に踏み込む」というFDEの本質は、Forward Deployedという名称そのものに表れています。
FDEは何をする仕事か?
FDEの仕事は、課題発見・要件定義・実装・事業推進の4工程を、顧客現場で一人が途切れさせずに回すことです。
従来の分業体制では、4つの工程がそれぞれ別の担当者に分かれがちです。FDEはこれらを一人でつなぎ、工程間の受け渡しで生じる認識のズレを最小化します。
| 工程 | FDEが担う中身 |
|---|---|
| 課題発見 | 顧客現場に入り込み、表面的な要求の奥にある本質的課題を掘り起こす |
| 要件定義 | 「何を作るべきか」を、仕様書を待たずに顧客と同じ現場で定義する |
| 実装 | 生成AIも活用し、その場で素早く形にして顧客と目線を合わせる |
| 事業推進 | 機能の完成で終わらせず、顧客の課題解決・事業成果まで前に進める |
FDEの価値は、どれか一つの工程の専門性にあるのではなく、4工程を途切れさせずに回し切ることにあります。
FDEを確立したPalantirとその広がりは?
FDEは米Palantirが2010年代に体系化した職種で、近年はOpenAIやスタートアップ各社にも広がっています。
Palantir Technologiesは、顧客の複雑な業務データと現場課題に深く入り込む働き方として、FDEというロールを確立しました。FDEの起源はPalantirにありますが、現在ではOpenAIやスタートアップ各社にも広がり、Palantir一社だけの職種ではなくなりつつあります。
背景には、ソフトウェアの導入をゴールとせず、顧客の課題解決そのものを成果とみなす考え方があると考えられます。この考え方がPalantir以外の企業にも受け入れられ始めている、というのが現在の流れです。
日本におけるFDEの位置づけは?
日本ではデータ活用や業務DXの需要拡大を背景に、2020年代半ばからFDEの採用が広がっています。
本記事の監修者である田巻氏(VACAN Technologies 代表取締役)は、国内でFDEの実務を実践してきた一人です。田巻氏は親会社の株式会社バカンで混雑可視化基盤「vCore」を立ち上げ、現場での課題発見からアーキテクチャ設計・実装・事業推進までを一気通貫で担ってきました。
田巻氏によれば、FDEに特有なのは即応性です。顧客の「このプロダクトを導入したい」という表面的な要求の奥にある本質的課題をその場で捉え、生成AIも活用して素早く形にし、顧客と目線を合わせます。通常のプロジェクト体制では受けきれないこうした相談があることが、VACAN Technologies設立の背景にもなりました。
データ活用や業務DXへの需要が高まるなか、現場に入り込んで課題から事業を立ち上げる担い手の重要性は、国内でも増していると考えられます。
FDEとソフトウェアエンジニアの違いは?
最大の違いは起点と時間配分です。FDEは課題定義から始め、実装は業務時間の半分未満に抑えます。
一般的なソフトウェアエンジニアは、与えられた仕様の実装に集中します。これに対してFDEは、「何を作るべきか」を顧客現場で自ら定義するところから始めます。この「何を作るべきか」を決める工程を担うかどうかが、FDEと従来型のエンジニアを分ける境界線です。
業務時間の使い方はどう違う?
FDEは実装を業務時間の半分未満に抑え、残りを顧客ヒアリング・要件整理・関係構築に充てています。
田巻氏の実務感覚でも、FDEは純粋な実装よりも、顧客現場でのヒアリング・要件整理・関係構築に多くの時間を割いています。実装は業務時間の半分未満というのが実情です。
FDEにとって実装スキルはあくまで土台であり、コードを書く前の「課題を定義する時間」が実装と同じくらい重い比重を占めます。ただし、実装時間が短いことは技術力が不要という意味ではありません。FDEは、技術力を課題定義と組み合わせて使う職種です。
顧客との距離と成果指標はどう違う?
FDEは顧客現場に直接常駐し、成果は機能の完成ではなく、顧客の課題解決や事業成果で測られます。
一般的なソフトウェアエンジニアは、プロジェクトマネージャーなどを経由して顧客と間接的に関わり、機能の完成度や品質で評価されます。一方FDEは顧客の現場に直接入り込み、課題が解決されたか、事業として前に進んだかで評価されます。両者の違いを6つの観点で整理すると、次の表の通りです。
| 観点 | ソフトウェアエンジニア(一般) | FDE(Forward Deployed Engineer) |
|---|---|---|
| 主な起点 | 与えられた仕様・要件 | 顧客現場での課題発見 |
| 実装時間の割合 | 業務時間の大半 | 半分未満(残りは顧客接点) |
| 顧客との距離 | 間接的(PM等を経由) | 直接常駐・伴走 |
| 求められる越境 | 技術中心 | 技術×ビジネスの両輪 |
| 成果の測り方 | 機能の完成・品質 | 顧客の課題解決・事業成果 |
| ツール活用 | 開発効率化中心 | 生成AIで即時プロトタイピング |
FDEはコンサルタントやPMとどう違う?
FDEはコンサルタントやPMの役割も担いつつ、自ら実装して事業を前に進めるところまで引き受けます。
FDEは、エンジニアリング能力を土台に、コンサルタントやプロダクトマネージャーの役割まで一人で横断します。課題を定義するだけ、方向づけるだけで終わらず、その場で形にして事業として前に進めます。
そのためFDEは、技術力の高さだけでも、提案力の高さだけでも評価しきれない職種です。FDEを評価するには、課題定義から事業推進までを一貫して担えるかという視点が欠かせません。
FDEに求められるスキルとは?
FDEに求められるのは、課題定義・技術×ビジネスの越境・即応的プロトタイピング・信頼構築の4つの力です。
田巻氏の観察では、FDEで伸びる人と詰まる人を分けるのは、技術とビジネスを越境できるかどうか、そして課題を自らヒアリングして定義し、顧客と信頼を築けるかどうかです。仕様を実装する技術力だけでは頭打ちになりやすく、現場で課題そのものを定義する力が成長を左右します。
FDEで伸びる人と詰まる人の違いは?
分かれ目は、技術とビジネスを越境し、自ら課題を定義して顧客と信頼を築けるかどうかにあります。
田巻氏が現場で見てきた違いを3つの観点で整理すると、次の表の通りです。
| 観点 | FDEで伸びる人 | FDEで詰まる人 |
|---|---|---|
| 越境 | 技術とビジネスを越境できる | 技術かビジネスの一方に閉じる |
| 課題の扱い | 自らヒアリングして課題を定義する | 仕様を実装する技術力だけで勝負する |
| 顧客との関係 | 顧客と信頼を築ける | 顧客との信頼構築が進まない |
3つの観点はいずれも、技術力そのものではなく、技術力を現場でどう使うかに関わるものです。
課題定義力とヒアリング力はなぜ最優先か?
課題を正しく定義できなければ、どれほど実装力が高くても的外れなものを作ってしまうからです。
顧客が口にする「このプロダクトを導入したい」という要求は、多くの場合、本当の課題が表に現れた一部にすぎません。FDEはこの言葉をそのまま受け取らず、なぜそれが必要なのかを現場で問い直して真の課題を掘り起こします。
田巻氏が重視するのも、言葉の裏にある真の課題をその場で捉える姿勢です。ヒアリングによる課題定義は、FDEの仕事すべての出発点になります。
技術×ビジネスの越境力とは何か?
越境力とは、アーキテクチャ設計と事業推進の両方を一人で担い、技術とビジネスを接続する力のことです。
田巻氏自身も、アーキテクチャ設計からプロジェクト推進まで、役割の枠にとらわれず事業を牽引してきました。技術側に閉じると「作れるが売れないもの」に、ビジネス側に閉じると「売りたいが作れないもの」に陥りがちです。
FDEは技術とビジネスを自分の中で接続し、技術的に実現可能で、かつ事業として意味のある解を導きます。
即応的なプロトタイピングと信頼構築はどう効く?
生成AIでその場で形にすると顧客との認識のズレを早く解消でき、その積み重ねが長期的な信頼になります。
田巻氏によれば、生成AIも活用して素早く形にし、顧客と目線を合わせる即応性こそがFDE特有の強みです。課題を言葉で議論するだけでなく、その場でプロトタイプとして見せることで、顧客との認識のズレを早い段階で解消できます。
こうした即応の積み重ねが、顧客現場での長期的な信頼につながります。
4つのスキルはどう連動する?
4つの力は独立しておらず、課題定義から信頼構築までを一連の循環として現場で回し続けるものです。
| スキル領域 | 具体的な中身 |
|---|---|
| 課題定義力 | 表面的要求の奥にある本質的課題をヒアリングで特定する |
| 技術×ビジネス越境 | アーキテクチャ設計と事業推進の双方を担う |
| 即応的なプロトタイピング | 生成AIを活用し、その場で形にして目線を合わせる |
| 信頼構築 | 顧客現場に伴走し、長期的な関係を築く |
FDEは課題を定義し、越境して解を設計し、すぐに形にして信頼を積み上げます。信頼が深まるほど顧客から本質的な課題を打ち明けてもらえるようになり、次の課題定義の精度も上がります。FDEは、この循環を顧客現場で繰り返す職種です。
FDEのキャリアパスはどう広がる?
FDEのキャリアパスは、ソリューションアーキテクト、プロダクトマネージャー、事業責任者・経営層へと広がります。
FDEで培う課題定義力と越境力は、上流のポジションで求められる能力と重なります。そのためFDEは、エンジニアとしての到達点ではなく、より広い役割へ進むための足がかりになります。
FDEの次のポジションは?
FDEの次は、ソリューションアーキテクトやプロダクトマネージャー、事業責任者・経営層へ進む例が見られます。
| 次のポジション | FDE経験との接続点 |
|---|---|
| ソリューションアーキテクト | 技術とビジネスを越境した経験を、システム全体の設計に活かす |
| プロダクトマネージャー | 現場で課題を定義した経験を、プロダクトの方向づけに活かす |
| 事業責任者・経営層 | 課題から事業を立ち上げた経験を、事業全体の牽引に活かす |
田巻氏自身も、株式会社バカンでのFDE的な実践を積み重ねた先で、VACAN Technologiesの代表取締役に就任しました。FDEの経験が経営層のポジションにまでつながりうることを示す一例です。
なぜFDEが事業人材の起点になるのか?
FDEが日々行う「課題から事業を立ち上げる」経験は、事業責任者や経営層に求められる経験と同じ性質だからです。
FDEが日常的に行っているのは、現場の課題を発見し、事業として成り立つ解に結び付けることです。これは事業責任者や経営層が担う仕事と同じ構造を持ちます。
FDEは技術者としてのキャリアが行き止まる場所ではありません。エンジニアリングを土台に、事業を動かす人材へと広がっていく起点です。
FDEで身につく力は他の領域でも通用する?
通用します。FDEで培う力は特定の製品や技術に依存せず、どの事業領域でも使える普遍的な力だからです。
FDEが現場で繰り返しているのは、「課題を定義し、解決し、前に進める」ことです。この力は、扱う製品や技術スタックが変わっても失われません。そのためFDEを経た人材は、ソリューションアーキテクトやプロダクトマネージャー、さらには経営層へと自然につながっていきます。
監修:田巻氏(VACAN Technologies 代表取締役)。本記事は監修者の公開発言・経歴に基づく一次情報と、FDEに関する一般的な傾向をもとに構成しています。





