FDEとは何か——客先で本稼働まで通す職種（シリーズ1/5）

目次▼

1. 1結論を先に
2. 2まず用語の地図（この記事で使う言葉）
3. 3具体例：FDEの最短定義
4. 4なぜ今、需要が増えるか
5. 51週間の仕事は「コード行数」では測れない
6. 6向く人／向かない人（転職前の自己チェック）
7. 7「AIが使える」だけでは足りない理由
8. 8このシリーズでやること
9. 9いまの一手（本気の人／様子見の人）

「AIが使えるエンジニア」の求人票は増えた。とはいえ肩書きはバラバラで、中身もバラバラだ。そのなかで、ここ数年で輪郭がはっきりしてきた職種がある。Forward Deployed Engineer（FDE）——客先に出て、本稼働まで通すエンジニアだ。

このシリーズは、いま転職を本気で考えている人にも、まだ眺めるだけの人にも読めるように書く。第1回は「何者か／なぜ需要があるか／向き不向き」に絞る。勉強法や選考対策は第2回以降。

途中のビジネス用語には、その場で短い言い換えを添える。知っている人は読み飛ばしてよい。

この記事の使い方

• 決めること: 自分が想像している仕事が、FDEに近いのか／別職種なのか
• 決めないこと: まだ「どう勉強するか」「どの会社を受けるか」（それは後続回）
• 前提: 米系テックで広まった職種名を借りつつ、日本の導入プロジェクト（お客さんの業務にシステムを載せる案件）一般にも当てはめて書く
• 読者: キャリアチェンジを考える人、採用する側、「自分の仕事に近いかな？」と覗いた人——いずれも想定

結論を先に

問い	答え（短い）
FDEは何か	客先（顧客の職場・現場）で、プロダクトを本稼働（本番で日常使いされる状態）まで通すエンジニア
何ではないか	本社の社内プロダクトだけを書く人／助言だけして帰る人
なぜ今か	AI導入の成否は「モデルの性能表」より「業務フロー（現場の仕事の流れ）に載るか」で決まることが多い
向く人	実装ができ、曖昧な要望を合意できる形に落とし、客先の調整に耐えられる人
向かない人	コードだけ書きたい人／顧客との接触を避けたい人／完璧な仕様書待ちの人

まず用語の地図（この記事で使う言葉）

初めて読む人向けの早見表。本文でもまた使う。

用語	かみ砕いた意味
客先／顧客現場	発注した会社のオフィス・工場・店舗など、「実際に使う側」の場所
本社／プロダクト側	ソフトを作っている会社の内側。客先の外
導入	製品を置いただけにせず、その会社の仕事のやり方に載せる作業
本稼働（本番稼働）	デモや試験ではなく、毎日の業務で使われている状態
PoC（Proof of Concept／概念実証）	「理屈どおり動くか」を小さく試す段階。褒められやすいが、本稼働とは別物
要件定義	「何ができれば成功か」を文章や受け入れ条件に落とす作業
業務フロー／業務プロセス	現場で誰が何を入力し、誰が止め、誰が承認するかの流れ
情シス（情報システム部門）	社内のIT・権限・セキュリティの門番になりがちな部門
稟議・決裁	社内でお金や契約を通すための承認ルート。技術が正しくてもここで止まることがある
ステークホルダー	案件に口や決裁権を持つ人たち（現場ユーザー、情シス、法務、事業部長など）
責任分界点	「ここからはベンダー（売り手）／ここからは顧客」の線引き
運用移管	作り手が居なくなっても、顧客側（または運用チーム）が回せるように渡すこと
プリセールス／ソリューションコンサル	売る前〜提案の技術説明が主で、本稼働の泥まで背負わないことが多い役割
職務経歴書	転職で「何を成し遂げたか」を書く書類。履歴書（学歴・職歴の表）より中身が問われる

FDEの話は、この表の言葉が現場でぶつかり合う話だと思ってよい。

具体例：FDEの最短定義

FDEは次の三つを同じ人間が持つ職種だ。

1. 実装できる — スライドやPoCで終わらず、本番環境（実際の利用者・権限・データに近い場所）で動くものを出す
2. 客先に入れる — 要件がきれいな文書になっていない場所でも働ける
3. 通しきる — セキュリティ、権限、データ、運用、運用移管まで含めて「使われている」状態にする

どれか一つ欠けても、別の職種名の方が正確になる。

欠けているもの	実際に近い職種	かみ砕いた説明
実装	ソリューションコンサル／プリセールス	提案と説明は上手いが、コードとして残さないことが多い
客先	本社のプロダクトエンジニア	自社プロダクトを深く作るが、顧客の会議室には出にくい
通しきる	PoC屋	デモの拍手は取れるが、本稼働の泥を避けがち

日本の求人票では「フィールドエンジニア」「導入エンジニア」「カスタマーエンジニア」「ソリューションアーキテクト」など別名でも出る。名前より、三条件を満たすかで見た方が、採用のミスマッチは減る。

「AIエンジニア」という曖昧なラベルより、この三条件の方が、採用する側も受ける側も損をしにくい。

なぜ今、需要が増えるか

AIプロダクトの失敗の大半は、モデルの性能表だけでは説明できない。

• 顧客のデータが汚い／取れない／法務で止まる（個人情報・契約・社外持ち出し）
• 現場の業務フローが、プロダクト側の前提と食い違う
• 「誰が承認（決裁・チェック）ボタンを押すか」が決まっていない
• デモ環境では動くが、本番の権限設計（誰が何を見られるか）で止まる

ここを直すのは、本社のバックログ（やりたい作業の積み残しリスト）だけでは追いつかない。顧客の会議室とログのあいだを往復できるエンジニアが必要になる。それが FDE の需要だ。

生成AIの波は、この職種を「特別な精鋭枠」から「定常の採用枠」（毎期きちんと席が立つ）に押し上げている。理由は単純で、どの企業も「自社の業務に載せたい」と言い、載せる作業は会社ごとに違うからだ。

転職を考えていなくても、「自社のAI導入がなぜ止まるか」を説明する図としても使える。

1週間の仕事は「コード行数」では測れない

典型的な1週間（架空だが、現場感は寄せてある）:

曜日	中心作業	成果の単位（何が残るか）
月	客先で現状の業務フロー棚卸し	「誰が何を入力し、どこで止まるか」の図
火	薄い縦スライス（端から端まで通る最小の機能）の実装	本番相当で動く1本の経路
水	権限・監査ログの穴埋め	情シス／セキュリティ審査が通せる差分
木	現場ユーザー試験と失敗の回収	「使えない理由」のリストと修正
金	引き継ぎと次スプリント（短い開発の区切り）の境界	顧客側が独力で回せる範囲の明示

評価で効きやすいのは「GitHubのスター」より、通った経路の本数と現場が独力で回せる範囲だ。ここを分かっていないと、面接で「個人の趣味リポジトリ」を自慢して噛み合わない。

くだけて言えば、FDEの成績表は「かっこいいデモ」より「本稼働して、自分が居なくても回る」に近い。

向く人／向かない人（転職前の自己チェック）

まだ応募しなくても、ここだけは先に見てよい。

向くサイン

• 仕様書がない週でも、検証できる仮説を自分で置ける
• 「動かない」を人のせいにせず、ログと権限から切り分けられる
• 顧客の言葉を、エンジニアリングの契約（入出力・失敗時の振る舞い・権限）に翻訳できる
• 完璧より、通る薄いスライスを何度も出せる
• ステークホルダー（現場・情シス・事業側）の利害がズレても、合意形成（関係者が「これで進めてよい」と言える線）を取りにいける

向かないサイン

• チケット（作業依頼）がきれいに切られるまで手を動かしたくない
• 顧客との会話を「営業の仕事」と切り捨てる
• PoCの称賛で満足し、本稼働の泥を避けたい
• 一人でライブラリを深掘りする時間が仕事のすべてであってほしい
• 稟議や審査の待ちに、気がすり減って仕方ない（待ちも仕事の一部だと感じられない）

向かないことは恥ではない。本社プロダクトやリサーチの方が向いている人は多い。職種のミスマッチをシリーズの最初で潰すのが、この回の仕事だ。興味半分で読んでいる人は、「自分は向かない側だな」と分かった時点で十分価値がある。

「AIが使える」だけでは足りない理由

FDE採用でよく見かける誤解:

1. プロンプトが上手い = FDE — 客先ではプロンプトより、権限とデータの取り扱い合意が勝つ
2. Kaggle / ベンチが強い = FDE — 競技用データと、顧客の本番データは別物
3. スタートアップで何でも屋だった = 自動的にFDE — 何でも屋経験は強みだが、「本稼働まで通しきった」証拠が要る
4. 英語の職種名がある会社だけがFDE — 日本企業の導入部隊にも、実質FDEはいる。求人票の表記を信じすぎない

逆に、従来型の実装力（API、型、監視、デプロイ）があり、顧客折衝（相手とすり合わせて決める対話）に耐性がある人は、最新モデルの暗記より先に候補になる。モデル知識は第2回のスキル地図で足せばよい。

このシリーズでやること

回	テーマ	読後に分かること
1（本稿）	職種の正体	自分が FDE を狙う／狙わない判断の軸
2	スキル地図	実装・顧客・運用の何をどの順で埋めるか
3	証拠の作り方	職務経歴書に載せる「現場で通した痕跡」の残し方
4	選考の回し方	ケース面接・ロールプレイで見られる観点
5	最初の90日	客先で信頼をどう作り、どう壊すか

一覧は常に FDEシリーズハブ に置く。転職を決めていなくても、第1〜2回だけ地図として読める構成にする。

いまの一手（本気の人／様子見の人）

本気で狙う人

1. 直近で「自分が通しきった」仕事を1つ書き出す（誰がユーザーで、本稼働したかまで）
2. それが無いなら、小さな縦スライスを本番相当で1本通す計画を立てる
3. 肩書きに「AI」を足す前に、三条件（実装・客先・通しきる）を自己採点する

まだ様子見の人

1. 自社（または前職）のAI／DX案件で、どこがPoC止まりだったかを1つ思い出す
2. その詰まりが「モデル」だったか、「業務フロー・権限・決裁」だったかを分ける
3. 後者に寄るなら、FDE的な役割が組織に不足していないかだけメモする

次の 第2回（スキル地図） では、実装・顧客・運用の三層で必須スキルを、同じように用語つきで分解する。

※この記事の内容についてご意見・ご指摘がある場合は、お問い合わせよりご連絡ください。確認の上、必要に応じて追記・訂正します。