NEW! ITニュース
米国発の新職種「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は、従来の「SIerの客先常駐エンジニア」と、どのような点で異なるポジションなのでしょうか。
役割上、両者を明確に分けるものが二つあります。一つ目は「自社のプロダクトがあるかないか」です。
客先常駐型のエンジニアは、お客様の要望に従ってゼロからシステムを作ったり、既存のシステムをカスタマイズして顧客の業務課題を解決します。
一方でFDEは、大前提として「自社のプロダクトがあること」を基盤に組まれたビジネスモデルです。土台となるプロダクトがあるからこそ、「この機能は個別に作る」「ここは作らない」と選べる手段の幅が全く違います。
ーー最近は、規模や領域を問わず、様々な日本のSaaS企業が「うちもFDEを採用する」と掲げ始めています。この動きについてはどう見ていますか？
FDEの存在意義を考えたときに、少し危うさを感じますね。というのも、一般的なSaaSのビジネスモデルの利点と、相反してしまう可能性が高いからです。
そもそもSaaSの最大の強みは、共通のプロダクトをより多くの人に使ってもらうことでスケールメリットを出す点にあります。
例えば、SMB（中堅・中小企業）を中心に1万のアカウントを抱えるSaaS企業があったとします。そこにFDEというポジションを置いて、顧客ごとの個別課題に合わせてカスタマイズを提供し始めたらどうなるか。「じゃあ、1万通りのシステムを作るのか？」という話になってしまいますよね。
対象顧客の数が絞れていなかったり、1アカウントあたりの単価が小さかったりする状態でFDEを置いても、人を一人張り続ける原資が出ず、採算が合いません。
そうなると、実態としては顧客の現場で個別最適化するだけの仕事になり、結局のところ受託開発に限りなく近くなってしまいます。せっかくのSaaSのビジネスモデルを、自ら毀損してしまう行為になりかねないんです。
ーー安易にFDEというポジションを置くのは危険かもしれませんね。
大前提として、「FDEという言葉が流行っているからうちも入れよう」というのはおかしな話です。どんな役割も、事業をどういう形にするかという根本的なビジネスモデルから逆算されて生まれるものであり、役割に合わせてビジネスモデルができることはあり得ません。
ただ現状、「FDEを採用します」と言って動き出しているSaaS企業の中には、ビジネスモデルがFDE向きではないのにも関わらず、とりあえずポジションだけ置こうとしているケースもあるのではないでしょうか。
この流れは、何もFDEに限った話では無く、数年前の「PdMブーム」が辿った道筋と構造的にほぼ同じだと見ています。
言葉が先に来て、それを支える事業構造が後からついてこないと、肩書きと実態がズレていく。少なくともPdMの場合は、そのズレが量産された数年があったと思います。
ーーでは、FDEが本来の役割として正しく機能するのは、どのようなビジネスモデルでの話なのでしょうか。
ここで大事なのは、本来のFDEは非常に重い役割を担うポジションだということです。
顧客の業務に深く潜り、しばしば「この機能は作りません」と顧客に対して提案を断る決定権まで持つ。表現としては「プロジェクトごとのCTO兼CPO」に近いと言ってもいいレベルの責任です。
この責任を負える優秀な人材を一つの顧客に張り付ける以上、いただける対価が非常に大きくないとビジネスとして成立しません。必然的に、顧客側に大きな投資予算がある「少数のエンタープライズが市場の大半を占める領域」であることが第一条件になります。
PalantirやOpenAIでFDEの報酬が高額になっているのは、ここの設計が機能しているからです。「優秀な人をエンタープライズ顧客の最前線に入り込ませ、その成果がプロダクトに還流する」ループが成立している会社の中でしか、FDEは本来のFDEになり得ません。
そしてその上で、ただ顧客が大きいだけではなく、「業界特化の深さ」がある領域かどうかが重要です。
ーー具体的にはどういう領域ですか？
例えば、現場の担当者がWeb上でマニュアルを見ながら自然と使えるような、表層的な業務効率化のSaaSであれば、わざわざFDEを現場に行かせる必要はありません。そうしたプロダクトは、人を介さずに安価にデリバリーできるからこそ価値があります。そこにFDEは要りません。
FDEが必要になるのは、顧客の事業の根幹に関わるような、複雑性が極めて高い領域です。独自の業務プロセスや、昔からの商慣習、あるいは部署間の複雑な前後関係など、「現場に深く潜り込んで、ドロドロした文脈まで理解しないと価値が出せない領域」です。
こういう深い課題を解くために、高度な技術的判断ができるFDEという存在そのものが、プロダクトを届けるデリバリーの一部として機能するわけです。
ーーしかし、エンタープライズの深い業務課題に入り込めば入り込むほど、「うちの会社の独自のルールに合わせて作ってほしい」という個別要望が強くなりそうです。
そうですね。そして、そこに引っ張られてそれぞれの顧客ごとにほぼ別のものを作ってしまったら、それは受託開発です。
このジレンマを防ぐという意味でも、FDEが成立するには「強いプロダクトの存在」が欠かせません。単なるWebサービスではなく、顧客のビジネスの基盤となり、ユーザーが使うことでデータやログが溜まり、それがさらに別のビジネスや改善に再利用できる「エコシステム」が構築されていること。
この強力な土台があるからこそ、FDEはゼロからシステムを作るのでは無く、自社プロダクトをベースにした「セミオーダーメイド」の形で、顧客の深い課題に当てにいくことができます。
ーー強いコアがあるからこそ、個別要件を一定の範囲に集約できると。
ただ、それだけではまだ不十分で、最後に絶対に欠かせない条件があります。それが「FDEが個別最適に流れないための、社内の統合の仕組み」です。
というのも、現場にいるFDE単体で動かすと、目の前の顧客の深い課題を一つ一つ解いていくうちに、どうしても「顧客の数だけリリースブランチを持つようなカオスなプロダクト」に近づいていきます。
だからこそ、FDEが得た現場の学びや要望を、「これはプロダクト本体の機能として取り込もう」「これは作らないでおこう」と交通整理し、プロダクトに集約・統合させる役割が絶対に必要になります。
実際にアメリカでは、FDEを単独で配置するのではなく、顧客と向き合う中で得た学びをプロダクト本体に還流させる「Deployment Strategist」や「PdM」のような統合役がセットで置かれているようです。
ーーまずは、自分たちの会社がそもそもFDEを支える形になっているかどうかを検証することが大事ですね。
はい。まず自社のビジネスモデルがFDEを支える形か検証する。その上で、業界特化と顧客予算規模を見極める。最後にFDE単独で置かず、それを統合する役割をセットで設計する。
この三つが重要で、かつ順番も大事です。ビジネスモデルが先で、外部市場の見極めがその次、そして組織設計が最後。この順序を間違えてしまうと、FDEというポジションを作って人を配置したはいいものの、いたずらに疲弊するだけで終わってしまいます。
FDEは全てのSaaS企業が目指すべき進化の方向ではなく、特定のビジネスモデルに特化した「全く別の形態」だと割り切った方がいいですね。
ーーFDEが成立するビジネスモデルの条件を踏まえると、直近SNSなどで話題になっている「PdMを廃止してFDEにする」といった極端な論調には、違和感を覚えますね。
そうですね。私から見ると、少し過剰反応されているだけな気がします。漠然と「AIによって何かが変わる」という不安がある中で、会社側の発表や発信に過剰反応しやすい土壌があるのでしょう。
会社側がわざわざ「PdMを廃止してFDEにしました」と発信するのも、基本的には採用マーケティングの一環なのかなと思います。同じような職種名だと埋もれてしまうので、採用市場で興味を持ってもらうための工夫の一つですよね。
そもそもアメリカの雇用環境は、ジョブディスクリプションに紐づいて募集し、その職種が要らなくなれば切るという文化です。それと日本の雇用習慣は全然違うので、アメリカの職務定義をそのまま日本に持ち込んで「これからはこの職種だ」と語るのは、少し慎重になった方がいいと思います。
ーー今後の日本のテック業界において、PdMとFDEは「どちらかが食う関係」になるわけではないのでしょうか？
結論から言うと、食い合うのではなく、別物として共存すると考えています。両者が同じ層を取り合っているように見えるのは、どちらも「プロダクトを作ることに関わる職種」という外見が共通しているからで、内側を見ると重心がまるで違います。
これは私なりの整理になるのですが、事業責任者、PdM、FDEの三つの職種は「何を作っているか」で重心が異なります。
事業責任者は「構造」を作る人です。何に投資してどう回収するか、事業全体の仕組みやロジックを設計します。
PdMは「プロダクト」を作る人。全員に同じプロダクトを届けることが前提で、その中で何を作るか、作らないかを判断し、統合します。
そしてFDEは「セミオーダーメイド」をつくる人。完全パッケージのプロダクトでも、フルカスタムの受託でもない、その中間。自社プロダクトをコアに置きつつ、顧客の個別業務に合わせて実装していくのがFDEの本質です。
三つの「作る」は、作る対象も、作り方の制約も違います。だからこそ、一方が他方を喰うという関係には本来ならないのです。
ーーただ実際には「PdMがFDEに置き換わった」ように見える組織もありますよね。
それは単純に、その会社のビジネスモデルが、最初から「FDE的な動き」を必要としていた事業構造だったというだけの話です。たまたまそこに「PdM」という肩書きの人が置かれていたから置き換えに見えただけで、構造側を見れば最初からFDEが必要な会社だった。
だから、「PdMがFDEに置き換わる時代だ」と語る前に、「自社のビジネスモデルが本来必要としていたのはどちらか」という問いに戻ったほうが見通しが良くなります。
ーーなるほど。一方で、AI時代には「PdM自身も自らコードを書いて作るべきだ」という議論も起きています。この点についてはいかがでしょうか？
私もエンジニア出身のPdMなので、「作れる環境があるなら作ってみたらいいじゃん」とはシンプルに思います。エンジニアリングの解像度がないと「何を作るか、作らないか」の判断精度も落ちますからね。
ただ、ここで誤読されやすいのは、「作る手段を持つ」ことと「作るのが主体になる」ことは別物だという点です。全てのPdMが日々の仕事としてコードを書くべきかというと、それは暴力的です。それなら最初からエンジニアだけで良かったじゃないか、という話になってしまいます。
PdMの仕事のコアバリューは、多様なステークホルダーの要望を「統合して意思決定すること」です。AIによって手軽に作れる学習環境が揃ったことで、その本来の役割がより強化されると考えるのが自然です。
FDEの「この顧客のための実装そのもの」と、PdMの「みんな向けの判断のための手段」は、同じ「作る」でも向いている方向が違います。
ーーここまで、FDEが成立する条件やPdMとの比較について伺ってきました。FDEに向いているのは、どのようなマインドセットを持っている人だと思いますか？
大きく二つあります。一つは、自分の仕事の領域が拡張されることに前向きな人。「私の仕事はここからここまでです」と線を引いてしまう人は向いていません。
もう一つは、お客様自身も言語化できていない「本当の苦しみ」に向き合うのが好きな人です。正面にいるお客様が要件を綺麗に並べ立てられるのであれば、そもそもFDEという職種は要りません。
「この人が言っていることは論理的じゃないな」と不快に思ってしまう人は向いていなくて、「この人は本当は何に困っているんだろう」と興味を持ち、泥臭くヒアリングして形にすることにやりがいを感じられる人が向いていると思います。
ーーAIの台頭やFDEという新職種の登場によって「自分の仕事はどうなっていくのか」と不安を感じているエンジニアは多いです。柳川さんご自身は、どう感じていますか？
私自身、自分の仕事が今後どうなっていくのか、本当に必要な仕事なのか分からなくて不安に思うことはあります（笑）。ただ、話としては凄くシンプルで、「自分は何を対価に、誰からお金をもらっているんだろう」というビジネスの根本を、改めて考え直す他ないですね。
SIerや受託開発の会社であれば、「開発効率が上がり、人月の生産性が上がる＝給料が上がる」という分かりやすい構造があります。しかし、自社でプロダクトを持っている会社の場合、ただコードを書く行数が増えたからといって、お客様から収益がもらえるわけではありません。
「この機能は本当に必要なのか？」「どういう風に収益が上がり、それが最終的に自分の給料に入ってくるのか？」をゼロベースで考えること。PdMや事業責任者が言ったことが絶対的に正しいわけではないので、そこに対して自分なりの意見を持ち、ユーザーにとって良いものに変えていく。
そうした思考の積み重ねが自信になり、環境が変化しても生き残る力になると思っています。
ーー技術の進化が早くても、エンジニアとしての基礎は決して無駄にならないと。
全然無駄にならないですね。「AIが出てきたからエンジニアの仕事はなくなる」「コードを書くなんて誰でもできる」と言われる風潮もありますが、私は全くそう思いません。
AIがない状態でエンジニアとして働いてきた人たちは、必死に頑張って勉強してきた人たちです。その「頑張って勉強する基礎」が身に付いている人は、必ず対応していけます。私自身、今もAIツールを使って自分のプロダクトを作ったりしていますが、エンジニア時代に得た経験が細かく役に立っていると実感します。
単にコードを書くというレベルの話ではなく、物事を理解するときの認知方法や思考体系そのものに、エンジニア的な素養が生きているんです。今でこそ事業責任者という立場ですが、プロフィールに「心はいつまでもエンジニアです」と書いているくらい、ファーストキャリアの経験は私の財産です。
だから、エンジニアの皆さんは大丈夫です。流行りの言葉に踊らされず、自分の仕事の本質的な価値に向き合い続けてほしいですね。
写真／竹井俊晴 取材・文／今中康達（編集部）
タグ
