日本の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業界のためになる」のかもしれません。（清水）

前回、顧客業務を深く理解し、適切な業務設計・AI設計・実装を一気通貫で行える人材としてFDEの需要は高まると論じてきました。しかし良いことだけではありません。FDEが不在（別の顧客に移った場合）の際の製品のメンテナンスはどうするのでしょうか。後半（今回）はその課題への対処方法を考えてみましょう（清水）。やはり生成AIによる回答をご覧ください。

結論から言うと、FDEに依存したままプロジェクトを進めると、メンテナンス上の大きなリスクがあります。 実際、多くのAI企業でもこの点が課題として認識されており、FDEは「何でも一人で抱え続ける人」ではなく、顧客が自立運用できる状態を作る人へと役割が変化しています。

なぜFDEが属人化しやすいのか

FDEは次のような領域を横断して担当します。

• 業務分析
• AIエージェント設計
• システムアーキテクチャ設計
• コード実装
• プロンプト設計
• RAG設計
• 顧客との意思決定

これらを一人で理解しているため、担当者が異動・退職すると、

• 「なぜこの設計にしたのか」
• 「このプロンプトは何を意図しているのか」
• 「このAIエージェントはどの業務ルールを反映しているのか」

といった暗黙知が失われやすくなります。

特にAIシステムではリスクが大きい

従来の業務システムでは、コードを読めばある程度動作を理解できます。
しかしAIシステムでは、例えば以下のような要素が絡みます。

• プロンプト
• デル選定
• ツール呼び出し
• RAGの検索設計
• 評価基準
• ガードレール
• 業務ルール

これらはコードだけでは意図を理解しにくく、設計判断の背景が重要です。

先進企業はどう対策しているか

AI企業では、FDEが成果物だけを残すのではなく、「設計資産」を残すことを重視しています。例えば、

• ビジネス要件：どの業務課題を解決するのか
• AI要件：どの判断をAIに任せるのか
• プロンプト設計書：プロンプトの目的や変更履歴
• エージェント設計書：役割、ツール、制約条件
• 評価基準：何をもって「良い回答」とするか
• 運用手順書：モデル更新や障害時の対応方法

こうしたドキュメントを整備し、属人化を防ぎます。

 ビジネスアナリストの役割が重要になる

ここで、ビジネスアナリシスが非常に重要になります。
FDEは実装に強い一方で、業務知識や要求の背景を体系的に整理することは、必ずしも得意とは限りません。そこで、ビジネスアナリストが以下を成果物として残すことで、保守性が大きく向上します。

• ビジネスゴール
• 業務能力（Capability）の定義
• 業務プロセス
• 要求仕様
• 業務ルール
• KPI
• 意思決定モデル

これらがあれば、新しいFDEでも「何を実現すべきか」を理解しやすくなります。

AI時代は「FDE＋BA＋AI運用」の分業が現実的

理想的な体制は、一人のスーパーマンに依存するのではなく、次のような役割分担です。

このように知識を分散し、成果物を標準化することで、FDEが交代しても保守を継続しやすくなります。

FDEをビジネスアナリストの代替ではなく、その実装パートナーとして捉えるのが適切

むしろ生成AI時代には、ビジネスアナリストが「なぜ・何を実現するのか」を構造化し、FDEが「どう実現するか」を設計・実装するという役割分担の方が、保守性・拡張性・人材育成の面で持続可能です。
この観点から見ると、BABOKによる要求分析と、BIZBOKのCapability Mapは、FDEの成果を長期的に維持・改善するための「設計資産」として、これまで以上に価値が高まると言えるでしょう。

やはり、メンテナンスまで考えるとFDEだけでは不足でBAが不可欠になるということです。（清水）

次回（3回）は日本の大手SIerが常駐SEの進化系としてFDEを考えている風潮について考察していきます。当初は予定していなかったのですが、意外と日本市場でも脚光を浴びているようなので気になっています。

最近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が不在（別の顧客に移った場合）の際の製品のメンテナンスはどうするのでしょうか。後半（次回）はその課題への対処方法を考えてみましょう（清水）。