FDEを直訳すると「前線に配備されたエンジニア」。その名が示す通り、FDEはもともと、顧客の拠点に出向いてソフトウェアを導入し、稼働させる役割として生まれた。

　2008年頃、Palantirにおける初期のFDEは、顧客のオンプレミス環境にソフトウェアを導入し、システムの安定稼働を維持する仕事を担っていた。サーバの構築や障害対応など、現在でいうDevOpsやインフラ運用に近い役割だ。

　顧客のシステムが深夜に停止すれば、FDEが現地に赴いて復旧させることもあった。華やかなコンサルティングではなく、顧客のシステムを動かし続けることが主な仕事だった。

　2012年頃になると、Palantirのサービス運用は安定化し、FDEの仕事は顧客が複数の場所に保有するデータの統合へと拡大した。データ統合ソフトウェアは、データが取り込まれて初めて価値を持つ。そこでFDEは、顧客環境を理解し、データを接続・整理し、業務に合った形でモデル化する役割を担うようになった。

　2016年以降、FDEは「統合し整理したデータをどのように業務に役立てるか」をミッションとするようになった。そこでFDEは、ダッシュボードや個別アプリケーションを構築。顧客のデータや業務を最もよく理解しているFDEが、そのままソリューション開発を担うようになったのだ。

FDEの最大の強みは「顧客の成果に責任を持つこと」

　ミューラー氏によると、2020年以降のFDEには、インフラ運用、データ統合、アプリケーション開発、業務分析、顧客教育、利用促進、組織への定着支援など、幅広い能力が求められるようになった。顧客自身がプラットフォームを使い、データ統合やアプリケーション構築を進められるようにするためだ。

現在のFDEに求められるスキル

　では、現在のFDEにはどのようなスキルが求められているのか。ミューラー氏は、複数の企業が公開するFDEの求人要件をまとめた。その結果は以下だ。

• 高度なソフトウェア開発能力
• 顧客との折衝、営業経験
• ソリューション設計能力
• システム導入、運用能力
• 顧客を教育する能力

　つまり、FDEという名称から、FDEが具体的にどのような業務を遂行する立場なのか、判断することは困難だとミューラー氏は指摘する。企業によってはインフラ担当者に近く、別の企業ではITコンサルタントやソリューションアーキテクト、アプリケーションエンジニアに近い場合もある。ただし各役割には共通点がある。顧客に対して直接的な責任を負うということだ。

　例えば製品開発チームは、全顧客に共通する機能や長期的な製品ロードマップを重視する。一方FDEは、目の前の顧客が抱える問題を解決し、製品を実際の業務で使える状態にすることを優先する。

　顧客の環境で製品が動かないなら原因を調べ、データがつながらないなら統合方法を考え、現場に定着しないなら利用方法や業務フローを見直す。FDEの強みは、技術を提供するだけでなく、顧客が成果を得られるようにするまでコミットする点にある。

AI時代にFDEが注目される理由

　FDEの重要性が高まっている背景には、生成AIやコーディングエージェントの普及がある。

　AIを使えば、プログラムの試作や改修にかかる時間を短縮できる。FDEは顧客から要望を聞いて開発部門に持ち帰るだけでなく、その場で試作品を作り、検証し、実際に稼働するソリューションまで構築しやすくなる。

　これまで個別開発は、費用と期間の面から対象を限定せざるを得なかった。コードを生成するコストが下がれば、顧客固有の業務に合わせてソフトウェアを調整する余地が広がる。

　一方FDEは、顧客との会話から得た情報を製品改善にも反映できる。顧客がどの機能でつまずいたのか、既存システムとの連携で何が不足しているのかを把握し、製品開発チームへ直接伝えられるためだ。

　ミューラー氏によれば、FDEは顧客対応や試作にとどまらず、コーディングエージェントを利用して、エンドツーエンドのソリューションを構築できるようになる。一方、製品開発を担うエンジニアも、顧客や業務を意識する必要性が高まる。

　その結果、FDE、プロダクトエンジニア、AIエンジニア、ソリューションエンジニアといった職種の境界は曖昧になるとミューラー氏は予測している。エンジニア全体が、製品を作るだけでなく、顧客が成果を得るところまで考える方向へ近づくという見方だ。

情シスはFDEに何を任せるべきか

　情シスがFDEを活用する際は、単なる追加の開発要員として扱わないことが重要である。

　FDEの価値を引き出しやすいのは、製品を導入するだけでは解決できず、業務、データ、既存システムを横断した調整が必要な場面だ。

　例えば、生成AIを社内問い合わせ対応に利用する場合、AIモデルを契約しただけでは業務に使えるとは限らない。社内文書を検索できるようにし、利用者の権限に応じて参照範囲を制御し、回答できない質問を既存の問い合わせ窓口へ引き継ぐ仕組みも必要になる。

　FDEには、こうした一連の設計と実装を任せることができる。具体的には、次のような業務が対象だ。

既存システムやデータとの接続

　社内に分散した文書、データベース、SaaSを調査し、AIや新しいプラットフォームから利用できる形に整える。

現場業務に合わせたソリューションの試作

　要件定義書だけを基に開発するのではなく、利用部門の担当者と対話しながら、画面や処理手順を短期間で作って検証する。

本番環境への導入と安定運用

　アクセス権、セキュリティ、監視、障害時の対応まで含めて設計し、試作品を業務システムとして運用できる状態にする。

利用部門への教育と定着支援

　利用方法を説明するだけでなく、現場が自ら設定や改善を進められるように、マニュアルや開発環境、管理ルールを整える。

FDEに業務を丸投げしてはいけない

　FDEは幅広い課題に対応できるが、情シスが導入目的を整理しないまま仕事を丸投げすると、個別開発が際限なく増える恐れがある。

　顧客ごとの要望に対応することを優先し過ぎれば、標準機能から外れた仕組みが増え、特定のFDEしか保守できないシステムになる可能性がある。短期的には問題を解決できても、長期的には技術的負債や属人化を招きかねない。

　情シスは、少なくとも「どの業務成果を実現したいのか」「標準機能で対応する範囲はどこか」「個別に開発してよい範囲はどこか」を決める必要がある。

　FDEが作った仕組みについて、設計書、ソースコード、設定内容、運用手順を社内に残すことも欠かせない。FDEがプロジェクトから離れた後に、情シスや別の担当者が運用できる状態を契約や成果物の条件に含める。

FDEを選ぶ際に確認すべきポイント

　FDEを配置するベンダーを選定する際は、「FDEがいる」という説明だけで判断してはならない。FDEという名称が示す業務範囲は企業ごとに異なるためだ。

　情シスは、契約前にFDEが担う仕事を具体的に確認する必要がある。

　例えば、FDE自身が本番用のコードを書くのか、試作品だけを作るのか。データ統合やインフラ構築まで担当するのか。製品開発チームへ改善要求を伝える権限があるのか。導入後の運用や教育も支援するのかといった点である。

　技術力だけでなく、対象業務を理解する能力も重要になる。業務部門への聞き取りや課題整理ができなければ、技術的には動作しても、現場で使われないシステムが出来上がる可能性がある。

　FDEの成果を評価する指標も事前に決めておく必要がある。開発した機能数ではなく、処理時間、問い合わせ解決率、利用率、売り上げ、エラー件数など、導入目的に関連する指標を設定する。

成果報酬型サービスではFDEが重要になる

　ミューラー氏は、AIエージェントの普及に伴い、ソフトウェアの価格体系も変化する可能性があると指摘する。

　従来のSaaSでは、利用者数に応じて料金を支払う席数課金が一般的だった。一方AIエージェントの場合、問い合わせを何件解決したか、販売につながったかといった成果を測定できる。

　そのためミューラー氏は、AIソフトウェアの価格は、利用者数や処理量ではなく、実際に生み出した成果に基づく料金体系へ移行する可能性があるとみている。

　ベンダーが成果に応じて料金を受け取るなら、顧客の環境で成果を出す責任も負う。標準製品を提供するだけではなく、顧客のデータや業務に合わせて導入し、継続的に改善する必要がある。

　こうしたサービスでは、FDEが製品と顧客の間をつなぐ重要な役割を担う。情シスにとっても、導入作業を支援する担当者ではなく、ベンダー側で業務成果に責任を持つ相手としてFDEを位置付ける必要がある。

　FDEという職種の定義は曖昧になっている。一方で、顧客の現場に入り、技術と業務をつなぎ、成果が出るまで責任を持つという働き方は、エンジニアリング全体に広がっている。

　情シスがFDEを活用する際に重要なのは、高度なエンジニアを確保することだけではない。FDEとともに解決すべき業務課題を定め、社内へ知識を残し、成果を測定できる体制を作ることである。

本稿は、AI Engineerが2026年7月29日に公開した動画「The Dirty Secret of Forward Deployed Engineering―Natalie Meurer, Sierra」を基に作成しました。