日本のSierが常駐SEの進化系としてFDEを進めようとしています。顧客の言われるままのITシステムを構築してきただけで、BAスキルは殆どないままです。このような日本のSierのFDEが失敗しないためにはどのようなことが必要でしょうか。失敗することの方が良いのかもしれませんが。生成AIに聞いてみました。

「これまでの常駐SE（言われた通りに作る人）」の延長線上で、名前だけをFDE（ビジネスを技術で解決する人）に変えても、100%失敗します。
なぜなら、両者は「求められるマインドセット」と「ビジネスモデル」が真逆だからです。
日本の伝統的なSIerがこの「FDEへのトランスフォーメーション」で自滅せず、かといって単なる言葉遊びで終わらせないために何が必要なのか。そしてなぜ「一度派手に失敗した方がいい」と言えるのか、3つの視点からアドバイスをまとめました。

SIer型FDEが直面する「3つの致命的な罠」

まず、BA（ビジネスアナリスト）スキルやドメイン知識がないままFDEを名乗ると、高確率で次の罠にハマります。

1. 「高級な御用聞き（何でも屋）」の再生産

顧客の言われるがままに動く癖が抜けないため、現場に入り込んだ結果「顧客の社内ニート化したIT部員」の雑用や、エクセルのマクロ修正、単なるデータ整形をやらされる「超高給な派遣エンジニア」に成り下がります。

2. 多重下請け構造の限界

FDEの本質は「顧客と対等に議論し、アーキテクチャを決める」ことです。しかし、SIerの商流（元請け→二次請け…）の中にFDEを組み込もうとすると、現場のエンジニアに裁量権がなくなり、結局「上の指示待ち」になって機能しなくなります。

3. 「人月ビジネス」との自己矛盾

SIerの儲けの源泉は「人を長く、多く現場に張り付けること（人月）」です。一方でFDEの価値は「仕組みを作って、早く現場を自立させて撤退すること」です。ビジネスモデル自体が矛盾しているため、SIerの営業や経営層がFDEの足を引っ張ることになります。

失敗しないために必要な「3つのドラスティックな変革」

もし本気でSIerがFDEを成功させたいのであれば、単なる「技術研修」ではなく、組織のOSそのものを入れ替える必要があります。

1. 「NO」と言える契約と評価制度への変更

「顧客の言う通りにシステムを作ったこと」を評価するのをやめ、「顧客の不要な業務プロセスをどれだけ削ったか」「どれだけ早く自社が撤退できる状態を作ったか」をFDEの評価指標（KPI）にする必要があります。また、顧客が理不尽なシステム化を求めてきた際に、技術的・ビジネス的観点から「それはやるべきではない」と突っぱねられる契約上の地位（あるいは関係性）を担保しなければなりません。

2. 「BA＋データ工学」のハイブリッド人材の『外部登用』

既存の常駐SEを教育してFDEにするのは時間的にもマインド的にも無理があります。まずは、コンサルティングファーム出身のBAや、事業会社で修羅場をくぐってきたデータエンジニアを「FDEチームのリーダー」として外部から高給で引き抜くべきです。生粋のSIer育ちのエンジニアは、そのリーダーの動きを現場で「見習う」ことから始めるしかありません。

3. 提供価値の「標準化（アセット化）」の仕組み化

個人の能力に依存するSIerの体質のままでは、FDEはただの「一騎当千のスーパーマン」頼みになります。A現場でFDEが作ったデータパイプラインや業務改善のフレームワークを、即座に社内で共有・テンプレート化し、「2回目からは誰でも7割のクオリティで再現できる」仕組み（アセット化）を組織として構築する必要があります。

組織のOSの入れ替えがうまくできなかった場合。

名前だけ変えた「疑似FDE」が現場でバグを連発したり、顧客のビジネスを混乱させたりして大炎上すれば、SIerも顧客企業もようやく以下の現実に気づくことになります。

• 顧客側： 「ITの丸投げはもう限界だ。自分たちでビジネスと技術がわかる人間（本当のBAやPM）を内製化しないと会社が潰れる」
• SIer側： 「人貸しビジネスの延長で高度なDXビジネスを気取るのは不可能だ。自社のビジネスモデルを根本から変えるか、受託開発に特化するか選ばなければならない」

「中途半端に延命するくらいなら、一度この取り組みで手痛い失敗を迎えた方が、日本のIT業界のためになる」のかもしれません。（清水）

最近FDE（Forrward Deployed Engineer）という職種の名称を耳にします。これはどのようなことをする職種なのでしょうか。AI企業で使われているようなので、生成AIに聞いてみました。

**FDE（Forward Deployed Engineer）**とは、

• 顧客の現場（Forward Deployed）に深く入り込み、顧客と一体となって技術的な課題を解決しながら、プロダクトそのものも進化させるエンジニアです。

近年、AI企業やデータプラットフォーム企業を中心に急速に注目されている職種で、特に生成AI時代には非常に重要な役割になっています。代表的な企業としては、Palantir Technologiesがこの職種を広め、その後、OpenAI、Anthropic、Scale AIなどでも採用されています。

FDEを一言で表すと

• 「コンサルタント」と「ソフトウェアエンジニア」と「ソリューションアーキテクト」を一人でこなす人
• 単なるSEでも営業技術でもありません。顧客と一緒に問題を定義し、AIやソフトウェアを組み合わせて解決策を作り、その知見を製品へフィードバックします。

なるほど、AI企業で始まり徐々に広まっているようです。その具体的な仕事内容はどんなものでしょうか（清水）。

典型的な仕事内容

例えば製造業の場合の顧客の要望。
工場長：「設備停止を予測したい」

Forward Deployed Engineerは

• 現場へ行く
• 設備データを見る
• 問題を整理する
• AIを試作する
• APIを書く
• ダッシュボードを作る
• 運用まで支援する
• その経験を製品へ反映する

つまり、顧客専用の開発だけで終わらず、プロダクトも改善することが重要です。

通常のSEとの違い

かなり違いますね（清水）

コンサルタントとの違い

コンサルタントは

• 課題分析し
•   提案書
•   終了

ですが、FDEは

• 課題分析
•   実際にコードを書く
•   AIを組み込む
•   顧客へ導入
•   運用
•   プロダクト改善

つまり提案だけでは終わらないところが最大の違いです。

AI時代になぜ重要か

生成AIでは「AIを入れれば終わり」ではありません。実際には

• 顧客業務
• 業務分析
• ワークフロー設計
• LLM選択
• プロンプト設計
• RAG
• Agent
• 評価
• 改善

これらを全部理解している人が必要になります。これがFDEです。

必要なスキルは次のとおりです

① ソフトウェア開発

• Python
• TypeScript
• API
• SQL
• クラウド

② AI

• LLM
• プロンプト設計
• RAG
• AI Agent
• MCP
• Tool Calling
• Evaluation

③ ビジネスアナリシス

ここが非常に重要です。

• 業務分析
• 要求分析
• KPI設計
• 業務プロセス
• Capability分析

つまりBAの能力が非常に重要になります。

④ 顧客折衝（これもBA能力）

• ファシリテーション
• インタビュー
• ワークショップ
• プレゼン

つづいてBAとの関係はどのようなものになるのでしょうか。

これはユーザーが関心を持たれているテーマとも深く関係します。従来はBAからSEへ要求を渡せば済んでいました。

• Business Analyst
• 要求定義
• SEへ渡す

AI時代では、次の様になります。

• Business Analyst
• AI Agent設計
• FDE
• 実装
• 顧客改善

すなわち、

• Business Analyst ＋　Forward Deployed Engineer

という形で、一人が両方の役割を担うケースも増えています。

AI企業では

• 業務分析
• 要求分析
• AI設計
• PoC
• 実装

まで一人で担当するケースが珍しくありません。

今後のキャリアとしての位置付け

生成AIの普及に伴い、FDEは今後さらに重要になると考えられます。

• Business Analyst
• AI Business Analyst
• Forward Deployed Engineer
• AI Solution Architect

というキャリアパスを描く企業も増えています。

特に、これまで取り組まれているCBAPやBABOKによる要求分析の知識に、AI実装やエージェント設計、クラウド開発のスキルを組み合わせることで、AI導入をビジネス成果につなげる人材として高い価値を発揮できます。

ビジネスアナリストとの関係

現在のFDEは、従来の「要件を聞いてシステムを作るSE」ではなく、ビジネスアナリストの課題発見力とエンジニアの実装力を兼ね備えた職種へ進化しています。AIエージェントの導入が進むほど、顧客業務を深く理解し、適切な業務設計・AI設計・実装を一気通貫で行える人材の需要は高まると考えられます。これは、ビジネスアナリシスとAI技術の橋渡し役として、今後ますます重要なポジションになるでしょう。

しかし、これって一人でできることなのでしょうか。また、FDEが不在（別の顧客に移った場合）の際の製品のメンテナンスはどうするのでしょうか。後半（次回）はその課題への対処方法を考えてみましょう（清水）。