「SaaS疲れ」を乗り越える次世代のアプローチ
── FDEがもたらす真の業務変革

近年、DX推進の文脈でもてはやされてきたSaaS（Software as a Service）の導入が、現場の疲弊を招く「SaaS疲れ（SaaSスプロール）」を引き起こしている。標準化された汎用SaaSは、企業独自の複雑な「周辺業務」をカバーしきれず、結果として現場でのExcelマクロやRPAへの依存、あるいはノーコードツールによる新たな技術的負債（ブラックボックス化）を生み出している。本レポートでは、生成AIによる開発生産性の劇的な向上を背景に「フルスクラッチ開発＝高額かつ長期」という従来の常識が崩壊しつつある現状を分析し、その新たな環境下で注目を集める次世代の専門職「FDE（Forward Deployed Engineer）」について解説する。

1. 「SaaS疲れ」の正体

長らく、企業のIT戦略における最適解は「パッケージやSaaSの標準仕様に自社の業務を合わせる（Fit to Standard）」ことだとされてきた。しかし現在、多くの大企業で「SaaSスプロール（SaaSの乱立）」という深刻な課題が顕在化している。

機能が重複する複数のアプリケーションが存在することで、不要な支出が発生するだけでなく、データのサイロ化や部門横断での可視性低下を招いている。業務を汎用SaaSに無理やり合わせようとするアプローチは、現場での「二重入力」や「不要なID課金」を誘発し、生産性向上のメリットを完全に上回るほどの疲弊を生み出しているのが実態だ。これが一部で囁かれる「SaaS疲れ」の本質である。

2. 周辺業務のブラックボックス化──汎用SaaSの死角とノーコードの罠

汎用SaaSがカバーできるのは、あくまで「世の中の標準」となるコア業務のみである。例えば人事給与業務において、SaaSがカバーするのは標準的な「給与計算」であり、その前処理となる「複数システムの履歴を突合した複雑な昇格要件判定」や、中間処理である「独自の歩合給・インセンティブ計算」といった周辺業務は守備範囲外となる。

SaaSからこぼれ落ちたこれらの周辺業務は、現場の担当者が自力でExcelマクロやRPAを用いて自動化を図るケースが多い。しかし、これらは属人化しやすく、担当者の異動や退職が即座に業務停止リスクに直結する。

近年では、これらの課題解決にノーコード・ローコードツールが用いられることも多いが、非エンジニア主導の開発（シャドーIT）は、適切なアーキテクチャ設計を欠いたまま進行しがちである。複雑な独自ロジックをノーコードで無理やり実現しようとすると、保守不可能なスパゲティ状態に陥り、結局は「新時代の技術的負債」を抱え込むことになりかねない。

3. 生成AIがもたらすパラダイムシフト──「フルスクラッチは高額・長期」の終焉

これまで、自社専用のシステムをゼロから構築する「フルスクラッチ開発」は、莫大なコストと期間を要するため、経済合理性の観点から敬遠されてきた。しかし、生成AI（特に自律型マルチエージェントAIやコーディング支援AI）の登場により、この前提は崩壊しつつある。

現在の最先端の現場では、生成AIを活用することでコーディングの時間が極限まで圧縮されており、「妥協してSaaSに業務を合わせるコスト」よりも、「AIを活用し、自社の実態に100%適合する専用システムを迅速・安価に作るコスト」の方が下回るというパラダイムシフトが起きつつある。

4. AI開発における「現実の壁」──なぜ劇的な生産性向上は現場で実感しにくいのか

専用システムをゼロから構築するほうが安い。これは、確かに生じつつある現実だ。生成AIの進化によって、コードを書くこと自体は劇的に簡単になった。しかし、「生じつつある」と注釈付きで記載せざるを得ないこともまた事実だ。当然のことながら、「企業の複雑な業務システムを誰もが簡単にフルスクラッチで構築できるようになった」わけではない。

昨今、メディア等では「AIに指示するだけであらゆるシステムが完成する」といった喧伝がなされることもあるが、現場の最前線にいる担当者の多くは「自社の複雑な業務や既存システムとの連携において、そんな魔法のような話がすんなり通用するはずがない」という現実的な懐疑を抱いているはずだ。そして、その直感は極めて正しい。

壁①：業務と設計の壁

生成AIはあくまで「指示された通りにコードを出力する」強力なツールに過ぎない。現実のエンタープライズ領域のプロジェクトでは、まず現場の混沌とした業務ルールを解きほぐすこと（BPR）から始まる。そして業務を整理する中で、法改正の影響を頻繁に受けやすい部分など、「標準化されたSaaS等に任せるべき領域」を正確に切り分け、スクラッチで対応すべき領域を特定する。

領域を特定したうえで、将来の仕様変更に耐えうる拡張性を持ったシステム構造を描き（アーキテクチャ・パッケージ設計知見）、それをAIが正確に処理できるプロンプト（要件）へと翻訳していくのだ。

壁②：非機能要件の壁

さらに、エンタープライズのシステムにおいては、単にアプリケーションレイヤーのコードが意図通りに動けばよいという単純なものではない。情報漏洩を防ぐ強固なセキュリティ設計や、既存システムとの安全な連携など、インフラからアプリケーションに至るまでの総合的なシステム知見が求められる。

この「業務と設計の壁」、そして「非機能要件の壁」を超えられなければ、AIは「最新技術で作られた保守不可能なスパゲティコード」を大量に吐き出すだけに終わる。AIによるフルスクラッチ開発を真に安価・高速なものにするためには、業務要件の整理からSaaSとの切り分け、システム実装に至るまでの、この「巨大な分断の壁」を乗り越えなければならない。ここを従来のSIerのような分業体制（業務要件はコンサル、設計はPM、実装はプログラマー）で行っていては、結局コミュニケーションロスと手戻りが膨大になり、AIの恩恵を享受しきれないのである。

5. 次世代のアプローチ「FDE（Forward Deployed Engineer）」とは何か

このAI開発における「現実の壁」を突破し、AI時代の恩恵を最大限に引き出し、現場の複雑な課題を解決するために台頭しているのが「FDE（Forward Deployed Engineer：前線配置型エンジニア）」である。

FDEの要件と特長

FDEの最大の特長は、前述した壁を突破するための一連のプロセスを、分業せずに「同一人格」で一気通貫に遂行できる点にある。

従来のエンジニアのように開発拠点で仕様書を待つのではなく、顧客の現場に自ら入り込む。ここで、上述した業務課題整理、システム配置の見極め、アーキテクチャ設計、システム開発を、全てその場で高速かつ統合的に実施していく。それによって、「事業完遂型」の推進力を持つのだ。つまり、次の3つの役割を一人で統合しているのである。

• コンサルタント：混沌とした現場の業務ルールを解きほぐし、あるべき業務プロセスを描くBPR知見
• プロダクトマネージャー：SaaSに任せる領域とスクラッチで作る領域を切り分け、将来の仕様変更に耐える構造を描くパッケージ設計知見
• エンジニア：要件を正確な実装へと翻訳し、非機能要件まで含めて動くシステムに落とし込むAI開発知見

これによる強力なメリットは、スピードと、意外なことに品質だ。従来の分業による「伝言ゲーム」を排し、実機を動かしながら手触り感をもってエンドユーザーの指摘を直接開発者がその場で受け、かつ、同一人格が全体業務・システム構成も見据えたグランドデザインも手掛けることで、真に価値がありUI・UXも洗練したソリューションを開発できる。この圧倒的な推進力と品質は、繰り返しになるが、業務理解からシステム設計、実装に至るまでの能力が分断されず、「同一人格」に宿っているからこそ発揮されるのだ。

6. おわりに──自社専用システムへの回帰が真のDXを牽引する

「SaaS疲れ」は、クラウドやSaaSという形態自体の否定ではなく、「自社のコア競争力や独自業務を、無理やり標準ツールに押し込めることの限界」を示している。AIの進化により、コーディングのハードルが劇的に下がる中、エンジニアの本質的な価値は「コードを書くこと」から「顧客のビジネス課題の特定と、その解決策の迅速な実装」へと移行した。

FDEという「同一人格」によるアジャイルな課題解決こそが、大企業に蓄積された技術的負債を解消し、真の業務効率化とDXを実現するための鍵となるだろう。

もし自社の業務が「標準に合わない」ことに悩んでいるのであれば、それは業務が間違っているのではなく、合わせる先の選択肢が限られていた、というだけかもしれない。前提が変わった今、どこまでを標準に委ね、どこからを自社の形に作るのか──その線引きを引き直す時期に来ている。