FDEを受け入れる自社の役割分担と、AIの成果の測り方

FDE型のAI支援を受け入れるとき、自社側が受け持つのは、どの業務から手を付けて何を本番に出すかの決定、現場の業務とデータの提供、出来たものが業務で使えるかの検証、の3つです。作ることはFDEに任せられますが、この3つは自社にしか持てません。成果は作った物の数ではなく、対象業務の1件あたりの時間が前後でどれだけ減ったかと、誰の仕事が何に変わったかで測ります。

FDEを受け入れる自社は、何を受け持つのか

FDEを受け入れる自社が持つのは、決定・情報の提供・検証の3つです。FDEを提供しているAtlassianも、顧客に用意してもらうものとして、解決すべき明確な課題がある価値の高いワークフロー、ワークフローを理解してFDEと連携できる専任のパートナー、ソリューションを構築・テスト・デプロイするための適切なシステムと環境へのアクセス、の3つを挙げています。課題のある業務を選ぶのは決定、業務を分かっている担当者は情報の提供、システムと環境は作ったものを試す検証の土台にあたります。

Atlassianは自社のFDEの関わりを「共同エンジニアリングのパートナーシップ」と説明しています。提供する側の説明でも、FDEが自社だけで完結する形にはなっていません。

FDEはIPAの資料で定められた言葉ではありませんが、要件を決めながら進める委託の公的な型では、同じ線の引き方がされています。IPAのアジャイル開発版モデル契約では、プロダクトの方向と内容に責任を持つプロダクトオーナー（PO）をユーザ企業（発注側）が選び、POは開発チームが必要とする情報や意思決定を適時に出します。ベンダ企業（受注側）が受け持つのは、助言や技術的なリスクの説明です。IPAはあわせて、発注側には主体的かつ積極的な関与が必要で、相応の負担を伴うと書いています。

つまり、FDEに任せられるのは作ること・つなぐこと・うまくいったやり方を手順にまとめることで、何を作るかを決めること、業務の中身を出すこと、使えるかを確かめることは自社に残ります。FDE型が自社の案件に合うか、契約が請負か準委任かといった話は、FDEとAIの受託開発・常駐SEの違いを整理した記事で扱っています。

観察から移管まで、段ごとに誰が何をするか

観察と設計の段では自社が対象の業務と本番に出す範囲を決め、実装の段ではFDEが作って自社が業務で試し、移管の段ではFDEが手順にまとめて自社が自分で回せるかを確かめます。観察・設計・実装・移管の4段は、提供する側の説明を受け入れる側から読み替えた整理で、どこかの会社が定めた区切りではありません。

提供する側の原文では、段の名前は次のとおりです。Atlassianは自社のFDEを4つのフェーズで説明し、その名前を「発見する」「ビルド」「導入」「価値」としています。これは提供する側の段の区切りなので、受け入れる側が持つことは表の右の列のように自分で書き出しておく必要があります。

揉めやすいのは段の境目

1つ目の境目は、観察から設計へ移るときです。FDEが候補を挙げても、自社が対象の業務を1つに決めなければ、設計は候補の数だけ広がります。どの業務から手を付けるかは、FDEに聞かれて答えるものではなく、自社が決めて渡すものです。

2つ目の境目は、実装から移管へ移るときです。作ったものが業務で使えるかを誰が確かめるかを決めていないと、FDEは作り終えたと考え、現場はまだ使えないと考え、そのまま移管の段に入ります。実装の段に入る時点で、検証をする担当者の名前を決めておきます。

始まる前に、自社は誰を出し何を用意するか

FDEを受け入れる自社側は、始まる前に何を用意するか。決める人・業務の担当者・システムの担当者の3人と、対象の業務1つ、今の1件あたりの時間の記録、触ってよいデータと環境の範囲、の3つです。

仮の場面として、FDEが初日に来て「どの業務から見ますか」と聞いたとき、社内の誰も答えられない状況を考えます。この時点で止まるのは、FDEの腕ではなく、決める人と対象の業務が決まっていないことが原因です。下の表の右の列に、自社の名前を入れてから初日を迎えます。

用意するものの1つ目は、対象の業務1つです。Atlassianの言う「解決すべき明確な課題がある」業務、つまり何が困っているかを一文で言える業務を選びます。2つ目は、その業務の今の1件あたりの時間の記録です。次の節で使う削減時間の式の前提になり、始まった後では取れません。3つ目は、FDEが触ってよいデータと環境の範囲です。システムの担当者が、本番のデータを使うのか、試すための環境を別に用意するのかを先に決めておくと、観察の段で待ちが出ません。

IPAの契約前チェックリストで確かめる

IPAのアジャイル開発版モデル契約には、契約の前に発注側が確かめる項目があります。FDEを受け入れるときに特に関わるのは、ユーザ企業とベンダ企業の役割分担を理解しているか、適切なプロダクトオーナーを選任し権限委譲ができるか、の2つです。決める人の名前が表に入っていても、その人が対象の業務や本番に出す範囲をその場で決められないなら、2つ目の項目は満たしていません。

FDE型の支援の成果は、何で測ればいいか

FDE型の支援の成果は、作った物の数ではなく、対象業務の1件あたりの時間がどれだけ減ったかと、誰の仕事が何に変わったかの2つで測ります。

削減時間＝対象業務の件数 ×（前の1件あたりの時間 − 後の1件あたりの時間）

この2つの物差しは、提供する側の説明とも向きが同じです。Atlassianは、何を作ったか（アウトプット）ではなく、顧客のビジネスに何をもたらしたか（アウトカム）で見るとし、その物差しとしてコスト・スピード・収益・リーチなど顧客にとって大事な指標を挙げています。

仮に、対象の業務が月200件あり、1件あたりの時間が15分から9分になったとすると、削減時間は200×6で月1,200分、つまり月20時間です。ここで要るのは前の15分の記録で、これが無いと後の9分だけがあっても差が出せません。件数も、同じ期間・同じ数え方でそろえます。

誰の仕事が何に変わったかの記録欄

時間だけでは、浮いた時間が何に使われたかが分かりません。もう1つの物差しとして、担当者ごとに次の欄を埋めます。

作った仕組みの数、打ち合わせの回数、試した件数は物差しにしません。どれも作った物（アウトプット）の側の数で、業務が変わったかは表しません。

移管のあと、自社に何が残っていればよいか

FDEが抜けたあとも回るために自社に残っていてほしいのは、動かし方の手順書と運用の決まり、検証を自社の担当者が自分で回せること、削減時間を測り続ける記録、の3つです。

1つ目について、Atlassianは導入の段階で、定着させて維持するためのガバナンスとプレイブックを渡すと説明しています。移管の段の終わりに、この手順書と運用の決まりが自社の担当者の手元にあるか、FDEの説明なしで読めるかを確かめます。

2つ目は、分担表の移管の行の「自社の担当者だけで回せるか」の検証です。FDEがいる間に、業務の担当者が1回は自分だけで最初から最後まで回し、詰まった所を手順書に足しておきます。3つ目は、前の節の記録欄を移管の後も同じ数え方で埋め続けることです。本番で使われなくなれば、記録の件数に表れます。

作ったものを本番に上げてよいか、止める条件や見張り方をどう決めるかは、AIのPoCを本番へ移行してよいかの条件をまとめた記事で整理しています。手順書や運用の決まりを完了の条件として契約にどう書くかは、前に挙げたFDEと受託開発の違いの記事が受け持ちます。

公開日：2026年10月