FDEは「客先常駐SES」と何が違う？人間の複雑さに向き合う「AI SaaSの生存戦略」【ログラス×LayerX】

近年、AIのコーディング能力などが向上し、ソフトウェア開発への導入が進んでいくなかで、にわかに注目を集めるようになった、ある“エンジニアのポジション”があります。それが、「FDE」です。

FDE（Forward Deployed Engineer）とは、「顧客の現場の最前線に配置されたエンジニア」のことです。米国のデータ分析企業・Palantir（パランティア）社などで確立されたポジションとして知られています。

FDEは、顧客がはたらく現場に身を置き、そこに存在する複雑なデータと直接向き合いながら、最適化したシステムを構築します。それを通じて、顧客のミッション達成を支援することが彼らの役割です。

Palantirは、公共・防衛から商業まで、複雑な大規模データ問題を解くAI企業。近年、日本国内のSaaS事業者の間でも、この「FDE」というポジションを取り入れる動きが急速に広まっています。

しかしその一方で、日本国内のエンジニアの間では「客先常駐のSESと何が違うのだろうか」「技術コンサルタントとの違いは？」と戸惑う声も見られます。

本記事では、クラウド経営管理システム「Loglass」シリーズを手掛ける株式会社ログラスで、FDE組織を牽引する坂本龍太氏、業務効率化AIクラウド「バクラク」シリーズや大企業向けAIプラットフォーム「Ai Workforce」などを展開する株式会社LayerXでFDEグループのEMを務める白井英氏にインタビュー。

両社は2023年〜2024年からFDEの導入に取り組み、組織化を進めてきたAI SaaS企業であり、坂本氏、白井氏は「FDEとは、自社のAIプロダクトを持ちながら顧客の現場に入り込み、個別課題の解決を通じてプロダクト自体を改善させていく存在。そして、その改善サイクルを担うエンジニアであり、従来のエンジニア像とは一線を画する」と口をそろえます。

では、FDEはこれまでのエンジニア像とどう異なるのでしょうか？　なぜAIの進化とともに、逆に「人間が現場に入り込む」この役割が強く求められるようになったのでしょうか？　お二人に伺いました。

FDEは「エンジニアの役割」というより「AI SaaSのビジネスモデル」

――異なるドメインでサービスを提供するログラス、LayerX。なぜ両社は2025年、「FDEという新たなエンジニアロールの導入」という意思決定をしたのでしょうか。その経緯を教えてください。

白井：LayerXは2018年の創業時からPalantir社を研究していましたが、「研究していた」だけでなく、当時から実践もしていました。創業期はブロックチェーン事業を展開していましたが、そのころから大企業の現場に深く入り込み、顧客と同じKPIを持ちながら一緒にソリューションを見つけていくアプローチを採っていました。三井物産等とのジョイントベンチャーでFintech事業を立ち上げているのもその典型で、エンジニアが顧客の業務プロセスそのものと向き合いながら事業をともに作っていくという動き方をしていました。

その後、PrivacyTech、そして現在のAI事業へとピボットしてきましたが、顧客の現場に入り込むという方法論は一貫して変わっていません。

2023年に立ち上げた「Ai Workforce」でも、この方法論なしには価値を届けられないと確信しています。正直に言うと、“Palantirを再発見した”というより、自分たちがずっとやってきたことにようやく名前がついた、という感覚に近いです。

ちなみに、FDEというポジション名を最初から採用していたわけではありません。「見慣れない名前だと浸透しなさそうだ」という判断から、しばらくのあいだは「LLMエンジニア」と呼んでいました。名実ともにFDEというポジションを確立し、募集を開始したのは2024年7月からになります。

坂本：実を言うとログラスも、創業時（2019年）からPalantir社に注目していました。「特定ドメインに特化したシステムで意思決定を支援する」という同社のビジネスモデルが、弊社のミッションと重なるためです。

ログラスの社名は、スペイン語で「実現する」を意味する「lograr」と、「見通す」を意味する「glass」を組み合わせた造語ですが、これは「テクノロジーによって経営の未来を映し出し、正しい意思決定を支援する」という私たちのスタンスを表しています。このスタンスを具現化する構想が、企業の戦略的意思決定を支援するAIエージェント「Loglass AI Agents」です。数量的なデータや議事録などの非構造化データをAIで分析し、意思決定のための示唆を提示します。

名称変更の経緯もLayerXさんとよく似ていますね（笑）。当初は「LLMエンジニア」と呼んでいましたが、採用を始める段階で「この役割の本質を最も正確に伝える名称は何か」を検討し、FDEに改めました。

――SNSなどを見ると、FDEというポジションに対して「客先常駐のSESや、技術コンサルタントと同じなのではないか」と疑問視する声も見受けられます。両社が考えるFDEの役割と、これらの職種との違いはなんでしょうか？

白井：LayerXでは「FDEは役割というより、ビジネスモデルに近いもの」と位置づけています。

SESや技術コンサルタントとの決定的な違いを一言で言うなら「プロダクトを持っている」ことです。FDEは自社プラットフォームという制約の中で動きますが、この制約こそが強みでもあります。顧客の課題を解くたびに、その知見がプロダクトに実装され、次の顧客への価値になっていく。SESは顧客企業を離れたら終わりですが、FDEが解いた課題は会社の資産として積み上がっていきます。

個別最適の対応が、そのままプロダクトのスケールに直結する。このサイクルを回せるのが、FDEがFDEであることの本質だと考えています。

坂本：「FDEとはビジネスモデルである」という考え方には同意します。

ただ、もう少し踏み込んで言うと、FDEの固有性は「顧客への個別最適化と、自社プロダクトのスケーラビリティという、本来トレードオフになる二つの目標を同時に背負う」点にあると考えています。

顧客の現場に入り、その企業固有の課題に対して自社プラットフォーム上や、個別最適なシステムを構築する。同時に、その過程で「この課題解決のどの部分が汎用化できるか」を常に見極め、プロダクト本体にフィードバックする。

SESやコンサルタントとは違って、FDEは個別の顧客対応がそのままプロダクトの進化に直結する責任を持っています。

AI SaaSだけでは解けない課題を解くために、直接対話するエンジニア

――「日本国内でFDEという言葉が広まっていった時期」と「AIがソフトウェアの開発現場、ソフトウェア自体に導入されていった時期」は重なります。この背景を整理するうえで伺いたいのですが、AIはSaaS業界に対して、どのような変化をもたらしているのでしょうか？

白井：従来のSaaSは、顧客に対して「プロダクトに合わせて、業務のほうを変えてください」と求めざるを得ない側面がありました。この一因は、システムがルールベースで動いていて、柔軟性が低かったことです。

しかし、ソフトウェアにAIを取り入れることでより柔軟なシステムをつくれるようになり、従来のSaaSとは反対に「業務に合わせて、プロダクトのほうを変えていく」ことが容易になりました。

これにより、いままでよりも顧客の業務にフィットし、“ラストワンマイル”の課題解決につながるシステムが実現できるようになった、と考えています。

坂本：AIの登場で、従来のSaaSでは手が届かなかった「ラストワンマイル」の課題解決に踏み込めるようになりました。これは大きなチャンスです。

ただし、これは裏を返すと「業務効率化だけを価値としているSaaSは、差別化が難しくなる」ということでもあります。AIで動くものを作ること自体は誰でもできるようになりました。しかし、業務システムの本質的な価値は、運用保守の持続、規制への追従、ベストプラクティスの実装にあり、作って終わりではなく、使い続ける中で初めて実現するものです。

だからこそ、SaaSは「記録と効率化のシステム」から「意思決定を支援するシステム」に進化する必要がある。そしてその進化を、顧客の現場で実装していくのがFDEの役割だと考えています。

――AI普及の以前と以後で、SaaSのあり方が変わる。その変化が起こるなかで、なぜFDEが必要になるのでしょうか。どうしてAI SaaSだけでは不十分で、新しい人間の役割が求められるのでしょうか。

坂本：2024年〜2025年にかけて、多くのエンジニア組織が気づいたことがあります。「AIコーディングで開発が速くなるはずが、そうでもない。真のボトルネックはコーディングや技術の外にある」と。顧客企業でも同じことが起きています。AIツールを入れただけでは成果は出ない。組織と業務プロセスを変えなければならないということです。

例えば、ログラスのAIエージェントは経営判断の示唆を出せます。しかし、AIの出力は確率的です。組織の意思決定は責任で動きます。その示唆を誰の権限で、どの会議体で、どの粒度で経営判断に組み込むかは、技術だけでは解決できません。

FDEが踏み込むのはこの接合部分です。そのためには顧客の意思決定プロセスを深く理解する必要があり、顧客との信頼関係の構築が不可欠です。これは現時点でAIには代替できない人間のエンジニアだからこその仕事です。

白井：「FDEは顧客企業のCTO」と例えられるように、「顧客が抱える経営課題に対して、エンジニアリングの観点からクリエイティブな解決策を提示する」のが、FDEの役割だと考えています。

ただ、Ai Workforceで実際にFDEとして動いてきた経験から言うと、顧客が「解くべき課題」をはじめから言語化できているケースはほとんどありません。

たとえば、請求書処理の自動化を相談されたとしても、その裏には承認フローの問題があったり、そもそも帳票の標準化ができていなかったりする。表に出てきている課題と、本当に解くべき課題は別物であることが多いという実感があります。

「本当の課題」にたどり着くには、顧客の業務を深く観察し、現場のキーパーソンが誰かを見極め、信頼を積み上げるプロセスが必要です。この工程はAIには代替できない。だからこそ人間のエンジニアが現場に入ることに意味があると思っています。

技術力×人間理解で、“本当に役に立つソフトウェア”を提供する

――FDEは、複合的なスキルが求められそうなポジションですね。どんな人材が適しているのでしょうか？

白井：理想のFDE像は、もはやスーパーマンですね（笑）。

坂本：理想を言うと、確かに（笑）。PM的なスキルも営業的なスキルも必要で、「そんなレベルの高いエンジニア、世界に何人いるんだ」という感じになってしまうと思います。

坂本：より現実的なお話をすると、FDEに求められるスキルをひとつ挙げるなら「自社プラットフォームの制約の中で、技術的・論理的な正しさだけでなく、人間の複雑さを加味しながら前に進めていく力」でしょう。

これまでPMや営業担当者などが向き合っていた「顧客の組織のあるべき姿とは何か」「その組織が受け止めやすい方向性は何か」といった問題を、スピーディーに把握して技術的に解決するアプローチを提示する。これは、FDEならではのスキルだと思います。

白井：弊社では、FDEとDS（※1）というポジションがチームを組む体制を取っています。

実際には「顧客が抱える課題の本質を見極める能力は、DSのほうが高い」「技術的な課題を解く能力は、FDEのほうが高い」という風に、お互いのスキルを補い合いながら動くことが多いですね。

そのような分担を前提としたうえで、FDEに求められるのは「課題に対して複数の技術的解決策を提示し、顧客にとってどれが最適かを議論できる能力」です。ここはやはり、エンジニアとしての深い経験が活きるところだと思います。

※1 DS:デプロイメントストラテジスト。ビジネス課題を特定し、解決策の設計から現場定着までをリードして成果を最大化する役割。FDEが「顧客企業におけるCTO」と例えられるのに対し、DSは「顧客企業におけるCPO」と例えられる。

――最後に。FDEという存在が、今後のIT業界において担う役割とはなんでしょうか？

白井：これまで日本のIT業界では、顧客の発注を受けて納品するという商流が強かったのですが、そこには「そのように開発されたソフトウェアは、本当に顧客の役に立つのだろうか」という疑問がつきまとっていました。

FDEはこの構造への、アンチテーゼとも捉えることができると考えています。顧客の現場で課題を解き、その知見をプロダクトに実装して汎用化し、次の顧客へとつなげていく。このサイクルが回ることで、個別対応がそのままプロダクトの進化になる。従来の商流では絶対に起きなかったことです。

LayerXが2018年から一貫してやってきたことの正体は、振り返るとこれだったのではないかと思います。事業がピボットしても、このアプローチが変わらなかったのは、それが正しかったからだと確信を持って言えます。この方法論を組織として体系化している最中ではありますが、再現可能な体制ができつつあります。

そして、この形を、エンタープライズのお客様を対象とするAIエージェントプラットフォームの業界標準にしていきたいと考えています。

坂本：「2027年ごろに、ソフトウェアエンジニアが不要になる」という説があります。私も、「コードを書くこと自体が価値の中心ではなくなる」と捉えています。今後はコードを書く前の「課題特定」、書いた後の「組織への実装」の両極がエンジニアの重要な役割になっていく、と考えています。

まだ言語化されていない課題を見つけて体系化していく。技術的な解決に必要な要素をピックアップしていく。この工程はエンジニアリングそのものであり、なくなりません。

また、私自身がFDEとして活動するなかで、「AIは確率で動く」「組織は責任で動く」ということを強く実感しています。AIを組織に実装するためには、原理が異なるこの2つをマッチさせなければなりません。

「どうすれば人間は、AIの出す答えに対して責任を持つことができるようになり、どうすればAIを組織運用に組み込めるようになるか」――この「確率と責任の接合設計」こそが、FDEが技術的に突き詰めていくべきテーマになると思います。

取材：川島 昌樹、王 雨舟
執筆：川島 昌樹
編集：川島 昌樹、王 雨舟
撮影：曽川 拓哉