PoC計画書・企画書に何を書くか

一般的なPoC計画書との相違点は、1の「判断目的」と13の「意思決定計画」が最初と最後で対になっていることです。この2項目があることで、計画書は作業一覧ではなく判断のための設計図になります。

ベンダー提案書やPoC計画書のレビューでは、13項目のうち13の意思決定計画と8の評価方法の欠落が最も高い頻度で観察されます。いずれも「終了後にどう判断するか」に関わる項目であり、ここが空白のまま承認された計画書も複数の案件で確認されています。

記載するのは「PoCで何をするか」ではなく、「PoCが終わったときに何を判断するか」です。

3つのKPIの選び方と歯止めの置き方はPoCの評価項目をどう決めるかで解説しています。

PoCだけでなく、その後の限定実運用（一部の業務・利用者で実際に使用し、効果と運用を確かめる段階）と本番まで、段階ごとに目的・範囲・次に進む条件を記載します。PoCの位置づけが全体の中で明確になります。

なお、正解が一つに定まらない出力を扱う場合や、AIが送信・更新・削除などの操作を自動で実行する場合は、ここに追加の条件が生じます。該当する評価項目はPoCの評価項目をどう決めるかの一覧にあります。

「重大な誤り0件」を合格条件にする場合は、何件のうち0件なのかを必ず併記します。件数が少なければ、0件という結果は判断材料になりません。評価データの要件はPoCの評価項目をどう決めるかで解説しています。

効果の金額換算については、算出した金額が損益のどの科目に届くかまで書けているかが分かれ目になります。「削減時間 × 人件費単価」で出した金額は、その時点では支出として減っていません。 浮いた時間の行き先を特定できた分だけを科目に落とします。

AIの場合は前提が異なります。MVPとしてリリースし、使いながら精度を高め、自動化できる範囲を広げていくのが基本の進み方であり、リリース後も相当な投資が継続します。この状態で、導入初期の効果見込みをそのまま5年に引き延ばして回収計画を作成すると、継続する投資が計算に入らないため、実態と乖離します。

回収期間そのものは、3年以上でも承認されることがあります。問題は長さではなく、長い計画ほど途中で前提が崩れても気づけないことです。利用量や単価が想定と変わっても、再計算されないまま進行します。

また、回収期間を示すこと自体が形式化し、後から実績と照らし合わせる担当者が存在しない状態も複数の案件で観察されます。回収の前提には、見直す時期をあらかじめ設定します。「1年後にこの前提が正しかったかを確認する」と計画書に記載しておくだけで、扱いが変わります。

許容を判断するのが誰かも、ここで決めます。 リスクの議論は、許容する判断者を決めないまま対策の設計から入ると終わりません。あわせて、撤退する場合に何が必要か（業務手順の復旧に要する人日、データの持ち出し形式、改修した既存システムの扱い）も見積もっておきます。

PoCの段階では詳細な運用設計は不要ですが、業務がどう変わるか、誰にどのような教育が必要か、利用状況を何で確認するかの初期方針を記載します。本番の運用を誰が担当するかについては、PoC開始前に運用部署の合意を取っておきます。

判定する人、判定日、そして判定4区分それぞれの条件を記載します。

この項目が決まっていない場合、PoCの結果を見てから判断基準を検討することになり、判断が長期化する原因になります。判定4区分の使い分けと、保留・再設計を例外扱いとする理由はPoCの評価項目をどう決めるかで解説しています。

測定項目の選び方はPoCの評価項目をどう決めるかに一覧があります。ここでは、選んだ項目を計画書の形式（項目＋合格条件）に落とした例を示します。

これらは、PoCの企画を第三者の立場で見直す際にも使用できる観点です。PoC全体の流れはAI PoCの進め方で解説しています。

PoCそのものの基本はAI PoCとは何かで解説しています。個別の疑問への短い回答はAI PoCのよくある質問にまとめています。