先日HR系の会社の方から聞いたのですが
スカウトの件名に「FDE（Forward Deployed Engineer）」と入れると、返信率が明らかに変わる。

いま、そういう時期に入っているのだそうです。でも、その言葉を自分の会社の言葉として定義できているチームは、どれくらいあるでしょうか？と社員からミーティング中に質問が出てきました。定義がないまま「FDE」という言葉を使うと求職者の方も迷うのではないか？せっかく一緒に働くことになっても「ちょっとイメージと違う」なんてことになるのではないか？

今回は、インタビュアーの私が社内のミーティングで実際に交わされた議論をもとに、マネージャーとエンジニアの2人に、「FDEをどう定義しているのか」を聞きました。転職希望者様に会社の考え方を解像度高く理解して頂けたら幸いです。

登場人物

• マネージャー：事業と開発の両方を見る立場。FDEの定義づくりを進めている。
• エンジニア：開発とリリースの実務を担当。現場からの視点で問いを返す。
• インタビュアー：聞き手。（業務委託です。今回は代表のアカウントを借りました）

1. FDEの「F」は、Field=戦場だった

インタビュアー：まず素朴な質問からいきます。FDE、Forward Deployed Engineer。この「Field」って、どういう意味なんでしょうか。

マネージャー：もともとの言葉の意味は、戦場なんですよ。Fieldって書いてあるけど、あれはバトルフィールドのこと。

エンジニア：あ、そうなんですか。

マネージャー：Palantirがなぜあれだけ評価されたか。戦場にエンジニアが行ってるからです。ホワイトボードの前で、この輸送路で物資を運んでいて、ここで何人も死んでいる、という話を現場で聞く。それでエンジニアが「じゃあGPSでこことここが危険だと分かるんだから、回避する仕組みを作るよ」と言って、その場で作る。

インタビュアー：エンジニアが会議室ではなく、現場にいる。

マネージャー：ヘルメットにブラックベリーをくっつけて走り回っていた、なんて話が出てくるような会社です。現場に身体ごと入っていくというのが、あの言葉の出発点なんでそうです。

2. 私たちのFDEの定義

インタビュアー：それを、自分たちの言葉にするとどうなりますか。

マネージャー：いま整理している最中ですが、軸は決まっています。

私たちが定義するFDE

1. 「使われる」ことが第一原則である
2. 前提条件を置かない
3. 要件定義ではなく、運用から入る
4. ラッパーにならない。顧客のデータと事業を守る技術を自分たちで持つ
5. エンジニアとは「今までできなかったことを、できるようにする仕組み」を作る人である

インタビュアー：ひとつずつ伺わせてください。

3. 第一原則：「使われる」

マネージャー：まず第一は、使われること。ここが最優先です。

エンジニア：作ったものが、使われる。

マネージャー：そう。そのために「前提条件を置かない」。前提を置いた瞬間、技術バイアスがかかるんですよ。「これは僕のやり方じゃない」「この技術で作りたい」——そうなると、使われるものにはならない。

インタビュアー：耳が痛い話でもありますね。転職活動でポートフォリオを作る、というのも近い構造でしょうか。

マネージャー：まさにそれです。自分の技術以上のことをやらないんですよ。「僕の技術を見てください」「僕の能力を見てください」と言う。見てもいいけど、僕らはビジネスをやっているので、「それでお客さんからお金は取れているの？」と聞くと、取れていない。未経験ITエンジニアブームの時は良かったのかもしれませんが、今は通用していない。

エンジニア：技術バイアスをもとに作るということは……。

マネージャー：レベルとしては趣味と同じなんです。趣味としては素晴らしい。でも僕らは仕事でやっているんだから、仕事のレベルまで持ってこないといけない。言及したように「作った」ではなく「使われる」ことが重要なのです。自分本位ではなく、お客さん本位で貢献する。第一はそこです。

4. 前提条件を置かない、とは何をすることか

インタビュアー：「前提条件を置かない」を、もう少し具体的にお願いします。

マネージャー：たとえば現場に行って、「ラズベリーパイを持ってきて、ここに接続して、カメラをつけたら、ここにつながりますよね」となれば、もしかしたらそこでブレイクスルーできるかもしれない。Palantirの人たちは、それくらいのことを実際にやるんですよ。

エンジニア：制約側から発想する、ということですね。ネットワークの帯域が遅い、みたいな条件でも。

マネージャー：そう。「この帯域だと全然遅い、それは条件なのか？」から入る。だったら分割して送りますか、そのためにサーバーをこう組んで……とやっていく。速くはないけど、なんとか耐えられる、我慢できるところまで持っていく。それが現場で効くんです。

インタビュアー：理想の構成を先に描くのではなく、現場の制約から逆算する。

マネージャー：前提を作ると、そこで伸びが止まっちゃうんですよ。

5. 要件定義ではなく、運用から入る

マネージャー：もうひとつ付け加えると、運用なんです。FDEの肝は。

エンジニア：エンジニアって、要件定義から考えるじゃないですか。

マネージャー：違うんですよ、逆なんです。お客さん側から見ないといけない。最後は要件定義に行くかもしれないけど、まず運用から入る。だって、誰も運用を崩したくないでしょう。

エンジニア：業務のやり方が変わるって、すごくハードルが高いですよね。

マネージャー：日本市場は特にそうです。海外だと「システムに合わせろ」という話になる場面でも、日本はそうならない。カスタマイズではなくパッケージを当てはめる、という発想が通りにくい。だから「まず運用から入りませんか」と言えないと、そもそも会話が始まらないんです。

インタビュアー：一方で、業界にはパッケージで割り切って利益を出している会社もありますよね。

マネージャー：オービックさんなんかは突出していると聞きました。カスタマイズは「いや、それはうちではできません」と断る。他のパッケージ会社が「アドオン！」と言っているなかで、しっかり利益を上げている。古いやり方を続けたい人に寄り添う考え方も間違っていないし、自分たちを磨いて利益を上げて新しくしていく考え方もある。どちらが成功するかは、正直わからない。

エンジニア：選択の問題、ということですか。

マネージャー：そう。だから自分たちで考えて、自分たちが正しいと思うものを選ぶしかない。特にAIが破壊し続ける時代には「考える」ことが重要なのですが日本の教育は「考える」ことを捨てる教育をし続けている。高学歴の方は特にこの「考える」は苦手に見えます。ただ共通して言えるのは、貢献がないと、長い間利益は上がらないということです。

6. ラッパーにならない

インタビュアー：スカウトで「FDE」が刺さる、という話が冒頭にありました。それでも警戒していることがあるとか。

マネージャー：ラッパーになったら勝てない、ということです。AIサービスの単純な仲介で、いまは情報の非対称性があるから儲かっているかもしれない。でもそれが落ち着いた段階——数年後ですね——は、やっぱり厳しくなってくる。

エンジニア：いまの仕組みも、少しずつAI企業側に取り込まれていきますしね。

マネージャー：向こうはデータも持っている。情報も設計情報もどんどん集まっている。デザインの力もある。その上で「皆さん何をやるの？」という話なんです。

インタビュアー：では、何をやるんでしょうか。

マネージャー：Palantirがいまやっているのは、顧客を守るために自分たちの技術を作ることです。AIに裸のデータをそのまま飛ばさないようにしている。だって、AI企業に全部データを渡したら、顧客はAI企業に模倣されてしまいますよね？

エンジニア：ローカルで動くLLM、という話につながりますか。

マネージャー：そこに取り組まない選択肢はありません。WindowsもMacも、IoTもGPUも含めて。儲かるうちに儲けて、次の投資に回す。やりつつ、API利用を外していかないといけない。ただ、いま言ったような技術は一朝一夕には作れないから、本物のエンジニアは付加価値が高まる。

7. そもそも、エンジニアとは何をする人か

インタビュアー：ここまでの話を貫いている考え方がある気がします。

マネージャー：エンジニアの定義は、今までできなかったことをできるようにする仕組みを作ることです。プログラムが作れる、というのはその一部でしかない。

エンジニア：インターネットの話に近いですか。

マネージャー：まさにそう。インターネットは技術ですけど、意味は何かというと、それまで世界中の情報にアクセスできなかった、ということなんですよ。図書館に行く、本屋に行く、論文なら大学に行って見せてもらう。それが、つながった瞬間にいろんなものがつながり始めた。

インタビュアー：飛行機で何十時間もかけて行くはずだった図書館が、手元に来た。

マネージャー：インターネットは時空を歪めたんです。時間と空間を。今までできなかったことを、できるようにした。それが技術です。だから僕らもそうならないといけない。お客さんが困っていることに対して、新しいテクノロジーも古いテクノロジーも含めて「こういうものが作れますよ」と提供していく。

エンジニア：しかも、お客様のサイズに合わせないといけない。

マネージャー：そこが難しいんですよ。いくらでもお金をかけていいなら、たいていのことはできる。そうじゃないから、難しい仕事なんです。

8. 変わらないために、内側で変わり続ける

インタビュアー：最後に、これから入ってくる人に伝えたいことを。

マネージャー：和菓子屋さんの話をよくするんです。お客さんから見ると、商品はずっと変わっていないように見える。でも実は、中では積み重ねが続いている。変わらない品を出し続けるために、内側では変わり続けている。

エンジニア：それ、すごく日本的ですよね。

マネージャー：海外のミシュランに載るようなお店は、これ見よがしにサービスをする。ゴージャスなんですよ。でも日本のお店は、仲居さんが親子の会話をちゃんと聞いていて、お酒の好みが次に行ったときには通っている。お客さんからは見えないけれど、確実に積み上がっている。

インタビュアー：出汁の話もされていましたね。

マネージャー：フランスから料理人が、鰹節や出汁を研究しに来るんです。「なぜ日本料理は、こんな旨味を十数分で出せるんだ」と。でも実際は、そこに至るまでの手間のかけ方が、そもそも違う。表に出ている十数分の裏に、膨大な積み重ねがある。

エンジニア：結局はお客さんだ、という話に戻ってきますね。

マネージャー：そう。お客さんへの貢献という軸に叩き込めば、続いていく。それがない技術は、たぶん続かない。

まとめ：私たちが探しているのは、こういう人です

私たちのFDEの定義を、もう一度置いておきます。

• 「使われる」ことが第一原則——技術バイアスで作ったものは、使われない
• 前提条件を置かない——現場の制約から逆算する
• 運用から入る——要件定義から始めない
• ラッパーにならない——顧客のデータと事業を守る技術を、自分たちで持つ
• 今までできなかったことを、できるようにする——それがエンジニアの仕事

FDEという言葉自体は、これからもっと一般的になっていくと思います。だからこそ、言葉ではなく定義で選んでほしい。

現場に入って、お客さんの運用から逆算して、自分の得意な技術の外側にも手を伸ばせる人。ポートフォリオではなく、「それで誰が助かったか」で語れる人。そういう人と一緒にやりたいと思っています。

まとめ：私たちが探しているのは、こういう人です。

あなたが最後に作ったものは、誰に、どう使われましたか？

その答えを話しに来てくれる方を、お待ちしています。

弊社代表がAI時代に生きるヒントをnoteに記載しています。
コーヒーブレイクの時にでも！
https://note.com/20210116_ryoichi