AIコーディング時代のエンジニアの道 ― Forward Deployed Engineer（FDE）という選択肢

Table of Contents

まとめ

  • AIコーディングの普及により、 手を動かしてコードを書く作業はほとんど無くなった 。エンジニアの仕事の重心は「実装」から「 顧客の要求を引き出し、MVPで検証するループを回すこと 」へ移った。
  • Most Valuable Product（MVP、顧客の最もコアな要求だけを満たす最低限のプロダクト）は要求定義の精度を上げるためのたたき台に過ぎない 。ソフトウェアを作ること自体が目的ではない。
  • 顧客は自分の要求を自覚していない。 こちらが仮説を立てて提案し、あえて否定させることで、隠れた要求が初めて引き出せる 。
  • 要求を引き出すクリティカルなMVPを最小工数で設計するには、 エンジニアとしての経験・知識 と 顧客のドメイン知識 の両方が必要。
  • これらが交わる先が Forward Deployed Engineer（FDE） である。AIコーディング時代においてエンジニアが進むべき道の１つになりうる。

はじめに

この記事はAIを用いた製造業のDXに取り組む現場で私自身が得た経験と肌感覚をまとめたものだ。

私はイメージセンサの会社でAIを用いたDX（デジタルトランスフォーメーション）業務に従事している。

ここ最近の私の業務の大きな変化は、 手を動かしてコードを書く作業がほとんど無くなった ことだ。

これは開発業務から遠ざかったことを意味しない。むしろ逆で開発のアウトプットは増えている。AIコーディングの活用によって、実装という工程が「人間が時間をかけて手を動かす作業」ではなくなったというだけのことだ。

では、コーディングをしなくなったエンジニアは何をして時間を使っているのか。そして、その先にどんなキャリアが見えてくるのか。

本記事では、私自身の現場の実感を起点に AIコーディング時代のエンジニアの進むべき道の１つはForward Deployed Engineer（FDE）ではないか という仮説を論じる。

AIがコーディングという”作業”からエンジニアを解放した

まず、現在地を確認しておきたい。

AIによって 誰でもそれっぽく動くソフトウェアを作れる時代 になった。要件をざっくり伝えればAIが一気にコードを書き上げてくれる。動くプロトタイプが数十分、ときには数分で手に入る。

この変化は、エンジニアの業務時間の使い方を根本から変えた。私の場合、現在の業務時間の大半はコーディングではなく以下に費やされている。

  • DXを進めたい事業部の担当者へのヒアリング
  • その業務内容やドメイン知識の理解
  • 理解に基づいた、提案ベースの要求定義

つまり、 「何を作るか」を見極める上流の時間 が業務のほとんどを占めるようになった。プロトタイプ（MVP）開発そのものはAIで一瞬で終わってしまうからだ。

ここで重要なのは、 実装が速くなったこと自体が本質ではない という点だ。本質は、実装が速くなったことで エンジニアの価値の源泉が「何を作るかを決めるプロセス」へとシフトした ことにある。

MVPは目的ではなく、要求を引き出すたたき台である

私がDX業務を通して強く実感したことがある。それは、 MVPは要求の精度を高めるための道具に過ぎない ということだ。

少し乱暴に聞こえるかもしれない。しかし、少なくとも私の現場では、MVPはそれ単体で価値を出すために作るのではなく、 顧客（事業部）から本当の要求を引き出すための「たたき台」 として作られている。

具体的には、次のようなループを高速に回している。

  1. 事業部へ要求ヒアリングを行う
  2. その内容から仮説を立て、提案ベースで「こういう要求ではないですか」と要求を提案する
  3. その仮説に基づいてMVPを開発する
  4. デモを見せてフィードバックをもらう
  5. フィードバックを元に要求を微修正する
  6. 修正した要求に基づいてMVPを作り直す
  7. 2〜6を繰り返す

このループの一周はアジャイル開発でいう１スプリント（おおむね1〜2週間）に相当する。仮説を立て、MVPという形で動くものを届け、デモでフィードバックを得て、次の周回で要求を調整する。スプリントごとに少しずつ要求の解像度を上げていく、という点でまさにアジャイルの反復と同じリズムだ。

このループの目的は完成品を作ることではない。 要求定義の精度を上げること だ。MVPはそのためのたたき台でしかない。

そして、AIコーディングの登場によって このループを圧倒的な速さで回せるようになった 。仮説を立てたら数日以内には動くものを作って見せられる。フィードバックをもらったら、すぐに作り直して次のデモにかけられる。

これは、スタートアップの世界で語られてきた Build-Measure-Learn（作る・計測する・学ぶ）のループ や、「MVPとは、最小の労力で顧客に関する検証済みの学び（validated learning）を最大化するためのもの」という考え方とも、きれいに重なる。MVPの目的は、製品を作ることではなく 学ぶこと なのだ。AIはその学習サイクルの回転数を一気に引き上げた。

顧客は自分の要求を知らない ― 否定が要求を生む

ここで、要求ヒアリングについて、私が最も大切だと考えていることを述べたい。

それは、 顧客は、自分の要求を自覚していない という事実だ。

ゼロベースで「あなたの要求（やりたいことや困りごと）を教えてください」と聞いても、たいてい何も出てこない。出てきたとしても、表層的で、本当に解くべき課題からはずれていることが多い。これは顧客が悪いのではない。 人間の脳はゼロから何かを創造するよりも、既にあるものを批判したり微修正したりする方がはるかに得意にできている からだ。

だから、こちらの戦略はこうなる。

まずこちらが仮説を立て、「こういう要求ではないですか」と具体的に提案する。

すると相手は初めて反応できる。「いや、そこはちょっと違う」「それよりこっちの方が重要だ」と。この 否定や修正の中にこそ、顧客自身も気づいていなかった本当の要求が隠れている 。

そして、その提案を 言葉だけでなく、動くMVPとして見せる ことで反応の解像度はさらに上がる。実際に触れる、目に見えるものがあると、人は「これは違う」「ここをこうしたい」とより具体的に語り出す。立てた仮説に基づくMVPを作って見せて、ようやく顧客から 顧客すらも気づいていなかった要求 が出てくるのだ。

ちなみに、ここで決定的に重要なのが我々の マインドセット である。

要求の提案も、MVPのデモも、 否定される前提で出すたたき台に過ぎない 。したがって、否定されても怒ったり落ち込んだりする必要はまったくない。むしろ逆だ。否定されたらこう捉えるべきだ。

よし、また一つ、隠れた要求を引き出せた

否定は失敗ではなく前進である。このマインドセットを持てるかどうかがループを健全に、そして高速に回し続けられるかの分かれ目になる。

余談だが、「あえて間違った答えを投げることで、正しい答えを引き出す」という現象は、インターネットの世界ではCunningham’s Law（カニンガムの法則）として知られている。「ネットで正しい答えを得る最良の方法は、質問することではなく、間違った答えを投稿することだ」というものだ。人は、空欄を埋めることより、間違いを正すことに強く動機づけられる。要求ヒアリングで起きていることも本質的にはこれと同じである。提案とMVPは相手の「それは違う」を引き出すための上質な「間違った答え」なのだ。

AIコーディングで本当に差がつくところ

ここまで読んで「AIで誰でもMVPを作れるなら結局みんな同じことができるのでは」と思うかもしれない。

たしかに、AIで”それっぽく動くもの”はもはや誰でも作れる。

しかし、 本当に良いソフトウェア 、そして何より 要求を引き出すためのクリティカルなMVPを、最速・最小工数で設計すること は誰にでもできるわけではない。

なぜなら、それには次の二つが要るからだ。

  • エンジニアとしての経験・知識 ：何が技術的に筋が良く、何が破綻するか。どこを作り込み、どこを捨てれば最小の労力で検証したい仮説だけを的確に突けるか。こうした設計の勘所はエンジニアとしての蓄積からしか出てこない。
  • 顧客のドメイン知識 ：そもそも何を検証すべきか、どの仮説が本質的で、どのフィードバックが本物のシグナルなのか。これを見抜くには顧客の業務とドメインへの深い理解が要る。

AIは実装を肩代わりしてくれる。しかし、 「次にどんな仮説を、どんなMVPで検証すべきか」という問いそのものに答える力 はまだ人間の側にある。そして、その力こそがAI時代に最も差がつく、代替されにくい価値の源泉になる。

言い換えれば、AIによってコーディングという作業がコモディティ化した分、 「エンジニアの設計力 × 顧客のドメイン理解」の希少性が相対的に跳ね上がった のだ。

この変化は、「How」と「What・Why」という対比で捉えると分かりやすい。技術仕様への落とし込みや、それを実装するコーディングといった 「どう作るか（How）」はAIに急速に代替されつつある 。一方で、 顧客の要求を引き出し、仮説を立てて提案し、ドメインを理解した上で「何を作るべきか（What）」「なぜそれを作るのか（Why）」を見定める力 は、依然として人間の側に残っている。そして、これからのエンジニアの価値はまさにこのWhat・Whyを握れるかどうかで決まっていく。Howを磨き続けるのではなく、 自分の重心をWhat・Whyへと移せるか が問われているのだ。

だからFDEが重要になる

ここまでの議論を一言でまとめると、こうなる。

これからの時代、エンジニアの設計力と、顧客のドメインに深く入り込む力を併せ持つ人材が決定的に重要になる。

そしてまさにこの像を指す職種が、近年世界的に注目を集めている Forward Deployed Engineer（FDE） だ。

FDEとはもともとPalantirが生み出したとされる職種で、 顧客の現場に深く入り込み、要求の理解から、設計・実装・統合・デプロイまでを一気通貫で担うエンジニア を指す。顧客のチームにembed（常駐）し、業務を理解し、本当に効くものを自ら作って届ける。

この役割はAI時代に入って急速に存在感を増している。著名ベンチャーキャピタルのa16zは、FDEを「スタートアップで今もっともホットな職種」と評した。実際、FDEの月間求人数は2025年1月から9月にかけて 800%以上 増加したとも報じられている。OpenAIをはじめとするAI企業が、モデルを作るエンジニアだけでなく、 それを顧客の現場で実際に動かすエンジニア を積極的に採用しているのだ。

なぜFDEが効くのか。それは、既存のロールと対比すると見えてくる。

  • コンサルタント ：上流の課題整理や戦略には強い。しかし、 エンジニア視点に欠け 、自ら手を動かして検証する手段を持たない。提案が「絵に描いた餅」で止まりやすい。
  • 受託開発 ：与えられた仕様を形にする下流には強い。しかし、 上流の要求定義には踏み込まない 。そして、まさにこの「仕様どおりに実装する」工程こそAIによって最も代替されやすい部分でもある。
  • FDE ：上流の要求定義から下流の実装・デプロイまでを ドメイン理解に基づいて一気通貫で担う 。コンサルの上流力と、エンジニアの実装力を一人の中で接続する。

つまりFDEは、コンサルと受託開発の「いいとこ取り」をしつつ、AI時代に最も価値の出る「要求を引き出すループを高速で回す」役回りにぴたりとはまる。

そして、ここに私が最も伝えたいことがある。

エンジニアとしてキャリアを積んできた人が、コンサル的な視点・能力 ― すなわち顧客のドメインに入り込み、要求を引き出す力 ― を身につけることができれば、つまりFDEになれれば、非常に強力で希少な人材になれる可能性がある ということだ。

エンジニアにとって、コンサル的な視点を後から獲得することは決して不可能ではない。むしろ、AIによってコーディングという作業から解放された今だからこそ、その時間を「顧客理解」と「要求を引き出す技術」に投資できる。土台となる技術力を既に持っているエンジニアはFDEへの最短距離にいるとも言える。

おわりに

AIコーディングの登場で、「コードを書ける」という能力だけの希少性は確実に下がっていく。動くものを作るだけならもう誰にでもできるからだ。

代わりに効いてくるのは、 「要求を引き出す力 × ドメインの理解 × エンジニアリング」 の掛け算だ。顧客自身も気づいていない要求を仮説とMVPのたたき台によって引き出し、それを高速の検証ループで磨き上げ、本当に効くものを設計して届ける。この一連の動きこそがAI時代に人間のエンジニアが提供できる、最も大きな価値だと私は考えている。

そして、その掛け算がちょうど交わる場所に立っているのが、Forward Deployed Engineerだ。

もちろん、FDEがすべてのエンジニアにとっての唯一の正解だと言うつもりはない。しかし、 AIコーディング時代にエンジニアが進むべき道の有力な選択肢の１つ であることは間違いないと思う。少なくとも、私自身の現場の実感はまっすぐにこの方向を指している。

もしあなたがAI時代の自分のキャリアに迷っているなら、まずは自分の現場で小さくこのループを回してみてほしい。仮説を立て、MVPで見せ、否定され、また作り直す。その繰り返しの中でエンジニアとしての新しい立ち位置がきっと見えてくるはずだ。

参考文献