FDE型案件、最初に何を決める？業務整理から本番運用までの成果物

「まずはAIで何ができるか、試してみましょう」。そこから始めるとしても、誰のどの仕事を変えるのか、試した結果を誰が判断するのかは決めておきたいところです。動くものができても、顧客と提供側が違うゴールを見ていれば、次に進めません。

FDE型支援を提供する事業者に必要なのは、工程名を増やすことより、節目ごとの合意を残すこと。本記事では、業務整理から運用移管までを、「始める前」「試した後」「引き継ぐ前」の3つの合意で整理します。

以下の工程・成果物は、inovieが提案する案件設計の一例です。特定企業の標準工程や、実際の顧客案件・支援成果を紹介するものではありません。

まず、何をFDE型と呼ぶか

inovieでは、自社の反復可能なプロダクトやプラットフォームを顧客現場へ適用し、その知見を製品へ戻す構造を、本来のFDEの重要な条件と捉えています。Palantirも、現場に近いエンジニアとコア開発チームが連携し、フィードバックを製品開発へつなげる方法として説明しています。出典：Palantir Architecture Center

一方、ここで扱うのは、課題整理から実装・運用までをつなぐ、より広い意味でのFDE型案件です。自社製品を持たない会社にも使える進め方ですが、これを採用するだけで本来のFDEになるわけではありません。定義の違いは、FDEに自社プロダクトは必要かで詳しく整理しています。

図の要点をテキストで読む

案件を進める3つの合意。対象業務と完了条件、評価結果と残るリスク、運用担当と止め方を決め、各段階の知見を共通資産へ戻す。

案件設計の一例。工程を一方向に進める図ではなく、続行・見直し・停止を判断する節目を示しています。画像を押すと拡大できます。

始める前：対象業務と、終わったと言える条件を揃える

「問い合わせ対応を効率化する」だけでは、範囲を決めたことになりません。受付、調査、回答文の作成、承認、送信。そのどこを変えるのかで、必要なデータも権限も違います。

GOV.UKのサービス設計ガイドも、構築に取り組む前に問題と制約を理解することを重視しています。ただし、そこで示される行政サービスの工程を、そのままFDE型案件へ当てはめる必要はありません。出典：How the discovery phase works

まずは、次のような一枚を顧客と一緒に埋めます。ここでは、問い合わせへの回答案を作る仕組みを想定します。

「精度を上げる」では、評価する人によって合否が変わります。どの質問群で、どんな誤りを許容せず、何を確認できたら次に進むのかを具体化します。数値を置く場合も、現状の測定結果と業務への影響から決めます。借りてきた正答率だけで、完了条件を埋めないことです。

この段階の成果物は、業務の流れ、対象・対象外、データと権限、評価の約束。すべてを長い資料にする必要はありません。未確認の欄には、確認する人と期限を添えます。

試した後：動いた事実と、業務で使える判断を分ける

デモで一度よい回答が出た。それは動作を確かめた記録であって、業務で使えるという合意ではありません。普段の質問だけでなく、資料が古い場合、答えがない場合、複数の規定が食い違う場合も確かめます。

評価記録には、少なくとも入力、期待する対応、実際の出力、参照元、担当者の修正、未解決の理由を残します。モデルや設定の版も記録すれば、変更前後を比べやすくなります。調整に使った例だけで評価せず、別に残した確認用の例でも試します。

ここでの成果物は「成功したデモ」ではなく、どの条件なら使え、どの条件では使わないかが分かる評価結果です。

評価会で決めること

• 続行：合意した条件を満たした範囲に限って、本番化の準備へ進む。
• 見直し：FAQの整備や対象業務の限定が必要なら、先に範囲を組み直す。
• 停止：必要な情報を使えない、確認負担が価値を上回るなど、続ける理由が弱い場合は止める。

残る問題を「運用でカバー」とだけ書くのは避けます。誰が、どの画面で、何を見て判断するのか。確認役を置くなら、その作業も含めて成り立つかを評価します。

引き継ぐ前：担当者と、止め方まで渡す

本番へ配置できることと、顧客が運用できることは別です。FAQを更新したあと誰が再評価するのか。生成処理が失敗したら、普段の対応へどう戻すのか。問い合わせ先が開発担当者一人の記憶にしかなければ、まだ引き継ぎは終わっていません。

運用移管に残す成果物の例

資料を渡して終えるのではなく、顧客の運用担当者が、開発者の口頭補足なしで停止や切替を試せるか確認します。できなかった箇所が、手順を直す場所になります。

顧客に残すものと、自社で育てるものを分ける

案件が終わったあと、顧客用のコードと資料だけが残るのか。次の案件にも持ち込める評価方法や接続部品が増えるのか。この違いが、FDE型の事業をどう育てるかにつながります。

たとえば「FAQが見つからないときは回答を保留する」という評価観点は、別の案件でも検討できます。一方、顧客の実データ、社内ルール、固有の接続情報まで共通資産へ移す話ではありません。再利用の可否は合意した権利・機密・利用条件を確認し、一般化できる知見と分けて管理します。

再利用候補には、使える条件、使えない条件、検証方法、保守する人を添えます。部品を保存しただけで「基盤ができた」とは扱わず、次の案件で何を確かめるかまで残しておきます。

最初の打ち合わせに持っていくもの

最初から全工程を精密に決める必要はありません。対象業務を一つ選び、「今回はしないこと」「評価する人」「使えなかったときの戻し方」を空欄のままにしない。それだけでも、試作のあとに何を話すべきかが明確になります。

工程表を完成させるより先に、次の判断を一緒にできる状態を作る。そのための成果物として、業務整理、評価、運用手順を設計していきます。

FDEの役割そのものを整理したい方は、FDEとは何かを解説した記事もご覧ください。

出典確認日：2026年9月8日。イラスト・解説図は本記事用にAI生成し、内容を確認したものです。