PoCまでは動いたのですが、そこから本番運用に移せずに止まっています。
PoCは「動くこと」の確認までしか作り込んでいないため、他の人が毎日使い続けるための作り込み（権限・障害時の復旧・データの引き継ぎ）が、まるごと残っているからです。
PoCは短期間で成立性を確かめるのが目的なので、URLを知っていれば誰でも見られる、処理が失敗しても気づけない、といった状態のまま完成扱いになりがちです。これは手抜きではなく、検証段階では正しい割り切りです。問題は、その割り切りを外す作業が計画に入っていないことにあります。
裏を返せば、本番運用に移すために必要なものは、おおむね決まっています。使う人と使う場面が特定されていること、担当分だけを見せられる権限の仕組みがあること、処理が失敗したときに気づいて元に戻せること、本番のデータ量と表記ゆれに耐えること、作った人以外が直せる状態になっていることの5つです。ここが揃えば、機能を増やさなくても本番に移せます。逆に、どれか1つでも欠けたまま公開すると、公開後の事故対応に時間を取られます。
すでにPoCを使っている人がいる場合は、これに切り替えの検討が加わります。検証のつもりで始めた仕組みが、いつのまにか日常業務に組み込まれているのはよくあることです。この場合は、すでに入力されたデータをどう引き継ぐか、切り替えの当日に業務を止めずに済むか、URLやログイン方法が変わることをいつ告知するかを、作り直しの計画と同時に決める必要があります。使っている人がいるほど、機能の作り直しよりも切り替えの段取りの方が難しくなります。
よくある原因
- 認証・権限・ログ・バックアップなど、検証では省いてよかった項目が積み残しになっている。
- 使う人と使う場面が決まっておらず、必要な性能と停止許容時間を判断できない。
- 検証用のデータで動いており、本番のデータ量・表記ゆれ・欠損に耐えられない。
- すでに一部の人が業務で使っており、止めて作り直す段取りが組めない。
- 作った人しか動かせず、運用と改修の担当が決まっていない。
- 本番化の費用と効果を比べる材料がなく、社内で決裁を上げられない。
最初に確認すること
止まっている理由が技術的なものか、意思決定によるものかを先に分けます。作り直しが必要という技術的な理由なら、残作業を洗い出せば見積もれます。投資判断ができないという理由なら、先に「誰のどの業務がどれだけ楽になるか」を数字にしないと動きません。PoCを触った人に、実際の業務で使うとしたら何が足りないかを聞くのが早道です。すでに使っている人がいるなら、その人たちが今どのデータを入れているかも同時に確認します。
- 本番で扱うデータ量と、PoCで使ったデータ量の差
- 使う人の範囲（社内だけか、社外にも公開するか）
- すでに業務で使っている人がいるか、そのデータを引き継ぐ必要があるか
- 止まったときに困る時間の長さ
- 作り直す範囲と、そのまま使える範囲の切り分け
改善の方向性
- PoCの成果を仕様書として扱い、実装は本番の前提で作り直す想定で見積もる。
- 認証・権限・ログ・バックアップを、最初のスコープに含めて計画する。
- すでに使われている場合は、データの引き継ぎと切り替え日の段取りを設計に含める。
- 対象業務を1つに絞って本番化し、使いながら範囲を広げる。
- 運用担当と改修の窓口を、公開前に決めておく。
PoCのコードをどこまで流用できるかは、構成を見れば判断できます。全面的に作り直す場合でも、検証で分かった要件はそのまま活かせるため、ゼロからのやり直しにはなりません。すでに使っている人がいる場合は、業務を止めずに切り替える段取りも含めてご相談いただけます。
