阪神大震災10年目に考えること、するべきこと（後編）：何かがおかしいIT化の進め方（23）（2/3 ページ）

[公江義隆，＠IT]

システム復旧のマネジメント――1日サイクルのPDCA

　マニュアルどおりに最初から整然と復旧作業が進められるというのは、大した事態でない場合だろう。大きな災害では、マニュアルに想定していなかったような問題が多々発生しているのが普通だ。出口である最終目標は「現状への復旧」であり、その意味では“やるべき”ことははっきりしているが、災害規模が大きければ大きいほど“やるべきこと”と、そのとき“現実にできること”の差は大きい。

　被害が大きい場合には、全社的・組織的な復旧体制が必要になる。しかし、このような体制が機能し始めるには、通信手段が確保され、必要な最小限の人がそろうことが条件になる。これには少し時間がかかる。社内各部門の業務の復旧スケジュールと、情報システムの復旧スケジュールの調整が必要になる。「生産管理システムの復旧が遅れて生産に入れない」といった事態を避けないといけない。一方で、製造設備の復旧に1カ月かかるようなら、生産管理システムの復旧を後回しにして、限られたIT資源や要員を、復旧を急ぐほかのシステムの復旧に充てるなどの適切なコントロールが必要になる。「現在利用可能な回線容量で処理するため、営業で取引形態の1つを一時停止できないか？」などの提案や調整が必要な場合も起こる。

　保守要員や保守部品が逼迫（ひっぱく）（注）するだろうから、ベンダに頼んでいる設備の修復予定など不確定な要素も多い。全社の動きに連動して、PDCAを半日サイクル、1日サイクルで回すプロジェクト管理がIT部門として必要になる。理屈どおりには進まない現場作業に対する判断・意思決定は、作業現場で行うことが望ましい。雰囲気の情報が欠落したオフィスの机上では、結論が理屈に走りがちになる。

　個別の問題の積み上げでしか復旧作業をしなかった場合と、全体への資源配分をダイナミックにできた場合との差は大きい。全社の業務の位置付けやそれらの重要度の理解、情報システム全容の把握・理解、アウトソース先業務の全容の把握、ITべンダ・メーカーなどの状況や立場の把握など、これら全体をバランスよくできている人が、いるか否かが結果を左右する。

---

---

マニュアルは有効か？

　「原状への復旧」というゴールは明確でも、被災の大きさや内容により復旧作業の具体的な内容や手順は大きく異なる。また、アウトソーシングなどが進み、オープンシステム化で関係者（ベンダ）の数が増えて、1つの問題解決への“AND”条件が増えたことで不確定性が増し、自分たちで直接コントロールできる範囲は激減している。

　つまりマニュアルどおりに作業を進めれば問題解決、といった意味でのマニュアルは作成不可能ということになる。マニュアルの内容を詳しくするほど、災害が行った場合に目の前の現実との違いが顕著（けんちょ）になるという、皮肉な結果になるだろう。文字通りの不測事態――想定していないことに対する対応方法を、事前に準備するというのは矛盾なのだ。

　では、まったく意味がないかといえばそうではない。本社のスタッフが現場をよく知らずに、外部のコンサルタントの助けを借りて、机上の理屈で作ったような、あるべき論を並べたようなものならあまり意味はないだろう。しかし、部門責任者、本社スタッフ、現場のマネージャ・担当者、できればアウトソーシング先の関係者が集まって、考えられるさまざまなケースについて問題を整理し、社内の他部門との関連事項を考え、対策や復旧手順を真剣に議論するなら、このプロセスにこそ大いに意味があると思う。

　人間は“経験や具体的に見聞きしたことのないこと”に遭遇した場合、事態を的確に把握することが非常に困難になる。“考えたことのないこと”に対しては、的確な対処の方法を短時間ではなかなか見いだせないものだ。

　マニュアル作成のための検討作業を、疑似ケース（シミュレーション）を通じた状況把握や対応力の学習機会、部門長や幹部社員にとっての、問題把握と万一の場合の覚悟の機会ととらえれば、大いに有効だと思う。また実際の作業に当たる人たちが、これを教材にして議論し合う機会を継続的に作れるなら、組織としての危機管理・対応能力は大きく向上してゆくだろう。

　できれば、ここで個々のアプリケーションシステムの重要度や優先度、さらに会社にとっての情報システムの位置付けを併せ議論してみることをお勧めしたい。

設備に対する対策――複数手段の組み合わせが鍵

　いうまでもないが、何が起きても通常どおりのことができるようにしようとすれば、システムや体制を二重三重に持つ――同じ機能と能力を持つバックアップセンターを複数個所に作る必要がある。しかし、構築・運用コストも2倍、3倍掛かることになるから、この方法は特定の業種の特定のアプリケーションシステムしか対象にはできないだろう。

　高い耐震性の建物や自家発電装置などを備えた堅牢な要塞を造り、籠城作戦・自給自足戦略はどうだろうか。これはこれで大変なことになる。紙の真ん中にコンピュータやサーバを描き、その周りにこれらを動かすために必要な資源とその概算コストを書いてみるとよく分かると思う。

　まず隣に人を描く、人がいれば飲料水、食料、生活できる環境が必要だ。電力?自家発電装置?燃料?その補給、大量に燃料を持てば危険物管理責任者、長期にわたるなら保守技術者、冷却水の供給、衛星通信装置などなど……。中途半端な形では、投資の割にリスク低減の保証は低いし、これら一式を整えようとすると大変なことになる。これも特定の業種か、製造業なら工場全体での対策に便乗するなどでないと、現実性に乏しい。

　3番目は、手段の複数化によるリスク分散策である。大型サーバ1台より1/2の容量のものを2台にする。電力は複数ルートで引き込む。通信回線もサービス業者を複数に増やし、東海道と中仙道ルートを確保するといった、災害発生時に容量は減っても機能は維持しようという考え方である。

　日常の費用効率は下がり、要素が増える分だけ問題の発生頻度は高くなるが、災害発生時の致命的なリスクを軽減できる。マネジメントの負荷が増えるが、一般企業にとっては、この考え方を中心にした展開が現実的なように思う。

　そのためには「最低限どうしても稼働させたいシステムはどれ？」「どうしても処理したいデータは何？」……など、業務の重要度、処理の優先度、情報の重要度などを事前に考え、明確にしておくことが大切である。

　対策の基本は、何をおいてもプログラムとデータのバックアップと安全な場所での保管である。これらは世の中で自社にしかない。これが残っていなければ本当にどうしようもなくなる。