wisdom Business Leaders Square
ビジネスに役立つ「次の一手」をあなたに
ビジネス用語辞典 Wisdomブログ

経営戦略 成功ストーリー マネジメント ビジネススキル ITトレンド IT講座 マーケティング ちょっと一息

2005/12/26

事業継続の観点からの目標復旧時間(RTO)は誰が決めてどう守るのか

目標復旧時間(RTO)は誰が決めてどう守るのかを考えていきたいと思います。

前回、業務をやっている人とIT部門との間でRTOに対して認識のずれがあるという例を挙げました。

IT部門の人にとっては、システムの切り替えを決断してから代替システムが立ち上がるまでが復旧作業の大項目でありその時間が一つの目標になるでしょう。

しかしその前後の作業は、意志決定までの時間であったり、業務部門の人によるデータ入力/確認の時間であったりするので、IT部門にとってはコントロール不能な部分です。

この辺りがRTOが、いわゆるSLA(Service Level Agreement:サービスレベル合意)で決めきれないObjective(目標)たるゆえんでもあるようです。

ということで事業継続の観点からのRTOは業務をやっている人が決めるべきということになり、それは災害が発生して業務に支障が出てから仮復旧するまでの時間です。

ではIT部門としては災害が発生してシステム切り替えの判断をするまで安否確認被害状況の確認をしているかというと、もちろんそれだけではありません

例えば台風のように予め被害が発生することが予測できる場合は、

  復旧手順書が最新のものか確認する、

  その手順書が代替システムが置いてある場所にもあるか確認する、

  最新のパッチデータなどを用意する、

  システムのパスワードを今一度確認する、

  システム管理者や開発者の所在を確認する、

  バックアップテープを代替場所に送る、

  被害発生の可能性が高い場合は人の移動を始めるなど、

色々ありますね。

地震のように予期しないで起こってしまった場合には、これらの作業を地震発生後、即刻始めないと、システムの切り替え判断をしても実行する人と戻すデータがない、パスワードが分からない、手順がよくわからん、ということでせっかく設定した目標時間を守ることが出来ません。

即ちこれらの作業は事業復旧という観点からすると、従来の作業と並行して行われるべきで、そのためにも役割と手順を決めておかなければなりません。この辺りがシステム復旧計画書をBCPっぽく作っていく一つのポイントのようです。

最終更新時間 08:43 | コメント (0) | トラックバック

2005/12/19

事業継続の観点からの目標復旧時間(RTO)とは何なのか

災害発生後業務が仮復旧するまでの時間(目標復旧時間:RTO)は事業継続の観点から見ると何なのでしょうか?

目標復旧時間(Rocovery Time Objective: RTO)は、政府のガイドラインでは以下のように書かれています。

●経済産業省:事業継続計画策定ガイドライン
「事業・業務の中断が発生した場合に、事業に重大な影響を及ぼさないうちに事業活動を復旧・再開させるための目標時間である。言い換えれば、どの程度まで中断が許容されるかの指標ともいえる。」

●内閣府中央防災会議:事業継続ガイドライン
「影響度評価の結果や、取引先や行政との関係、社会的使命等を踏まえ、企業にとってその重要業務の停止が許されると考える目標時間

さらっと書かれており、それなりに納得できる内容なのですが、いざ決めるとなると簡単ではありません。

RTOという言葉は、IT部門の人にとっては比較的なじみがあり、サーバが復旧するまでの時間といったイメージがあります。

ところが、業務をやっている人にとって業務が復旧する、もしくは無理やりでも継続させるというのは、色んなパターンがあり、IT部門のイメージと一致するとは限りません

例えば、業務をやっている人の立場から考えて見ましょう。

(1) 災害が起こって、業務システムがダウンしたのでしばらく待っている

(2) すぐに復旧しそうに無いのでコンピュータを使わずとりあえず手作業で業務を継続させる

(3) システムが立ち上がったと連絡が入ったが、すぐに使い始めると手作業で処理した分との不整合が起こるとか言われ、まず手作業分のデータを入力する

(4) 入力後、災害直前からの過去データも含めてデータチェックしてみると、昨日分のデータが無いのに気づく

(5) 昨日分を今すぐ手入力するのか、いや後日入力するのかIT部門の人ともめる

(6) 一応後日でも良いということになり、業務システムを使い始めようとしたら、IT部門から緊急連絡が入り、アプリケーションプログラムのバックアップテープを間違えて古いバージョンのものを使って戻したため、もう一度復旧作業がやり直しになるので更に待ってほしいといわれる

(7) 仕方ないということでまた手作業で業務を継続させるが、紙がいっぱいたまってきており、だんだんわけがわからなくなってきている

(8) IT部門から今度は正しくアプリケーションプログラムを復旧できたのでデータが正しいか再確認して欲しいと言われる

(9) チェックしたところ幸いにも先に入れた手作業分のデータもきちんと入っている

(10) ということで、つい今までに手作業で処理していた分のデータを入れることにする

(11) 全部入れ終わり、またデータチェックし、不具合が無いことを確認し、やっと業務システムを通常通りに使うことが出来るようになる

IT部門の人も含めてなんだか涙が出るような作業ですが、ここまで来てやっと業務が仮復旧したといえるかどうかという感じですね。

IT部門の人にとっては、サーバにプログラムやデータを戻して立ち上げなおしたら、とりあえずホッとして、RTO達成と言いたい所ですが、話は単純ではありません。

更に、上のシナリオでは、災害発生からシステム復旧指示が下るまでの時間経過が明示されていませんが、通常、安否確認、被害状況の確認が行われて、システム復旧が判断され、それが担当者に正しく伝わり、更に必要なデータも揃ってから本当の復旧作業が開始できるということになります。

いやはや、業務復旧/事業継続という観点から見ると道のりは長いですね。

RTO一つ決めるにも、業務部門とIT部門、それぞれ文化の異なる組織であり、共通の認識を持つ必要がありますね。

最終更新時間 08:58 | コメント (0) | トラックバック

2005/12/05

内部統制と事業継続計画(BCP)

日本版SOX法の制定が間近ということもあり最近、内部統制に対する関心が非常に高まっています。今回は内部統制とBCPについて考えてみましょう。

まず皆さんご存知とは思いますが一応SOX法の背景について簡単に説明します。

これは米国でエンロン、ワールドコムなどの巨額会計不祥事を受けて、サーベンス議員とオクスリー議員が提出した法案、サーベンス・オクスリー法(以降、SOX法)で2002年に制定されました。これは企業改革法とも呼ばれます。

企業の不祥事は社会的責任の観点からも大きな問題となるため、コーポレートガバナンス(企業統治活動)の強化が必要となります。その重要な仕組みの1つとして「内部統制」を位置づけています。

それまでは会計監査の結果、決算報告書の内容が正しければ良かったのですが、SOX法により、財務報告に関する内部統制についてもチェックを受ける、即ち結果だけでなくプロセスも問われることになったのです。

日本でも類似の不祥事への対策として、2005年7月金融庁から「財務報告に係る内部統制の評価及び監査の基準(公開草案)」が公表され、経営者による内部統制の評価・報告と外部監査人による監査の義務化が検討されています。これが通称日本版SOX法の元と呼ばれるものです。

早ければ2008年3月度の決算報告から適用されることが予想され、即ち内部統制の運用は2007年度当初から始めなければならないと見込まれています。

また、中身は軽めだが適用時期が早いという点では、2006年5月から施行見込みの会社法においても、株式会社(大会社)の取締役会に内部統制の構築決定と開示が義務付けられる方向で検討が進められています。

背景はこのくらいにして内部統制とBCPの関係について考えてみたいと思います。

SOX法では、日米とも財務諸表の内容についての信頼性確保が目的のため、直接的には事業継続/災害対策は関係ないように思えます。もちろん大事な財務諸表データをきちっと管理してバックアップをとっておき、確証を提出しろと言われた時にすぐに出せる体制を整えておくことは必要です。

実際米国の場合、SOX法がきっかけで、BCPを見直したという話を聞きます。

米国SOX法の場合、内部統制構築についての具体的手段について触れていないため、法律と実際に行われた手段の因果関係を定義することは難しいです。

一方日本の場合、公開草案では基本的要素の中に「ITの利用」という言葉が明示されています。「ITの利用」は「業務統制」と「全般統制」からなります。

個別のアプリケーションによる入力チェックや承認機能といった仕組みは「業務統制」の方に含まれ、本人認証の仕組みを含むセキュリティ機能のようなITインフラ全体をカバーするような機能は「全般統制」の方に含まれています。

「全般統制」で関係する情報システムのプロセスを、経済産業省のシステム管理基準、日本公認会計士協会のIT委員会報告3号、石島隆著「情報システムの内部統制」などの情報を参考に分解すると以下のようになります。

  1.組織及び計画
  2.企画・開発プロセス
  3.運用プロセス
  4.維持・保全プロセス
  5.情報セキュリティ
  6.事業継続/災害対策 => BC/DR
  7.外部委託

ITの内部統制を構築するには、上の7つのプロセスで現状どこが不足しており、どこを強化すべきかという点を考えることになります。

米国の場合、BCP構築済み企業が8割に達すると言われており、SOX法対応を契機にITの内部統制を見直した場合、BCP策定自身が改めて話題になることはなく、むしろBCP見直しの契機になったと思われます。

日本の場合、BCP策定済み企業はまだごくわずかで、これからといった企業や団体が主だということを考慮すると、内部統制の構築・強化を、BCP策定を企業の危機対応能力向上のチャンスとして前向きに捉え、SOX法対応活動を企業価値向上と結びつけるのが良いでしょう。

最終更新時間 08:47 | コメント (0) | トラックバック