第2話｜PoC を始める前のスコープ設計と KPI

PoC が「永遠に PoC のまま」になる理由

AI の PoC は始めやすい一方で、終わらないことが多い領域です。永遠に PoC のままになる主因は、スコープが曖昧で、終わったかどうかを判定できないからです。

PoC を始める前に、次の 4 点をひとつずつ書面化します。

1. 1. 対象業務（誰の・どの作業）
2. 2. 比較対象（現状のやり方の数値）
3. 3. 終了条件（達成 or 撤退）
4. 4. 期間（最大 8 週まで）

期間を 8 週で切るのが要点です。長い PoC は中身が薄まります。8 週で答えが出ない検証は、対象が大きすぎるか、現状の数値が取れていません。スコープを切り直します。

対象業務を 1 つに絞る

PoC で複数の業務を同時に検証しようとすると、どの結果がどの業務由来かが分からなくなります。最初の PoC は 1 業務に絞ります。

絞り込みの基準は次の 3 点です。

• - 現状のやり方が言語化されている（手順書がある／フローが描ける）
• - 月間の作業時間か件数が測れている（ベースラインが取れる）
• - 担当者が 5 名以下（ばらつきが小さい）

この 3 点が揃わない業務は、PoC 以前にプロセス整理が必要な状態です。AI を入れる前にやることがある、と判断します。

比較対象は「現状の数値」を取ってから

PoC は AI 導入後の効果を測る場なので、AI を入れる前に現状の数値を 2 週間取ります。

• - 1 件あたりの所要時間
• - 月間の総処理件数
• - やり直し率（再修正・再対応の割合）
• - 担当者ごとのばらつき

この 4 点を取らずに PoC を始めると、終了時に「速くなった気がする」「楽になった気がする」しか言えなくなります。

終了条件を 3 段で書く

PoC の終了条件は、達成・継続検証・撤退の 3 段で書きます。

• - 達成：現状比で目標数値（例: 所要時間 30% 削減）をクリア → 本番昇格設計に進む
• - 継続検証：目標未達だが改善傾向あり → 8 週延長は最大 1 回まで、それ以上は撤退
• - 撤退：改善傾向が見えない／重大事故発生 → ツールを停止、学びを文書化

達成と撤退の間に「継続検証」を 1 段挟むのは、判断を急がないためです。ただし継続検証が永遠に続かないよう、延長は 1 回までで止めます。

KPI は 3 種類を必ず取る

PoC の KPI は、効率系・品質系・利用系の 3 種類を必ず取ります。

• - 効率系：所要時間、処理件数、削減工数
• - 品質系：誤回答率、再修正率、クレーム件数
• - 利用系：実際に AI を使った社員数、利用回数

効率系だけを見ると、品質が落ちていることに気づきません。品質系だけを見ると、実は誰も使っていないのに表面的な数値だけ良く見えます。3 種類を並べることで、PoC の実像が見えます。

PoC 中の運用ルール

PoC 期間中は、本番運用の縮小版でルールを回します。

• - 利用ログを毎日保存（誰が／いつ／何に使ったか）
• - 週次レビュー（30 分、4 人以内）
• - 失敗事例の即時記録（誤回答・操作ミス・誤解）

「PoC だから運用ルールは緩く」とすると、本番昇格時に運用が立ち上がっていない状態になります。最初から本番の縮小版で動かすのが、結果的に近道です。

次回予告

次話は、PoC が終わったあとの本番昇格判定を扱います。「達成しました」をどう判定するかを、組織として再現できる形にしていきます。

この回のまとめ：

• - PoC は対象 1 業務、期間 8 週で切る。
• - 始める前に 2 週間の現状数値を取る。
• - 終了条件は達成・継続検証・撤退の 3 段で書く。
• - KPI は効率系・品質系・利用系の 3 種類を並列で取る。
• - 運用ルールは本番の縮小版で最初から回す。