技術を手放さずに、事業を動かす──FDEを定義する3条件と、その先で磨かれる3つの力

FDEを定義するにあたって、拠り所になるものがある。この役割を生み出したとされるPalantirの整理だ。

DevとDelta──Palantirが示した役割の記述

Palantirは2003年の創業当初から、米国の諜報機関や軍事産業という特異な業態のクライアントを抱えていた。その機密性の高さゆえに、技術者が自社ではなくクライアント企業内に身を置いて、ソフトウェアの要件定義や実装を行っていた。これがFDEの起源だとされている。

そして同社は公式ブログ「Dev versus Delta」で、エンジニアリングの役割を2つに分けて説明した（*）。一般的なソフトウェアエンジニアをDev、Forward Deployed Software Engineer（≒FDE）をDeltaと名づけた整理である。

*……Palantir公式ブログ「Dev versus Delta: Demystifying Engineering Roles at Palantir」を参照

両者の違いは、記事の中で端的に示されている。Devは「1つの能力を、多くの顧客へ」。Deltaは「1つの顧客へ、多くの能力を」。

Deltaは、Palantirのプラットフォームを土台に、クライアント企業のデータ、システム、業務へ接続し、そこで必要になるものを実装する。そして重要なのは、その先が明記されていることだ。

同記事では、Deltaがしばしばコア製品へコードを還元すると述べられている。成果を阻んでいるのがプラットフォームに欠けた機能やバグであるなら、Delta自身がそれを直すのは理にかなっている、と。そして大きな機能要望については、プロダクトチームのロードマップと突き合わせて組み込む必要があるとも書かれている。

さらに、Deltaに求められるスキルとして挙げられているのが、次の判断である。顧客が必要とする機能をコアプラットフォームへ組み込むのか、それとも速く届けられるカスタムなものをつくるのか。

ここから、3つの条件が取り出せる

Palantirの記述を整理すると、FDEを成立させる要素は3つに絞られる。

1．共通プラットフォームを実装の起点として持つ

2．クライアント企業の最前線に深く入り込んで実装を進め、成果を生み出す

3．その中での知見・経験を、プラットフォームの進化に還元する

取材内容等を基にFastGrowにて作成

そして重要なのは、この3つを回し続けることである。1社で成果を出しても、そこで止まればプラットフォームは強くならない。次の現場へ持ち込み、また成果を出し、また戻す。速く、多く回すほど、次の実装が複利で速くなる。FDEの価値は、1周の完成度よりも、回し続けられるかどうかで決まる。

ここまで示した3条件は、既存の職種と比べることで輪郭がはっきりする。

そして重要なのは、3つすべてが揃っていなければ、既存の呼称で説明できてしまうということだ。

既存の職種は、それぞれ違う欠け方をしている

取材内容等を基にFastGrowにて作成

SESは、①も②も③も持たない。クライアントの指示で工数を提供する契約であり、成果への責任を負わない。「クライアント先に常駐している」という一点だけをもってFDEと呼ぶなら、それはこの区別を捨てることになる。

受託開発・SIerは、②を部分的に持つ。合意した仕様を完成させ、稼働まで届ける責任がある。だが①がないため毎回ゼロからつくることになり、結果として③も成立しない。方法論やテンプレートは次の案件へ再利用されるが、それは人と組織の側に残るもので、すべてのクライアントが同じ形で使う1つのソフトウェアへは集約されない。

ITコンサルティングは、課題を構造化し、何を変えるべきかを示す。だが責任範囲は、そこまでである。自ら実装しない。そして助言に対して報酬を得るのであって、その助言が実装され、成果を生んだかどうかは契約の外にある。「何を変えれば成果が出るか」はわかっても、「その実装が本当に動くか」も「実際に数字が動いたか」も、自分では確かめられない。

SaaSの導入支援は、①を明確に持つ。共通プロダクトを土台に、クライアントの環境へ接続する。だが既存機能の範囲を出ない。足りない部分は要望として持ち帰り、開発するのは別のチームだ。

最も紛らわしいのは、SaaS企業そのものである

ここが重要な論点になる。

SaaS企業を組織として見ると、3条件が揃っているようにも見える。プロダクト開発チームが①と③を担い、カスタマーサクセスが②に近い動きをする。現場の声はプロダクトへ届き、機能として実装され、次のクライアントへ提供される。

だが、決定的に違う点がある。間が切れているのだ。

カスタマーサクセスが現場で聞いた要望は、要望書としてプロダクトチームへ渡る。そのとき、なぜその要望が出たのかという因果が失われる。何を汎用化し、何を個社固有として残すか。この判断が、現場を見ていない人の手で行われることになる。

FDEは、この間を切らない。

現場で課題を見つけた人が、実装し、成果を確かめ、何を還元するかを決める。3条件を、同じ因果の中で満たす。ここがFDEという呼称が必要になる理由である。

「現場常駐」は、FDEの条件ではない

ここで、もう一つ誤解を解いておきたい。

「Forward Deployed」が「現場常駐」と訳され、FDEを「クライアントのオフィスに身を置くエンジニア」と理解している例がある。これは明確に誤解である。

理由は、ここまでの整理から導ける。クライアントのオフィスに常駐していたとしても、3条件に当てはまっていなければ、それは「常駐の多い受託開発」や「常駐の多いコンサルティング」であって、FDEではない。身を置く場所は、何一つ条件を満たさない。

そして逆も言える。現場へ行かなくても、「クライアント企業の最前線」に身を置くことはできる。

つまり「Forward」が指しているのは、物理的な距離ではない。クライアント企業の事業が、実際に動いている場所のことである。

経理の担当者が申請を処理している画面。営業担当者が商談前に開くデータ。その企業のECで、消費者が商品を選んでいるページ。そこでは今日も、事業が動いている。その場所に手を入れられる状態にあるかどうかが、最前線に立てているかどうかを決める。

クライアント企業の事業が動いている場所に立てているなら、自社オフィスからでも、自宅からでも成立する。

なお、この「最前線」が具体的にどこを指すのかは、FDEが向き合う事業領域によって大きく異なる。従業員の業務そのものなのか、消費者との接点なのか。そこは次の記事で詳しく扱う。

つまり、既存語で説明できるものを、FDEと呼ぶ理由はない

3条件のどれかが欠けているなら、それは既に名前がある仕事だ。新しい呼称が必要になるのは、3つすべてが揃い、しかも間が切れていないときだけである。

なお、3条件を満たすうえで、担当する技術領域まで1人がすべて引き受ける必要はない。海外では、インフラに特化する、AI実装に特化するといった分化が始まっている。ただしその場合も、現場へ入り、成果まで届け、学びを戻すというサイクルは、それぞれが担っている。ここは後ほど詳しく見る。

定義が固まったところで、なぜこの役割がいま急速に語られるようになったのかを確認しておきたい。

まず、FDEをAIのために生まれた役割として捉えるのは正確ではない。Palantirがこの働き方を始めたのは2003年で、公式ブログでの整理も生成AIが一般化する前のものだ。

では、何が変わったのか。理想が変わったのではない。経済性が変わったのである。

深く入る価値は、昔からわかっていた。だが、割に合わなかった

クライアント企業ごとに、入力となるデータ、運用プロセス、求めるアウトプット、重視する指標は異なる。そこを理解しなければ、本当に解くべき課題は見つからない。これは新しい発見ではなく、ソフトウェア産業ではずっと理解されていたことだ。

問題は、コストである。

1社ごとの差分を調べ、つくり、試すには、大きな工数がかかる。しかもFDEを担えるのは、技術力と課題設定力を併せ持つ人材だ。人件費は高く、1社に張り付けば当然、粗利は圧迫される。

だから長らく、この働き方が成立する企業は限られていた。Palantirが例外的に成立させられたのは、諜報機関や軍事産業という、桁違いの予算を持つクライアントを相手にしていたからである。得られる契約金額が大きければ、深く入るコストを吸収できる。

裏を返せば、それだけの予算が動く現場でなければ、深く入ることは事業として選べなかった。

生成AIが、3つの前提を同時に変えた

だが、生成AIがその条件を変えた。しかも、1つではない。

1つは、実装コストが劇的に下がったこと。

コード生成によって、試作と検証が桁違いに速くなった。非定型業務の理解や、業務ドキュメントの読み解きも、以前とは比べものにならない速度で進む。1社に深く入るためのコストが、下がったのである。

もう1つは、モデルがコモディティ化したこと。

高性能な基盤モデルへ、誰もがアクセスできるようになった。ということは、モデルの性能そのものでは差がつかない。表層的なUIや、汎用的な機能の組み合わせは、誰でも速くつくれて、すぐに真似される。

そして3つ目に、実装コストの低下は、仕事の分け方そのものを変えた。

従来は、現場でヒアリングする人と、持ち帰って開発する人を分けるのが合理的だった。実装に時間がかかる以上、要件を固めてから着手しなければ手戻りが大きすぎたからだ。

だが、その前提が崩れた。聞きながら試作し、その場で反応を見て、また直す。分業して受け渡すより、1人が通しでやるほうが速くて安い。分けることの経済合理性が、失われたのである。

この3つが同時に起きたことで、競争の場所が移った。

浅いところは、誰でも解ける。だから、深いところを解きにいくしかない。クライアント企業のデータの癖、業務の例外、意思決定の順序。そこにしか、模倣されない価値が残っていない。

深く入ることは、もはや選択肢ではない

つまり構造はこうだ。深く入るコストが下がり、同時に、浅いところで勝てなくなった。

以前であれば、深く入るのは「できればやりたいこと」だった。コストが見合わなければ諦める選択肢もあった。いまは違う。深く入らなければ、すぐに追いつかれる。

FDEという役割がいま急速に増えているのは、この構造変化に対応するためである。生成AIがFDEを生んだのではなく、生成AIが、FDEという昔からあった理想を、事業として選べるものに変えた。

入場条件としての、エンタープライズ

ただし、コストが下がったといっても、ゼロになったわけではない。FDEは今も、エンタープライズ向けでなければ構造的に成立しない。

1社に深く入る実装は、依然としてコストが大きい。それを回収できるのは、動く売上・業務の規模が大きい企業だけである。SMBが抱える課題は、共通プロダクトの標準機能で解くべきであり、その領域にFDEを張る必然性がない。

そしてこれは、条件3と表裏の関係にある。還元がなければ、そもそもハイタッチな実装はペイしない。深く入るコストを、次の実装が速くなることで取り戻す。この前提が成り立つ規模でしか、FDEという役割は置けない。

FDEを置くとは、短期の利益率を差し出して、中長期の競争優位を取りにいくという判断である。

ここまで見てきた3条件は、FDEかどうかを判定するためだけのものではない。それぞれの条件が、FDEの現場で直面する難しさを生み出している。そしてその難しさの裏側に、この仕事を選ぶ理由になる面白さと、エンジニアとして磨かれる力がある。

先に、全体像を示しておく。

取材内容等を基にFastGrowにて作成

ここからは条件ごとに、具体的に何をすることになるのか、そこにどんな難しさがあるのか、それを越えると何が面白いのか、そして何が自分に残るのかを順に見ていく。

条件1｜共通プラットフォームを起点にする

◆ 具体的に、何をすることになるのか

共通プラットフォームが、実装それ自体のスピードアップはもちろんのこと、その前の現場課題把握や、一つひとつの具体的なソリューション提案までスムーズにする。なぜなら、それは決まった機能を実現するものではなく、「過去の実装で蓄積した知見・経験を、いかにして次の実装に活かすか」を考え抜いてつくられているものだからだ。

つまりFDEは、武器を携えてクライアント企業の前に立つ。何もない状態から要件を聞き、見積もり、つくり始めるのではない。すでにある能力を組み合わせながら、目の前の課題にどう応えるかを考えることになる。

◆ 難しさ──どこから手をつけるかの決まっていない、大きな事業課題に向き合う

だが、武器を持って立つということは、相手の期待もそれだけ大きいということだ。

「このシステムをつくってほしい」ではなく、「この事業をなんとかしたい」から会話が始まる。課題の粒度が、最初から事業のサイズで来る。

受託開発なら要件定義書がある。自社プロダクトの開発ならプロダクトマネージャーが仕様を持ってくる。ここにはどちらもない。そして相手も、何を解けば事業が動くのかをわかっているとは限らない。

だから、その大きな塊のどこに手を入れるかを、こちらが決めることになる。求められるのは、本質を見極める力である。

担当者の言葉を、そのまま受け取らない。なぜその課題が生まれているのかを、複数の側から探ることになる。現場の担当者に聞く。既存システムの構造を読む。データを見て、実際に何が起きているかを確かめる。日々の運用がどう回っているかを追う。

そうして集めたものを突き合わせると、最初に言われた課題の裏にあるメカニズムが見えてくる。なぜこの作業が発生しているのか。なぜこの数字が伸びないのか。根本の原因に辿り着いて初めて、何をつくれば事業が動くのかが決まる。

これは、エンジニアリングの外側にある能力ではない。システムの構造を読み、データから実態を掴み、処理の流れを追う。エンジニアが日常的にやっていることを、事業のレベルで働かせることになる。

◆ 面白さ──解くべき課題だけに、集中できる

では、その難しさを越えると何が返ってくるのか。

事業のサイズで課題が来るということは、裏を返せば、そのサイズの問題に手を入れられるということだ。

そして車輪の再発明をしなくていい。

受託開発では、毎回ゼロからつくることになる。認証も、データ連携も、監視も、案件が変わるたびにつくり直す。そのどれもが、本当に解きたい課題ではない。

FDEは違う。自分が、あるいは先人が積み上げてきたものの上に立てる。だから、そのクライアント企業にしかない深いペインへ、最初から時間を注げる。手を動かす対象が、誰かが既に解いた問題ではなく、そこでしか出会えない難問になる。

これは、エンジニアがOSSの文化の中で当たり前にやってきたことと同じである。巨人の肩に乗り、まだ誰も解いていない部分だけに向き合う。その営みを、事業の最前線でやるのがFDEだ。

◆ 磨かれる力──事業の本質を、見極める力

そしてこれを繰り返すうちに、ある力が育つ。

大きな課題を渡されるたびに、その裏で何が起きているのかを掘り当てる。この作業を何十回と重ねると、見えてくるものが変わってくる。

最初は、担当者の説明を頼りにしていた。次第に、システムの構造を見れば業務の流れが推測できるようになる。データの分布を見れば、どこで詰まっているかの見当がつくようになる。言われたことと、実際に起きていることのズレに、早く気づけるようになる。

そして業界が変わっても、この見立ては効く。表面の業務はまるで違うのに、詰まる場所の構造は似ているからだ。承認が多層になっている。データが分断されている。人が判断を代行している。何度も掘っているうちに、こうした型が頭の中に溜まっていく。

これは、要件が降りてくる立場では育たない。与えられた仕様の内側で最善を尽くすことと、そもそも何が問題なのかを見極めることは、使う筋肉が違う。課題の定義から任されるからこそ、この力が鍛えられる。

そしてこの力は、FDEを離れても効く。プロダクトの意思決定でも、技術選定でも、「本当に解くべきはそこなのか」を問える人は、どの組織でも重宝される。

条件2｜最前線に深く入り込み、成果を生み出す

◆ 具体的に、何をすることになるのか

FDEの役割は、開発・実装だけではない。それらは手段であり、成果を出さなければならない。

そして、実装が終わった時点では、成果はまだ1ミリも出ていない。

つくったものが本番環境で動く。それが実際に使われる。使われた結果として、人の行動が変わる。変わった行動が続く。その結果として数字が動く。動いた数字が、実装によるものだと確認できる。この全部が起きて、ようやく成果である。

FDEは、この最後まで責任を持つ。実装の前にも後にも、やるべきことがある。手を動かしてコードを書いている時間より、それ以外の時間のほうが長いことすらある。

◆ 難しさ──実装と成果の間に、壁が幾重にも立っている

実装から成果までは、一直線ではない。間に性質の違う壁が、幾重にも立っている。

まず、システムの壁。本番環境で安定して動くこと自体が簡単ではない。既存システムとの接続、データの欠損、負荷、権限、障害時の挙動。動くものと、動き続けるものは違う。

次に、導線の壁。動いたとしても、すでにある流れに乗らなければ使われない。従業員が使うものなら、日々の業務手順のどこに差し込むのか。消費者が触れるものなら、購買や利用の流れのどこに置くのか。新しいものをつくることと、既存の流れに組み込むことは、別の仕事である。

そして、意思決定の壁。動くものができ、置き場所も決まった。だが、それを本番へ出す判断は、技術の外で下される。従業員向けなら、現場の負荷や他部門との整合が問われる。消費者向けなら、ブランドへの影響や法務の確認が入る。「出してよい」と組織が言わなければ、完成したものが使われないまま止まる。

さらに、行動変容の壁。全部が整っても、人はすぐには変わらない。従業員なら、慣れたやり方のほうが早いと感じれば元に戻る。消費者なら、そもそも選んでくれない。用意したものが、実際に選ばれ、使われ続けるかどうかは、別の問題である。

最後に、計測の壁。行動が変わっても、それが数字に出ているかは別の話だ。何を測れば効果が見えるのか。その数字は本当に実装によるものか。因果を示せなければ、成果は「出たかもしれない」で終わる。

このどれか1つでも越えられなければ、実装を成果へ繋げることができない。技術的にどれだけ正しくても、である。

だから、越えるべき壁に応じて、やることは変わる。システムの壁ならアーキテクチャを組み直す。導線の壁なら、置き場所や見せ方を変える。意思決定の壁なら、判断に必要な材料を揃えて持っていく。行動変容の壁なら、使われ方を観察して直す。壁の性質を見極め、それぞれに合った手を打つ。これがFDEの「実装」である。

◆ 面白さ──自分がつくったものが、実際に使われ、事業を動かす

では、その難しさを越えると何が返ってくるのか。

自分がつくったものが、現場で使われている。そして使われた結果として、業務にかかる時間が減り、あるいは売上が増えている。その因果を、自分の目で確かめられる。

自社プロダクトの開発であれば、機能をリリースした先に何が起きたかは、間に何層もの人と時間を挟んで届く。受託開発であれば、納品した時点で自分の手を離れる。つくったものが誰にどう使われ、何を変えたのかを最後まで見届けられる立場は、実は多くない。

そして、越えた壁の分だけ、手に入るものがある。システム、導線、意思決定、行動変容、計測。幾重にも重なるこれらを自分で通した経験は、実装だけを繰り返していても身につかない。

さらに、その規模も特異である。目の前の担当者の顔が見える距離にいながら、変えているのはその企業の事業そのものだ。

受託開発なら、手触りはあるが影響は1つのシステムに閉じる。大規模プロダクトの開発なら、影響は大きいが、誰の何が変わったのかは遠い。FDEは、目の前の手触りと事業インパクトの両方を、同時に持てる立場にある。

◆ 磨かれる力──技術を、事業成果まで繋げ切る力

幾重にも重なる壁を、何度も越える。この経験を繰り返すうちに、つくる前から先が見えるようになる。

これをつくれば、システムとして安定するのか。既存の流れに乗るのか。組織の判断は下りるのか。相手は本当に使い続けるのか。そして、その効果は測れるのか。このすべてを、着手前に見通せるようになる。

そして、どこで詰まりそうかがわかるようになる。機能としては正しいが、承認が下りない。動きはするが、既存の流れに置く場所がない。つくる前にそれが見えれば、最初から違うものをつくれる。

多くのエンジニアは技術で止まる。多くのビジネス職は数字から逆算する。両端を自分の手で繋いだ経験がある人は、実は少ない。

この力は、プロダクトを持つ企業のどこへ行っても効く。「これは事業を動かす」と自分で見立てて、実際にそのとおりになる。その打率が上がっていくほど、任される問題は大きくなり、扱える技術の幅も広がる。面白い仕事が、向こうから来るようになる。

条件3｜プラットフォームへ還元する

◆ 具体的に、何をすることになるのか

1社で見つけた課題や実装上の工夫を、担当者の頭や個別コードに残すだけにしてしまうことは、許されない。緻密に取捨選択し、自社で運用するプラットフォームを進化させ続ける義務が、FDEにはある。

還元するものが、必ずしもソフトウェアのレイヤーとは限らない。接続部品、評価方法、実装手順、設計パターン、品質基準、権限設計、失敗しやすい条件なども、次の実装を強くする共通プラットフォームの一部になる。

そして、還元するかどうかを決めるのはFDE自身である。誰かが「これは共通化すべきだ」と指示してくれるわけではない。目の前の実装を終えたあと、これは他社でも使えるのか、それともここだけの事情なのかを、自分で判断することになる。

◆ 難しさ──正解のない決断を、毎回迫られる

共通化するか、個別に残すか。この決断に、正解がない。

個社固有の事情を無理に共通化すれば、かえって複雑になり、他社が使いにくくなる。逆に、共通化を怠れば、次の案件でまた同じところからやり直すことになる。目の前の成果と、次の再利用性を、同時に見ながら決めていくしかない。

そして、前例が答えをくれるとも限らない。過去に共通化してうまくいったパターンは積み上がっていく。だがそれが今回に当てはまるかは、やってみるまでわからない。1社しか見ていない時点で、それが共通の型かどうかはわからない。3社目でようやく「あれは共通だった」と気づくこともあれば、汎用化したつもりのものが次の現場で邪魔になることもある。

さらに、還元先も一様ではない。プロダクトの機能として実装すべきか。実装手順として残すべきか。それとも設計の判断基準として言語化しておくべきか。形が違えば、次に使える場面も変わる。

判断材料が揃うのを待てば、次の現場はもう始まっている。だから、揃わないまま決めることになる。

◆ 面白さ──1つのインサイトが、全顧客の武器に変わる

では、その難しさを越えると何が返ってくるのか。

ある現場で、ふと気づく瞬間がある。「この処理、他社でも同じように詰まっているのでは」「この見せ方、あの業界でも効くんじゃないか」。

通常なら、そこで終わる。だがFDEは、その気づきから動ける。プロトタイプをつくり、本番で試し、うまくいけばプラットフォームへ組み込む。そして次のクライアント企業では、それが最初から使える手札になっている。

個社のために書いた実装が、共通プラットフォームの能力として残る。目の前のクライアント企業を助けたことが、次のクライアント企業の初日を変える。

これは、エンジニアの仕事の残り方として特異である。受託開発では、成果物は納品した先に置いてくることになる。自社プロダクトの開発なら、書いたコードはプロダクトの中に積み上がる。だがそれが本当に誰かの役に立ったのかは、確かめられないまま次の機能へ進むことも多い。

FDEは違う。目の前の1社で実際に効いたことを確認したうえで、それを資産として積み上げる。役に立つとわかっているものだけが、複利の資産として積み上がっていく。

そして、その積み上がりを自分で実感できる。1社目で数カ月かけて見つけた解き方が、2社目では出発点になる。3社目ではさらに短くなる。同じ努力の量で、届く範囲が広がっていく。

条件1では、先人が積み上げたものの上に立てることを面白さとして挙げた。ここは、その反対側である。今度は自分が、次の誰かのために積む側に回る。一度解いた問題を、次は誰も解かなくて済むようにする。乗る側と積む側の両方を、同じ人間が担う。それがFDEの立ち位置だ。

◆ 磨かれる力──技術と事業を、具体と抽象で行き来する力

目の前の1社で動いたものを、次の10社で動くものへ変える。この変換で問われるのは、どこで切るかである。

細かく切り出しすぎれば、その1社にしか効かない。粗く括りすぎれば、どこにも当てはまらない。その中間のどこかに、他社でも使える粒度がある。それを、判断材料が不十分なまま探し当てることになる。

そして、この判断は技術だけでは下せない。この処理は、この企業の組織構造から来ているのか。それとも業務そのものの性質なのか。事業の側で本質と事情を切り分けられて初めて、技術の側でどこまで汎用にするかが決まる。

1社目では「これは特殊事情だ」と思ったものが、3社目で「共通の型だった」とわかる。逆に、汎用化したつもりの機能が、次の現場では邪魔になる。この失敗と修正を繰り返すうちに、技術と事業を往復する速度が上がっていく。

そしてこの力は、扱える問題の大きさを決める。

コードの中だけで考えられる人は、コードの中の問題しか解けない。事業の言葉しか持たない人は、実装に落ちない構想しか描けない。技術と事業を、具体と抽象で自在に往復できる人だけが、両方にまたがる問題を引き受けられる。

そういう問題は、たいてい誰も解けていない。だからこそ、解けたときのインパクトが大きい。この力を持つほど、手を伸ばせる問題が大きくなっていく。

FDEは、事業へ染み出したいエンジニアにとって、最高のキャリアになる

ここまで条件ごとに見てきた。だがFDEの本当の価値は、この3つが1つのサイクルとして回り続けることにある。

課題の本質を見極め、自分でつくり、幾重の壁を越えて成果まで届け、そこで得たものを次へ残す。そしてまた次の現場で、一段強くなったところから同じサイクルを回す。

このサイクルを回し続けられる立場から、1つのことが言える。

コードを書く手を止めずに、事業を動かせるということだ。

多くのエンジニアは、どこかで選択を迫られる。事業に関わりたければ、プロダクトマネージャーや事業開発へ移る。だがそこでは、手を動かす時間は確実に減る。技術を手放すか、事業から遠いままでいるか。これが従来のキャリアの分岐だった。

FDEは、その分岐に乗らずに済む。軸足はエンジニアのまま、扱う対象が事業まで広がっていく。自分で設計し、自分で書き、自分でデプロイする。そのうえで、その実装が事業を動かす。

技術を手放して事業へ行くのではない。技術を持ったまま、事業へ染み出していく。

そしてこの立ち位置は、AI時代においてこそ価値を持つ。

誰もが同じAIモデルにアクセスできるようになった。モデルの性能そのものでは、もう差がつかない。ならばエンジニアの価値はどこで決まるのか。誰のどんな問題を解くのか。何をつくるのか。そして、どうやって成果が出るところまで持っていくのか。

FDEは、技術を軸に置いたまま、この3つすべてに手を伸ばせる。そして解いた分だけ、次に解ける範囲が広がっていく。

技術者であり続けながら、事業を動かし、さらに強くなっていける。

技術を手放したくない。だが、つくったものが事業を動かすところまで見届けたい。その両方を諦めたくないエンジニアにとって、FDEはいま最高のキャリアになる。

ここまで見てきたのは、FDEという役割そのものの姿である。では実際に、この役割はいまどこまで広がっているのか。そして、これからどう変わっていくのか。

そこで、海外と日本の求人を見比べてみたい。FastGrow編集部は今回、日本と海外それぞれにおいて、FDEおよびその近接職種に関する各社の公開求人・公式発信をできるだけ多く確認し、比較を試みた。

その範囲での観察結果として、FDEポジションが、英語圏を中心に海外企業で多く設置されていることは間違いない。見つかった関連求人の数は、日本国内と比べて数倍〜十数倍にのぼる。

だが、今重要なのは、その数ではない。中身だ。

海外では、FDEが技術領域ごとに分かれ始めている

興味深いのは、FDEという名称を使いながら、担当する技術領域を絞った求人が出始めていることだった。

インフラの実装を中心に担うForward Deployed Infrastructure Engineer。特定のAI実装を担うForward Deployed AI Engineer。ソフトウェア実装へ責任範囲を絞ったForward Deployed Software Engineer。

たとえばSierraは、インフラを担うForward Deployed Infrastructure Engineerと、クライアントの現場でエージェント開発を進める職種を別々に設けている。同じ「FDE」でありながら、1人がすべての技術領域を担う前提ではなくなっているということだ。

分化しても、3条件は保たれている

ここで確認しておきたいことがある。分化は、FDEを別のものに変えてしまわないのか。

Sierraの例を見る限り、答えは「変えていない」である。

インフラを担う人も、エージェント開発を担う人も、どちらもクライアントの現場に入り、本番環境を触り、そこで得たものを戻している。分かれているのは扱う技術の範囲であって、3条件のどれかを手放したわけではない。むしろ専門性が深まることで、サイクルの質は上がる。

つまり、技術領域は分けてよい。

ただし、分けてはいけないものがある

一方で、今後さらに分化が進んだとき、注意して見るべき点がある。

現場で課題を見つける人、実装する人、何を還元するか決める人。これらが別々になった瞬間、FDEはFDEでなくなる。セクション2で見たSaaS企業の構造と、同じ状態に戻ってしまうからだ。

分けてよいのは技術領域であって、サイクルではない。

現場で何が起きたのか。その成果は、どの実装によって生まれたのか。そこから何を共通基盤へ戻すのか。この一続きが同じ人の中で繋がっている限り、技術領域をどれだけ細かく分けてもFDEであり続けられる。

そして、これから新しい名前のFDE職が次々と生まれるだろう。そのたびに確かめるべきは、名前ではなく3条件のほうだ。現場へ入り、成果まで届け、学びを戻す。この一続きが切れていないか。そこを見れば、それが本当にFDEなのかがわかる。

日本は、技術領域の分化がまだ起きていない

この読み方をすると、日本の現状についても、「単に募集が少ない」というのとはまた違った見方ができる。

まず、日本でもFDEを正式な職種名として掲げる企業は、着実に増えている。LayerX、Sakana AI、Gen-AX、Sansan、ナレッジワーク、InsightX、プレイドなどが、この名称で募集を行っている。OpenAI、Palantir、Sierraなど、海外企業が日本市場を担当するFDE職を募集する例も増えている。

一方で、FDEの役割を技術領域で分化させている例は、確認できなかった。

日本のFDEが1職種に集約しているのは、遅れているからではない。まだ型化の前段にいるからである。

職種の分化は、その領域がどこまで型化されたかを示す。型が固まっていない段階では、何が難所になるかも読めないため、1人がすべての技術領域を通しで担うしかない。型が固まってくると、領域ごとに専門を立てられるようになる。インフラならインフラで、AI実装ならAI実装で、深く掘る人を置ける。

そしてこれは、FDEを目指す人にとって決定的に重要な示唆を含む。

いま日本でFDEになると、分化した後では担えない範囲を、1人で通しで経験できる。クライアント企業の課題設定から、インフラの構築、AI実装、フロントの改善、成果検証、そして製品への還元まで。数年後に技術領域の分化が進めば、この範囲は領域ごとに分かれていく。

全部を1人で担える時期は、長くは続かない。

FDEに興味を持っている時点で、あなたは、最もエキサイティングな環境に身を投じたいという思いを持っているはず。それなら、今このタイミングがベストになる。

ここまで、FDEと呼べるものと呼べないものの線を引き、3条件が生む面白さと難しさ、そして今後あり得る動きについて詳しく見てきた。

ただし、同じFDEでも、誰の仕事や体験を変えるのか、何を成果として追うのか、現場レベルでは大きな違いがある。

1人が担当するクライアント企業は1社なのか、複数社並列なのか。1つの案件は3カ月で終わるのか、期間を定めないのか。そしてエンジニアとして、何が磨かれるのか。

この違いは、偶然ではない。FDEがクライアント企業のどこへ入っているかによって、構造的に決まっている。

次の記事では、縦軸に「目指す成果（売上を上げる／コストを下げる）」、横軸に「働きかける相手（クライアント企業の従業員／消費者）」を置き、FDEが向き合う最前線を4象限で構造的に考察する。

取材内容等を基にFastGrowにて作成

4象限すべてに共通するFDEの本質は、本稿で示した3条件のままである。そして本稿で見てきた面白さも、4象限すべてに共通するものだ。

そのうえで、どの象限に入るかによって、磨かれる力がまったく違ってくる。業務の骨格を掘り当てる力なのか、技術で人と組織を動かす力なのか、何が来ても仕組みで受け止める力なのか、それとも答えのない問いに自分で答えを出す力なのか。

そしてこの4つは、互いに交換できない。1つを選ぶということは、他の3つを諦めるということでもある。

本記事と合わせて読むことで、あなたは、今後のキャリアの飛躍を改めて考える大きなきっかけを得ることだろう。