「FDE」という名の新たな化粧まわし　〜「ソリューション」の堕落に学ぶ、日本ITベンダーの構造的病理

近年、生成AI（LLM）の爆発的な進化や、エンタープライズ領域におけるデータ活用の高度化に伴い、IT業界で「FDE（Forward Deployed Engineer：フォワード・デプロイド・エンジニア）」という職種が急速に注目を集めています。

AIによって従来の「仕様書通りにコードを書く」「工数をかけてシステムを維持する」という人月ビジネスモデルが崩壊の危機を迎える中、多くのSIerやSES、ITベンダーが「これからはFDEの時代だ」「我が社もFDEを育成する」と息巻いています。

しかし、私は強い危機感を抱いています。かつて30年前に私たちが犯した過ちを、今のIT業界が全く同じ形で繰り返そうとしているように見えるからです。

私たちは、かつて「ソリューション」という言葉を都合よく使い古し、その本来の価値を簒奪（さんだつ）しました。そして今、再び「FDE」という流行り言葉を、自らを格好よく見せるための「化粧まわし」として引きずり出し、中身を変えないまま言葉の意味だけを自分たちの実力レベルにまで引き下げようとしています。

本稿では、私がIBMの営業として目撃した「ソリューション」誕生の真実と、同社が遂げた歴史的な事業構造転換のデータ、そしてその後の形骸化の歴史を振り返りながら、現在のFDEブームの欺瞞と、日本のITベンダーが直面する本質的な病理について警鐘を鳴らしたいと思います。

1. 1993年、私がIBMの営業だった頃——「ソリューション」誕生の真実と、IBMが下した決断

「ソリューション」という言葉が今のように当たり前になる前、そこには明確な「顧客の痛み」と、ビジネスモデルを賭けた「決断」がありました。

1980年代後半から1990年代初頭にかけて、IT業界は「ダウンサイジング」の嵐の中にありました。高価なメインフレーム（汎用機）の時代が陰りを見せ、安価なミニコン、オフコン、PCが急速に普及していった時代です。

部門個別のニーズに安く迅速に対応できるため、企業は競うように様々なメーカーのコンピューターを導入しました。確かに、ハードウェア単体の初期購入コスト（TCA: Total Cost of Acquisition）は劇的に下がりました。

しかし、その先に待っていたのはマルチベンダー化によるカオスでした。

• データの互換性が保てない
• ネットワーク接続によるシステム連携が複雑を極める
• トラブル発生時、どのメーカーに原因があるのかわからない
• システム間の整合性を保証した上でのバージョンアップが不可能になる

メインフレーム時代は、メインフレーム・メーカーが一括して保証してくれていた「システム全体の整合性」を、ユーザー企業が自らの負担で保証しなければならなくなったのです。バックアップ、ライセンス管理、トラブル対応などの運用コスト（TCO: Total Cost of Ownership）は急増し、企業は「個別最適化されたシステム群」という怪物に頭を抱えていました。

そんなマルチベンダーの混迷期にあたる1993年4月、IBM初となる外部招聘CEOとして、ルイス・ガースナーが就任します。当時、IBMはメインフレーム市場の縮小により、アメリカの企業史上最悪となる「81億ドル（当時のレートで約9000億円）の純損失」を計上し、解体の危機に瀕していました。

当時、私はIBMの現役の営業をしていました。日々の営業活動では、

「他社製品との組み合わせは保証できませんから、IBM製品で統一しましょう」

と、自社の純血主義を振りかざしてお客さまに売り込んでいたのです。

ですから、ガースナーが打ち出した方針は、まさに青天の霹靂でした。

ガースナーは、マルチベンダーシステムの組み合わせがお客さまの最大の負担（TCOの暴発）になっている現実を直視し、IBMの純血主義を180度転換。「競合他社製品を含むお客さまのシステム全体を一括して組み合わせ、動作をサポートする」と表明したのです。

これこそが、彼が定義した本来の「ソリューション（解決策）」であり、それを提供するサービスが「システム・インテグレーション（SI）」でした。

この「ソリューションへの純化」は、単なるスローガンではありませんでした。IBMは実際に、自社ハードウェア（プロダクト）への依存から、身を切るような事業構造の転換を成し遂げたのです。その変化は、同社の財務データに鮮明に現れています。

• 1993年（ガースナー就任時）：サービス部門の売上比率は、全体のわずか約27%に過ぎませんでした。
• 2001年（ガースナー退任の直前）：サービスとソフトウェアの合計は、同社の総売上の58%（サービスが350億ドル、ソフトウェアが130億ドル）にまで成長しました。
• その10年後（2003年頃）：ITサービス（旧IBM Global Services）単体だけで、全体の売上（約860億ドル）の40%以上を占める、最大の売上・利益の源泉へと変貌を遂げました。

自社製ハードウェアの「モノ売り」から脱却し、顧客の痛みを取り除く「コト（仕組み）売り」へ。この徹底的なビジネスモデルの転換があったからこそ、IBMは倒産危機から奇跡的なV字回復を果たし、世界最強のサービス企業へと生まれ変わることができたのです。

2. そして「ソリューション」は安価な看板へと堕落した

しかし、この強力な言葉は、瞬く間に形骸化の道をたどることになります。

「ソリューション」という言葉は、実は1980年代から一部で使われていました。当時の使われ方は、単に「プロダクト売りよりもレベルの高い仕事をしていますよ」と見せるためのキャッチフレーズに過ぎませんでした。

IBMが「マルチベンダーの組み合わせによる課題解決」という壮大な覚悟を定義したにもかかわらず、周囲のITベンダーは自らを変革する努力を怠りました。

他社製品を含めた複雑なシステムを保証・統合する技術力も、身を削る覚悟もないまま、自分たちが売りたいだけの単一のパッケージソフトウェアや自社ハードウェアに「〇〇ソリューション」というお洒落なラベルを貼り、ただ「格好よく」見せるためにお化粧を施したのです。

結果、ソリューションという言葉は本来の意味を失い、「ただのプロダクトや工数の言い換え」というバズワードへと堕落していきました。言葉の定義が、ベンダー側の「実力レベル」にまで引き下げられてしまったのです。

3. Palantirの「FDE（Forward Deployed Engineer）」とは何だったのか

そして今、全く同じ悲劇が「FDE」という言葉で繰り返されようとしています。

FDE（Forward Deployed Engineer）の元祖であり、この職種をビジネスモデルの心臓部に据えたのが、米Palantir Technologies（パランティア・テクノロジーズ）です。

彼らの定義するFDEは、単に「優秀なフルスタックエンジニア」ではありません。

彼らは、自社プロダクト（Foundry/Gotham/AIP）という強力な共通プラットフォームを持っています。しかし、エンタープライズのデータは、レガシーシステムへの分散や現場ルールの属人化により、常にカオスな状態にあります。

この「自社プロダクト」と「カオスな現場の現実」の最後の1マイルを埋めるために、FDEは現場（前方）へと展開（デプロイ）されます。現場で泥臭くデータを繋ぎ、プログラムを書き、ビジネスの成果（KPIの改善）を直接証明する。それこそが彼らの役割です。

そして最も重要なのは、「プロダクト開発チームとの強力なフィードバック・ループ」が回っている点です。

FDEが現場で直面した課題や、独自に開発した優れたデータモデル、製品への不満は、即座に本社のプロダクト開発チームへ還元されます。

「現場のこのニーズは、Foundryの基本機能として組み込むべきだ」

「この業界共通のデータ構造は、テンプレート化して他の顧客にも使えるようにしよう」

FDEは現場における「最良のテスター」であり「仕様の発見者」です。FDEの持ち帰る知見があるからこそ、Palantirの製品は急速に洗練され、再利用可能な「プラットフォーム」としてスケールする。

FDEとは、「自社プロダクトの進化」と「顧客の課題解決」が双方向に連動する、極めて精緻に設計されたエコシステム（思想・戦略・ビジネスモデル）そのものなのです。

4. 最大の病理：努力を怠り、言葉を「自分たちの実力」まで引き下げる

いま、日本のSIerやSES、ITベンダーがこぞって自社のエンジニアを「FDE」にしようと関心を持っています。

しかし、冷静になって考えてみてください。

自社プロダクトを持たない企業が、どうやってPalantirのような「プロダクトと現場のフィードバック・ループ」を回すのでしょうか。

彼らにはスケールさせるべき自社プロダクトがありません。現場でどれだけ優秀なエンジニアが課題を解決しても、それはその顧客限りの「一回性の個別受託開発」に終わります。

それにもかかわらず、彼らは「FDE」という響きの良さに飛びつきます。なぜか。AIの進化によって「仕様書通りにコードを書くだけの人月ビジネス」が行き詰まることへの焦りがあるからです。次の稼ぎ頭を模索しなければならない恐怖から、新しい言葉を持ち出し、自らを飾り立てようとしているのです。

かつて、プロダクトを売るよりも「ソリューション」と呼んだ方が格上に見えたのと、全く同じ心理です。今また、単なる「客先常駐SE（SES）」を「FDE」と呼び変えることで、手軽にお化粧を施そうとしています。

ここに、日本のIT業界の根深い病理があります。

「言葉の本来の意味や背景を正しく理解しようとせず、自分たちが変わる努力を怠り、逆に言葉の定義を自分たちの『できる範囲』にまで引き下げて都合よく解釈する」

彼らは、ビジネスモデル（人月の切り売り）そのものを変革するという血のにじむような努力から逃げるために、

「要件定義から実装、現場調整まで一人で自走できる、ちょっと優秀なフルスタックSE。よし、我が社ではこれを『FDE』と呼ぼう」

と、言葉の定義を現在の自分たちの実力レベルにまで都合よく引き下げ、安心しているのです。

この「自己都合の解釈」こそが、言葉の本来の意味を奪い、価値を貶める主犯です。FDEという思想やPalantirの戦略そのものに罪はありません。罪があるのは、その本質を理解しようとせず、安易な記号（バズワード）として消費する側の不誠実さ、そして怠惰です。

5. 安易な「お化粧」を排し、自らの足で歩む覚悟を決めよ

日本のSIer、SES、ITベンダーが、30年前の「ソリューション」と同じ悲劇を繰り返さないために、今すぐにやるべきことがあります。

それは、都合の良い言葉の借用（お化粧）を今すぐやめることです。

看板を「FDE」に掛け替えても、売っているものが「他人のシステムを構築するための工数（人月）」である限り、AIによる生産性向上はそのまま売上の下落に直結します。本質を変えないお化粧は、ビジネスモデルの死期をわずかに先送りするだけの、不毛な延命策に過ぎません。

かつてIBMが「ソリューション」を掲げたとき、彼らは「自社の純血主義を捨てる」「ハードウェア売上に依存しない」という、身を切るような痛みを伴うビジネスモデルの転換を行いました。それは、81億ドルの大赤字から、全社総力でサービス＆ソフトウェア比率を全体の約6割に引き上げるという、命がけの脱皮でした。

PalantirがFDEを組織しているのは、膨大なコストを払ってでも「世界に通用する自社プロダクトを圧倒的なスピードで磨き上げるため」です。

どちらも、言葉の裏には「身を削る戦略と痛み」が存在しています。

他社の文脈を都合よくハックし、自分たちの等身大に引き下げるようなフリーライドはもうやめましょう。それは何の問題解決にもなりません。

「自社が本当に救うべき顧客の痛みは何か」

「そのために、私たちはどんな痛みを伴う自己変革をすべきなのか」

流行り言葉に逃げるのをやめ、自らの頭で考え抜き、自らの手で歩むべきロードマップを描く。それだけが、この激変のAI時代において、日本のITベンダーが生き残る唯一の道なのです。