The_PoC_Playbook

概念実証を「証明」で最後まで回す PoC（Proof of Concept）実務向け・全体工程プレイブック 成果物に厳しく、人にやさしく。判定は人がする。

PoCの誤解と真実 【よくある罠（PoC死の入り口）】 目的: 「とりあえず動くものを作ること」 成果物: 網羅性のない脆弱なアプリ 結果: 終わりのない試行錯誤と「PoC疲れ」 【本来のPoC（概念実証）】 目的: 「アイデア・技術が成り立つかを証明すること」 成果物: 事実データとGo/No-Goの判断材料 結果: 確信を持った本番投資、または戦略的撤退

着手前に合意すべき「6つの鉄則」 「ここからはPoCモード。 精神論は不要、 厳しくするのは 判定だけです。」 1. 制作ではなく「証明」 動くことより、事実の確認。 2. ゴールを先決め 目的・仮説・成功基準を後から緩めない。 3. 最小構成で検証 使い捨て前提。作り込まない。 4. AI特有の合意 AIのPoCは「どの精度になれば完了か」を事前合意。 5. 事実による断言 Go/No-Go/Pivotを断言。撤退も成功。 6. 本番化の禁止 PoCコードは捨てる。そのまま運用に持ち込まない。

不確実性を削ぎ落とす「7つの検証工程」 企画 (1) 成功基準と中止条件の定義 検証設計 (2) 実装・準備 (3) 事実を測る仕掛け作り 実施・測定 (4) 評価・判定 (5) 忖度なき判定 報告 (6) 本番移行 (7) 【事実に基づく意思決定】

工程1: PoC企画 ―― すべては「測れるゴール」から 漠然とした目標を捨て、1枚の企画書に固定する。 PoC 1-Page Planning Template 【背景・検証する不確実性】 (なぜやるか? 技術・効果・コストのどれを検証するか) 【検証仮説】 (〇〇すれば△△になるはず、を一文で) 【成功基準・完了基準】 (精度〇%以上/処理〇秒以内。測れる合否ライン) 【中止条件/No-Goライン】 (これを下回ったら即時撤退する基準) 【スコープ】 (やること・やらないことの最小構成)

工程2・3: 検証設計と最小実装 検証設計 (Design for Facts) 印象ではなく「事実」で測る設計。 検証項目、評価指標、必要データ(量と質)、偏りを避ける工夫を定義。 実装・準備 (Minimal Disposable Build) 仮説検証に必要な最小実装のみ。「使い捨て」前提。 網羅的エラー処理や装飾は作らない。手動で代替できる部分は手動で。 「検証できれば十分」を徹底。

工程4・5: 実施測定と忖度なき評価 実施・測定 (Execute & Record) 事実を記録する。見栄えの良い1ケースだけで判断しない。 ダメな所、想定外も隠さず記録。 評価・判定 (Evaluate & Judge) - デモ映えに逃げない。 【GO】本番化へ進む 【NO-GO】中止。サンクコストに陥らず撤退(正当な結論)。 【PIVOT】仮説を変えて再検証。 「撤退(No-Go)も正当な結論です。もったいないからと続けないこと。」

工程6: 報告・意思決定 ―― 結論先出しの1ペーパー 誇張せず事実で。未検証は「未検証」と明記する。 PoC 1-Page Reporting Template 【目的と事前の成功基準】(企画書からの引き写し) ・ターゲット顧客の課題解決率80%以上達成 ・サービス導入意向の獲得が50%以上 ・実装工数が想定内の2ヶ月以内に収まること 【検証結果】(基準ごとの〇/×、事実・数値・想定外の発見) ・課題解決率(85%達成, 期待通り): 〇 ・導入意向(40%獲得, 目標未達): ×(価格設定が課題) ・実装工数(2.5ヶ月, やや超過): △(API連携に想定外の時間を要した) ・想定外の発見: ユーザーは機能Aよりも機能Bを高く評価した。UIの改善要望が多数。 【最終判定】(Go/No-Go/Pivotと、その明確な理由) 【No-Go(中止・撤退)】 理由: 導入意向の目標未達と、価格設定の根本的な見直しが必要。また、実装工数も想定を上回り、ビジネスモデルの再検証が不可欠なため、現時点での本番化はリスクが高いと判断。 【次のアクション・残課題】(本番化で必要となる追加検証・投資リスク) ・ビジネスモデル(特に価格戦略)のピボット検討 ・機能Bを中心とした新たな仮説の構築と再検証計画の策定 ・UI改善のためのユーザーヒアリング実施 ・API連携に関する技術的な課題の深掘りと解決策の検討

工程7: 本番移行判断 ―― 「PoC死」を防ぐ橋渡し PoCのまま本番化する誘惑への歯止め PoC Code (Wooden Rope Bridge) Production (Steel Bridge) Learnings / Requirements ・使い捨て品質を本番に持ち込むと「技術的負債」になる。 ・本番環境は、要件定義から作り直す。 ・コードは捨てても、「効いた所・落とし穴・必要な品質」の学びは本番要件として引き継ぐ。 ・性能・セキュリティ・運用など、新たな検証を設計する。

【特化】AI・生成AIのPoCは「別格」である 学習・生成させて初めて結果が分かる確率論の世界 【従来型IT】 挙動: 決定的(Deterministic) 完了基準: 仕様通り動くか 【AI・生成AI】 挙動: 確率的(Probabilistic) 完了基準: どこまでの精度で良しとするか Insight: AIのPoCでは、事前に挙動を確定できない。 「どの期間まで試行錯誤し、どの精度になれば完了か」の事前合意が絶対条件。

AIの精度実測と「過信の点検」 AI Accuracy Scale Target Zone 80% threshold agreed upon 1. 実測による評価: 体感ではなく、正解データと突合した「誤り率」など数値で測る。 2. プロンプト技法の検証: 複数パターンを現実に近いデータで試し、効いたと思い込まない。 3. 過信の点検: 生成AIの流暢な出力を「正しい」と錯覚しない。誤りや幻(ハルシネーション)を能動的に探す。 The Golden Rule: 精度は数値で測るが、最終判定は人が行う。AIに合否を決めさせない。

プロジェクトを爆破する「PoCの落とし穴」 罠1: 目的化・基準なし(動いたからOKになり、何も証明されない) 罠2: スコープ膨張(検証に不要な作り込みで時間切れ) 罠3: デモ映えへの逃避(見栄えは良いが本質的な実現性が未検証) 罠4: AI出力の過信(流暢さを正しさと錯覚) 罠5: PoCの本番化(使い捨て品質が居座り負債化) 罠6: PoC死・PoC疲れ(明確な中止条件がなく、無限ループに陥る)

結論: PoCは「証明」である。撤退を恐れるな。 1. 基準を先に決める。 2. 最小構成で確かめる。 3. 事実をもって判定する。 4. コードは捨て、学びを引き継ぐ。 「成功とは『本番化』だけではありません。 事実に基づき『やらない決断(No-Go)』を下すことも、立派なPoCの成功です。」 本ガイドラインは実務概念に基づく。(参考出典: IPA社会基盤センター, @IT AI用語辞典, NECソリューションイノベータ, JAPAN AI ラボ)