FDEとは何か——
LICが「前線配置」に賭ける理由

FDE（Forward Deployed Engineer）とは何か？

FDEとは、エンジニアと事業開発の専門家を顧客の事業現場に「前線配置」し、要件が固まる前から動くものを作り、結果を見ながらすぐ動かすアプローチです。Palantir Technologiesが生み出し、OpenAIやAndurilが採用したことで知られる、事業開発とエンジニアリングの融合形態を指します。

定義としてはこれで足りるのですが、この説明だけでは肝心なことが伝わりません。FDEの本質は「エンジニアが客先に行く」ことではないからです。本質は、事業の意思決定と実装の意思決定を、同じ人間が、同じ場所で、同時に持つという一点にあります。この記事では、私たちが実際の支援でどう機能させているかを通して、FDEを説明します。

なぜ「要件定義→設計→開発→納品」の順序を逆にするのか？

従来のシステム開発は、要件定義から始まります。ヒアリングを重ね、合意形成を経て、要件定義書が固まってから着手する。この手続きに平均2〜3ヶ月かかります。

問題は、この2〜3ヶ月のあいだに何が起きているかです。市場は動き、競合はピボットし、顧客の要求は別のものに変わっている。6ヶ月後に納品されたシステムは、6ヶ月前の課題に対する正解です。変化の速度に対して、この構造は根本的に遅すぎます。

そしてもうひとつ、より深刻な問題があります。要件定義書に書ける課題は、顧客が既に言語化できている課題だけだということです。現場の本当のボトルネックは、たいてい誰も言葉にしていません。言葉にできていないから、要件定義のヒアリングでは出てこない。出てこないから、要件定義書にも載らない。そうして、本当に解くべき問題を外したまま、正しく作られたシステムが納品されます。

FDEはこの順序を逆転させます。まず現場に入る。一次情報を自分の目で取る。翌日には動くものを出す。仕様書を待たない。この順序でしか掴めないものがあるからです。

現場に入らなければ出てこなかった課題とは？——Realize様の事例

青森県弘前市で中古カメラを中心とした物販事業を営む株式会社Realize様の支援は、この構造をよく表しています。

ご相談時点で言語化されていた課題は、「商品情報を外注先用のシートと自社の管理シートに二度入力していて手間だ」というものでした。要件定義から入れば、ここが要件になります。二重入力をなくすシステムを作れば、要件は満たせます。

しかし現場に入って業務を観察すると、事業の成長を止めていた真のボトルネックは別のところにありました。仕入れ判断が特定メンバーの経験知に依存していたことです。価格推移データの読み方、ジャンク品の見極め、値引き交渉の勘所——これらはすべて代表の頭の中にあり、口頭でしか伝わっていませんでした。だから人を増やしても仕入れ量は増えない。

この課題は、当初のご相談には含まれていませんでした。含まれていなかったのは、隠していたからではありません。「そういうものだ」と受け入れられていて、解ける問題として認識されていなかったからです。

私たちが取ったアプローチは、「ベテランの判断をAIに真似させる」ことではありませんでした。判断基準そのものを44項目に分解して言語化し、設定として外部に切り出すことです。AIは出品情報からリスクを抽出し、利益・回転率・交渉余地をスコア化して提示する。基準は現場が運用しながら調整できる。結果として、仕入れ判断はチーム全員が共有できるものになりました。

当初の要件だった二重入力も、もちろん解消しています。入力項目は19項目から9項目へ53%削減、入力先は3か所から1か所になりました。ただ、木村代表からいただいた言葉は、そこには向いていませんでした。

作業を減らすためのシステムではなく、判断できる人を増やすための仕組みをつくっていただいたと感じています。
——株式会社Realize 代表取締役 木村 尚斗 氏

この成果は、要件定義書からは出てきません。現場に座って、業務を自分の目で見て、初めて課題として立ち上がるものです。

「削るべき仕事」はどうやって特定するのか？——Megumi Company Group様の事例

株式会社Megumi Company Group様の営業支援でも、同じことが起きました。

「営業の生産性を上げたい」という課題は、どの企業にもあります。抽象度が高すぎて、そのままでは何も作れません。営業支援ツールの機能一覧を眺めても答えは出ません。

商談の現場に入って観察すると、営業メンバーの時間を最も食っていたのは、ターゲット選定と顧客リサーチ——つまり商談の前にある準備工程でした。さらに、業務が過多になった結果、商談後の追客タイミングを逃していた。売上機会は、商談そのものではなく、その前後で失われていたわけです。

ここが特定できれば、作るものは決まります。AIによるターゲット抽出でリスト取得時間を70%削減。AI要約と構成案生成で商談準備時間を50%削減。AIによるリマインドと提案提示でフォロー漏れを防ぐ。空いた時間は顧客とのコミュニケーションと深い課題ヒアリングに回す。

結果は、売上の前月比20%向上、顧客フォロー漏れ0件でした。作業削減で終わらず売上に直結したのは、削る対象を現場で特定できたからです。

LICがFDEで守っている4つの原則とは？

私たちがFDEとして現場に入るとき、必ず守っている原則が4つあります。

原則1：前線配置（Frontline Deployment）

顧客の商談・現場に常駐し、一次情報を直接取ります。ヒアリングシートの回答ではなく、業務フローを自分の目で観察する。Realize様の44項目も、Megumi様の準備工程も、この観察から立ち上がりました。伝聞で受け取った課題は、必ず誰かの解釈が一枚挟まっています。

原則2：即日実装（Same-Day Shipping）

仮説を当日から数日で動くものにします。仕様書待ちはしません。週次でリリースし、その週のうちに現場で検証する。動くものを前にしたときに初めて出てくる「これは違う」「ここまで来たら使える」という反応こそが、次の実装を決める最も濃い情報です。

原則3：Biz×Dev一体（Unified Ownership）

何を作り、何を捨てるかを、ビジネス側と切り分けません。FDE Leadが仮説オーナーとして、商談判断と実装判断を同時に持ちます。PMを介した翻訳が入ると、商談の温度感は必ず減衰します。同一人物が同一現場で決める。これがFDEの中核です。

原則4：AI加速（AI-Accelerated）

AIによって実装速度が桁違いに上がった今、FDEのサイクルはさらに短くなります。1日でMVPが動く時代に、「週次でデプロイ」は前提です。私たちはこの速度を、事業成果にそのまま当てます。

従来型開発とFDEは、具体的に何が違うのか？

言葉の定義よりも、実務でどう違うかを見たほうが早いと思います。

FDEには向かない仕事もあるのか？

あります。ここは正直に書いておきたいところです。

要件が既に確定していて、変更の可能性が低く、規模と品質が最優先される案件——基幹システムの刷新や、法令要件が細部まで決まっている領域では、従来型の開発プロセスのほうが適しています。FDEの価値は「何を作るべきかが確定していない」状況でこそ出るものだからです。作るものが決まっている仕事に前線配置を持ち込んでも、コストが上がるだけです。

私たちがFDEを提案するのは、課題の輪郭がまだぼやけている領域、市場の反応を見ながら方向を変える必要がある領域です。逆に言えば、そうした領域に従来型の要件定義を持ち込むと、冒頭に書いた「正しく作られた、外れたシステム」が生まれます。

なぜ私たちは前線に立つのか

Realize様の44項目も、Megumi様の準備工程も、遠くから設計図を書いていては辿り着けませんでした。現場に座り、業務を見て、その日のうちに動くものを出し、反応を受けて翌日また作り直す。この距離の近さだけが、言語化されていない課題を掘り当てます。

「作って渡す」のではなく、「前線で事業そのものを動かす」。私たちがFDEに賭けているのは、そこに一番大きな差が出ると考えているからです。

要件定義書に書ける課題は、顧客が既に解けると知っている課題である。現場に入って初めて言葉になる課題のほうが、たいてい事業にとって重い。

FDEの進め方はFDE事業のページで詳しくご紹介しています。実際にどう組織へ入れるかは、「FDEを自社に入れる——最初の90日の設計」もあわせてご覧ください。