— TEMPLATE
Web3 PoC設計テンプレート
「PoCで終わらせない」ための仮説・KPI・撤退基準の整理シート
PoC（Proof of Concept・概念実証）を始める前に、社内で整理しておくべき7要素を、記入式テンプレートとしてまとめた資料です。仮説・指標・KPI・スコープ・体制・期間・撤退基準の7観点を埋めることで、PoCの目的が明確になり、本番導入への接続を見通せる構成にしています。
Netsujo株式会社のPoC支援の現場で使っているフレームを公開しています。社内稟議・発注先との要件すり合わせ・投資家向けピッチ資料の起点としてご活用ください。
— 01
PoCの定義と本資料の使い方
PoCの目的は「動くものを作ること」ではなく、「次の判断に必要な材料を得ること」です。本番導入に進むのか、見直すのか、中止するのかを冷静に判断できる状態に至ることが、PoCの成功条件です。
このテンプレートは7章構成で、PoC開始前に整理すべき項目を順に記入する形式です。
- 第2章: 検証仮説の言語化（3つ以内に絞る）
- 第3章: 検証指標とKPIの設定
- 第4章: スコープと成果物の定義
- 第5章: 体制設計（発注側 / 開発側）
- 第6章: 期間とマイルストーン
- 第7章: 撤退基準と次フェーズ判断
要点
- ・PoCの成功は「次の判断材料が得られた状態」
- ・7要素を記入式で整理
- ・開発会社との要件すり合わせ・社内稟議でも使える
— 02
検証仮説の言語化（記入シート1）
PoCで検証する仮説は3つ以内に絞り込むことが原則です。仮説が4つ以上ある場合、PoC期間内で十分な検証ができず、結論が曖昧になります。
仮説の書き方
各仮説は次の文型で記入します。
〜にWeb3を適用すると、〜が改善される。理由は〜だから。
例：
- ・仮説A: 観光地のスタンプラリーにNFTを適用すると、来訪者の再訪率が改善される。理由は、NFT保有者にのみ次回特典を付与でき、保有が継続インセンティブとして機能するから。
- ・仮説B: 自社の社員証にDID/VCを適用すると、人事ローテーション時の権限管理工数が改善される。理由は、職位の変更がVC再発行で完了し、複数システムの個別変更が不要になるから。
「Web3でなければ解けない仮説」の確認
- 1. この仮説は、通常のデータベースで実現できないか？
- 2. 第三者検証可能性が事業上必要か？
- 3. 複数組織での記録共有が必須か？
記入シート
| # | 仮説 | Web3でなければ解けない理由 |
|---|---|---|
| A | ||
| B | ||
| C |
要点
- ・仮説は3つ以内
- ・「Web3でなければ解けない」を必ず確認
- ・Web2で代替可能なら、まず通常検証も検討
— 03
検証指標とKPIの設定（記入シート2）
仮説を3つの観点で評価する指標を設定します。技術的実現性、ユーザー価値、事業性の3観点で、それぞれ定量化可能なKPIに落とし込みます。
3観点の指標例
技術的実現性
- ・平均実行時間（秒）
- ・ガス代総額
- ・システム稼働率
- ・スループット（TPS）
ユーザー価値
- ・利用継続率
- ・タスク完了時間
- ・ユーザー満足度
- ・ウォレット保有率
事業性
- ・ユーザー獲得コスト
- ・LTV / CAC比
- ・ROI試算
- ・競合優位性
KPI閾値の事前合意
KPIの「合格ライン」をPoC開始前に決めることで、結果の解釈ブレを防ぎます。たとえば「利用継続率」のKPIに対し、「20%未満ならNoGo」「20-40%なら見直し」「40%以上なら本番進行」と段階的な閾値を設定します。
記入シート
| 観点 | KPI | 測定方法 | NoGo閾値 | 見直し閾値 | GO閾値 |
|---|---|---|---|---|---|
| 技術的実現性 | |||||
| ユーザー価値 | |||||
| 事業性 |
要点
- ・3観点（技術 / ユーザー / 事業）すべてを設定
- ・KPI閾値はPoC開始前に合意
- ・NoGo / 見直し / Go の3段階で結果解釈をブレさせない
— 04
スコープと成果物の定義（記入シート3）
「PoCに含めるもの」と「含めないもの」を明文化することで、開発側との認識齟齬を防ぎます。
標準的なPoC成果物
- 1. 動作するプロトタイプ（テストネットまたは限定環境）
- 2. ソースコード一式（GitHubリポジトリ）
- 3. 検証結果レポート（KPI測定値・判断推奨）
- 4. 技術的実現性レビュー（スケール時の制約・本番要件）
- 5. 経営層向けサマリ（A4 1-2枚）
- 6. 次フェーズ提案書（本番進行する場合）
記入シート
| 項目 | 含める | 含めない |
|---|---|---|
| ユーザー登録機能 | ||
| トランザクション処理 | ||
| 管理画面 | ||
| 外部システム連携 | ||
| セキュリティ対応 | ||
| ドキュメント整備 |
要点
- ・含めない項目を明示することがスコープ管理の本質
- ・成果物はPoC開始前に合意
- ・「動くこと」だけでなく「次の判断に使える形」が成果物
— 05
体制設計（記入シート4）
PoC期間中の体制を発注側・開発側の両面で整理します。曖昧な体制は意思決定の遅延を招きます。
記入シート
| 役割 | 発注側 担当者 | 開発側 担当者 |
|---|---|---|
| PM・進捗管理 | ||
| 業務要件 | ||
| 技術判断 | ||
| 法務・規制 | ||
| 監査連携 | ||
| ユーザーテスト |
定例ミーティング
- ・週次定例: PoC期間中、双方PMが必ず出席（30〜60分）
- ・マイルストーン定例: フェーズ切替時に意思決定者が出席（60〜90分）
- ・緊急エスカレーション: SlackやChatworkで24時間以内応答
要点
- ・発注側・開発側で対をなす体制
- ・週次定例＋マイルストーン定例の二層構造
- ・緊急時のエスカレーションパスを事前に決める
— 06
期間とマイルストーン（記入シート5）
PoC期間は4〜12週間が標準です。短すぎると検証が浅くなり、長すぎると「PoCのためのPoC」になりがちです。
記入シート
| Phase | 期間目安 | 開始日 | 終了日 | 判定会議日 | 主要マイルストーン |
|---|---|---|---|---|---|
| Phase 1 | 1〜2週 | 仮説・KPI確定 | |||
| Phase 2 | 2〜6週 | プロトタイプ動作確認 | |||
| Phase 3 | 1〜2週 | ユーザーテスト完了 | |||
| Phase 4 | 1週 | 判断レポート完成 |
要点
- ・標準4〜12週、4フェーズ構造
- ・各フェーズに判定会議を設けて意思決定を分散
- ・「PoCのためのPoC」を避けるため期間上限を設定
— 07
撤退基準と次フェーズ判断（記入シート6）
PoCの最も重要な設計が「撤退基準」です。撤退判断を事前合意することで、サンクコスト効果から逃れ、損失を限定できます。
記入シート
| 撤退基準 | 閾値 | 判定方法 | 判定者 |
|---|---|---|---|
| KPI未達 | NoGo閾値2項目以上未達 | ||
| 期日超過 | PoC期間 ___週 超過 | ||
| 予算超過 | 当初予算150%超 | ||
| 外部要因 |
次フェーズ判断のチェックリスト
本番進行を判断する場合、以下をすべて満たしていることを確認します。
- ・3観点（技術 / ユーザー / 事業）のKPIすべてがGo閾値達成
- ・本番運用部署・運用予算の確保見込みが立っている
- ・法務・コンプライアンスの最終確認が完了
- ・セキュリティ監査の発注先・予算が確定
- ・経営層の本番予算承認の見通しが立っている
要点
- ・撤退基準の事前合意でサンクコスト効果を防ぐ
- ・撤退時も知見化することで投資は無駄にならない
- ・本番進行の判断は5項目すべての合格が条件
— 08
Netsujoへのご相談
このテンプレートを単独利用することも、Netsujo株式会社のPoC支援で伴走利用することも両方を想定しています。「仮説の絞り込みがうまくいかない」「KPI閾値の妥当性に自信が持てない」といった段階での相談を受け付けています。
支援の標準範囲は以下です。
- ・テンプレート記入の伴走（社内インタビュー・論点整理）
- ・PoC設計レポートの作成
- ・開発会社選定・RFP作成サポート
- ・PoC実施期間中の意思決定支援
- ・本番進行判断のレビュー