FDEの仕事内容とは？プロジェクトの進み方を6つのフェーズで具体的に解説

「FDEが現場に入り込んで作り切る、というのは分かった。で、具体的には何をするの？」——本記事では、FDE（Forward Deployed Engineer）のプロジェクトが実際にどう進むのかを、6つのフェーズに分けて解説します。

発注を検討している企業の方には「何が起こるかの予告編」として、FDEという働き方に興味があるエンジニアの方には「仕事のリアル」として読んでいただけるはずです。

フェーズ1：観察──まず現場に「いる」ことから始まる

プロジェクトの初日は、ヒアリング会議室ではなく現場から始まります。営業に同行する。事務作業を隣で見せてもらう。実際のデータを見る。Slackやメールのやり取りに入れてもらう。

なぜなら、インタビューで語られる業務と、実際の業務は必ずズレているからです。「この転記作業、大変なんですよ」と語られた作業より、本人が無意識にやっている二重チェックのほうが遥かに時間を食っている——観察はそういう発見をもたらします。

このフェーズの成果物は、業務の流れと「痛みの地図」。数日から2週間ほどかけます。

フェーズ2：課題の構造化──「解くべき問題」を合意する

観察で見えた課題を、影響の大きさ×解決の難易度で整理し、どこから手をつけるかを経営・現場と合意します。

ここで重要なのは、最初のターゲットを「小さいが、確実に痛い課題」に絞ることです。いきなり基幹システムの刷新のような大物を狙うと、PoC止まりの典型パターンに陥ります。最初の成功が信頼を生み、信頼が次の変化を可能にする——この順番は動かせません。

フェーズ3：最小の実装──数週間で「動くもの」を出す

合意した課題に対して、動く最小限のシステムを数週間で作ります。完璧なものではなく、現場が「これは楽になる」と体感できる最小単位です。

このスピードを支えているのが生成AI・AIエージェントを前提とした開発スタイルです。従来なら数ヶ月かかった業務ツールの構築が、いまは週単位で回せます。FDEが少人数でも成立するようになったのは、AIエージェントの実用化と切り離せません。

フェーズ4：現場テスト──使われない理由を潰す

作ったものを現場に置き、実際に使ってもらいます。ここからがFDEの真骨頂です。

システムが使われない理由は、機能不足とは限りません。「入力が面倒」「今までのExcelのほうが慣れている」「そもそも存在を知らない」——現場に居るFDEは、こうした小さな摩擦をその場で発見し、翌日には直します。この高速な改善ループが、「納品されたが使われないシステム」との分かれ道になります。

フェーズ5：定着──業務の一部になるまで見届ける

システムが日常業務に組み込まれ、「それがない状態に戻れない」ところまで見届けます。マニュアル整備、朝会での使い方共有、うまく使えていない人への個別フォロー。地味ですが、投資を成果に変える最後の1マイルです。

定着の定義はプロジェクト開始時に決めておきます。「対象業務の処理時間が半分になる」「全員が週3回以上使っている」など、測れる状態をゴールにすることで、「なんとなく完了」を防ぎます。

フェーズ6：移管──自走できる状態にして、次へ

最後は、お客様のチームだけで運用・改善が回る状態を作ります。ドキュメントを残すだけでなく、社内の担当者と一緒に改修を行い、「自分たちで直せる」経験を積んでもらいます。

FDEの支援は「ずっと居続ける」ことがゴールではありません。内製化（自走できる組織づくり）につなげて卒業し、より難しい次の課題や新しいテーマで再び組む——この循環が健全な形です。

ありがちな質問：ウォーターフォールとどう違う？

6フェーズと聞くと直線的な工程に見えますが、実際にはフェーズ3〜5を小さく何周も回します。要件をすべて固めてから作る（ウォーターフォール）のではなく、観察と実装を行き来しながら正解に近づいていくイメージです。だからこそ、要件が曖昧でも、途中で変わっても、プロジェクトは前に進みます。

SAIの視点

私たち株式会社SAIのFDE伴走開発は、まさにこの6フェーズで進みます。不動産会社の営業自動化では観察から始めて営業業務の仕組み化まで、BCP支援企業の事例では定着・移管フェーズに重心を置いた支援を行いました。

「うちの場合はどのフェーズから始まるのか」「期間や体制はどれくらいか」——具体的なイメージが欲しい方は、お気軽にご相談ください。貴社の状況を伺って、最初の2週間で何をするかまで具体的にお答えします。