FDEのプロジェクトはどう進める？現場の型
- 現場に入る深く入り込み真の課題を捉える
- 構造化する課題を整理し解く順番を決める
- 小さく作る生成AIで動く成果物を形にする
- 検証・定着現場で使い改善して定着させる
- 起点：決められた仕様を受け取る
- 責任：仕様どおりに作り切ること
- 関与：作って納品するまで
- 起点：現場に入り課題を再定義する
- 責任：顧客の成果が出るまで
- 関与：実装から定着まで伴走する
FDEのプロジェクトはどう進める？
現場に入って真の課題を捉え、それを構造化し、小さく動くものを作って現場で検証・定着させる。この反復がFDEの型です。 大きな仕様を一度に作るのではなく、成果に向けて素早く回します。
FDE（Forward Deployed Engineer）は、顧客の事業に伴走して課題解決そのものを担う職種です。VACAN Technologiesはその進め方を、水になぞらえて説明しています。要件が固まってから動くのではなく、要件が固まる前の「課題の発見」から関わる点が、FDEのプロジェクトの起点になります。
現場に入り真の課題を捉えるとは？
FDEのプロジェクトは、顧客の現場に深く入り込んで真の課題を捉えるところから始まります。表面的な要望ではなく、その裏で本当に詰まっている論点を掴むことが最初の仕事です。VACANの代表・田巻 流は立ち上げの狙いを「顧客の現場に深く入り込み、真の課題を捉え、整理・構造化して、生成AIも活用しながら前に進めていく」と述べています（Wantedlyインタビュー）。この「現場に入る」姿勢が、後続のすべての工程の精度を決めます。
課題を構造化して順番を決めるには？
捉えた課題は、そのまま実装に移すのではなく、整理・構造化して解くべき順番を決めます。何が本質的なボトルネックで、どこから手を付ければ現場が早く楽になるかを見極める工程です。ここで順番を誤ると、動くものを作っても現場の渇きが潤いません。構造化は、次の「小さく作る」を正しい標的に向けるための設計にあたります。
検証と定着まで回す反復とは？
FDEは作って終わりではなく、現場で使ってもらい、改善して定着させるまでを担います。小さく作った成果物を現場に置き、実際の使われ方から学び、また課題の捉え直しに戻る。この「捉える→構造化→作る→検証・定着」の反復こそがFDEのプロジェクトの型です。一度きりの納品ではなく、成果が出るまで回し続ける点が特徴です。反復のたびに現場の理解が深まり、最初は見えなかった真の課題が輪郭を現します。だからこそ、要件を最初に固め切るのではなく、動かしながら課題を捉え直す進め方が有効になります。
なぜ「小さく作る」のか？
現場の渇きを早く潤し、使われながら改善するためです。 精緻な計画より、動くアウトプットを早く届けることを優先します。
巨大なダムを一度に造るのではなく、現場の渇きを潤す「小さな井戸」を掘り、やがてつなげて水路にする。VACANはこの考え方をコアメッセージに掲げています（公式サイト）。大きく作り込んでから世に出すと、現場のニーズとずれたときの手戻りが大きくなります。小さく作れば、ずれを早く発見して直せます。
「小さな井戸を掘る」思想とは？
「小さな井戸を掘り、やがて水路へつなぐ」は、VACANがFDEの進め方を表す中心的な比喩です。まず目の前の渇きを潤す小さな解決策を現場に届け、それを起点に少しずつつなげて、より大きな仕組み（水路）に育てていきます。最初から完成形を目指すのではなく、動くものの連なりとして全体を組み上げる発想です。
動くアウトプットを早く届ける利点は？
早く動くものを届ける最大の利点は、現場で使われながら育てられることです。使われて初めて分かる課題を次の改善に取り込めるため、机上の計画よりも成果に近づきます。小さく作れば投じる労力も小さく、方向がずれても軌道修正の痛みが少なくて済みます。潤した渇きを起点に次の井戸を掘り、やがて水路へつなげていく。これがFDE型プロジェクトの推進力であり、「小さく作る」を選ぶ理由です。
進め方の4ステップは？
現場に入る・構造化する・小さく作る・検証と定着の4ステップで進めます。 各ステップは一方通行ではなく、反復して回します。
| ステップ | 内容 |
|---|---|
| 1. 現場に入る | 顧客の現場に深く入り込み、真の課題を捉える |
| 2. 構造化する | 課題を整理・構造化し、解くべき順番を決める |
| 3. 小さく作る | 生成AIも活用し、動く成果物を素早く形にする |
| 4. 検証・定着 | 現場で使ってもらい、改善して定着させる |
各ステップの狙いは？
4ステップは、それぞれ次の工程の質を担保するために存在します。手順として整理すると次のとおりです。
- 現場に入る：顧客の現場に深く入り込み、要望の奥にある真の課題を捉える。
- 構造化する：捉えた課題を整理・構造化し、解くべき順番を決める。
- 小さく作る：生成AIも活用しながら、動く成果物を素早く形にする。
- 検証・定着：現場で使ってもらい、改善を重ねて定着させる。
Palantirの公開情報でも、FDEは設計・実装・テストを自ら行い、エンドユーザーと協働して解決策を実装するとされています（Palantir公式ブログ）。作る工程を外部に丸投げせず、自ら手を動かす点は各ステップに共通します。
生成AIはどこで活きる？
生成AIが最も活きるのは、3番目の「小さく作る」工程です。動く成果物を素早く形にする速度を、生成AIが押し上げます。田巻も、進め方を「整理・構造化して、生成AIも活用しながら前に進めていく」と表現しています（Wantedly）。速く作れるほど、検証と改善の反復も速く回せます。
受託開発と何が違う？
受託が「決められた仕様を作る」のに対し、FDEは「課題の再定義から成果まで」に責任を持ちます。 作る対象そのものを問い直す点が違いです。
「仕様を作る」との決定的な差は？
決定的な差は、責任範囲が仕様の実装ではなく成果にあることです。田巻は「単に相談に乗るだけでもなく、単にシステムをつくるだけでもない。顧客の事業にハンズオンで伴走する」とこの違いを語っています（Wantedly）。相談役でもなく、仕様どおりに作る開発会社でもなく、課題の再定義から実装・定着まで顧客と並走するのがFDEです。
関連記事でさらに深掘りするには？
FDEの進め方をさらに掘り下げたい場合は、関連記事が役立ちます。顧客の巻き込み方はFDEはどうやって顧客を巻き込む？、職種としての全体像はFDEとはで解説しています。プロジェクトの型を理解したうえで、実践と定義の両面から読み進めると立体的に掴めます。
