基幹システム刷新や大規模更改では、稼働日の直前に「本番稼働判定会（Go/No-Go判定）」を開きます。ところが現場では、判定会が実質的に稼働日を追認するだけの場になっていることが少なくありません。止めるべき状態でも誰も「No-Go」と言えないまま稼働し、障害対応に追われるケースが繰り返されています。

本記事では、稼働判定が機能しなくなる構造と、発注者側のPMやPMO（プロジェクトマネジメントオフィス）が事前に設計しておくべきことを整理します。

課題 ― 判定会が「儀式」になっている

形骸化した判定会には共通する兆候があります。報告資料には未解決の不具合が並んでいるのに、結論欄にはすでに「Go」と書かれている。判断の根拠を問われても「ベンダーが大丈夫と言っている」「利用部門も了承済み」としか答えられない。No-Goになった場合に何が起きるのかを、誰も説明できない——といった状態です。

これは担当者の気の緩みではなく、判定に必要な材料と選択肢が、判定会当日まで用意されていないことが原因です。

なぜ判定が機能しなくなるのか

一つ目は、判定基準が事後に作られることです。テスト終盤に基準を作ると、現状を追認できる水準に調整されがちです。基準は、結果が見える前に合意しておかなければ物差しになりません。

二つ目は、No-Goの選択肢が設計されていないことです。延期した場合の旧システムの延長利用、要員の再確保、利用部門への周知といった代替シナリオがなければ、判定者にとってNo-Goは「選べない選択肢」になります。

三つ目は、判定者が不明確なことです。ステアリングコミッティ（経営層を含む意思決定会議）、情シス部門長、利用部門長のうち誰が最終判断を下すのかが曖昧なままだと、全員が「反対しなかった」ことでGoが決まります。

判定基準を五つの観点で合意する

判定基準は、遅くとも総合テストに入る前に、利用部門・運用部門・ベンダーと合意しておきます。観点は次の五つに分けると漏れが減ります。

観点 判定基準の例
テスト 重大度の高い不具合が解消済みで、残存不具合に回避策と対応期限がある
移行 リハーサルで手順と所要時間が検証され、データの整合性確認方法が決まっている
業務 利用者教育が完了し、稼働初期の問い合わせ窓口と運用ルールが整っている
運用 監視・障害連絡・保守の体制が稼働日から機能する
切り戻し 旧システムに戻す手順・判断期限・判断者が決まり、リハーサルで確認済み

特に重要なのが切り戻しの観点です。「戻せる」ことが確認されていれば、Goの判断はリスクを限定した決定になります。逆に戻せない移行方式を選ぶなら、その分だけ前段の判定を厳しくする必要があります。

判定会の運営 ― 段階的に「止められる時点」を作る

判定を一回で済ませず、移行リハーサル後・稼働の数週間前・切替直前のように段階的に開くと、No-Goの判断が現実的なコストで下せるようになります。直前の一回だけでは、延期の影響が大きすぎて止められないためです。

判定会では各観点の責任者が基準に照らして「満たす／条件付きで満たす／満たさない」を報告し、最終判断者が結論を出します。PMOの役割は、判定資料の取りまとめではなく、基準と実績の差分を中立的に示すことです。進め方全体の意思決定の設計はプロジェクトの意思決定の設計で整理しています。

条件付きGoは便利ですが、乱用すると判定の意味が失われます。条件には必ず「期限」「責任者」「期限までに満たせなかった場合の扱い」を付け、判定記録に残します。

よくある失敗と回避策

失敗パターン 回避策
判定基準をテスト終盤に作り、現状追認になる 総合テスト前に基準を合意し、変更時は理由を記録する
No-Go時の代替シナリオがなく、延期を選べない 延期時の旧システム延長・要員・周知計画を事前に用意する
ベンダーの「問題なし」報告をそのまま採用する 基準ごとに証跡（テスト結果・リハーサル記録）で確認する
条件付きGoの条件が稼働後に放置される 期限と責任者を付け、稼働後の定例で消し込む

ベンダーとの責任分担が曖昧な場合は、判定の前提そのものが揺らぎます。発注者の協力義務とベンダーのPM義務の整理もあわせて確認しておくと安心です。

まとめ

本番稼働判定は、プロジェクトを止められる最後の関門です。判定基準を結果が見える前に合意し、切り戻しとNo-Go時の代替シナリオを用意し、判定会を段階的に開く。この三点を設計しておくことで、判定会は儀式ではなく意思決定の場として機能します。

FAQ

Q. 判定基準はどの程度定量的にすべきですか。 A. 判定がぶれない程度に具体的であれば十分です。「重大な不具合がない」ではなく、重大度の定義と許容できる残存状態を明記します。数値目標を置く場合も、その根拠を関係者と共有しておくことが重要です。

Q. 経営層が稼働日の死守を強く求めている場合はどうすべきですか。 A. 稼働を延期した場合と、リスクを抱えたまま稼働した場合の影響を並べて示し、経営層自身に選んでもらいます。判断材料を揃えて判断者に委ねることが、PMOの役割です。

Q. アジャイル開発のように頻繁にリリースする場合も必要ですか。 A. 毎回の重い判定会は不要ですが、リリース可否の基準を事前に定め、自動テストや承認フローに組み込む考え方は同じです。業務影響が大きいリリースだけ判定会を開く運用が現実的です。

参考資料