FDEの求人票にある「オーナーシップ」という言葉は、やる気の話ではありません。上長の承認なしにその場で決めて、外さない。そういう意味です。そしてこれは個人のスキルの話である以前に、会社が権限を渡しているかどうかという構造の話でもあります。この記事では、FDEという職種名を最近見かけるようになったエンジニア向けに、求人票に並ぶ抽象語を具体的な行動へ分解していきます。
FDEとは何か——「1つの機能を多くの顧客へ」の逆
FDEはForward Deployed Engineerの略です。「Forward Deployed」は元々軍事用語で、前線に展開する部隊を指します。職種として確立したのはPalantirで、2010年代からこの役割を置いています。同社ではFDSE（Forward Deployed Software Engineer）とも呼びます。
Palantirの採用ページの表現が、この職種の構造を一番よく表しています。通常のエンジニアが「1つの機能を多くの顧客向けに」開発するのに対し、FDSEは「1つの顧客に対して多くの機能を」実装する。この対比が軸です。顧客の現場に常駐し、事業課題の特定からシステムの運用・定着までを一貫して担います。
Forward Deployed Engineer（FDE）とは——PalantirのFDSE定義と日本での広がりFDE（Forward Deployed Engineer）とは、顧客の業務現場に入り込み、AIやデータプラットフォームを活用して課題を解決するエンジニア職です。直訳すると「前線配備エンジニア」を意味し、米国のデータ分析 […]exawizards.com
納品して終わり、ではありません。「現場で実際に使われる状態にする」までが責任範囲です。さらに、現場で得た情報を本社の開発チームに戻し、そこで解決した課題が製品の標準機能に組み込まれていくループを回すのも役割のうちです。実際の採用要件はPalantirのFDSE求人で確認できます。使用言語はPython・Java・C++・TypeScriptなどと幅広く、特定技術より課題解決の側に重心があります。
この職種はAI企業にも広がっています。OpenAIのFDEは「Model Deployment for Business」配下、AnthropicはApplied AIチーム配下に置かれているとされています。DeloitteのPalantir FDE求人には平均50%の出張、LLMのAPI・マイクロサービス・イベント駆動での統合、MLOps/LLMOpsが並び、AccentureのFDE求人には経営層に技術を説明する力や、要件・設計メモ・ランブックの記述力が挙がっています。コンサルティングファームまで職種名を採用している段階です。
日本の「FDE募集」には別物が混ざっている
ここで一つ、注意点があります。海外型のFDEは「自社プロダクトを顧客業務に深く組み込む役割」です。ところが日本では、GPT・Claude・Geminiなど既存のAIプロダクトを使って企業のAI導入・業務改善を支援する人材まで含めてFDEと呼ぶケースが増えています。海外型と日本型の分岐点は自社プロダクトの有無にあります。
つまり日本の「FDE募集」には、実態としてAIコンサル＋実装屋に近いものが混ざっています。冒頭の会話で「まあ日本は自社プロダクトがあまりないしね」と返した通りで、この構造のずれを知らずに求人票を読むと、同じ職種名でまったく違う仕事に応募することになります。
「意思決定できる」を6つの行動に分解する
では海外型のFDEに求められる「意思決定できる力」とは何か。求人票の記述を分解していくと、次の6つの行動に落ちます。なお、この6分解はPalantirや各社の公式定義ではなく、複数の求人票の記述を私が整理した解釈です。
- スコープを切る——「AIで業務を効率化したい」という要望を、着手できる一つの業務に絞る。同時に「今回やらないこと」を先に宣言する。
- その場で答える——会議中に「できる／できない／代わりにこれ」を持ち帰らずに返す。実装コストが頭に入っている前提の判断です。
- 決裁者を見極める——誰の承認で物が動くかを早期に特定し、そこに直接話す。窓口担当だけと握って止まる状態を避ける。
- 撤退線を引く——効果が出ない機能を自分から止め、別の業務に張り替える。沈没コストを顧客ごと背負わない。
- 個別か一般化か——この顧客向けの実装を本体プロダクトの標準機能に戻すか、その場限りで閉じるか。自社の資産設計の判断です。
- リスクを飲む線——精度・情報漏洩・法務のどこまでを許容して本番に出すか。安全側に倒し続けると、永遠に本番に出ません。
一つずつは、受託開発でも部分的に経験する場面です。ただFDEはこの6つを、現場で、日常的に、自分の名前でやります。
6つに共通するのは「持ち帰らない」こと
この6つを並べて気づくのは、全部に共通する動きがあることです。「持ち帰らない」。SIや受託なら一度社内に持ち帰って合意を取るのが普通の場面で、その場で決めて、責任も持つ。求人票の「オーナーシップ」「アンビギュイティ耐性」という抽象語の正体は、これだと考えています。
そしてもう一つ気づきます。「持ち帰らずに決める」は、会社側が権限を渡していないと成立しません。個人のスキル要件だと思って読んでいたものが、実は組織構造の要件でもあった。ここがこの記事で一番言いたいところです。どれだけ判断力のある人を採っても、決裁ラインが長い会社に置けば、その人は「持ち帰る人」になります。
政治は2種類ある——顧客側は職務、自社側は構造
「意思決定」を掘っていくと政治の話になります。冒頭の会話で「政治的な部分か」と一言で返しましたが、この政治は2種類に分けて考える必要があります。
顧客側の政治は、職務そのものです。決裁者が誰か、どの部署が既存業務を握っていて何を失うと反対するか、現場の本音はどうか。ここを読まずに技術的に正しいものを作ると、使われずに終わります。海外型FDEに高い報酬が払われている理由の相当部分はここだと見ています。
自社側の政治は、別物です。裁量を渡すと言いながら実際は上長承認が要る。プロダクトチームが現場の要望を受け付けない。営業が売った内容とFDEが実現できることがずれている。これらは会社の構造の問題なので、個人では動かせません。
見分け方はシンプルです。前者は「顧客の組織を理解する仕事」、後者は「自社の機能不全を人力で吸収する仕事」。応募前の面談で確認するなら、直近のFDEが実際にどこまで自分で決めているか、プロダクトチームとの距離はどうかを、具体例で聞くのが確実です。「裁量があります」という回答ではなく、事例を聞く。求人票のチェックポイントは、自分のスキルが足りるかより先に「その裁量が実在するか」です。
技術要件は広いが、詰まる場所は2つに偏っている
技術要件も見ておきます。求人票にはフルスタック・クラウド・データ・MLと幅広く並びますが、実際に仕事が詰まるポイントは偏っています。FDE求人の傾向をまとめた2026年のガイドでも、Python/TypeScriptにSQL/Spark、クラウドとコンテナを重ねたT字型プロフィールが挙がっていますが、優先順位をつけるとこうなります。
- 顧客のデータに触れる力（最重要）——FDEの仕事が止まる原因の大半は、モデルでもUIでもなくデータです。基幹システムの汚いテーブル、命名規則のない列、正規化されていないマスタ、Excelで運用されている業務データ。求人にSpark・dbt・Airflow・データモデリングが並ぶのは、この意味です。
- エンタープライズITへの接続——SAML/OIDCでのSSO、AD連携、閉域網やオンプレ、既存の認可モデルへの合流。技術的難易度というより「知っているかどうか」で、知らないと導入が数か月止まります。
- LLMを本番品質にするループ——プロンプトを書く部分ではなく、評価データセットを作り、精度を数値で示し、リグレッションを検知する部分。「なんとなく良さそう」では顧客が納得しないので、evalとオブザーバビリティが実質必須です。
- 一人で二週間で動くものを出す速度——分業前提の設計力より、雑でも触れるものを最短で置く力。
- セキュリティとデータの所在——どのデータがどこに出ていくか、テナント分離、監査ログ。
3のevalについては、公開前チェックを決定的ルールとLLM審査の2層に分ける設計を別記事に書いています。品質を数値と仕組みで示す考え方は、FDEの文脈でもそのまま使えます。
AIエージェントの公開前チェックは2層に分ける｜決定的ルールとLLM審査の設計AIエージェントに公開作業を任せるときのチェック機構を「決定的に落とす層」と「LLMに判断させる層」の2層に分けて運用している実装記録。GitHubがalt textチェックで公開した同じ層分けの設計と突き合わせ、誤検知で審査が信用を失わないための逃げ道の作り方、PASSを床として扱う考え方をまとめます。www.tentspace.net
モダンな構成に強いことは、そのままFDEの強さにならない
この優先順位を自分に当てはめてみました。私の場合、強いのは4です。サーバーレス中心のフルスタックで、受託で複数案件を並行して回しているので、一人で短期間に動くものを出すのは日常です。3も部分的に持っています。Langfuseでのオブザーバビリティ、RAG構成の実装経験。5もAWS中心のクラウドアーキテクト経験が効きます。
薄いのは1と2でした。AWSのマネージド構成やDynamoDB中心の設計は、レガシーな業務DBを掘る作業とはかなり別物です。SAML・AD・閉域網まわりも、自社プロダクトやモバイル受託ではあまり触りません。
つまり、モダンなサーバーレス構成が得意でも、FDEの技術的ボトルネックはカバーされない。ギャップは「新しい技術を知っているか」ではなく「古くて汚いものに触れてきたか」の側にあります。同じようにモダンスタック中心でやってきた人は、たぶん同じ形のギャップを持っています。位置を知っておくだけでも、求人票の読み方が変わるはずです。
スキルを寄せる前に、どう関わるかを決める
最後に構造の話へ戻ります。海外型FDEは、自社プロダクトを持つ企業の社員ポジションで、勤務地も都市に紐づきます。地方拠点のフリーランスという形とは、スキル以前に構造が違います。
だから判断の順番はこうなります。まず、FDEという関わり方（社員・常駐・1顧客に深く）を選ぶのかを決める。それから、選ぶならデータとエンタープライズITのギャップを埋めにいく。選ばないなら、6つの意思決定行動だけを持ち帰る。「持ち帰らない」働き方は、受託でも契約と信頼の設計次第で部分的に作れます。
FDEの求人票は、職種の説明である以上に「その会社が現場へどれだけ権限を渡すか」の宣言です。抽象語のまま憧れる必要も、諦める必要もありません。分解して、裁量の実在を確かめて、自分の関わり方を決める。それがこの職種名との正しい付き合い方だと考えています。