FDEは「凄腕の個人」から「チーム」へ──Microsoftの論考「FDEの24か月の進化」を読んで
Microsoftの開発者向けメディア「Command Line」で、FDE（Forward Deployed Engineering）の定義がこの24か月でどう変わったかを論じた記事を読みました。書いたのは、MicrosoftでFDE部門を率いるKevin Shatzkamer氏です。
FDEは「顧客の隣に置く凄腕エンジニア個人」から、「測れる業務成果に向けて投入する、AIで加速された少人数の多職種チーム」に変わった。 AIでいちばん難しい問題が、モデルそのものから「本番に入れて、使われ続けること」に移ったからです。
この記事では、記事の要点を3つの変化に整理します。
そもそもFDEとは
FDEは2009年ごろにPalantirが広めた考え方です。ひとことで言えば「個別案件の課題解決に、製品づくりの発想を持ち込む」やり方です。
具体的には、エンジニアが顧客の業務とデータに直接触れながら解決策を作り、そこで効果が確認できたやり方を、ほかの顧客にも使える製品の機能として取り込んでいきます。
仕組みは次のとおりです。
- 利用者とデータに直接触れられる権限を持ったソフトウェアエンジニアを、顧客の現場に置く
- 現場で「本当に成果が出るやり方」を見つける
- それを製品側のチームが汎用の機能に落とし込む
机上の要件定義は、製品と現場の業務がぶつかるところで失敗しがちです。FDEは仮説ではなく実際の業務の上で、発見・設計・統合・改善を回すことで、その溝を埋めてきました。
著者自身も、長くFDEを「ソフトウェアエンジニアの職種」と捉え、技術を動かして製品を良くする「ヒーローFDE」の像を大事にしてきたと振り返っています。そのうえで、この定義は今も必要だが、それだけでは足りなくなった、というのが記事の出発点です。
24か月で起きた3つの変化
著者は、FDEがいまや「職種」ではなく「能力」を指す言葉になりつつあると書いています。モデル提供者、クラウド事業者、SaaS企業のそれぞれで、不確実性が高く価値も大きいAI変革を進めるための仕組みとして定着してきている、という見立てです。
1. 守備範囲が広がった
開発職だったFDEが、業務プロセスの再設計、本番システムの構築、データサイエンス、ガバナンス、顧客への能力移転、そして測定できる事業成果までを担うようになりました。「作って渡す」から「業務を変えて成果を出す」へ、責任の端が大きく伸びています。
2. それでも「エンジニア」であることは譲れない
守備範囲が広がっても、共通項は「顧客の実業務のそばで手を動かすこと」です。本番のコード、システム設計、評価、可観測性、セキュリティに責任を持ち、助言で終わらせず運用まで引き受ける。ここが単なるコンサルティングとの違いだと思いました。
3. 単位は個人から「ポッド」へ
ヒーロー1人ではなく、ドメインの専門家、エンジニア、データサイエンティスト、業務設計の担当、デザイナーなどからなる小さなチームが単位になります。そのチームをAIのコーディング支援や導入用のエージェントが増強する、という姿です。
時期ごとの違いを表にすると、次のようになります。
| 観点 | 初期 | 2025年半ば | 現在 |
|---|---|---|---|
| ミッション | 強力な基盤を複雑な組織で動かす | 生成AIの試作を本番に届ける | AI前提で重要業務を再設計し、成果を出す |
| 体制 | 凄腕の個人＋戦略担当 | 専門家の小チーム | 多職種のポッド＋AIエージェント |
| 技術の中心 | データ統合、アプリ、基盤 | アプリ、API、RAG | マルチエージェント、評価、可観測性、ID、セキュリティ、コスト管理 |
| 責任の範囲 | 構築、ときに運用 | 試作から本番への引き渡し | 安定運用、運用後の調整、ガバナンス、能力移転 |
技術の中心を見ると、「作る技術」よりも「本番で安全に回し続ける技術」の比重が大きくなっているのがよくわかります。
壁はどこへ移ったか
定義が変わった背景には、AI導入を妨げる「壁」の移動があります。記事の整理を図にすると、次の3段階になります。
最初は「何にAIを使うか」が壁でした。次に、試作はできても本番に乗せる開発人材が足りなくなりました。そこへAIのコーディング支援が急速に良くなり、開発力の壁は低くなりました。
いまの壁は、アイデアを本番で価値が測れるところまで運び、さらに他のチームが使い回せる形にする「組織の変革能力」です。著者は、多くの組織がこの力を鍛えたことがなく、しかもAIの進化の速さに合わせて鍛える必要があると指摘しています。私はここが、この記事のいちばんの核心だと感じました。
「依存させない」というゴール
私がいちばん印象に残ったのはここです。著者は、FDEプロジェクトのゴールを「顧客に運用能力を移すこと」とし、顧客をずっと頼らせ続けることではない、とはっきり書いています。
成功の物差しも2つ挙げられています。ひとつは業務へのインパクト、本番での利用定着、ROIといった成果。もうひとつは、観測できるシステム、評価の仕組み、チューニング済みのモデル、育った人材といった「置き土産」です。
そのための実践として、次の3つが紹介されています。
- 共同エンジニアリング：ペアプログラミングの考え方を、テスト、CI/CD、継続的な評価、設計判断の記録、コードレビューまで広げ、顧客と一緒に行う
- 引き継ぎを形にする：最後の開発期間と並行して知識移転の場を設ける。終わってから慌てて引き継がない
- 顧客が自分で回せる状態にする：顧客側の責任者を名前で決め、サポート体制と運用手順を文書にそろえる
「作った人がいなくなっても回る」ことを納品物にする、という考え方だと私は受け取りました。
読んで考えたこと
AIの導入に関わる立場で読んで、考えたことを3つ書きます。
1. 「何を作るか」より「どの業務の何を変えるか」から始める
ミッションが「業務の再設計と測れる成果」になったのなら、最初に決めるべきは製品の機能ではなく、対象の業務と成果の物差しです。処理時間なのか、件数なのか、コストなのか。ここを最初に合わせておかないと、どれだけ良いものを作っても「で、何が良くなったの？」に答えられません。
2. 「動いた」と「使われている」を分けて数える
記事の成功の物差しは、本番での利用定着とROIです。進捗を見るときも「実装した」「検証した」「定着した」を別々に数えないと、表面上は順調に見えるのに現場では使われていない、という状態を見逃します。
3. 引き継ぎは最後ではなく、途中から始める
「終わってから引き継ぐ」は、たいてい時間切れになります。最後の開発期間と並行して移転の場を持ち、相手側の責任者を名前で決めておく。これはAIに限らず、システム導入全般に当てはまる教訓だと感じました。
一方で、注意したい点もあります。記事は大手の事例を前提にしているので、多職種のポッドを常に組めるとは限りません。小さな組織では、1人が複数の役割を兼ねつつ、AIの支援で穴を埋める形が現実的だと思います。
おわりに
著者は最後に、FDEを一文で定義しています。私なりに言い換えると「測れる事業成果に向けて投入される少人数の多職種チームで、製品・開発・AI・データ・運用・変革の力を組み合わせ、AIの機会を課題の発見から本番での価値まで運ぶもの」です。
6分ほどで読める短い記事ですが、AIの導入が「技術の問題」から「組織が変われるかどうかの問題」に移ったことを、現場の言葉で整理してくれています。AIの導入や業務改革に関わる方には、ぜひ原文もあわせて読んでみてください。
関連記事
金融業務へのエージェント導入の事例は、Compound AIの記事で解説しています。
AIエージェントのためにOfficeを作り直す ― Compound AIの講演から読む金融エージェント基盤
オープンモデル自社運用の事例は、Revolutの記事で整理しています。
出典
- Kevin Shatzkamer「Thinking about the evolution of forward-deployed engineers over the last 24 months」Command Line（Microsoft）、2026年10月28日