不測時対応計画2、あるいは一線を越えるの越えないの？
前回、CP（コンティンジェンシー・プラン）、つまり不測の事態への対応方法をあらかじめ考えておくこと、について書いた。
今日は改めて、CPを検討するときに毎回議論になるポイントを備忘的に列挙していく。
【１】切り戻し
⇒どこまで進んだら「なかったこと」にできなくなるのか？
スペースシャトルの打ち上げではたまに「異常値が発見され、打ち上げ10分前にカウントダウンがストップした」というニュースがあった。
システムの本番稼動でもスペースシャトルと同じように、直前になにかまずいことが発見された場合はストップしたい時がある。
ただし「この一線を越えたら、もう戻れない。行くしかない」という場合もある。本番環境にデータをガッツリ投入してしまった後などだ。
この「戻れなくなる一線はどこか」を見極めておくのは、本当に大事。
一線を越える前に最後の稼動判定をすることも大事だし（一線を越えた後に判定しても意味がないので）、いざ問題が発覚したときの対処は一線を越えているかいないかで全く変わってくる。
（余談だが、このあたり、男女の仲に置き換えても、全て話が通じるのが不思議・・）
従って、以下がCP検討時の議論ポイントになる。
・戻れるかどうかの一線は、どういう処理をはじめる前なのか。
・それは時刻で言うと何日の何時か。
・その時点で何が終わっていて、何は未着手なのか
・戻るために必要なバックアップはなにか
【２】単純遅延で何が起こるか
⇒異常値が発見されたわけではないのだが、単に予定スケジュールから遅れた場合
新業務・新システムというものは、1週間完成が遅れたら、単に1週間遅くはじめれば良いというものではない。
所得税の年末調整や四半期決算などの季節ものの業務では特に、時期が遅れると全く違った対応をとらなければならないときがある。
また、隣のプロジェクトとの関係もある。「4/1にはこちらのプロジェクトでこういう状態にします」という約束が守れなかったら、プロジェクト外で誰かが進めていた計画が台無しになることもある。
さらに人やお金が足りなくなる場合も多い。Aさんは5月から別の仕事をやることになっていて・・というケースや、遅れた期間の人件費の予算がない場合だ。
【３】一部機能のみ稼働させる
⇒どこか一部のシステム機能がうまく動かないとき、他の部分をどうするかを決めておく
「金融機関向け支払いデータ作成」など、どうしてもここだけは動かさなければ社外に大きな迷惑がかかってしまう、というケースもある。社内の混乱が大きい機能だけ動かしたい場合もある。
そういうことがそもそも可能か、は慎重に判断しなければならない。
「いったい何を検証できれば動くと保証できるか？」を、トラブルが起こる前に議論しておくのだ。
【４】○○さんがいなくなるとアウト？
プロジェクトでは1人、2人のキーマンに頼る部分がたいてい大きくなる。彼らが急に倒れたら、稼動を見送った方が良いのだろうか？
そうしないためには何をしておくべきなのだろうか？
あるプロジェクトでは替えの効かないキーマンを3人特定し、「そのうち2人が倒れても大丈夫な様にしよう」という目標でCPを検討した（たまたま新型インフルエンザの驚異が迫っていたのだ）。
【５】ありそうなリスクとその対策のリストを作成
これはCPというよりも、プロジェクトで一般的に作るリスク分析なので、稼働前に限らず、プロジェクトプランを練っている頃にやっておき、更新していこう。
リスクをなるべく網羅的に洗い出し、「影響度合い×起こる確率」が大きいものは、対処を決めておく。
以上、特に重要なものをざっとあげてみたが、他にも多面的に検討しようと思えばキリはないし、ある程度までは検討するだけの価値はある。
なにより、きちんと検討しておけば「これだけ検討したのだから」と腹をくくれる。
腹がくくれていれば、いざCPを発動という事態に陥ったとしても（陥りたくないが）、冷静に対処できるのではないだろうか。