まえおき

最近よく聞くようになりました、FDE（Forward Deployed Engineer）。

事業会社の社内向けプロダクトを現在作っているのですが、
FDEロールとして動かさせて頂き、
やってみて色々と考えることがあったので、
自分用メモとして思考整理、言語化したものをアウトプット。

自己紹介

例によって「おまえ誰やねん」対策でざっくり自己紹介。

キャリア10年ちょいのミドルエンジニア
2015年くらいキャリア開始、組み込み系でガッツリSE
2020年くらいからソシャゲサーバーサイドでテックリード
2025年くらいから事業会社でバックエンド
2026年くらいから社内向けでのFDEロール

何でも屋さんだった話

僕はソシャゲのテックリードとして、
ソシャゲを作るうえで必要なことは何でもやってきました。

設計・実装はもちろん
インフラ、CI/CD、プラットフォームも
スケジュールや調整ごとも
分析や、ゲーム体験の提案も

なので当時から、バックエンドメインな何でも屋さんを名乗ってました。

FDEをやってみた話

最近、FDEのロールをやることになりました。

以下が実際にやったことです。

プロセスマイニング
- 現場の業務が実際どう流れているのかを把握する
KPI定義
- 何が良くなったら嬉しいのかを数字で決める
簡易ツールの提供
- 目の前の困りごとをサクッと解決する
PoC実施
- 効果がありそうか小さく試す
プロダクトへの落とし込み
- 効果があったものを本体の機能にする

ただ弊社はプロダクトがあるといっても提供者は社内の事業部、
ぶっちゃけ社内SEなので本来のFDEとはそもそも由来が違います。

FDEの原典では、

Deltas (Forward Deployed Software Engineers) deploy our software platforms to customers. Deltas are part of Business Development, and their mandate is to achieve technical outcomes for our customers.

You can think of a Dev’s focus as “one capability, many customers,” while a Delta’s focus is “one customer, many capabilities.”

自分の言葉で言うと以下だと理解しました。

　Devは、1つの機能をたくさんの顧客に
　FDEは、1つの顧客にたくさんの機能を

（「Delta」がFDE、「Dev」が開発）

全体像については、元Palantirの方の記事が分かりやすかったです。

...the key idea is that you gain intricate knowledge of business processes in difficult industries (manufacturing, healthcare, intel, aerospace, etc.) and then use that knowledge to design software that actually solves the problem. The PD engineers then ‘productize’ what the FDEs build, and – more generally – build software that provides leverage for the FDEs to do their work better and faster.

FDEが顧客の現場で業務を深く知り、実際に問題を解決するものを作る
PD（プロダクト開発）が、FDEの作ったものをプロダクトに落とし込む
- さらにFDEの仕事が早くなる道具も作る

原典は自社プロダクトありきでtoBの顧客への向き合い方なので、
前途の僕の動き方がFDEとして適切かは少し曖昧ですが...

それでもFDEの動き方としては近しいものがあると考えています。

が、やってみて感じたのは、
このロール、そもそも必要なのか？ ってことでした。

FDEは必要なのか

PMとエンジニアはグラデーション

今求められているのは、エンジニアが現場に寄り添うことだと考えています。

現場に寄り添う事は、今まで主にPMが主体だったかと思います。
そしてそのPMも、最近はPRを作るようになりました。

エンジニアとしては最近、手を動かす時間が減ったはずです。
だとしたらエンジニアも現場に行かなきゃですよね？

お互いの出来る領域が増え染み出してきているだけだと考えると、
縦割りではなくグラデーションに自然となったのだと考えています。

大事なのは現場の信頼

現場に出るうえで大事なのは、信頼の取り方だと考えています。

エンジニアとして認めてもらうのではなく、
事業を伸ばす同じ目線の仲間として認めてもらえればOK。

そのためにエンジニアとしては、
現場の困りごとを１つサクッと解決して信頼を得るのが手っ取り早いと考えています。

（筆者の実例）
現場で使ってもらっている社内プロダクトに、
データの総数がすぐに分からないという問題がありました。

これに対して、めちゃくちゃ簡易のスプシをペライチで用意しました。

この業務は過渡期の困りごとのため、プロダクトに入れ込む予定は無いです。

が、スピード感を持って「即日で作っておきました」をしたので、
これ以降現場に話を通しやすくなったと感じてます。

やってることは当たり前のこと

FDEの一歩として実施したプロセスマイニングやKPI定義は、
エンジニアに限らず業務を遂行する人の共通の目線ですよね。

プロダクトへの落とし込み、共通化、FBといった横展開も、
FDEに限った話ではないですよね。

なのでFDEがやっていることは、
どれも特別なことではなく当たり前のことだと考えてます。

だから僕は何でも屋さんを貫く

FDEという枠組みについて、僕はこう考えています。

　出来ることが広がったので、やるべきことも広がっただけ
　エンジニアとしての当たり前が広がっただけ

~~ぶっちゃけやるべきことが広がったのに、名前を付けて守備範囲を明確化しようとしているところは僕はナンセンスだなーって感じてます...~~

~~会社によっては権限範囲の定義や採用観点、他社比較では便利かもしれないですが...~~

なので僕は、何でも屋さんを継続することにしました。

※唯一変わったかなと感じたのは作るものの決め方です。
エンジニアが現場で考えて、小さくPoCで試し作り込みするため、
コンサルに近い動き方が必要になってきたなと感じています。

現場に出る

今一番価値があると考えている動き方は以下です。

とにかく現場に出る
実際の業務実態を知る
実際に手を動かしている人と話す
エンジニアリングを武器に、サクッと目の前の問題を解決する
仲良くなる
信頼関係を築いたうえで、要望・提案・調整をする
プロセスマイニング・KPI測定から効果があったものをプロダクトに落とし込む
また現場に出る

現場に出ることがエンジニアの価値かなと考えてます。
自分は労働集約型の事業会社の社内SEなので現場に行くだけでなく、
新人研修に参加して業務の実体を追体験し手を入れる箇所を探しています。

toBでプロダクトありきの場合でも変わらず、
導入サポートに留まらず、現場でKPIに沿った課題収集に時間を費やすべきだと考えています。

toCの場合は少し難しそうですが...
以前より問い合わせの分析やコミュニティの把握など能動的なFB収集などが該当するかなと考えています。

AIには五感がない

AIには五感がないですよね。

現場の空気も、困っている人の表情も、AIはまだ自分で見に行けないです。

なのでとにかく現場に行って、AIのための五感になり、
「ふるい」になるのが直近のエンジニアだと考えています。
（現場で拾った情報を整理し、AIに渡すものを整頓する役）

まとめ（意思表明）

FDEというロールをちょっとだけやってみましたが、
僕にとっては何でも屋さんの延長のように感じられました。

なので無理せず、AI使われの何でも屋さんを名乗りながら、
変わらずやるべきことをやっていれば良いのかなと思います。

補足：何でも屋さんについて

よくネガティブな意味で使われるので...
言われたものつくる人とか御用聞きじゃなく、
明確なロールはない遊撃手であり、
やるべきことをやる人ってポジティブな意味で使ってます。