PoCを本番に移行するコツ
PoCが「動いた」。 この一言で、次に何をすべきかが曖昧になる現場は多い。
よくある誤解はこれです。 「PoCが動いた＝本番に進める」
その感覚は自然です。PoCは「動くかどうか」を確かめるための実験だから。 ただし、本番で求められるのは別物です。
本番で問われるのは、壊れたときに、誰が、どこまで、どう戻すか。 ここが未設計なPoCは、成功していても止まります。
なぜそれが起きるか（構造）
PoCが本番に移行できない理由は、個人の技術力の問題ではありません。 構造的に、次のズレが起きやすい。
成功条件が「デモ成功」で止まっている
画面が表示された、精度がそれっぽい、レスポンスが速い気がする。 これらはPoCとしては成功でも、本番の成功条件ではありません。
責任境界が決まらないまま関係者が増える
本番では障害、問い合わせ、権限管理、監査対応が発生します。 誰が一次対応で、誰が判断し、誰が直すのか。 これが決まらない限り、「進めない判断」は合理的です。
計測がなく、議論が感想戦になる
「速い」「使いやすい」という言葉だけでは、意思決定できません。 計測がないPoCは、改善の優先順位が決まらず、止まります。
PoCが止まる原因は「作れなかった」ではない。 本番を前提にした設計が存在しないことが多い。
解決の方針（設計原則3つ）
原則1：成功条件を「運用可能性」まで含めて定義する
PoCの成功条件に、可用性、権限、ログ、監視、復旧手順を含める。 ここまで定義できると、議論が前に進みます。
原則2：保守性を「変更コスト」として扱う
本番では必ず変更が入る。 保守性は美しさではなく、変更時の痛みを減らす設計です。
原則3：性能は最適化より「測れる状態」を作る
Lighthouseは万能ではありませんが、最低限の健康診断になります。 重要なのはスコアではなく、同条件で差分を追えることです。
実装/運用の具体
ステップ0：PoCの範囲を明確にする
どこまでがPoCで、どこからが未対応か。 スタブや仮実装は、仮であることを明示します。
ステップ1：計測点を最小限で入れる
- フロント：Lighthouse（同条件で再計測可能）
- バックエンド：主要APIのレイテンシ
- 運用：エラー時の一次対応手順
ステップ2：運用手順を文章で書く
コードより先に文章を書く。 書けない手順は、運用できません。
［PoC→本番 最小構成（概念）］
Browser
↓
Next.js（単一HTML /content）
↓
API / Backend
↓
DB / External Service
＋ 運用
- Logs / Metrics
- 障害時手順
- 責任者失敗パターン
- 成功条件がデモ止まり
- 運用手順が存在しない
- 計測がなく比較できない
- 責任境界が曖昧
- 保守性が議論されていない
意思決定のチェックリスト
| 観点 | 確認内容 | 判断 |
|---|---|---|
| 成功条件 | 本番OK条件が文章で定義されている | 進める／追加検証 |
| 責任 | 障害時の担当が決まっている | 進める／止める |
| 計測 | 最低限の指標が取れている | 進める／追加検証 |
まとめ
PoCを本番に進めるかどうかは、勢いでは決めない。 判断できる材料が揃っているかで決める。