FDEとコンサルタントは何が違うのか？

FDEとコンサルタントは何が違うのか？

FDEとコンサルタントの違いは、関与の終点にあります。コンサルは課題を分析し、「何をすべきか」を提言するところまでを担うことが多い役割です。FDE（Forward Deployed Engineer）は、その提言にとどまらず、自ら実装して動くものを作り、顧客の成果まで自分の手で持ちます。同じ「課題を見極める」動きから始まっても、どこで手を離すかが正反対なのです。

コンサルの成果物は、多くの場合「提言」や「戦略」です。何を解くべきか、どう進めるべきかを言語化し、意思決定を助けます。これは高度な仕事で、FDEにも同じ力が要ります。ただFDEは、そこで終わりません。提言した「何を作るか」を、自分でコードにし、顧客の現場で動かし、業務が実際に良くなったかまでを引き受けます。「示す人」で終わるか、「作って成果まで持つ人」になるか——これが最初の分かれ目です。

関与の範囲はどこまで違うのか？

課題設定の入り口は重なりますが、FDEは設計・実装・運用、そして顧客の成果まで踏み込みます。コンサルが濃く関わるのは「課題分析〜戦略提言」までで、その先は薄くなりがちです。FDEは全工程を貫き、特に「実装〜顧客の成果」を自分の責任範囲として濃く持ちます。

ここで大切なのは、優劣の話ではないということです。コンサルが提言に重心を置くのは、それだけ「何をすべきか」を見極める仕事が難しく、価値があるからです。問題が起きるのは、提言と実装の間に溝（ギャップ）があるときです。立派な戦略が描かれても、それを動くものに変える人がいなければ、提言は提言のまま止まります。FDEは、その溝を自分の手で越えることを役割の中心に据えています。

コンサルはFDEになれるのか？

なれます。コンサルが磨いてきた課題設定と構造化の力は、FDEにとっても共通の強みだからです。「本当に解くべき課題は何か」を見極め、複雑な状況を整理して筋道を立てる——この力は、FDEが上流に立つための土台そのものです。

コンサルからFDEへ広げるときに加わるのは、「自分で作って動かす実装力」です。提言を資料で渡すのではなく、自らプロトタイプを作り、顧客の現場で検証し、本番に乗せる。生成AIの普及で、この「作る」のハードルは大きく下がりました。課題を構造化できる人が、AIを使って自ら手を動かせるようになれば、提言と実装を一人で貫けます。必要な力の中身はFDEに必要なスキル（2つの設計力）で、UX設計力とAI設計力という形に整理しています。

AI時代に、なぜ"実装まで持つ"が効くのか？

提言だけでは、ものは動かないからです。そしてAIで自ら作れるFDEは、提言と実装の溝を自分で埋められます。これがAI時代に効く理由です。

これまで、「何を作るか」を決める人と「実際に作る人」は分かれているのが普通でした。提言する側は作れず、作る側は決められない。その間に溝があり、戦略が実装で痩せたり、実装が戦略から外れたりしていました。生成AIは、この前提を崩します。課題を構造化できる人が、AIを道具にして自ら動くものを作れるようになった。すると、提言と実装を分けずに、一人格・一チームで貫けます。

コンサルは"何をすべきか"を示し、FDEは"それを動くものにして成果まで"持つ。提言と実装の間の溝を、自分の手で越える。

言い換えると、AIが進むほど「提言だけ」の価値は相対的に下がり、「提言を、自分で動くものにして成果まで持てる」ことの価値が上がります。FDEは、まさにその位置に立つ役割です。同じ変化は受託開発の単価にも表れていて、AIを「実装」ではなく「何を作るか」の側に置くことで価値の源泉に変える話は、生成AIで受託開発の単価は下がるのか？で詳しく整理しています。