★ 山根執筆スペシャルブログ2026-07-20執筆：山根一城（株式会社ポテンシャライト）

FDE（フォワードデプロイドエンジニア）をどこよりもわかりやすく説明してみる

本記事は、山根一城がnoteで公開したブログの全文転載版です（原文：note「FDE(フォワードデプロイドエンジニア)をどこよりもわかりやすく説明してみる」／2026年7月20日公開）。

この記事の要点

FDEとは「顧客と直接コミュニケーションを取り、既存システムへの要望（課題）を文言化し、開発（実装）まで行うエンジニア」。フォワード＝前へ（顧客の最前線）、デプロイド＝配置される。
トレンド化の本質は「コーディングがAIに代替されたから」ではなく、AIによってプロダクトのライフサイクルが短命化し、「課題の文言化・課題提起」の価値が跳ね上がったこと。
SIer・SES・コンサル・Webプロダクト・社内SEなど出身業態によって強みと弱みが異なり、募集側もAI企業とWebプロダクト企業で求めるものが違う。FDPMとの違いは「起点」（実装起点か、要件定義起点か）。

「FDE（フォワードデプロイドエンジニア）って、結局何なのですか？」

そんなご質問を頂戴することが増えました。「フォワードデプロイド」という言葉自体は、AI時代に間違いなくトレンドになるだろうと思い、ブログを執筆することにしました。

では、参りましょう！

0. FDE（フォワードデプロイドエンジニア）とは？

FDE（フォワードデプロイドエンジニア）とは：顧客（ユーザー）と直接コミュニケーションを取り、既存のシステム（プロダクト）の要望（課題）を文言化し、開発（実装）まで行うエンジニアのことです。

まず、前提として、フォワードデプロイドエンジニアは「フォワード」と「デプロイド」という言葉を理解しましょう。

0-1. フォワードとは

和訳すると「前へ」という意味です。

サッカーのポジションにおいて最前線は「フォワード」ですよね。サッカーはゴールを「決める」仕事と「守る」仕事があります。「守る」仕事は「ディフェンダー」ですが、これをビジネスの世界で当てはめてみると、

フォワード：営業職
ミッドフィルダー：カスタマーサクセス、マーケティング、プロダクトマネージャー
ディフェンダー：バックオフィス全般、エンジニア？、デザイナー？
監督：社長、事業企画・戦略

どんな感じのイメージでしょうか。

エンジニアとデザイナーに「？」を加えたのですが、エンジニアとデザイナーが必ずしもディフェンダーというわけではありません。ただ、本項のメインテーマである「フォワード」という観点においては、エンジニアやデザイナーが「顧客の前へ出る」ということ自体が多いわけではない、という観点をもとにディフェンダーに配置していることだけ、ご認識・ご了承ください。

何を申し上げたいかというと、一般的にエンジニアご自身が「顧客の前」に出ること自体は多くはないと思います。

ただ、1つ補足をすると、「業態」によっては異なります。これは後ほどご説明いたします。

0-2. デプロイドとは

和訳すると「配置される」という意味です。

エンジニアリングの世界においては、「システムを本番環境にデプロイする」という言葉がありますが、フォワードデプロイドエンジニアという言葉を世の中に提唱した方は、おそらく「顧客の前へ配置されるエンジニア」という意味合いで、この言葉を設定したのだと思います。

1. なぜフォワードデプロイドエンジニアがトレンドになりつつあるのか？

人材業界で長く働いている僕の解釈で記載をしていきます。エンジニアとして従事されていらっしゃる方は、違う見え方もあるかもしれません。

1-1. AIの影響

間違いなく1つ言えるのは、AIを用いてシステム開発をすることが多くなったからだと思います。

特に、Cursor、Devin、Copilot、そして昨今ではClaude Code、Codexなど、様々なAIコーディングツールがシステム開発におけるスタンダードとなりました。様々な企業で、プログラミングソースコードのコーディング業務はほぼゼロになっているという話もよく耳にします。そして、ビジネスサイドの僕自身も、AIでソースコードを生成することができる時代になってきています。

そして、これまでエンジニアのメインの仕事であったプログラミングソースコードのコーディング業務自体が、AIで代替されることで、エンジニアの仕事の比重をどうするのか？という当たり前の議論に発展しています。

そのため、いわゆるエンジニアの仕事内容は変化していることは間違いないのですが、ただ誤解がないように言うと、「コーディングの仕事がなくなり始めているから、仕事の範囲を拡張しよう」というシンプルな思考回路で、フォワードデプロイドエンジニアが発生しているわけではないと、個人的には捉えています。

1-2. AIの登場は、サービスやプロダクトのライフサイクルをとてつもなく速くする

AIが登場したことにより、プロダクトやシステムの企画や要件定義、そして設計、かつプログラミングまで、一気にAIが賄うことができるようになりました。

シンプルに「仕事が簡略化する」ということが本質論ではなく、このサイクルが高速化してくると、「システムやプロダクトを開発するスピードが速まる」と同時に、「システムやプロダクトが誕生するペースが爆発的に速まる」ことにつながります。

そして、「システムやプロダクトの競争率が高まり、かつ、さらにその先のニーズを満たす新しいプロダクトやシステムが誕生することにより、システムやサービスのライフサイクルが短命になる」ことが発生します。

僕個人の考えとしては、「短命になる」ことが最も大きな変化であると感じています。

1-3. （補足）ビジネスサイドもフォワードデプロイドエンジニアとしての権利を持つ

フォワードは「前へ」、デプロイドは「配置」という意味があることを説明しました。シンプルに、法人企業におけるフォワードは「ビジネスサイド」だと思います。

システムやプロダクト開発において、ビジネスサイドの弱みは「技術的知見」でした。ただ、AIの力によって、少なからずシステムやプロダクトの機能レベルにおける要件定義、設計、開発・実装については、ビジネスサイドも叶えることができるような時代になっています。

これまでは、ビジネスサイドの方々が顧客からの要望やニーズをヒアリングして、それをプロダクトマネージャーやリードエンジニアに伝えて、エンジニアが機能開発をするというやり方でした。そして、ビジネスサイドである僕の本音を言うと、このコミュニケーションの説明工数やコミュニケーションの歪みなどはストレスであったことは確かです。おそらく、エンジニア側も同じ所感を持たれているのではないかと思います。

本項で何を言いたいかというと、フォワードデプロイドエンジニアは決して「エンジニア」が「フォワード（前へ）」に配置されるだけではなく、「ビジネスサイド」がAIの力を使って、「エンジニアリング」の職域に侵食するという「逆流」も発生しているということは事実だと思っています。

1-4. （本題）平成時代のエンジニアリングサイクルの終焉

昭和から平成に入り、平成時代にはたくさんのエンジニアリング用語が誕生しました。

ウォーターフォール型、アジャイル開発、スクラム開発、コードレビュー、ペアプログラミング、GitHubに草が生える、フォークなど、挙げればキリがないですが、つまり平成時代で登場したエンジニアリング開発の「あり方」や「やり方」については、個人的には完全に「変容」しなくてはならないフェーズに差し掛かっていると感じています。

「過去の良い部分も残そう」と社内で言葉が上がる組織もあるかと思うのですが、完全に変わる時代に差し掛かっているように思います。

そして、開発体制や開発組織のあり方ややり方が変わらなくてはならない時代です。それと同時に、「エンジニア」のあり方ややり方、端的に言うと「職域」が大きく変化しなくてはならないタイミングになってきています。

2. フォワードデプロイドエンジニアは、IT／Web業界の「各業態」出身で観点が異なる

重要な観点としては、IT／Web業界における「各業態」別に、フォワードデプロイドエンジニアという職域についての観点が異なることです。

2-1. システムインテグレーター

IT業界が誕生して、初めに発生したのは、この業態であると個人的には捉えています。システムインテグレーターとは、「システムにおける何でも屋」と社内の研修で伝えています。

システムインテグレーターには、必ず「顧客」が存在します。顧客はシステムの「発注者」とも表現され、本質的には、「顧客の課題を、ITという手段（ツール）を用いて解決する」という業態です。

そのため、フォワードデプロイドエンジニアにおける「フォワード」という意味においては、「顧客」と接することが多いわけですから、その部分においては適していると言えます。

ただ、非常に細かい話をすると、システムインテグレーターは、顧客側で「課題や要望」がほぼ固まっている場合と、そうではない場合があります。つまり、課題や要望がふわっとしている場合は、「課題の文言化・課題提起」をする必要もありますし、一方で、課題や要望が明確な場合は、「要件定義」から入ります。ここが、似て非なるポイントになります。

ちなみに、フォワードデプロイドエンジニアは、「課題文言化」「課題提起」の職域が非常に重要です。そのため、システムインテグレーターで働いていたという事実自体が重要なのではなく、その中での「職域」が非常に重要になるということです。

2-2. SES

一般的なSESの認知としては、システムインテグレーターの下請けとして業務を行っているような、そんな認識を持たれがちだと思います。ただ、誤解がないように言うと、SESとは「商流」ではなく、「契約形態」を指します。

つまり、顧客との接点を持つ最上流のポジションをSESで埋めていることもあるので、SES＝下流というわけではないことを認識しましょう。SES型でプロジェクトに入り、フォワードデプロイドエンジニアの職域である、課題の文言化や課題提起をしていることもあるわけです。その個人の仕事における職域次第であると思います。

ちなみに蛇足ですが、システムインテグレーターとSESにおいては、「プロジェクトマネージャー」というポジションが最もフォワードデプロイドエンジニアの職域に近いです。

ただ、1つ「弱いポイント」も記載すると、「細かい技術的な知見」になります。システムインテグレーターやSESのプロジェクトマネージャーは、大きなプロジェクトであればあるほど、開発や実装、つまりプログラミングに近い職域にほぼタッチしていないことも多くあります。

フォワードデプロイドエンジニアを採用している企業の「業態」によっては、その部分を懸念されることもあります。一方で、「技術的な知見はAIが叶えるから、そこまで重要視していない」という企業もあります。

2-3. コンサルティング企業

コンサルティングとは何か？という問いについては、「医者」と僕は表現しています。医者は、体調が悪いときに「病名」と「薬の処方」をしてくれます。ただ、「薬の開発」はしていませんよね。

つまり、医者は、「体調が悪い、または怪我をしている」という状態に対して、「課題（原因）を明確化して、解決策（薬の処方）を提示する」という仕事です。

コンサルタントが実施している仕事内容は、まさにフォワードデプロイドエンジニアの仕事内容の一部であると、僕は捉えています。

コンサルティング会社には、「ITコンサルティング」「戦略・経営コンサルティング」「財務コンサルティング」「HRコンサルティング」など、様々な種類が存在します。「主領域」は異なるのですが、課題解決という観点においては、共通している役割（職域）になるわけです。

フォワードデプロイドエンジニアは、一般的に「ITコンサルティング」出身者がマッチすると思われている傾向がありますが、課題解決という観点においては、IT「以外」のコンサルティング出身者でも、個人的には賄える可能性があるのではないかと思っています。

コンサルティング経験者の弱みは、「技術的な細かい知見をどこまでお持ちいただけているのか？」になることが多いです。

2-4. Webプロダクト（SaaSなど）

イメージとしてはソフトウェアエンジニアの方です。Webプロダクトやサービスを開発している、バックエンドエンジニアやフロントエンドエンジニアのようなイメージです。開発言語は、PHPやPython、Ruby、TypeScriptなどです。

フォワードデプロイドエンジニアは、もともとはこのソフトウェアエンジニアが、より顧客の前へ立つという意味において、「フォワードデプロイド」という話から始まったと認識しています。

この業態・職種のエンジニアの強みは、「技術的な知見」です。一方で、弱みとしては、「顧客折衝能力がどこまであるのか？」になるかと思います。

2-5. 情報システム部門（社内SE）

社内SEは、企業や人によって職域が本当に多様です。仕事のほとんどをコンサルティング企業やシステムインテグレーターに預けていらっしゃる企業様もいらっしゃいますし、自社におけるシステム開発やインフラ環境の整備を、外部パートナー企業に頼らずに、すべてご自身で完結している方もいらっしゃいます。

細かい仕事内容の分析としてご認識いただきたいのは、「企業や現場の課題文言化と課題提起を、社内側で実施しているのか否か」です。

AI時代において、2026年7月時点で重要だと感じているのは、「課題文言化と課題提起」だと僕は思っています。それこそ、この課題提起自体もAIができてしまうような時代が、すぐそこまで来ていると思うのですが、そのため「2026年7月時点」と記載しました。

「社内SEの方は発注側だから、深いところまで携わっていないのではないか」と判断するのは、もったいないと思います。現在社内SEの方も、職域については細かく記載したほうが良いかと思います。特に、課題にまつわる話や、要件定義にも手を出していらっしゃったというのは、ポジティブなポイントだと思います。

社内SEの弱みとしては、技術的な知見です。

2-6. その他あらゆる職種

フォワードデプロイドエンジニアを募集している企業において、「顧客折衝やコミュニケーション、課題文言化や課題提起」に重きを置く企業と、「技術的な知見」に重きを置く企業に分類されると、個人的には思っています。

前者の内容に重きを置かれる場合は、多様なポジションからチャレンジできる可能性があります。例えば、

会社の取締役など、経営において様々な課題解決をしてきた経験がある方
スタートアップにおいて、様々な職種を担当し、様々な種類の課題解決をしてきた方々
プロダクトマネージャーで、技術的な知見を一定お持ちでいらっしゃる方
マーケティングを専門としているが、デザインやエンジニアリングの知見も一定お持ちの方

これらの方々もチャレンジできる可能性は多分にあるのではないかと捉えています。

ただ、2026年7月時点においては、まだ評価を完全に受け切れない可能性もあります。なぜならば、まだ日本におけるフォワードデプロイドエンジニアの完全な市民権が得られているわけではなく、「フォワードデプロイド」と「エンジニア」を2つに分けたときに、後者の「エンジニア」のほうに引っ張られている傾向もあるかと思います。

一方で、「エンジニアという観点は、ほとんど不要なのではないか？それよりも、AIにおける知見とフォワードデプロイドの素養があれば良いのではないか？」という求人も、僕は多数見たことがあります。

3. フォワードデプロイドエンジニアを募集している「業態」について

3-1. AI企業

AI企業と一言で言っても多岐にわたります。ここでは、「AIのアルゴリズム開発」「ソリューション開発」「AI SaaSも一部保有している」という企業を指して説明します。

AIのアルゴリズム開発のタイミングでは、フォワードデプロイドエンジニアがメインで登場するわけではないと個人的には解釈しているのですが、ソリューション開発、つまり顧客の課題をAIを用いて解決するという観点においては、「フォワードデプロイド」の観点と「エンジニア」の観点の両者を担うという目的の募集が多い状態であると思っています。

むしろ、AIにもともと強みがあるという観点においては、フォワードデプロイドエンジニアを募集する必然性も高く、個人的には、フォワードデプロイドエンジニアを募集している業態としては筆頭であると感じています。

3-2. Webプロダクト系企業

AI企業と比較すると、もともとAIを軸にプロダクト開発をしていたわけではないのですが、AIを手段として活用した暁に、フォワードデプロイドエンジニアというポジションが誕生した状態だと、個人的には捉えています。

Webプロダクト系企業の中でも、特にSaaSは「The Model」を適用している企業が多く、つまり「職域」によってポジションを分けている傾向があります。過去においては、バックエンドエンジニア、フロントエンドエンジニア、インフラエンジニア、SRE、スマホアプリ開発エンジニア、スクラムマスター、エンジニアリングマネージャー、テックリード、テスターなど、様々な職種を細かく分けていた印象でした。

少なからず、バックエンド・フロントエンド・スマホアプリ開発など、「実装」の業務においてはAIで代替され始めているという観点をもとに、フォワードデプロイドエンジニアのポジションが誕生しているイメージです。

Webプロダクト企業が募集しているフォワードデプロイドエンジニアの特徴は、「技術的な知見」を求める傾向があることだと、個人的には捉えています。

AIが登場したことによって、コーディングの職務が代替されていることは間違いないのですが、フォワードデプロイドエンジニアの仕事で最も重要度が高いのは、顧客折衝であり、課題の文言化や課題提起だと思います。ただ、Webプロダクト企業は、そもそもカルチャーとして「技術」が上段にあるケースが多いため、技術的な知見を求めたがる傾向が強いように思います。

一方で、前述したAI企業は、生成AIを超越したLLMの知見を求めたがる傾向にあるのではないかと、個人的には思っています。これは、業態による大きな違いであると思っています。

3-3. フォワードデプロイドエンジニアの募集をほぼ見かけない業態

システムインテグレーターとSES、コンサルティング企業では、あまり見かけないなと思います。ただ、一部例外もあります。

システムインテグレーターについては、一次請けの、いわゆるプライムSIと呼ばれている企業の中でも、そこまで規模感が大きくはない企業様においては、フォワードデプロイドエンジニアっぽい求人を募集していることがあります。「っぽい」と記載したのですが、職務内容を聞いてみると、「それ、フォワードデプロイドエンジニアですね」となるパターンです。

プライムSIは、エンドユーザーである顧客と直接コミュニケーションを取るポジションです。大規模なSIはプロジェクトが大きいため、「フォワードデプロイド」は実行するかと思うのですが、「エンジニア」という観点においては、職域が完全に別であることが多いです。

また、小規模なITコンサルティング企業様にも、同じような事例があります。そこまで顧客の企業規模が大きくなければ、ITコンサルタントの方が課題の文言化や課題提起はもちろん実施し、その後のシステム開発までご自身で賄うことは、昨今増えてきているように思います。

SESとして派遣型でプロジェクトに入り、フォワードデプロイド的な、顧客の前でのコンサルティングなどを実施し、エンジニアとして実装までをするという方もいる可能性があるなとは思っています。

4. フォワードデプロイドPMとフォワードデプロイドエンジニアの違い

4-1. フォワードデプロイドPMとは

プロジェクトマネージャーは、一般的には要件定義や基本設計の業務がメインになることが多いです。また、要件定義を済ませた後は、プロジェクトが円滑に進むために全体の調整をしたり、スケジュール管理をしたりすることも、仕事の一部となります。

ただ、プロジェクトマネージャーの職域についても、AIの侵食はどんどん始まっています。AWSのKiroというAIエージェントが、要件定義や基本設計をほぼパーフェクトに実施するということも、耳にすることが増えてきました。

そのため、フォワードデプロイドエンジニアとフォワードデプロイドPMは、同じような背景で「職域」が「フォワード」になっていくような、そんなイメージです。

ただ、いわゆるプロジェクトマネージャーは、ソフトウェアエンジニアと比較すると、「フォワード」の領域がもともと多いです。プロジェクトマネージャーは顧客とコミュニケーションを取りながら進める機会も多く、ソフトウェアエンジニアは顧客の前に出ない方も多い中で、「フォワード」という観点においてはアドバンスしているようなイメージです。

一方で、フォワードデプロイドPMに求められるのは、フォワードデプロイドエンジニアと同様に、顧客の曖昧な要望を文言化して、課題を提起し、そしてシステムやサービス、機能レベルであったとしても企画をすることです。

2026年時点では、さらにその上流の業務がフィーチャーされており、「フォワードデプロイドPM」というポジションが誕生したような、そんな背景です。

4-2. フォワードデプロイドPMとフォワードデプロイドエンジニアの違い

現時点における仕事の違いは、少ないかと思います。ただ、明確に異なるのは、「起点」です。

フォワードデプロイドエンジニアは、「開発・実装」を起点として、職域を「フォワード」に伸ばしている
フォワードデプロイドPMは、「要件定義や基本設計」を起点として、職域を「フォワード」に伸ばしている

こんな違いです。

どちらが有利なのか、優位なのかという話も発生するかと思いつつ、重要なのは得意分野の話だと思うのです。プロジェクトマネージャーは、「顧客折衝能力」に一定長けていると思います。一方で、エンジニアは技術的知見に長けています。そのため、どちらにも強みと弱みが発生しています。

明確に言えるのは、プロジェクトマネージャーであったとしても、エンジニアであったとしても、「このシステムやプロダクト、サービスが解決したい、本質的な顧客の課題は何なのか？」を強く意識した上で、これまで仕事をされていらっしゃった方は、大きなアドバンテージを得るように思います。なぜならば、フォワードデプロイドPMもフォワードデプロイドエンジニアも、その観点が共通項であり、最重要事項だからです。

（この「起点」論をさらに深掘りした記事はFDEとフォワードデプロイドPMはどう違うのかをご覧ください）

4-3. 「課題文言化や課題提起は、私できますよ？」と言う前に

顧客やユーザーの課題は無数に存在します。

例えば、ダイエットをして痩せたいという課題があった場合に、課題解決策として、「食事をする量を減らす」「ランニングをする」「糖質制限をする」などの課題解決策があります。

つまり、課題の文言化や課題解決策の明示は「できた」ということになりますよね。ただ、皆さん、ダイエットを成功されたことはありますか？解決策を見出し、実行したけれども、解決できなかったという方が、ほとんどなのではないかと思います。

何を申し上げたいかというと、顧客やユーザーが感じている課題の解決策をシステムやサービスに実装したとしても、本当にその課題が解決できたかは分からないということです。

「本質的な」という言葉は、よくビジネスの世界で活用されることがありますが、まさにこの「本質的な課題」にたどり着くスキルが重要になってくるのです。

事業部長やマネージャーが、「こんな施策に取り組んでみよう！」と打ち出した際に、「え、その施策、ズレてない？」と思ったことってありませんか？つまり、今の問題や課題の感じ方や捉え方は、ユーザーによって異なります。そして、表層的な課題解決をしたとしても、本質的な課題は解決されないことも多くあります。

4-4. 顧客やユーザーに課題に気づいてもらうためには、コミュニケーション力が非常に重要

本音を申し上げると、一般論として、いわゆるエンジニアの方々は、コミュニケーション力という点において、ビジネスサイドの方と比較すると、やや劣る傾向にあると思います。

ここで言うコミュニケーションというのは、「技術を正確に表現するコミュニケーション」というよりは、「顧客と気持ちの良いコミュニケーションを取る」という観点です。

皆さん、仕事でも私生活でも、「あなたの課題は〇〇だから、これを改善したほうが良いですよ」と唐突に言われて、イラッとした経験ってありませんか？普通、人間は自分の至らないこと、つまり問題や課題を指摘されたら、心中穏やかではないことは多分にあるかと思います。

エンジニアという仕事は、課題解決をする仕事だと僕は捉えています。そのため、とにかく「事実」に目を向ける傾向があると思います。表面化している事実をどのように解決していくのか？というスキルには長けていると思うのですが、顧客やユーザーは人間であって、そこには感情が伴います。

そのため、フォワードデプロイドをするにあたって、ただ課題を追求し、突き止めるだけではダメなわけです。

人間には感情がある中で、顧客やユーザーが「解決したい」と思えるような課題を、コミュニケーションによって創発させながら、お伝えする必要があります。論理的にはその課題が成立していたとしても、顧客やユーザーがそれに合意するかどうかは分かりません。「どう考えても、これが課題なのに、なぜ分かってくれないのか」と感じることも、多数あるでしょう。ただ、それがフォワードデプロイドをするために必要な要素なのです。