FDEやGTMエンジニアがなぜ必要とされるのか
最近、FDEやGTMエンジニアリングという言葉を聞く機会が増えてきました。
FDEはForward Deployed Engineerの略で、事業や顧客の現場に入り込み、課題発見から実装、改善までを一気通貫で担うようなエンジニアを指します。
GTMエンジニアリングは、Go To Market、つまり売上や顧客獲得、営業、マーケティング、CSなどの事業活動に対して、エンジニアリングでレバレッジをかけていく考え方です。
どちらも、単に新しい職種名というより、AI時代にエンジニアがどこに価値を置くべきかを考えるうえで、とても重要な概念だと思っています。
なぜ今、FDEやGTMエンジニアが必要なのか
AIの進化によって、エンジニアの仕事は大きく変わりつつあります。
特に、コードを書くという行為そのものは、今後さらにAIに置き換わっていくと思っています。
もちろん、技術力が不要になるわけではありません。
むしろ、AIを使いこなすためにも、設計力、実装力、品質を見極める力は引き続き重要です。
ただし、「要件を受けて、仕様通りにコードを書く」だけでは、価値を出し続けることが難しくなっていくはずです。
Salesforceのような業務システムでも、今後は管理画面にログインして設定を変更する、フローを組む、オブジェクトを作る、といった作業の多くが自然言語化されていくと思います。
インフラやSRE領域でも同じです。
AWSコンソールに入り、設定を変更し、Terraformを書き、監視設定を入れる。そうした作業も、AIとの対話によって、より自動化・抽象化されていくはずです。
そうなると、エンジニアに求められる価値は少しずつ変わります。
何を作るべきかを見極める力。
誰のどんな課題を解くべきかを見つける力。
事業成果につながる打ち手に落とす力。
AIを使って、通常より何倍も速く価値を届ける力。
現場に入り込み、課題発見から実装、検証までを回す力。
こうした力が、これまで以上に重要になります。
その意味で、FDEやGTMエンジニアリングは、AI時代におけるエンジニアの価値を考えるうえで、かなり本質的なテーマだと思っています。
FDEやGTMは、スキルというより「重心の置き方」
FDEやGTMエンジニアに必要なものは何か。
もちろん、技術力、データ分析力、業務理解、コミュニケーション力、プロジェクト推進力など、必要なスキルはいろいろあります。
ただ、個人的には、それ以上に大事なのは「重心の置き方」だと思っています。
たとえば、同じ開発タスクでも、重心の置き方によって見え方が変わります。
「依頼された機能を正しく作る」ことに重心を置くのか。
「この機能によって誰が助かるのか」に重心を置くのか。
「その人が助かることで、どの事業成果につながるのか」に重心を置くのか。
この違いはかなり大きいです。
前者が悪いわけではありません。
品質高く、安定して、期待通りに作ることはとても大事です。
ただ、FDEやGTMエンジニアリングの文脈では、もう一歩踏み込む必要があります。
この開発によって、誰の困りごとが減るのか。
誰が今より前に進めるようになるのか。
その結果、売上、成約率、CPA、CSコスト、LTV、オペレーション改善のどこに効くのか。
ここまで自分で問いにいく。
最初から完璧に数字で語れなくてもよいと思っています。
ただ、少なくとも「これは誰を助ける仕事なのか」「なぜ今これをやる意味があるのか」について、自分の中で納得できている状態が大事です。
「困っている人の顔」が浮かんでいるか
事業成果という言葉は、ときどき抽象的に聞こえます。
売上、成約率、LTV、CSコスト、オペレーション改善。
もちろん、これらの指標は大切です。
ただ、最初から数字だけを見ても、なかなかリアリティが湧かないこともあります。
むしろ最初に見るべきなのは、「困っている人の顔」だと思っています。
たとえば、営業やCSの現場で、何かを説明したいのに判断材料がない人がいる。
お客様により良い提案をしたいのに、過去のナレッジが整理されていない人がいる。
改善したい気持ちはあるのに、どこを直せばよいのか分からず悩んでいる人がいる。
経営や事業責任者から問われたときに、体感でしか答えられず苦しんでいる人がいる。
そういう人の顔が浮かんでいるか。
そこに対して、エンジニアリングやデータ、AI、プロダクトの力で何ができるのかを考える。
この重心があると、動き方が変わります。
「依頼が来るまで待つ」のではなく、「何に困っているのかを聞きに行く」。
「要件が固まってから作る」のではなく、「まず意思決定に必要な最小限の材料を出す」。
「全部きれいに作る」のではなく、「今日その人が一歩進むために何が必要か」を考える。
この感覚が、FDEやGTMエンジニアリングの入口だと思っています。
2週間かかるものを、どうすれば1日で届けられるか
FDEやGTMエンジニアリングでは、スピードも非常に重要です。
ただし、これは「品質を下げて早く作る」という話ではありません。
大事なのは、「最終的に作るべきもの」と「今日届けるべき価値」を分けることです。
たとえば、普通にやると2週間かかる分析があるとします。
データをきれいに整え、要件を整理し、ダッシュボードを作り、レビューして、運用に乗せる。
正攻法で進めると、それなりに時間がかかります。
もちろん、それが必要な場面もあります。
ただ、目の前に本当に困っている人がいるなら、こう考えることもできます。
今日の意思決定に必要な数字だけなら、SQLで出せないか。
完璧なダッシュボードではなく、スプレッドシートで一次集計できないか。
全件分析ではなく、まずサンプル20件をAIで分類できないか。
恒久対応ではなく、今日の会議で使える暫定アウトプットを出せないか。
手作業とAIを組み合わせて、30分で仮説だけでも作れないか。
これは手抜きではありません。
価値を届ける順番を変えているだけです。
最終的には、ちゃんとした仕組みにする。
でも、今日困っている人には、今日届く価値を出す。
この発想ができるかどうかが、これからますます重要になると思っています。
FDE的な動きは、現場でしか身につきにくい
FDEやGTMエンジニアリングは、座学だけで身につけるのが難しい領域です。
なぜなら、必要なのは単なる知識やスキルだけではなく、「重心の置き方」だからです。
事業側の会議に出る。
営業やCSの会話を聞く。
現場の人が何に困っているのかを知る。
実際に小さなアウトプットを出してみる。
それが使われたか、使われなかったかを見る。
なぜ刺さったのか、なぜ刺さらなかったのかを振り返る。
この繰り返しの中で、少しずつ感覚が掴めてくるものだと思っています。
最初から完璧にできる必要はありません。
むしろ大事なのは、小さく入ってみることです。
会議に同席して、分からない言葉をメモする。
現場の人に「今、一番困っていることは何ですか」と聞いてみる。
データを少し触って、仮説を出してみる。
AIで議事録や音声を要約して、改善の観点を出してみる。
手作業でもよいので、意思決定に使える材料を出してみる。
こうした経験を重ねることで、「事業に入り込む」とはどういうことかが少しずつ分かってくるはずです。
エンジニアの価値は、より事業に近づいていく
AI時代において、エンジニアの価値はなくなるわけではありません。
ただし、価値の置きどころは変わっていくと思っています。
コードを書く力だけでなく、何を作るべきかを見極める力。
技術的に正しいものを作る力だけでなく、事業成果につながるものを選ぶ力。
依頼を受けて実装する力だけでなく、現場に入り込み、課題を発見し、AIを使って高速に価値を届ける力。
こうした力が、これからのエンジニアにはより強く求められるはずです。
FDEやGTMエンジニアリングは、その変化を象徴する考え方だと思っています。
そして、これは一部の特別な人だけが目指すものではありません。
バックエンドエンジニアでも、フロントエンドエンジニアでも、SREでも、Salesforceエンジニアでも、データエンジニアでも、少しずつこの重心を持つことはできます。
自分の仕事の先に、誰がいるのか。
その人は何に困っているのか。
自分の技術で、その人をどう前に進められるのか。
ここから考えるだけでも、仕事の見え方は大きく変わります。
まとめ
FDEやGTMエンジニアリングは、単なる新しい職種名ではありません。
AI時代に、エンジニアがどこに価値を置くべきかを考えるための重要なヒントだと思っています。
大事なのは、特定のスキルセットを一気に身につけることではなく、まず重心を変えることです。
依頼されたものを作るだけでなく、誰が助かるのかを考える。
数字だけでなく、困っている人の顔を思い浮かべる。
正攻法だけでなく、今日価値を届ける方法を考える。
AIを使って、課題発見、分析、実装、検証までの速度を上げる。
事業側に入り込み、現場の困りごとを自分ごととして捉える。
この重心の置き方を、具体的なシーンやエピソードを通じてイメージし、実践し、少しずつ感覚として掴んでいくことが大切だと思っています。
AI時代に必要とされるエンジニアの働き方を汲み取れる機会は、今後も増やしていきたいと思っています。