FDEは「最前線に派遣される技術者」
Forward Deployedとは軍事用語に由来する表現で、「前線に配置された」という意味です。FDEはエンジニアリングオフィスではなく、顧客の現場（=最前線）に物理的・組織的に近い位置で働きます。
普通のエンジニアと違うのは——
- 要件を"スペック"で受け取らない。現場で観察し、ヒアリングし、必要なら自分で業務を試す
- "納品物"より"顧客の業務が変わったか"を成果指標にする
- プロダクト改善の意思決定権を持つ。会議室経由ではなく現場で決める
SES・受託開発との違い
「人を派遣する」という意味ではSES（System Engineering Service）と似て見えますが、ロールの構造は本質的に違います。
| 項目 | SES | 受託開発 | FDE |
|---|---|---|---|
| 提供物 | 工数 | 納品物 | 業務変化 |
| 要件 | 先方が出す | 先方が出す | FDEが現場で発見 |
| 意思決定 | 顧客主導 | 合議 | FDEが現場で判断 |
| 関係 | 発注 - 受託 | 発注 - 受託 | パートナー |
| 成果指標 | 稼働率 | 納期・品質 | 業務インパクト |
なぜAI事業にFDEが効くのか
AIプロジェクトは「ドキュメント化されていない暗黙知」の上で動きます。スペック上は同じ業務でも、現場の動き方は会社によって違う。だからこそ、現場に入り込めるFDEが大きな差を生みます。
1. AIの精度は「データ前処理」で決まる
業務AI／RAGの精度はモデルではなく、データ前処理で決まります。前処理は「業務の意味」を理解しないと設計できない。現場の語彙、業務フロー、暗黙のルール——これらを観察できる人がいないと精度は出ません。
2. "使われるUI"は現場でしか分からない
業務AIは「精度80%でも使われないUI」より「精度65%でも使われるUI」が勝ちます。"使われるUI"は、ユーザーが業務のなかでどんな順序・タイミングで触るかを観察した人にしか設計できません。
3. SaaSの種が現場に転がっている
個別案件で見えた「業界共通の困りごと」は、次のSaaSへの種。FDEが現場で得た知見が、もふろぐ・riglogのような業界特化SaaSの出発点になります。
FDEは「いま現場で起きていること」と「次に作るプロダクト」を、同じ人がつないでくれる希少なロール。SaaSを連続で立ち上げる組織には、構造的に欠かせません。
MUがFDEを置く3つの理由
- AI事業はスペックで戦えない：業務の曖昧さを扱える人が必要。
- 自社SaaSの種を拾える：個別案件→SaaSへ昇華するパイプラインを成立させる。
- 顧客との長期関係を作る："受発注"を超えて、同じチームとして動ける。
採用要件 — FDEに求めるもの
技術力はもちろん前提として、より重視するのは「顧客の業務を理解しに行く好奇心」と「未定義の問題を構造化できる力」。コーディング以前のフェーズで価値を出す必要があるからです。
FDEとプロダクトマネージャーは違う
「それPdMじゃないの？」と聞かれることがありますが、FDEは"自分で実装する"ところが違います。PdMは方針を示す役割、FDEは現場で発見してその場でコードを書く役割。実装と現場の距離をゼロにすることが、最大の価値です。
これからFDEは増える
AIが「業務に着地する時代」の本格化に伴って、FDEを置く企業は確実に増えます。OpenAIもAnthropicも、最近の求人で"Forward Deployed Engineer"を明示的に募集しています。日本企業もこのモデルを意識せざるを得なくなるでしょう。
MU AI事業部は、FDEを事業の中核に据えた組織です。プロジェクトFDE・常駐FDE・JVの3パターンで、御社の事業に伴走することができます。