結論: PoCでは、技術が動くかだけでなく、業務上の目的、現行フローとの接続、終了時の判定を事前に決めます。この三点がないPoCが必ず失敗するという調査結果ではなく、判定不能を避けるための設計原則です。
一つ目：何を変えるPoCか
「AIを試す」だけでは、終了時に成功・継続・中止を判断できません。対象業務、現状値、期待する変化、変えてはいけない品質を定義します。
たとえば「月次決算の工数を30%削減する」という数字は、既存実績ではなく目標例です。実際の目標値は、現在の工数、差し戻し、誤り、繁忙期の変動を測って決めます。
PoC前に記録する項目は次の通りです。
- 対象業務と対象外業務
- 現在の所要時間、品質、差し戻し、担当人数
- PoCで変える工程と変えない工程
- 守るべき法令、契約、顧客説明、レビュー責任
- 成功とみなす指標、最低基準、測定期間
二つ目：実際の業務へどう接続するか
技術デモが動いても、入力データ、例外、承認者、出力先が日常業務と接続しなければ、本番利用の可否は分かりません。
試算表の要約を例にすると、架空データで動作を確認した後、次を検証します。
- どの形式のデータを誰が用意するか
- 顧客固有の会計方針や例外をどう渡すか
- 誤った要約や重要事項の欠落を誰が見つけるか
- 出力をどこへ保存し、誰が承認するか
- 顧客データを使う前に必要な契約・権限・ログがあるか
- 問題が起きた場合に止め、戻す方法があるか
情報システム担当、外部ベンダー、現場担当のいずれが主導する場合でも、必要な業務知識と判断責任が参加者に含まれているかを確認します。「ベンダーだけなら誰も使わない」と一律には断定しません。
三つ目：終了時に何を判断するか
PoC終了時の選択肢を先に決めます。
- 基準を満たし、安全要件も確認できたため、限定範囲で本番化する
- 基準未達だが原因と追加検証が明確なため、期間・範囲を限定して続ける
- 効果、安全性、維持費のいずれかが基準を満たさないため、終了する
判定には、実行時間だけでなく、準備、レビュー、差し戻し、教育、保守を含めます。利用率や顧客評価を使う場合は、測定方法と対象者を事前に決めます。
PoC開始前チェック
- 対象業務、対象データ、利用者が決まっている
- 現状の時間・品質・費用を測った
- 人が判断する工程と最終責任者が決まっている
- 契約、守秘義務、個人情報、権限、監査ログを確認した
- 成功・継続・中止の基準が数値または観察可能な条件で決まっている
- 問題時の停止・復旧方法がある
- 本番化する場合の運用者と維持費を見積もった
関連記事
本記事はShigyoAIの相談件数や、複数事務所で観測した失敗割合を示すものではありません。PoCの目標値と終了基準は、自所の実測値から決めてください。