FDE（Forward Deployed Engineer）とは、顧客の現場で業務を理解し、課題の発見から解決策の実装、運用定着まで関わるエンジニアです。アンドドットが公開している常駐型FDEの考え方をもとに、役割と進め方、導入前に確認したい点を整理します。
FDEとは、現場で課題を見つけて解決まで進めるエンジニア
「何を作るか」を決める前から関わる
FDEはForward Deployed Engineerの略です。アンドドットの常駐型FDEの公式ページでは、顧客の業務を最前線で理解し、課題発見、解決策の提示、システム開発、運用定着を繰り返す役割として説明しています。
依頼された機能を実装するだけでは、依頼の背景にある業務上の問題が残る場合があります。FDEは現場の担当者と業務の流れを確認し、「どこが止まっているのか」「何を変えれば使い続けられるのか」から考えます。開発はそのための手段です。
ただし、FDEという呼び名だけで、提供範囲や契約上の責任が一律に決まるわけではありません。この記事では一般論とアンドドットの公開サービス説明を区別し、個別案件の条件は断定しません。
DX・AXで不足しがちな役割をつなぐ
DXやAIを使った業務変革では、技術の選定より前に、解くべき課題と進め方を定める必要があります。公式ページは、課題の特定、解決策の企画、実装・推進、運用定着を担う人材が同時に不足しやすいと整理しています。
担当者が分かれていること自体が問題なのではありません。段階の間で前提や判断が引き継がれず、企画はあるのに開発が始まらない、完成したのに現場で使われない、といった断絶が問題です。FDEは現場に関わり続け、各段階の判断を次の実務につなげます。
FDEは課題発見から運用定着までどう進めるのか
アンドドットの「FDEジャーニー」は、CPF、PSF、SPF、POFの4段階で示されています。各段階の目的を分けて合意することで、後から期待のずれに気づく事態を減らす設計です。順番は一度進んで終わりではなく、新しい課題が見つかれば見直します。
1. CPF：本当に解くべき課題を特定する
CPFはCustomer Problem Fitの略です。現場から出た依頼をそのまま開発要件にせず、業務を観察し、関係者に確認しながら問題を構造化します。例えば「入力を自動化したい」という依頼なら、入力作業だけでなく、情報の受け取り方や確認の流れも見る必要があります。これは実案件の事例ではなく、課題整理の考え方を示した例です。
この段階で確認するのは、困っている人、発生する場面、現在の対処、変えたい状態です。公式ページが示す到達点は、顧客自身の言葉で真の課題を説明できることです。課題が曖昧なまま解決策だけを決めると、後の実装が正しくても利用されないおそれがあります。
2. PSF：解決策を比べ、進める案を合意する
PSFはProblem Solution Fitの略です。課題が分かった後は、複数の解決案を業務への効果、実装の難易度、運用負荷で比べます。AIの導入を前提にせず、既存の手順を整理する、入力項目を減らす、システムで支援するなど、課題に合う方法を選びます。
重要なのは、誰が何を根拠に決めたかを共有することです。現場には使いやすさ、管理側には統制、運用担当には保守の観点があります。案の利点と制約を並べ、進める方向と見送る案を合意しておくと、実装中の判断も揃えやすくなります。
3. SPF：小さく実装し、業務で試す
SPFはSolution Product Fitの略です。公式ページでは、短い開発サイクルで動くものを作り、現場を巻き込みながら仕上げると説明しています。設計書の完成や画面の見た目だけでは、業務で使えるかは分かりません。実際の作業に組み込み、例外処理や引き継ぎまで確認する必要があります。
この段階では、利用する担当者、入力する情報、判断を人に残す箇所、失敗時の戻し方を明確にします。使って初めて見える課題は、次の改善に反映します。到達点は、動くプロダクトが対象業務で使われている状態です。
4. POF：担当者が使い続けられる状態を作る
POFはProduct Operation Fitの略です。導入後の業務で誰が運用し、変更や障害にどう対応するかを決めます。担当者への説明、手順、権限、問い合わせ先が曖昧だと、仕組みは完成していても使われなくなります。
公式ページは、FDEが離れた後も運用と改善のループが社内で回ることを目標にしています。利用状況と業務上の効果を確認し、期待と違えば原因を探す。その結果を次の課題発見につなぐところまでが、定着の工程です。
FDEの役割を「開発」だけで捉えない
成果物より、業務の変化を確認する
システムを作ったことと、業務が改善したことは同じではありません。FDEを検討するときは、何を納品するかに加え、対象業務のどの状態を変えたいかを確認します。例えば、担当者の手戻り、確認待ち、利用の継続といった観点は、改善を振り返る手がかりになります。
ただし、具体的な測定指標や成果を決めるには、現状の業務と計測条件を確かめる必要があります。公開されていない顧客成果を、この段階で実績として扱うことはできません。まずは「何を見れば前進といえるか」を関係者で揃えることが大切です。
他の支援形態とは、依頼時の前提を比べる
人材派遣・SES、コンサルティング、開発会社とFDEは、単純な優劣では選べません。依頼内容が明確で開発する機能が決まっているのか、課題の整理から必要なのか、運用まで同じ体制で見たいのかによって、適した支援の形は変わります。
アンドドットの公式ページは、常駐型FDUの範囲を課題発見から企画、開発、運用改善までとしています。個々の契約で担う範囲は別途確認が必要です。SESやコンサルティングとの詳しい比較はそれぞれの専門記事で扱い、ここではFDEの役割の全体像に絞ります。
一人に任せきりにしないFDUという体制
現場に入るFDEと後方支援の役割
アンドドットは、常駐するFDEを中心に、Success PartnerとExpertが支えるFDU（Forward Deployed Unit）を説明しています。FDEは現場で課題を見つけ、解決策を企画し、開発と定着を進める中心の役割です。
Success Partnerは目的や優先順位、範囲と期待値を定期的に揃えます。Expertはセキュリティや業界固有の論点など、専門的な判断が必要な場面で加わります。これはアンドドットの提供体制の説明であり、すべてのFDEサービスに共通する構成ではありません。
体制を見るときの確認点
導入側は「誰が常駐するか」だけでなく、判断が難しいときの相談先、目的を見直す場、担当が変わった場合の引き継ぎを確かめるとよいでしょう。現場の活動を後方支援につなぐ仕組みがあるかで、個人の経験だけに依存しにくくなります。
公式ページには常駐日数やユニット構成も示されていますが、実際の契約条件をこの記事から推定しません。対象業務の規模や必要な専門性と合わせて、相談時に適用範囲を確認してください。
FDEに必要な視点と、導入前に整理したいこと
技術・課題整理・進行管理・対話を組み合わせる
アンドドットはFDEの能力を、コンサルティング、エンジニアリング、プロジェクト管理、オープンで親しみやすい関わり方の4軸「CEPO」で示しています。課題を分析する、AIを含む技術で作る、進捗と品質を管理する、現場の本音を引き出すという役割です。
どれか一つが強ければ十分とは限りません。現場の課題を理解できても形にできなければ前に進まず、開発できても利用者と認識がずれていれば定着しません。企業がFDEを選ぶ際は、候補者の技術だけでなく、課題の聞き方や合意の進め方も確認する必要があります。
最初に「止まっている業務」を言語化する
導入の検討時点で、詳細な要件定義書を完成させる必要はありません。一方で、どの部門の業務に困りごとがあり、誰が困っていて、どの判断で止まっているかは整理しておくと、最初の対話が具体的になります。
課題を一つに決めきれない場合は、候補を並べて現場の担当者と優先順位を確かめます。FDEに全てを任せるのではなく、社内側の責任者、意思決定者、利用する人が参加できる状態を作ることが、改善を続ける前提です。
相談時は3つの合意を確認する
相談時には、まず課題を発見する範囲、次に解決策を決める人と基準、最後に導入後の運用担当を確認します。担当範囲と期待する変化を分けて話すと、開発するものだけが先に決まることを避けられます。
課題：どの業務と関係者を対象にし、現状をどう確認するか
判断：効果・実現性・運用負荷を誰と比べ、何を合意するか
定着：利用状況を誰が確認し、改善を続けるか
費用、常駐条件、具体的な成果指標は案件ごとの確認事項です。公開情報にない条件を一般的な提供条件として記載しません。
進捗は納品物だけで判断しない
進捗確認では、作業時間や完成した機能の数だけを見ても、現場の変化は分かりません。CPFなら課題を関係者が同じ言葉で説明できるか、PSFなら選んだ案と見送った案の理由が共有されているか、SPFなら対象業務で試せているか、POFなら運用担当が自分たちで回せるかを確認します。
これは公式ページの各段階の到達点を、導入側の確認項目に読み替えたものです。実際の評価指標は、対象業務と計測できるデータに合わせて決める必要があります。数値を決める前に、いつ・誰が・何を測るのかを揃えておくと、成果の解釈がぶれにくくなります。
FDE以外の進め方が合う場合もある
既に解くべき課題と仕様が定まり、決められた機能の実装が主な目的なら、開発会社への依頼や社内開発が適する場合があります。逆に、まず経営方針や制度を整理したい段階では、技術者を現場に置くだけで課題が解決するとは限りません。
FDEを選ぶ理由は「新しい職種だから」ではなく、課題発見から実装・運用までの間に担当の切れ目があり、同じ現場で改善を繰り返す必要があるかどうかです。検討時は他の支援形態も含め、必要な役割と自社が担う役割を先に整理してください。
FDEについてよくある質問
何を作りたいか決まっていなくても相談できる？
課題の発見から扱うという公開サービスの説明に照らせば、解決策やシステムの仕様が未確定でも相談の入口になります。どの業務に困りごとがあるか、誰が関わるかを共有すると、課題整理を始めやすくなります。実際の受け入れ範囲は相談時に確認してください。
AIを使うことが目的なの？
AIは業務改善の手段の一つです。先に課題と業務上の判断を確かめ、AIを使う案と使わない案を比べる方が、解決策を選びやすくなります。この記事はAI導入の効果を保証するものではありません。
FDEが離れた後はどうなる？
アンドドットの公開ページは、FDEが離れた後も運用が回る状態をPOFの目標としています。引き継ぐ人、手順、改善の判断方法を導入中に整えることが重要です。どこまで支援に含むかは、個別の契約で確認してください。
まとめ：FDEは現場の課題から運用までつなぐ役割
FDEとは、現場で課題を見つけ、解決策を選び、作って試し、使い続けられる状態まで進めるエンジニアです。アンドドットはこれをCPF・PSF・SPF・POFの4段階と、FDE・Success Partner・ExpertによるFDU体制で説明しています。
自社でFDEを検討する際は、まず導入の進め方を押さえ、費用と投資対効果を見積もり、社内で説明する材料をそろえる必要があります。次の3点セットでは、それぞれを別の資料で確認できます。
