本番移行当日のPMの動き方

本番移行の日は、プロジェクトで最も緊張する一日です。うまくいけば誰も気づきませんが、失敗すれば業務が止まります。

この日のPMの仕事は、作業することではありません。時刻と条件を見て、進めるか戻すかを判断することです。

■ 当日に決めることは、当日に決めない

いちばん多い失敗は、切り戻すかどうかを当日その場で相談し始めることです。

深夜、全員が疲れていて、作業は途中。ここで「どうしましょうか」と相談を始めると、判断は必ず遅れます。そして遅れた分だけ、戻すことも難しくなります。

移行計画の段階で、次の3つを文書にして合意しておきます。

この3つが書かれていれば、当日は時計を見て条件に当てはめるだけになります。

■ 開始判断（GO / NO GO）を独立した時刻に置く

作業開始の時刻と、開始を判断する時刻は分けます。

たとえば作業開始が21時なら、判断は20時。この1時間で、次を確認します。

• 必要な人が全員そろっているか

• 直前の障害・未解決の不具合が残っていないか

• 連絡先と待機体制が整っているか

• バックアップの取得先に空き容量があるか

1つでも欠けていたら、延期という選択肢を選べる状態にしておくことが大事です。延期の判断は、始めてしまってからでは取れません。

■ 手順書は「チェック欄つき」で作る

移行当日の作業は、深夜で判断力が落ちた状態で進みます。そこで効くのが、手順書の作り方です。

とくに想定所要時間は重要です。これがないと「なんとなく押している気がする」という感覚でしか判断できません。

■ 動作確認は、業務側の人にやってもらう

開発側が動作確認をして「問題ありません」と言っても、業務が回るかどうかは分かりません。

移行当日の確認は、実際に使う人に、決めておいた手順で操作してもらいます。

• 確認するシナリオは、事前に紙で用意しておく（当日その場で考えない）

• 確認する人を名指しで確保しておく（深夜なら交通手段も手配）

• 確認が終わったら、その人に「確認しました」と記録に残してもらう

ここを省くと、翌朝に「使ってみたら動かない」が起きます。そのときにはもう戻せません。

■ 連絡の順番と文面を前日に作っておく

開放の連絡も、中止の連絡も、深夜や早朝に出すことになります。そのときに文章を考える余裕はありません。

次の3パターンを、前日までに下書きしておきます。

送る順番も決めておきます。業務部門の責任者 → 現場の利用者 → 社内関係部署 → 経営層。順番が前後すると、現場が上司から先に聞かされることになります。

■ 初日は、人を厚く置く

移行は、切り替えた瞬間に終わりではありません。むしろ初日の問い合わせ対応が本番です。

• 問い合わせ窓口を、いつもより厚くする

• 開発メンバーを、その日は業務現場の近くに置く

• 問い合わせ内容を記録して、翌日以降の対応に使う

初日に出る問い合わせの多くは、不具合ではなく操作の分からなさです。ここで丁寧に対応できるかどうかで、システムの評価が決まります。

■ PM自身は、作業に入らない

手が足りないと、PMも作業に入りたくなります。しかし当日のPMが作業に没頭すると、全体を見る人がいなくなります。

PMがやることは、次の4つだけです。

• 手順書の進み具合と時刻を見る

• 予定より遅れているかを判断する

• 切り戻しの条件に当てはまっていないか確認する

• 関係者に状況を伝える

■ まとめ

移行当日にうまくいくかどうかは、当日の頑張りではなく事前にどこまで決めてあるかで決まります。

いま移行を控えている案件があれば、「何時までに、どこまで終わっていなければ戻すのか」が文書になっているかを確認してみてください。書かれていなければ、そこが最初にやることです。