なぜ「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の持つべき機能は
- あいまいな話や内部情報を聞き出せる関係性づくり
- 雑多な情報から、本質を見出す
- 問題点と課題を切り分け、注力ポイントを見つける
- 解決策を「ビジネス面」と「技術面」の両方の観点で検討する
- 実現可能なもののうち、最低限の実装範囲を見極める
- 実装する
- 実装したMVPを現場に使ってもらい、フィードバックを得る
というようなものになるでしょう。
これは、従来の職種の保持機能に照らし合わせれば、
- あいまいな話や内部情報を聞き出せる関係性づくり（営業職、コンサルタント職）
- 雑多な情報から、本質を見出す（コンサルタント職）
- 問題点と課題を切り分け、注力ポイントを見つける（コンサルタント職）
- 解決策を「ビジネス面」と「技術面」の両方の観点で検討する（コンサルタント職、SE職）
- 実現可能なもののうち、最低限の実装範囲を見極める（SE職、エンジニア職）
- 実装する（エンジニア職）
- 実装したMVPを現場に使ってもらい、フィードバックを得る（SE職、コンサルタント職）
ということになります。
これを、一人のスーパーマンに担わせるのは、果たして現実的なのか？というお話になるわけですが、「やっぱ分業制・チーム制が現実的なんじゃないんですかね」と思ってしまうんですよね、という感想めいたものを置いて、今日のところは終わりとします。
続きは、また近いうちに書きたいと思います。
