FDEとビジネスアナリスト（3）
日本の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業界のためになる」のかもしれません。（清水）