現状の測定を先に行う
自動化前の時間、確認回数、誤り、例外の件数を測ります。比較する期間や業務条件が違うと、改善したように見えても原因が別にあります。繁忙期や特殊な案件を含むかを記録し、検証の対象範囲を明示します。
平均だけで合格させない
通常の入力では速くても、失敗時に長い修正が必要なら総負担は減らない場合があります。処理時間、失敗率、人が確認する時間を一緒に見ます。利用部門が受け入れられる品質と、開発側が測る性能を結び付けます。
条件付きの判断を用意する
継続、対象を限定して継続、中止のように結果ごとの行動を準備します。基準値は案件の業務条件に合わせて決め、一般的な数値をそのまま採用しません。判断者、必要な証拠、会議日を契約や実施計画と合わせます。
報告書の最小構成
前提、比較条件、結果、例外、追加費用、残るリスクを整理します。次の開発に必要な作業と予算を付けることで、PoC報告が次の意思決定へつながります。
参考資料と編集について
新規事業.com の関連ナレッジ ↗をもとに、Otsumuが検証・実装・運用の観点から再編集しました。制度・仕様・サービスの現況は、各提供元の最新情報をご確認ください。
編集：Otsumu株式会社 ／ 編集日