本番当日のリスクマネジメントはどこまでやれば良いか

on


遠足とか、そういったイベント、催事の当日に熱を出していけなくなるとか、親戚に不幸ができていけなくなる経験をしている人は少なからずいると思うのですが。


プロジェクトマネジメントのリスクマネジメントで「あぁ、そうだな」と思ったのは移行当日のリスクの識別なんですよ。移行当日のリスクを洗い出ししてみてください。どんなリスクが思いつきますか。

  • 移行手順の漏れの発見
  • 移行がうまくいかないときの切り戻し手順の確認不足
  • ネットワークの切替ミス
  • 移行時間の見積もりミス
  • 利用者への広報間違い

　：


役割が、アプリケーションかインフラか、リーダか、プロジェクトマネージャーか、若しくは、ユーザのプロマネかでだいぶ観点が変わるとおもいます。


が、どっちにしても

「準備してきたことに対して見落としがないか、気づいていないことがなかったか」


という、これまでの作業に対しての観点で物事を捉えようとしているんですよね。これ、とっても自然じゃないですか。いいんですよ、基本はこれで。


その発想はなかった
では、どんな観点が必要なのかというと、移行当日に対するリスクの識別が必要ですよ、ということです。

「え、それ、だって移行当日にミスを起こさないための識別ならやっているじゃん」


と思うでしょ。そこまではいいのです。そこまでは。


じゃあ、移行当日の移行作業はどこでやるんですかねぇ、とワタシはみなさんにお尋ねするのです、はい。


関東ですか、東京ですか。印西ですか。それとも栃木とか、大阪ですか、それとも三田ですか。


その場所は通中の勤務地とは同じ場所ですか。そこは開発場所から「遠隔地」ではありませんか。


そうなんですよ、データセンター作業があるときって、DCが遠隔地にあるんですよ。都内もありますけど。で、遠隔地の場合、

  • 移動手段の予約が面倒
  • 往復で撮りたくなる
  • 宿泊も予約とらないといけない


でも、でも、これって何か暗黙の前提がありますよね。そこがリスク識別しないといけないんですよ。


それは、移行当日に

「ちゃんと辿り着けるの」


です。

  • この時期なら台風が来て新幹線が止まったら
  • 冬なら雪で（略


自然相手じゃどうしようもないじゃないか、リスクの選択は受容しかない、と思うなら、それでもいいんですが、でもプロジェクトとしてはまずいですよね。


それが起きたときの対応方針を決めておきましょうよ、ということですす。交通手段、移行作業をする人、移行を妨げるもの（専用線の故障とか考えにくいですが）、とにかく、実際起きて後で費用請求できないケースで考えておくんですね。


まぁ、ここまでをリスク識別する前の準備作業の棚卸が大変で手が回らないですけど、プロジェクトの統括責任者はそのくらいの幅広い観点は必要です。