PoC報告書の書き方 — 経営層に伝わるレポートの構成

PoC報告書を書いた。30ページ。技術構成図も入れた。テスト結果のスクリーンショットも貼った。経営層の反応は「で、これはやるべきなの？」だった。

この経験があるなら、報告書の設計を見直すべきだ。

PoC報告書の目的は「やったことの記録」ではない。経営層がGo/No-Goを判断するための材料を提示することだ。つまり、書くべきは「やったこと」ではなく「わかったこと」。そして「わかったこと」から導かれる「次にやるべきこと」だ。

この記事では、経営層に伝わるPoC報告書の構成と、結果の見せ方を具体的に書く。

PoC報告書の6つの構成要素

経営層が判断できる報告書には、6つの要素がある。この順番で書く。

1. エグゼクティブサマリー

報告書の最初に、結論を書く。1ページ、できれば半ページ以内。

含めるべき内容:

• 検証した仮説（1文）
• 結果の要約（成功基準に対してどうだったか）
• 推奨する判断（Go / No-Go / Pivot）

経営層は報告書を最初から最後まで読まない。最初の半ページで判断の方向性を掴み、残りのページで根拠を確認する。だから結論が先だ。

NG: 「本報告書は、○月○日から△月△日にかけて実施したPoCの結果をまとめたものです」 OK: 「検証の結果、ターゲット顧客の課題存在は確認できたが、想定した解決策への支払い意欲は基準未達。ピボットを推奨する」

→ 新規事業のプレゼン — 経営層に刺さる3つの構成パターン

2. 検証の目的と仮説

「このPoCで何を確かめようとしたのか」を明確にする。

書くべきは以下の3つだ。

• 検証仮説: 何が正しいと仮定したか
• 成功基準: どうなったらGoと判断するか（数値）
• スコープ: 今回のPoCで検証する範囲と、検証しない範囲

ここで重要なのは、成功基準が「事前に設定されたもの」であることを明記すること。結果を見てから基準を作ったのではないと示すことで、報告書の信頼性が上がる。

→ PoCの成功基準の設定方法 — 曖昧な「成功」を数値で定義する

3. 実施内容

何を、誰に、どのように検証したか。ただし、ここは簡潔に書く。

書くべきこと:

• 検証手法（インタビュー、プロトタイプテスト、LP検証など）
• 対象者のプロフィール（人数、属性、選定理由）
• 期間

書かなくていいこと:

• 技術スタックの詳細
• 開発プロセスの日次レポート
• プロトタイプの画面遷移図すべて

実施内容は「方法論の妥当性」を確認するための章だ。経営層が知りたいのは「ちゃんとした相手に、ちゃんとした方法で聞いたのか」であって、技術的な工程ではない。

4. 結果（定量・定性）

ここが報告書の核心だ。結果の見せ方は後述するが、原則は「定量データと定性データの組み合わせ」。

定量データ:

• 成功基準に対する達成状況（数値の対比で示す）
• 例: 「課題確認率：目標60%以上 → 結果80%（5名中4名）」

定性データ:

• 顧客の生の声（具体的な発言の引用）
• 例: 「『毎月この作業に3日かけている。なくせるなら年間100万円は出す』——A社 部長」

数字だけでは温度感が伝わらない。声だけでは客観性がない。両方を組み合わせて初めて、経営層は「これは本物だ」と感じる。

5. 考察と学び

結果から何が言えるか。ここでは「データの解釈」を書く。

書くべきこと:

• 仮説は正しかったのか、外れたのか
• 想定と異なった点は何か、なぜそうなったのか
• 今回の検証で新たに見えた仮説や機会

書かないこと:

• 感想（「手応えを感じた」は考察ではない）
• 言い訳（「サンプル数が少ないため断定はできないが…」）

サンプル数が少ないなら、少ないなりに言い切る。「5名中4名が課題を確認。母数は小さいが、課題の存在を示す強いシグナルと判断する」。言い切ったうえで限界を付記する方が、先に言い訳するより信頼される。

6. 推奨アクション

報告書の最後は「次に何をすべきか」で締める。

含めるべき内容:

• Go / No-Go / Pivot の推奨判断
• 次のアクションの具体的内容（何を、いつまでに、いくらで）
• 残存リスク（今回検証できなかった仮説）

NG: 「引き続き検討を進めることを推奨します」 OK: 「次フェーズとして3社でのβテストを推奨。予算300万円、期間6週間。支払い意欲の検証を主目的とし、有料契約1社以上をGo基準とする」

→ PoCの進め方 — 目的設定から成果報告までの全手順

結果の見せ方 — データと声を組み合わせる

経営層に刺さる結果の見せ方には型がある。数字で全体像を示し、声で温度感を伝える。

型: サマリーテーブル＋顧客の声

まず成功基準に対する結果を一覧で示す。

次に、各項目を裏付ける顧客の声を添える。

「在庫管理に毎月40時間かけている。自動化できるなら月5万円は出す」——B社 生産管理部長

「面白いとは思うが、今の予算では難しい。来期なら検討できる」——C社 経営企画

数字で「何が達成できて何ができなかったか」を客観的に示し、声で「なぜそうなったのか」の文脈を補う。この組み合わせが、経営層の判断を動かす。

やってはいけない書き方

技術詳細に偏る

プロトタイプの技術構成、API設計、インフラ構成図。エンジニアは書きたくなるが、経営層はそこを見ていない。

技術詳細は別紙にまとめ、報告書本体では「技術的に実現可能であることを確認」の1行で済ませる。経営層が判断に必要な情報は「顧客が欲しいか」「事業として成り立つか」だ。

→ PoCと仮説検証の違い — 新規事業で本当に必要な検証とは

結論を先送りにする

「今回の結果を踏まえ、引き続き検討を進めたい」。これは結論ではない。先送りだ。

報告書を書く人間が判断を示さなければ、経営層も判断を出せない。「自分はGoを推奨する。理由はこの3つ」と言い切る。間違っていたら修正すればいい。判断を出さない報告書は、次のPoC疲れを生むだけだ。

→ PoCで終わらない。PoC疲れの3つの原因と処方箋

「成功」を演出する

都合の良いデータだけを並べ、ネガティブな反応を省く。経営層はこれを見抜く。

ネガティブな結果も正直に書き、その解釈と対策を添える方が、報告書の信頼性は格段に上がる。「5名中1名は既存ツールで十分と回答。ただし当該企業は従業員30名でターゲット外」。隠すより、解釈を添える方が強い。

まとめ

PoC報告書は「やったこと」の記録ではなく、「わかったこと」と「次にやるべきこと」を伝えるための文書だ。

6つの構成で書く。

1. エグゼクティブサマリー — 結論を先に。半ページ以内
2. 検証の目的と仮説 — 何を確かめようとしたか。成功基準を明記
3. 実施内容 — 簡潔に。技術詳細は別紙
4. 結果 — 定量データと顧客の声を組み合わせる
5. 考察と学び — データの解釈。感想ではなく分析
6. 推奨アクション — Go/No-Go/Pivotを言い切る。次の具体策まで書く

報告書を書く側が判断を示さなければ、読む側も判断を出せない。伝わる報告書とは、経営層に「判断するための根拠」を過不足なく渡す報告書だ。

LITMUSは、新規事業の検証に特化したスタジオです。PoCの設計から検証の実施、経営層向けの判断レポート作成まで、「やりっぱなし」にしない検証を一気通貫で支援します。

→ LITMUS — 事業検証スタジオ