FDEを巡る3つの論点

なぜ「Engineer」なのか？なぜ「Forward Deployed」なのか？それは「役割」なのか「ビジネスモデル」なのか？

先日、FDEに関する記事（前編/後編）を書きましたが、本日は、それを踏まえて、FDEに関する3つの論点をご紹介します。

前回記事でご紹介した通り、FDE、すなわち、Forward Deployed Engineerとは「前線に配置されたエンジニア」を意味しますが、必ずしも、それは「職種・職能」ではなく、「考え方、ふるまい（ビヘイビア）」であるべきである、と僕は捉えています。
すなわち「顧客の現状を理解し、課題を明確化した上で、それを解決するための実行可能な取り組みに落としこむ」という態度こそが、FDEの本質であるといえます。

それを踏まえた上で、今回は、そこから生じる3つの論点について考えていきたいと思います。

田中の考える、3つの論点

僕の考える3つの論点は、以下です。

• なぜ「エンジニア」なの？（コンサルタントと何が違うの？）
• なぜ「前線配備（Forward Deployed）」なの？（いままではバックエンドにいたじゃん。）
• それは、「役割」の話なの？（多くの人は「ビジネスモデル」の話をしてるよね）

この3つです。

まるで流行語のように、皆が取り上げているからこそ、こうした基本的な部分を考えたくなりますよね。（僕はなります）

論点１：なぜ「エンジニア」なの？

早速、内容に踏み込んでいきましょう。まず、一つ目の論点として挙げたいのが「なぜ、エンジニアなのか」です。言い換えると「なぜ、コンサルタントじゃダメなの？」という問いですね。

FDC、すなわちForward Deployed Consultantじゃぁダメなのか？ってことなんですよ。

結論から言うと、世の中のコンサルタントは、最初っからForward Deployedです。常駐しているかどうかはさて置いて、最前線で、クライアントの抱える問題点や困りごとを拾い集め、課題に昇華し、どうやって解決するのかを考える役割を担い続けてきました。

僕自身、「こんなに世の中がFDE、FDEと騒ぐなら、僕はFDCを名乗ってやろうかな」と思ったりしています。（飲みの席では、もはや名乗りつつあります）

この点については、

■コンサルタントでは解決できない、リアルな課題解決をその場で行いたいから

ということになるのでしょう。要するに「企画だけ」で終えたくないから、実装力のあるエンジニアによって「動くもの（プロトタイプ、MVP：Minimum Viable Product）」を作って欲しい、というクライアントの（潜在的な）ニーズにこたえるためには、口だけ言うだけコンサルタントではなく、あるいは、アウトプットがパワポのコンサルタントではなく、手が動いてモノが作り出せるエンジニアにお願いしたい、というのは、（FDCたる僕としては悲しいことですが）納得感があります。っていうか、僕がクライアントでも、そう思う。

一方で、生成AIの台頭によるAIコーディングが実現してきた昨今では、「コンサルタントがプロトタイピング能力を身に付ける」という選択肢も生まれてきています。この方向に進むのであれば、FDC empowered by generative AI がフォーカスされてくる未来も見えます。

論点２：なぜ「前線配備（Forward Deployed）」なの？

続いて、ふたつめの論点「なぜ、前線配備（Forward Deployed）なのか」です。言い換えると「従来通り、バックエンドに居ちゃダメなの？」です。

これについては、論点１と重なる部分もあるのですが、前線にいることで、

■要件になる手前の「あいまいな問題・困りごと（課題とも呼べないレベルのものごと）」をピックアップできるから　

という点に尽きると思います。従来のエンジニアは、どうしてもクライアントの現場と距離があり、営業やコンサルタントなどからの伝言ゲームによって、課題を理解し、解決策に紐づけるということになっていました。これが、前線に出向くことで、生の声を聴ける、というわけです。

これが実現するのならば、極めて素晴らしいことなのですが、反対に「じゃぁ、なぜ、今までバックエンドに居たの」という話にもなるわけです。

ここは、とても重要なポイントです。つまり、「エンジニアが、クライアントと話して、あいまいな話を具体的な要件まで昇華できるのか」という問題に直面するわけです。

それができるなら、最初からやっていたよ、という話なんですよね。対人スキルの高さ、と言うと職業差別み・ステレオタイプみがあるかもしれませんが、いずれにしても、人には得意不得意があり、だからこそ得意領域で輝けるわけなので、「クライアントと話すなかで、順不同かつ不明瞭な話を “課題”としてまとめあげて、それを要件として磨き上げる」ということができるエンジニアは、それほど多くは無いように思えます。（くりかえしますが、できるなら、やってただろ、という話なのです）

もっと言うと、「クライアントから、曖昧な話をうまく聞き出す」ということは、コンサルタントや営業であっても不得意な人がいる領域です。誰にでもできるわけではありません。

一方で、システムスキルが無ければソリューションを考えることができないというのも事実です。コンサルタントや営業職が弱いのはそのあたりです。ここにはエンジニアに一日の長があります。

しかしながら、そうすると「じゃぁ、SE（システムエンジニア）じゃダメなの？」という議論になります。分かります。僕も、元SE（新卒から4年ほどやってました）なので「まさに、SEがやるべき仕事じゃん」という気持ちになります。

ただ、これは、SEという仕事が、PG（プログラマ/コードを書く人）→SE（システムエンジニア/要件をまとめる人）→PM（プロジェクトを運営する人）という出世魚モデルを長らく採用してきていることが、FDEとの違いを生んでいると考えられます。

つまり、上級職に上がれば上がるほど、手を動かさなくなってしまうのです。そうなると、「要件はまとめられるが、モノは作れない」ということになってしまうため、FDEに求められる「実装力」が低いと評価されてしまうんですよね。

しかし、論点１でも述べたように、SE powered by generative AI という道が拓けましたので、今後は、そういう人も増えてくるんじゃないか（むしろ、増えてきたらいいな）と思います。

論点３：これは「役割」なの？

さて、最後の論点です。「FDEは役割なの？ビジネスモデルなの？」です。

僕の限られた観測範囲においては、やはり、このトピックに先鞭をつけたPalantir社が大きく注目を集めたということもあって、この話を「ビジネスモデル」として評価する人が多いように思います。（多い、は言い過ぎなら、散見されます、と読み替えてください。）

要するに、「無償でFDEを投入して、（自社プロダクトを活用した）課題解決の道筋が見えたところで、お金をもらえるビジネスにする」という、クサビ形ビジネスと言いますか、そういうお話です。

しかしながら、僕（個人の感想です）としては、「それって、サービス提供者側の話であって、世の中の多くの企業＝クライアント・利用者からすれば、どうでもよくない？」という気持ちになってしまいます。本来、こういうトピックは「クライアント・利用者にどのように役に立つのか」が先にあるべきです。それでどう稼ぐのかは別の話だと僕は思うんですよね。

そのため、ビジネスモデルとしての議論は他の方に譲るとして、この論点に対しては

■FDEは、ビジネスモデルではなく、役割である

と、結論付けたいと思います。

役割、すなわち守備範囲ということですが、これは、機能に分解可能です。この話をし出すと長くなるので（そして、本稿もだいぶ長くなってきたので）サラッと流しますが、FDEの持つべき機能は

1. あいまいな話や内部情報を聞き出せる関係性づくり
2. 雑多な情報から、本質を見出す
3. 問題点と課題を切り分け、注力ポイントを見つける
4. 解決策を「ビジネス面」と「技術面」の両方の観点で検討する
5. 実現可能なもののうち、最低限の実装範囲を見極める
6. 実装する
7. 実装したMVPを現場に使ってもらい、フィードバックを得る

というようなものになるでしょう。

これは、従来の職種の保持機能に照らし合わせれば、

1. あいまいな話や内部情報を聞き出せる関係性づくり（営業職、コンサルタント職）
2. 雑多な情報から、本質を見出す（コンサルタント職）
3. 問題点と課題を切り分け、注力ポイントを見つける（コンサルタント職）
4. 解決策を「ビジネス面」と「技術面」の両方の観点で検討する（コンサルタント職、SE職）
5. 実現可能なもののうち、最低限の実装範囲を見極める（SE職、エンジニア職）
6. 実装する（エンジニア職）
7. 実装したMVPを現場に使ってもらい、フィードバックを得る（SE職、コンサルタント職）

ということになります。

これを、一人のスーパーマンに担わせるのは、果たして現実的なのか？というお話になるわけですが、「やっぱ分業制・チーム制が現実的なんじゃないんですかね」と思ってしまうんですよね、という感想めいたものを置いて、今日のところは終わりとします。

続きは、また近いうちに書きたいと思います。