2週間後に受け取るもの
2週間のPoCはメモだけで終わるべきではありません。次の判断をしやすくする動く証拠を残します。
期待できる成果物
成果物はスコープによりますが、社内説明や次の判断にそのまま使える形で残るべきです。
- 動くプロトタイプ
- デモシナリオ
- 前提条件とリスク
- 次ステップのロードマップ
- 必要に応じたソース引き継ぎ
2週間で見えるべきこと
2週間で全社基盤は作れません。ただし、コアワークフローが実在するか、リスクがどこにあるか、次に予算を付けるべき範囲は十分に見えます。
- 実ユーザー経路
- 1つのデータ/API経路
- 既知のブロッカー
- デモの反応
- 次スコープの推奨
約束すべきではないこと
2週間PoCをエンタープライズ展開のように見せるべきではありません。約束するのは、動く証拠、見えるリスク、現実的な推奨です。
- 架空ROIは出さない
- 広い変革効果を主張しない
- 本番前提を隠さない
- 曖昧な引き継ぎにしない
指標・実績
- 1: コアワークフロー - 1つの狭いワークフローを実デモできる状態にします。
- 2w: 検証期間 - 経路を証明するには十分で、曖昧さを隠すには短い期間です。
- Next: 次判断 - 拡張、縮小、停止、方向転換のどれかを判断できる状態にします。
- Handover: 再利用資産 - コード、メモ、前提、デモ証拠が会議後も使える形で残ります。
2週間の証拠パッケージ
- 動く範囲: デモできる小さなアプリ、API、LLMワークフロー、ダッシュボード経路。
- デモシナリオ: 関係者に見せる具体的なシナリオ、データ、期待挙動。
- リスクメモ: 次ステップに影響する技術、データ、AI、セキュリティ、定着リスク。
- 次スコープ: 次に構築、検証、連携、停止すべき範囲の推奨。
よくある質問
- 2週間で本番ソフトウェアは作れますか？
- 通常、完全な本番システムではありません。ただし、本番形の薄い範囲を作り、経路と堅牢化に必要なことを見せられます。
- 社内で使いやすい成果にするには？
- デモシナリオ、書面のリスク、受入条件、具体的な次スコープ推奨があると、経営・関係者へ共有しやすくなります。
- PoCでアイデアが弱いと分かった場合は？
- それも有用な成果です。小さなPoCにより、弱い前提のまま大きな案件を承認することを防げます。