- Published on
PoCはなぜ本番にたどり着けないのか — 成功基準、セキュリティレビュー、引き継ぎ
- Authors
- Name
- Youngju Kim
- @fjvbn20031
PoCの墓場 — 死に方のパターン
FDEの仕事で最も虚しい場面は、技術的に成功したPoCが静かに消える瞬間です。デモでは拍手をもらい、担当者も満足していたのに、3か月後に聞くと何も起きていない。検死をすると、死因はたいてい次の五つのどれかです。
- 成功基準がなかった。終わったのに成功かどうか誰も判定できなければ、決定は無期限に先送りされます。
- チャンピオンがいなかった。デモに感嘆した人は多くても、予算会議で戦ってくれる一人がいなければ次の段階はありません。
- セキュリティレビューを最後に始めた。技術検証が終わってからセキュリティチームが登場すると、審査期間がそのまま勢いを殺します。
- PoC環境と本番の差に気づくのが遅かった。ダミーデータ、迂回した権限、一台きりのサーバーで証明したものは、本番の証明ではありません。
- 予算サイクルとずれた。決裁者の予算日程と無関係に終わったPoCは、次の会計年度まで冷凍されます。
五つとも、コードの問題ではないことが核心です。PoCから本番までの区間は、エンジニアリングの腕ではなく運営設計で分かれます。そしてこの区間でのFDEの役割は二重です。コードを書くエンジニアであると同時に、成功基準と日程とステークホルダーを管理する事実上のプロジェクトマネージャーでもあります。後者を自分の仕事ではないと見なした瞬間、上の五つの死因のどれかが予約されます。以下の四つの章は、その後者の仕事を順に扱います。
開始前に成功基準を文書にする
成功基準の文書はPoCを始める前に、顧客と一緒に、1ページで書きます。数字、期間、判定者の三つが揃って初めて基準であり、一つでも欠ければ感想です。
[PoC成功基準 — 構成した例]
目標 : オペレーターの文書検索-初回応答時間を40%短縮
測定 : 対応100件のサンプルで検索-初回応答時間を2週間測定
基準線 : 現行平均90秒（開始前1週間の事前測定で合意）
判定 : 54秒以下なら成功。判定者は顧客側コールセンター運用リーダー
失敗条件 : 再検索率が15%を超えたら、速度に関係なく失敗と判定
次の段階 : 成功時は4週間以内にパイロット拡大の範囲と予算の議論を開始
この文書で最も価値のある行は失敗条件です。失敗条件を先に書いておいたPoCは、失敗しても信頼を残します。何がだめなのかを正確に知ることができたからです。逆に失敗条件のないPoCは、成功しても疑念を残します。そして最後の行、成功したら何が起きるかの約束があって初めて、PoCは意思決定につながります。
セキュリティレビュー、権限、データ境界
セキュリティレビューはPoCの最後の関門ではなく、最初の週の予定です。第1週に顧客のセキュリティチームと30分のミーティングを取り、三つを合意します。
第一に、データ境界。顧客データはどこまで移動するのか。外部APIに出るのか、出るならどのフィールドか。ログに何が残るのか。モデルの学習に使われるのか。この問いへの答えを一枚の図に描いて合意すれば、後から来るはずだった反対の大半が先に消化されます。第二に、権限。PoC用アカウントは最小権限で、有効期限を刻んで受け取ります。便宜のためにもらった管理者権限は、後のセキュリティ監査でPoC全体の信頼を削る証拠物になります。第三に、審査日程そのものの合意。本番移行にどんな審査が必要で通常何週間かかるのかを最初の週に聞いておけば、最終週のサプライズが消えます。
PoCコードが隠している負債
PoCコードは速く証明するために意図的に借金をします。問題は、その借金が見えないまま本番決定の根拠になることです。移行を議論する時点では、負債リストを明示的にテーブルに出さなければなりません。
- 設定ファイルに埋め込まれた認証情報 — シークレット管理の仕組みへ移す必要があります。
- エラー処理の不在 — ハッピーパスだけ検証されたコードは、最初の障害で崩れます。
- 単一インスタンス — 再起動、スケール、デプロイ戦略がすべて未定です。
- モニタリングの不在 — 本番では死んでも誰も気づきません。
- 迂回された認証 — PoCで切っておいたSSO連携が、移行作業の半分を占めることは珍しくありません。
このリストを顧客の前に先に出すのがFDEの誠実さであり、同時に移行見積もりの根拠です。「デモは動いたのに、なぜ本番は3か月かかるのか」への答えがこのリストです。ただし、負債リストは脅しではなく見積もりの言語で語るべきです。この五つを返すのに何週間必要だという文は、顧客にはコストではなく計画として聞こえ、リストが具体的であるほど移行予算の承認は速くなります。
引き継ぎ文書 — 去る日のために
FDEの成功条件は独特です。自分がいなくても回って初めて成功です。常駐が終わる日にシステムも一緒に止まるなら、それはデプロイではなくレンタルだったことになります。だから引き継ぎ文書は最終週ではなく、プロジェクトの中盤から積み上げます。
[引き継ぎ文書の目次 — 構成した例]
1. システム概要 — アーキテクチャ図一枚とデータフロー
2. 運用手順 — 起動、停止、デプロイ、バックアップ、復旧
3. 障害ランブック — 頻出する症状別の最初の30分の行動
4. 権限と連絡先 — アカウント一覧、承認者、エスカレーション経路
5. 既知の限界 — できないこと、未解決の課題、暫定対応の一覧
6. 拡張ロードマップ — 次の段階として議論されたものと保留されたもの
このうち顧客が最も頻繁に開き直す文書は障害ランブックです。FDEエンジニア育成RPGの引き継ぎロールが、ランブックのあるミッションでしかプレイできないよう設計されているのも同じ理由です。ランブックのないシステムは、渡せないシステムです。文書を渡す日には文書だけを渡さず、顧客のエンジニアがランブックどおりに障害シナリオを一つ自分の手で処理してみるリハーサルまでやって、初めて完結です。
手を動かして練習する
PoC運営の感覚は、圧力の中の意思決定の練習で育ちます。
- FDEエンジニア育成RPG — プリセールスPoCロールは制限時間内に成功基準を満たす必要があり、引き継ぎロールはランブックがあって初めて始まります。この記事の二本の軸を、そのままゲームのルールにしたものです。
- FDEカリキュラム ロードマップ — セキュリティ、データパイプラインなど移行作業に必要なドメインをチェックリストで点検します。
FDE完全ガイドシリーズ