AI時代のFDE：LLMを武器に現場を変えるエンジニアの新しい形

結論

生成AIの普及でFDEの生産性は大きく変わりました。半日かかっていたプロトタイプが数時間で動き、クライアントとのファーストミーティング翌日には試せるものを持ち込めるようになっています。1人のFDEが同時に面倒を見られる案件数が増え、より多くの組織に深く関われるようになりました。

ただし、その恩恵は均等ではありません。LLMを自分のワークフローに組み込めたFDEと、まだ使い慣れていないFDEの間には、すでに体感できるほどの生産性差が生まれています。そしてクライアント側の期待値も同時に上がっており、「AIがあれば何でもできるはず」という誤解を丁寧に扱うスキルが、新しい必須能力になっています。

---

LLMがFDEの仕事を変えた3つのポイント

コーディング速度：雑務から設計に集中できるようになった

FDEが現場で書くコードは、クリーンで美しいアーキテクチャより「動いて意図が伝わる」ことが優先されます。CSVを読んでグラフを出す、Slackに通知を飛ばす、既存APIから必要なフィールドだけ抽出して整形する。こうした「設計というよりも実装」の部分は、LLMが得意とするタスクとほぼ一致しています。

以前は、PythonでAPIを叩いてデータを取得し、必要な加工をして簡単なUIに乗せるまでに半日程度かかっていました。現在は、やりたいことをプロンプトで説明し、出力を手直しして動かすまでが2〜3時間で完了する事例が増えています。コーディング量が多いほど恩恵が大きく、特にFDEが繰り返し書く定型的な処理ではその効果が顕著です。

浮いた時間の使い道は、クライアントとの対話です。現場の課題をより深く掘り下げ、「本当に解きたい問い」を一緒に言語化する時間が増えました。ツールを早く作れるようになったからこそ、何を作るべきかを考える余裕が生まれています。

ドキュメント作成：議事録から提案資料まで

FDEの仕事はコードだけではありません。ヒアリング後の議事録整理、現状課題の整理ドキュメント、クライアント向けのハンドオーバー資料、提案内容をまとめたスライドの下書き。こうした文書作成にかかる時間も、LLMの活用で大幅に圧縮されています。

ミーティングの録音やメモをLLMに渡し、課題整理と仮説を引き出す形式は、多くのFDEが日常的に使うようになっています。重要なのは、LLMが出した文書をそのまま送らないことです。クライアントの業界固有の言葉遣いや、関係者の優先度感覚は、LLMが補えない部分です。下書きを引き出す道具として使い、仕上げは人間が担います。

提案資料の骨格を作る際にも変化があります。過去の類似案件の事例や業界の標準的な解決策をプロンプトで整理させ、それを足がかりにクライアント固有の部分を肉付けする方法は、ゼロから考えるより圧倒的に速いです。FDEが日本でどんな場面で求められているかについては、日本でFDEが求められる理由も参照してください。

提案力：「この程度の速さで動く」を即座に見せられる

FDEの提案が刺さるのは、「こういう方向で解決できます」という言葉より、「こういう動きのものが作れます」と画面を見せたときです。生成AIがコーディングを加速したことで、ヒアリングからプロトタイプ提示までのサイクルが短くなり、クライアントが具体的なイメージを持ちやすくなりました。

かつては提案フェーズでモックを用意する時間的余裕が取りにくく、スライドと言葉だけで方向性を伝えるしかない場面がありました。現在は、ヒアリング翌日に動くプロトタイプを持ち込み、「こういう操作でこう変わります」を体験してもらえます。クライアントが思っていなかった使い方への気づきや、「実はこっちの方が重要だった」という優先度の組み替えが、早い段階で起こるようになりました。

---

FDEがLLMを現場に組み込む実際のワークフロー

FDEのLLM活用は、ツールを使うというより、作業のリズム自体を変えることに近いです。代表的な使い方を整理します。

ヒアリングのその場で仮説を言語化する

クライアントの話を聞きながら、並行してLLMに「この課題の整理を手伝って」とメモを渡します。FDE自身の思考の整理ツールとして使い、ミーティング中に「整理するとこういうことですか？」と確認できます。後から議事録を作る時間が減り、認識のずれを早めに発見できます。

スキャフォールドをLLMに書かせ、中身を自分で判断する

新しいプロジェクトでよく使う構成、例えばFastAPIの基本構造やSQLAlchemyのモデル定義などは、LLMに生成させます。時間がかかるのは構造の選択と、クライアントの業務ロジックを組み込む部分です。そこに集中し、定型部分は任せます。

出力は必ず動かして確認する

LLMが生成したコードは、一見正しく見えても、境界値のハンドリングや特定の環境依存の挙動が抜けている場合があります。FDEが現場で使う場合、動作確認なしに本番データを流すことはしません。生成→確認→手直しのサイクルを崩さないことが、速さと品質を両立させる基本です。

プロンプト設計の精度が最終的な差になる

同じことを頼んでも、プロンプトの書き方次第で出力の質は大きく変わります。FDEがLLMをうまく使いこなすためのプロンプト設計については、FDEのプロンプトエンジニアリングで詳しく解説しています。業務文脈を正確に渡す方法や、反復的な改善のやり方が参考になります。

---

クライアントへのAI活用移転：FDEが果たす新しい役割

FDEの役割として、自分が使うだけでなく、クライアントがAIを自走して使えるようにする側面が強まっています。単発の実装を渡して終わりではなく、「次は自分たちで変えられる」状態を作ることが、FDE関与の本質的な価値になりつつあります。

この移転には3つの段階があります。

第1段階：FDEが使って見せる

クライアントの前でLLMを使って作業を進め、「これがどう速くなるか」を体験させます。抽象的な説明より、目の前でコードが生成される光景の方が理解が早いです。「AIに何を渡して何を頼むか」の感覚が、この段階で伝わります。

第2段階：一緒に使う

担当者とペアでプロンプトを書き、出力を見て直す経験を積んでもらいます。FDEが隣にいる状態で「うまくいかないとき」を体験することが重要です。一人でやると詰まって諦める場面でも、FDEがリカバリーの仕方を見せることで、「なぜうまくいかなかったか」の学習になります。

第3段階：クライアントが自走する

FDEが関与しない場面でもLLMを使えるよう、使い方のドキュメントや社内向けのプロンプトテンプレートを整備します。この段階に到達したクライアントは、FDEとの次の協働テーマをより高度な課題に設定できるようになります。

FDEが使うAIツールの選び方や比較については、FDEが使うAIツールをあわせて参考にしてください。

---

「AIがあれば人はいらない」という誤解とFDEの答え

生成AIが注目されるにつれ、クライアントから「FDEに頼まなくてもAIで自分たちが作れるんじゃないか」という話が出るようになりました。これはFDEにとって脅威というより、向き合うべき誤解です。

実際のギャップはどこにあるか

LLMはコードを書けますが、何を作るべきかは指示する側の判断です。現場担当者がLLMに「在庫管理ツールを作って」と頼めば、それらしいものが出てきます。しかし、「この会社の在庫管理の本当のボトルネックはどこか」「作ったツールが実際の業務フローと合っているか」「半年後に保守できるか」を判断するには、業務理解と実装経験の両方が要ります。

ツールを生成することと、組織の課題を解決するツールを作ることは、別の仕事です。LLMが前者を速くしたのは事実ですが、後者はFDEが担ってきた本質的な役割です。

誤解が生まれる理由

LLMのデモやメディアの報道では、「プロンプト数行でアプリが完成」という印象を与える事例が多いです。実際には、その後の修正サイクル、エラー処理、データの整合性確認、クライアントの実業務に合わせた調整のコストは映っていません。FDEが現場で体感しているのは「早くなった」であって「なくなった」ではないです。

FDEの答え

この誤解に対してFDEが取れる最も有効な対応は、言葉で説明することではなく、プロトタイプを通じて価値の差を見せることです。「自分たちでもできそう」という感覚が「やっぱり一緒にやる方が速い」に変わるのは、実際に試した後です。FDEがその機会を作り、体験させることが、誤解を解く最短ルートです。

---

5年後のFDEはどう変わるか

現時点での変化を整理すると、LLMはFDEの「実装する速さ」を大きく底上げしました。5年後にどうなるかは不確実ですが、現在見えているトレンドからいくつかの方向性が読み取れます。

コーディングの自動化はさらに進むとみられる

コード補完からコード生成、そしてより複雑な設計判断への関与へと、LLMの能力は拡張しつつあります。FDEが今手で書いている定型コードの多くは、5年後には生成ツールに任せられるようになっているとみられます。FDEに残るのは、何を作るかの判断と、クライアントと作り上げるプロセスです。

マルチモーダルな現場対応が増えるとみられる

現在はテキストや画像を扱うLLMが主流ですが、動画・音声・センサーデータなど、より多様な入力への対応が進むとみられます。FDEが現場データとLLMをつなぐ場面が増え、対応できる課題の種類が広がる可能性があります。

FDE同士、またはFDEとAIエージェントの協働が標準になるとみられる

現在は「FDE1人+ツール」という構図が多いですが、複数のFDEが並行して動くプロジェクトや、FDEがAIエージェントを指示・監督しながら案件を進める形が出てくるとみられます。この場合、エージェントの動きを設計・管理する能力が、コーディング能力と並ぶ重要スキルになります。

変わらないもの：クライアントの業務文脈を読む力

生成AIがどれだけ進化しても、クライアントが何に困っていて、何を解決すれば組織として動き出すかを判断するのは人間です。現場に入り、担当者の言葉を聞き、課題の構造を整理し、技術的に何が可能かを伝える。FDEのコアはそこにあり、AIが高度化するほど、その部分の価値は際立つとみられます。

FDEという役割そのものについての基本を確認したい場合は、FDEとは何かを参照してください。

---

まとめ

生成AIはFDEの仕事を消すのではなく、より高い場所でより多くの課題と向き合える状態にしました。コーディングが速くなったことで、現場での対話と判断に使える時間が増えています。クライアントのAI活用移転を担い、誤解を実体験で解いていくことも、FDEの新しい仕事になっています。5年後の変化は予測の域を出ませんが、クライアントの業務文脈を読む力が中心にある限り、FDEの役割は変わらず求められるとみられます。