Key Takeaways
- FDEのプロジェクトは「観察→課題の構造化→最小の実装→現場テスト→定着→移管」の6フェーズで進み、実際にはフェーズ3〜5を小さく何周も回す。
- FDEは要件定義書を待たず現場の観察から始める。インタビューで語られる業務と実際の業務は必ずズレているためである。
- 最初のターゲットは「小さいが確実に痛い課題」に絞るのが有効。最初の成功が信頼を生み、信頼が次の変化を可能にする。
- 現場テストでは「入力が面倒」といった小さな摩擦をその場で発見し翌日に直す。この高速な改善ループが「使われないシステム」との分かれ道になる。
- 定着は「処理時間が半分になる」など測れる状態をゴールに定め、移管では社内担当者と一緒に改修して自走できる状態を作ってから卒業する。
「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フェーズは海外AI企業の職務記述と重なる
6フェーズという分け方は、SAIが独自に考えた枠組みではありません。FDEという職種を生んだ米Palantirは、採用ページでこの職種を自社が切り拓いたものと位置づけ、エンジニアを顧客に直接配属して最も切実な課題に取り組ませる働き方だと説明しています。求人票には、顧客と並んで課題を素早く理解し解決策を設計・構築するという職務が書かれています（Palantir公式求人 Forward Deployed Software Engineer・2026年9月8日確認）。
OpenAIの東京拠点向けFDE求人は、担当範囲を課題の発掘から技術要件の見極め・システム設計・構築・本番展開までと書いています。成功の測り方として挙げているのは、本番運用への定着と業務上の効果です（OpenAI公式求人 Forward Deployed Engineer - Tokyo・2026年9月8日確認）。本記事のフェーズ1から5までの並びと、ほぼ同じ順番になっています。
職種としての広がりは、AI企業の内部にとどまりません。Anthropicは2026年6月11日の発表で、ITサービス大手DXCが数万人規模のClaude認定FDEを育成すると述べています。同じ発表はFDEを「顧客組織の内部に直接配置されるエンジニア」と説明しています（Anthropic公式発表・2026年6月11日）。なぜこの職種が世界的に増えているのかはPalantir・OpenAIに学ぶ新しい働き方で扱っています。
なお上記のうち求人票は募集の状況で内容が変わります。日付は本記事の執筆時点に確認したものです。
FDEのプロジェクト進行に関するよくある質問
Q. ウォーターフォール開発とどう違いますか？
6フェーズと聞くと直線的な工程に見えますが、実際にはフェーズ3〜5を小さく何周も回します。要件をすべて固めてから作る（ウォーターフォール）のではなく、観察と実装を行き来しながら正解に近づいていくイメージです。だからこそ、要件が曖昧でも途中で変わってもプロジェクトは前に進みます。
Q. 各フェーズはどれくらいの期間で進みますか？
対象業務の広さと関わる人数で変わります。目安として観察は数日から2週間、最小の実装は数週間を置いています。全体の期間を先に固定するより、フェーズ5の定着を何で測るかを開始時に決めておくほうが、進み方の判断はしやすくなります。
Q. 要件定義書がない状態でも、フェーズ1から頼めますか？
頼めます。FDE型の支援は「何を作るべきか」の特定から始まるため、要件定義書がないことは前提の一つです。逆に要件が完全に固まっている大規模開発や、既製のSaaSで足りる課題では、従来型の発注のほうが向きます。
Q. フルリモートでも6つのフェーズは回せますか？
回せます。現場常駐・高頻度訪問・フルリモートのいずれにも対応できます。ただし業務観察が中心のフェーズ1は、隣で見ることでしか気づけない作業が多いため、訪問を組み合わせる進め方をおすすめしています。
Q. 1つの部署の1業務だけで始めることはできますか？
できます。1業務・1チームの課題から始めて、成果を確認しながら適用範囲を広げるのが最も失敗の少ない進め方です。最初のターゲットを絞る理由はフェーズ2で述べたとおりで、最初の成功が次の変化を進めやすくします。
SAIの視点
6フェーズを工程表として読むと、フェーズ1と2は「まだ何も作っていない期間」に見えます。だからこそ、この2つで何を受け取れるのかを先に決めておく必要があります。
私たち株式会社SAIのFDE伴走開発では、各フェーズで手元に残るものを次のように置いています。
- 観察・課題の構造化：現場の業務とデータを見て特定したボトルネックと、どれから解くかの合意
- 最小の実装：業務システム、生成AI・AIエージェントの業務組み込み、データ基盤・ダッシュボードのいずれか。数週間単位で現場に置いて使える状態のもの
- 現場テストと定着：処理時間や利用率など、開始時に決めた定着の指標にもとづく計測結果
- 移管：貴社メンバーと一緒に作った改修の実績と、自社だけで運用が回るドキュメントと体制
広告代理店のマーケティング自動化では観察から始めて制作・運用業務の仕組み化まで、BCP支援企業の事例では定着・移管フェーズに重心を置いた支援を行いました。
「うちの場合はどのフェーズから始まるのか」「期間や体制はどれくらいか」——具体的なイメージが欲しい方は、お気軽にご相談ください。貴社の状況を伺って、最初の2週間で何をするかまで具体的にお答えします。