fde aiをフル開発前提で導入するな。プロトタイプを作り込みすぎる新規事業が検証前に予算を失う理由

「FDEとはAIで何ですか」という疑問に対し、最先端の技術者をアサインすれば新規事業が立ち上がると考えるのは誤りだ。FDE（Forward Deployed Engineer）は、顧客の現場に入り込んで課題を特定し、実装から運用定着までを主導する前線エンジニアを指す。この専門職をフル開発の要員として扱い、最初から完璧なシステムを作ろうとすれば、検証前に開発予算は底を突く。要件整理を怠り、作らない機能を決めないまま外注管理に丸投げする開発体制では、手戻り工数と確認待ち時間が増えるだけで、事業は一歩も進まない。

プロトタイプを最初から作り込みすぎる新規事業は、検証フェーズに入る前に予算を失って停滞する。多くの現場では、リソース不足を補うために「あれもこれも」と機能を盛り込んだMVP（Minimum Viable Product）を設計しがちだが、それは検証の引き延ばしに過ぎない。問題はツールの不足ではなく、検証すべき仮説を絞り込めていない設計の甘さにある。本稿では、fde aiを活用してプロトタイプの範囲を最小限に抑え、無駄な開発投資を削ぎ落として事業を前進させるための実務判断を提示する。

1.開発範囲を広げすぎる新規事業は、検証前に現場の運用が崩壊する

競合製品を意識するあまり、最初から多くの機能を盛り込んだプロトタイプを作る担当者は多い。しかし、多機能すぎるシステムは現場の運用を複雑にし、検証そのものを不可能にする。現場のスタッフは新しいツールの操作方法を覚えるだけで疲弊し、肝心の顧客価値を検証する余裕を失う。結果として、現場から「前のやり方の方が速い」と不満が噴出し、導入したシステムは使われなくなる。

この事態を避けるには、最初のプロトタイプで検証する対象を「顧客が最も価値を感じる1点」だけに絞り込む必要がある。あれもこれもと欲張る姿勢は、丁寧な開発に見えて、実際には現場への負担を増やしプロジェクトを破綻させる原因となる。運用が回らなくなってから機能を削るのでは、それまでに費やした開発費と時間がすべて無駄になる。

2.要件整理はAIに任せ、作らない機能の最終判断は人間が責任を持つ

プロトタイプの範囲を絞り込む際、要件整理のプロセスで生成AIを活用する。AIは競合製品の機能分析や、想定されるユーザーの行動シナリオから、必要な機能リストの「下書き」を瞬時に作成することに長けている。しかし、ここで最も重要なのは、AIが提案した機能リストから「何を作らないか」を決めることだ。この「作らない機能」の決定こそが、人間が責任を持つべき境界線となる。

要件整理をAIに丸投げした結果、一般的な機能がすべて盛り込まれた膨大な仕様書が出来上がり、外注管理の調整だけで数週間を浪費するケースが後を絶たない。AIに任せるべきなのは、比較材料の作成や整理などの補助作業までだ。新規事業の撤退判断や、どの機能を削ってリリースを早めるかという意思決定をAIに委ね、判断を先送りすることは、事業の失敗リスクを劇的に高める。人間が責任を持って「この機能は第1段階では作らない」と断言することが、プロジェクトのスピードを保つ唯一の方法だ。

3.プロトタイプ開発を外注管理に頼る前に、自社で検証すべき判断基準

新規事業の現場でよく見られる失敗は、自社に技術知識がないからと、要件整理が曖昧な状態で開発を外注することだ。外注先とのやり取りで「誰が確認したのか分からない」という状態が続くと、仕様の認識齟齬が発生し、手戻り工数が膨れ上がる。外注管理のコストを最小限に抑えるためには、外注する前に、自社内で「何を検証したいのか」という判断基準を明確にしておく必要がある。

この開発手法に向いているのは、検証したい仮説が1つに絞られており、そのために必要な最小限のデータ構成を自社で把握できている企業だ。一方で、向いていないのは「とりあえずシステムを作れば、後からアイデアが形になる」と考えている企業である。後者の場合、外注先に振り回され、開発予算を浪費しただけで何も検証できないままプロジェクトが終了する。FDEをチームに迎え入れる場合も、彼らの役割は「言われたものを作る」ことではなく、現場の課題を分解して最小のプロトタイプを設計することにある。

4.完璧なMVPを求めると、手戻り工数と確認待ち時間で予算は静かに消える

完璧なMVPを作ろうとすればするほど、開発プロセスにおける確認待ち時間と手戻り工数は増加する。新規事業において、最初に作ったプロトタイプがそのまま最終製品になることはない。顧客のフィードバックを得て、何度も作り直すことが前提だ。それにもかかわらず、初期段階でデザインや例外処理を作り込みすぎると、仕様変更が発生した際の手戻りが巨大な負債となってのしかかる。

プロトタイプ開発における優先事項は、綺麗なコードや美しいデザインではなく、仮説が正しいかどうかを1日でも早く確かめることだ。作り込みすぎたプロトタイプは、変更に対する心理的・物理的な抵抗を生み、結果として市場の変化や顧客の声に合わせた迅速なピボットを妨げる。未完成に見える状態であっても、コアとなる価値が伝わるのであれば、その状態で検証を開始すべきだ。

5.失敗する新規事業が陥る「全機能一斉開発」の罠と仮定計算

多くの新規事業が、人事や採用、営業などの業務プロセス全体を一気にシステム化しようとして失敗する。例えば、採用業務の改善において、求人票の作成、スカウト送信、書類選考、面接評価、オンボーディングのすべてをカバーするシステムを一度に開発しようとするパターンだ。これを行うと、各工程の連携部分で不具合が多発し、どこが原因で業務が止まっているのかすら特定できなくなる。

ここで、全機能一斉開発によって失われるコストを仮定計算してみよう。不要な機能を1つ追加するために、要件整理と外注管理の調整に1回あたり3時間かかり、それが週に3回発生するなら、月36時間もの時間が無駄な仕様調整だけに消えていく。さらに、仕様変更による手戻り工数が発生すれば、開発会社のエンジニアの人件費として数十万円から数百万円の追加費用が毎月発生する。この損失を放置することは、穴の空いたバケツに水を注ぎ続けるようなものだ。まずは「求人票の作成」や「面接評価の記録」など、1つの特定工程だけをAIで効率化し、その効果を検証してから次の工程へ広げるのが鉄則である。

6.最初の2週間で検証を終わらせるために、今すぐやめるべき過剰開発

新規事業の立ち上げを先送りし続けるほど、競合に先を越される商談機会損失や、無駄な調査に費やす人件費などの損失が積み上がる。これを防ぐためには、最初の2週間で検証すべき1つの重要業務を決め、それ以外の過剰開発を今すぐやめるべきだ。全社的なシステム導入を構想する前に、まずは1つの部署、あるいは1つの業務プロセスだけでプロトタイプを動かし、実際のデータを入力して運用が回るかをテストする。

弊社で新規事業支援のご相談を受ける場合、最初に確認するのは「このプロジェクトで最も確かめたい仮説は何か」という点である。私たちは、単に言われた通りのシステムを開発するのではなく、現場の業務フローを徹底的に整理し、どこで時間が失われているかを特定した上で、AIをどの部分に適用すべきかを提案する。プロトタイプの範囲を最小限に抑え、現場で実際に使われる形に落とし込むための運用設計から伴走する。まずは、次回の会議で「今回のプロトタイプから削るべき機能」を3つ決めることから始めてほしい。