はじめに
本番リリース（カットオーバー）の直前、関係者が集まる判定会議では、独特の空気が流れます。ここまで投じてきた予算とスケジュールを前に、「もう後戻りできない」という心理が働き、本来は見送るべき状態でも押し切ってしまう——これは私が発注側支援の現場で何度も見てきた光景です。
SIerで4年半、ITコンサルファームで4年半、要件定義からベンダーマネジメントまで一貫して対応してきた経験から、カットオーバー判定を感覚ではなく基準で行うための考え方を解説します。
判定基準は「リリース直前」ではなく「事前」に決める
判定基準を、リリース判定会議の場で初めて議論するのは危険です。会議の場では、すでに「予定日にリリースしたい」という圧力がかかっており、冷静な基準設定ができません。
判定基準（機能・性能・データ移行・セキュリティ・運用体制など、各観点での合格ライン）は、プロジェクトの早い段階、少なくとも判定会議の1〜2週間前までに関係者で合意しておくことが重要です。基準を先に決めておくことで、当日の判定は「基準に照らしてどうか」という機械的な確認作業になり、空気に流されにくくなります。
必須項目にNGが残っていたら、原則として見送る
判定基準を作る際は、項目を「必須」と「推奨」に分けることをおすすめします。すべてを同列に扱うと、重要な未達項目が軽微な指摘に埋もれてしまいます。
必須項目に1件でもNGが残っている場合は、原則としてリリースを見送るというルールを、判定基準を作る段階で決めておいてください。これを事前に合意しておけば、当日「このくらいなら大丈夫では」という空気に流されることを防げます。
ロールバック基準も、リリース前に決めておく
もう一つ見落とされがちなのが、リリース後に問題が発生した場合の、ロールバック（切り戻し）判定基準です。多くのプロジェクトでは「とにかくリリースすること」に意識が集中し、リリース後に問題が起きたときどう判断するかが決まっていません。
結果として、本番で重大な障害が発生しても「もう少し様子を見よう」と判断が遅れ、被害が拡大するケースがあります。「データ破損が確認されたら即時ロールバック」のように、事象のレベルごとに判断基準と対応アクションを事前に決めておくことで、有事の際に迷わず動けます。
まとめ
カットオーバー判定を「その場の空気」に委ねないためには、判定基準を事前に決め、必須項目にNGが残っている場合は原則見送るというルールを合意しておくことが欠かせません。あわせてロールバック基準も事前に定めておくことで、リリース前後を通じて一貫した判断ができるようになります。
実際に使っているカットオーバー判定基準書のテンプレートは、noteで配布しています。
執筆者プロフィール：SIerで4年半、ITコンサルファームで4年半、要件定義からベンダーマネジメントまで一貫して対応。基幹システム刷新・DX推進プロジェクトに多数従事。
コメント