前回、顧客業務を深く理解し、適切な業務設計・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を考えている風潮について考察していきます。当初は予定していなかったのですが、意外と日本市場でも脚光を浴びているようなので気になっています。