米国発の新職種「FDE（Forward Deployed Engineer）」への注目が、日本のSaaS界隈で急速に高まっている。顧客の現場に深く入り込み、技術の力で個別課題を解決していくこのポジションに対し、新たなエンジニアのスタンダードとして期待を寄せる声は多い。

しかし、界隈の熱狂のままに、あらゆるSaaS企業がこぞってFDEを導入するのは本当に正しい選択なのだろうか。SIer文化の根強い日本において、その実態としては「都合の良い受託開発」になってしまう可能性はないのか。

その疑問に対し「流行りの肩書きに踊らされる前に、自社のビジネスモデルを見極めるべきだ」と冷静な視線を送るのが、組織論やキャリア論をテーマにしたnoteの発信で注目を集める柳川慶太さんだ。

柳川さんは、SIerからキャリアをスタートし、その後自社開発のWebエンジニアやPdMを経て、現在は大規模プラットフォームを展開するテック企業で事業責任者を務めている。

「自分はFDEの当事者ではない。だからこそ、客観的に見えている部分がある」と語る柳川さんに、FDEが正しくワークする条件について聞いた。

柳川慶太さん（@gimupop）

1991年生まれ、神奈川県出身。横浜市立大学国際総合科学部卒業後、TIS株式会社に入社。クレジットカード基幹システムの開発に従事。その後、株式会社マイクロアドでのDSPシステム開発を経て、2017年7月にBASE株式会社に入社。入社後はショップコインや「YELL BANK」の開発を経た後に、19年よりプロダクトマネージャーへキャリアチェンジし「YELL BANK」のグロースに従事。並行して「BASEカード」や「PAY.JP YELL BANK」の開発を推進する。25年よりBASE BANK Department Managerとして同事業を統括。25年3月27日付で執行役員に就任

FDEの安易な導入は、SaaSのスケールメリットを殺す

ーーそもそもFDEは、従来の「SIerの客先常駐エンジニア」と、どのような点で異なるポジションなのでしょうか。

役割上、両者を明確に分けるものが二つあります。一つ目は「自社のプロダクトがあるかないか」です。

客先常駐型のエンジニアは、お客様の要望に従ってゼロからシステムを作ったり、既存のシステムをカスタマイズして顧客の業務課題を解決します。

一方でFDEは、大前提として「自社のプロダクトがあること」を基盤に組まれたビジネスモデルです。土台となるプロダクトがあるからこそ、「この機能は個別に作る」「ここは作らない」と選べる手段の幅が全く違います。

そして二つ目は「プロダクトへ還流させる前提があるかどうか」です。客先常駐エンジニアのゴールは目の前のシステムを納品することですが、FDEの本来の目的は、現場の深い課題を解きながら、そこで得た学びを自社のコアプロダクトの改善に繋げること。この両者は、向いているベクトルが明確に異なります。

ーー最近は、規模や領域を問わず、様々な日本のSaaS企業が「うちもFDEを採用する」と掲げ始めています。この動きについてはどう見ていますか？

FDEの存在意義を考えたときに、少し危うさを感じますね。というのも、一般的なSaaSのビジネスモデルの利点と、相反してしまう可能性が高いからです。

そもそもSaaSの最大の強みは、共通のプロダクトをより多くの人に使ってもらうことでスケールメリットを出す点にあります。

例えば、SMB（中堅・中小企業）を中心に1万のアカウントを抱えるSaaS企業があったとします。そこにFDEというポジションを置いて、顧客ごとの個別課題に合わせてカスタマイズを提供し始めたらどうなるか。「じゃあ、1万通りのシステムを作るのか？」という話になってしまいますよね。

対象顧客の数が絞れていなかったり、1アカウントあたりの単価が小さかったりする状態でFDEを置いても、人を一人張り続ける原資が出ず、採算が合いません。

そうなると、実態としては顧客の現場で個別最適化するだけの仕事になり、結局のところ受託開発に限りなく近くなってしまいます。せっかくのSaaSのビジネスモデルを、自ら毀損してしまう行為になりかねないんです。

ーー安易にFDEというポジションを置くのは危険かもしれませんね。

大前提として、「FDEという言葉が流行っているからうちも入れよう」というのはおかしな話です。どんな役割も、事業をどういう形にするかという根本的なビジネスモデルから逆算されて生まれるものであり、役割に合わせてビジネスモデルができることはあり得ません。

ただ現状、「FDEを採用します」と言って動き出しているSaaS企業の中には、ビジネスモデルがFDE向きではないのにも関わらず、とりあえずポジションだけ置こうとしているケースもあるのではないでしょうか。

この流れは、何もFDEに限った話では無く、数年前の「PdMブーム」が辿った道筋と構造的にほぼ同じだと見ています。

言葉が先に来て、それを支える事業構造が後からついてこないと、肩書きと実態がズレていく。少なくともPdMの場合は、そのズレが量産された数年があったと思います。

「強いプロダクト」でなければ、FDEは必要ない

ーーでは、FDEが本来の役割として正しく機能するのは、どのようなビジネスモデルでの話なのでしょうか。

ここで大事なのは、本来のFDEは非常に重い役割を担うポジションだということです。

顧客の業務に深く潜り、しばしば「この機能は作りません」と顧客に対して提案を断る決定権まで持つ。表現としては「プロジェクトごとのCTO兼CPO」に近いと言ってもいいレベルの責任です。

この責任を負える優秀な人材を一つの顧客に張り付ける以上、いただける対価が非常に大きくないとビジネスとして成立しません。必然的に、顧客側に大きな投資予算がある「少数のエンタープライズが市場の大半を占める領域」であることが第一条件になります。

PalantirやOpenAIでFDEの報酬が高額になっているのは、ここの設計が機能しているからです。「優秀な人をエンタープライズ顧客の最前線に入り込ませ、その成果がプロダクトに還流する」ループが成立している会社の中でしか、FDEは本来のFDEになり得ません。

そしてその上で、ただ顧客が大きいだけではなく、「業界特化の深さ」がある領域かどうかが重要です。

写真／竹井俊晴　取材・文／今中康達（編集部）