■「Do」はここがポイント

「Do」の一つ目は「災害時にどのシステムを生かすのかを決めておく」ことです。これはシステム管理者のMさんが各部署にアンケートをとり、これとBCPの目的とを突き合わせて、IT依存度の最も高い重要業務を特定しました。

二つ目は「データの回収およびシステムの復旧手順を分かりやすくマニュアル化しておく」こと。これもMさんの担当です。ここで言うところの「データ」や「システム」は、一つ目の作業で特定された「IT依存度の最も高い重要業務」のことです。誰が引き継いでも理解できるように、丁寧かつ分かりやすいマニュアルを作成するよう配慮しました。

三つ目は「社員の中からITに明るい人材を掘り起こし、機会を見つけてクロストレーニングで育成する」。これは上記2つが完成した後の実施項目となります。Aさんが全社員の技能や得意な分野に関するデータを調べてみたところ、幸いにもMさんの役割を補完できそうな社員が2名見つかりました。彼らには、ITのより深い知識を習得させるべく外部の研修に参加させたほか、Mさんが作成したマニュアルを用いてデータのリカバリとシステムの復旧に関する指導をしてもらいました。

こうして、Mさん不在でも何とか緊急時には対応できる体制は整いました。次は「Check」のステップに移るわけですが、上記の3つの作業や活動が完了しただけでは、これらが妥当か、目的に適っているかの判断はできません。"実効性"が問われるからです。かといって、実際に災害が起こるのを待ってうまくいくかどうかを試してみる、などというのも現実的ではありません。

そこでAさんは、Doの最後の段階で「テスト」を行い、この一連の対策の実効性を確かめてみることにしました。その結果を「Check」に持ち込んで、評価・検証しようというわけです。

■「Check」~「Act」の判定はどうなる?

その「テスト」とは、Mさん立ち合いのもと、1名の社員がリモートバックアップの保管場所に実際に出向いてダミーのデータを回収し、それを会社に持ち帰って、もう1名の社員がセットアップした予備のサーバにインストールするというものです。

テストは無事終了し、2人とも不慣れな点は少し割り引くとして、ある程度のレベルには達していたので全員安堵のため息をつくことができました。Mさん曰く、「今回のテストだけでは少し心配です。年1回はテストを行って、彼らが継続的にスキルを磨き続けることが重要と考えます」。これで「Check」のステップは終わりです。

さて、最後の「Act」の判定はどうなったでしょうか。Aさんは「Act」の判定を「毎年1回、マニュアルに基づくリカバリテストの実施を標準的な手順とする。ただし今後、テストで望ましくない結果が出た場合は、PDCAに改善プランを盛り込んで再度実施・評価することにする」としたのでした。

今回は、特別な専門知識やスキルを持つ社員が事業継続活動に当たれなくなったらどうするかについて、システム管理業務を中心に考えてみました。これはBCPでは典型的なテーマであろうと思いますが、もちろんシステム管理者に限らず、キーパーソンがいないとビジネスに重大な影響が出ると考えられる役割や業務が、みなさんの会社にもあるでしょう。

もし「その人」の不在が業務の継続や災害復旧のボトルネックとなり得るような役割や業務が思い当たったら、それらを洗い出し、PDCAにかけてみてはいかがでしょうか。

(了)