PoC報告書に何を書くべきか

PoCの報告書は、「やったこと」と「できたこと」を並べた資料になりがちです。画面のスクリーンショットが並び、精度の数字が載り、最後に「一定の有効性が確認された」と書かれる。この形式の報告書は、読んだ人が何も判断できません。

報告書の目的は、検証の成果を見せることではなく、次の判断を下せる状態にすることです。そのために最も重要なのは、できなかったことと、その理由を厚く書くことです。本記事では、判断に使える報告書を作る手順を整理します。

誰が読むのかを先に決める

手順に入る前に、前提を一つ確認します。PoC報告書の読み手は、本番化の予算を決める人です。技術部門のレビューではありません。

この人が知りたいのは、「やるか、やらないか、条件付きでやるか」と、「やるならいくらで、誰が、いつまでに」です。モデルの選定理由やアーキテクチャの詳細は、この判断に直接効く部分だけを残し、あとは別添にまわします。

以下の手順は、この読み手を想定しています。

手順1: 結論と次の一手を冒頭に書く

報告書の1ページ目に、次の三行を書きます。

• 検証の結論（本番化を推奨する／推奨しない／条件付きで推奨する）
• その理由を一文で
• 推奨する次の一手（何を、どの範囲で、いつまでに）

最後まで読まないと結論が分からない報告書は、多くの場合最後まで読まれません。冒頭に結論を置くと、以降の本文は「その結論の根拠」として読まれ、理解が速くなります。

「条件付きで推奨する」を選ぶ場合、条件を具体的に書いてください。「精度の改善が必要」ではなく、「入力フォーマットを3種類に統一できるなら推奨する」のように、誰かが実行できる形にします。

手順2: 検証した条件を再現できる形で書く

次に、何をどう試したかを書きます。ここは事実の記述なので、簡潔で構いませんが、次の項目は省かないでください。

• 使用したデータ（出所、件数、期間、どのような偏りがあるか）
• 使用したAIサービスと設定（サービス名、モデル、主要な設定値）
• 検証の期間と、実際に手を動かした人
• 業務のどの範囲を対象としたか

この記述が抜けていると、報告の数字が何を意味するのか分かりません。特にデータの偏りは重要です。「過去3か月の問い合わせ200件。繁忙期を含まない」と書いてあるだけで、読み手は結果を割り引いて読めます。

手順3: できたことは短く書く

うまくいったことは、事実を短く書きます。詳しく書きたくなる部分ですが、判断材料としての価値は低いところです。

「問い合わせの一次分類を、人の判断と8割程度一致する水準で自動化できた」といった記述に、判断の根拠となる数字を一つ二つ添える程度で足ります。スクリーンショットは、読み手が動くものを見ていない場合に一枚あれば十分です。

手順4: できなかったことを原因つきで列挙する

ここが報告書の中心です。分量の目安として、手順3の2倍から3倍を割いてください。

できなかったことは、次の形式で一件ずつ書きます。

原因が分からないまま終わった項目もあるはずです。その場合は「原因未特定」と正直に書き、切り分けに必要な追加作業の見込みを添えてください。分からないことを隠した報告書は、本番化の途中で同じ問題が再燃したときに、信頼ごと失います。

手順5: 原因を回避可能か不可能かに分類する

手順4で挙げた原因を、次の三つに分類します。この分類が、報告書全体で最も判断に効く部分です。

• 回避できる（技術で）: 処理の追加、入力の検証、人による確認の組み込みなどで対処できる。費用と期間の見込みを添える
• 回避できる（業務で）: 入力フォーマットの統一、記入ルールの整備など、業務側の変更で対処できる。誰が何を変える必要があるかを添える
• 回避できない: 対象業務の性質上、現在の技術では許容水準に届かない

三つ目に該当する項目が、業務の中核に関わるものであれば、結論は「推奨しない」になります。これは失敗の報告ではなく、投資を止められたという成果です。二つ目が多い場合は、システムの前に業務のルールを整えるほうが先だという結論になります。

手順6: 本番化した場合の費用と体制を概算する

PoCの段階で正確な見積もりは出せませんが、桁は出せます。次の三つを書いてください。

• 開発にかかる費用と期間の見込み（幅を持たせて構いません）
• 運用にかかる月額の概算（AIサービスの利用料を、一件あたりの費用×想定件数で試算）
• 運用に必要な人（誰が結果を確認し、誰が異常時に対応するか）

三つ目が抜けた報告書は多いのですが、ここが決裁の場で必ず聞かれます。AIを組み込んだ機能は、出力を確認する人が必要になることが一般的です。「全自動で人手が不要」と書くと、その前提が崩れた瞬間に計画全体が揺らぎます。

手順7: 未検証の論点を残課題として書く

最後に、今回のPoCでは確かめられなかったことを列挙します。

• 処理量が増えたときの応答速度
• 繁忙期のデータでの挙動
• 既存システムとの接続
• 現場の担当者が日常業務の中で使い続けるか

これを書くと報告が弱く見えると感じるかもしれませんが、逆です。範囲を明示した報告は信用されます。むしろ、検証していないことを検証したかのように書いた報告書が、本番化の後に一番大きな手戻りを生みます。

書きにくいことを書いた報告書が、次を動かす

PoC報告書の質は、都合の悪いことがどれだけ書かれているかで決まります。できなかったこと、原因が分からなかったこと、確かめられなかったこと。これらを原因と分類つきで書いた報告書は、読み手が自分で判断を下せる文書になります。

逆に、良い結果だけを並べた報告書は、読み手に判断させず、「もう少し検討します」という先送りを生みます。PoC止まりになる7つのパターンで挙げた行き詰まりの多くは、報告書の書き方でも防げるものです。

弊社がAI活用開発で検証をご一緒する場合も、報告では達成できなかった点とその原因の分類に最も時間をかけています。判断を止めないことが、検証の目的だからです。お問い合わせからご相談ください。オンラインで全国対応しており、ご相談・お見積りは無料です。