読者です 読者をやめる 読者になる 読者になる

BCP〜防災の時代

事業継続計画(Business continuity planning、BCP)は、災害などの緊急事態が発生したときに企業が損害を最小限に抑え、事業の継続や復旧を図るための計画[1][2][3]。事業継続と復旧計画(Business Continuity & Resiliency Planning、BCRP)とも呼ばれる。類義語としてコンティンジェンシープラン(緊急時対応計画)があり、この語も非常事態が発生した場合の対応策をまとめた計画を表すが、事業継続よりも緊急時の初動計画に力点をおいている[4]。


事業継続計画を策定し維持・改善する事業継続マネジメントシステムが満たすべき条件を定めた規格がある。2012年に国際標準化機構による国際規格 ISO 22301 (Business continuity management systems — Requirements) が発行され、翌2013年にはその日本語訳である日本工業規格 JIS Q 22301(事業継続マネジメントシステム — 要求事項)が制定された。

経済産業省[5][6]や厚生労働省[7]は、BCPの内容を以下の4つのフェーズに分類している:

BCP発動フェーズ
業務再開フェーズ
業務回復フェーズ
全面復旧フェーズ
これらの フェーズを決定するため、復旧計画には以下の指標を用いる[8]

RPO(Recovery Point Objective、目標復旧時点(英語版)) - 災害発生の何時間前の状態に戻せるか。バックアップを取る頻度の目安となる
RLO(Recovery Level Objective:目標復旧レベル) どのレベルの操業度まで復旧できるかの目標値。災害発生時からの経過時間の関数として表される。
MTPD(Maximum Tolerable Period of Disruption: 最大許容停止時間(英語版) ) 操業停止時間を何時間以下に抑えるかの目標値。なお「操業停止」はRLOが事前に定められた許容限界を下回る事として定義する。
RTO(Recovery Time Objective、目標復旧時間(英語版) )- 災害発生後、何時間で操業を再開できるかの目標値。なお「操業再開」はRLOが事前に定められた値以上なることとして定義する。

2004年に、イギリスは民間緊急事態法2004(Civil Contingencies Act 2004)(すべての救急隊と地方自治体に、非常事態に対して積極的に備えと計画するよう命じる法規)を制定した。地方自治体も、それぞれの地理的地域に事業継続経験の促進を積極的に導くこの法令の下で法的義務がある。

2006年12月に、英国規格協会はBCP — BS 25999-1のための新しい独立した標準を発行した。BS 25999の発表以前のBCP専門家[誰?]は、組織の情報セキュリティ遵守を改善するためにBCP周辺を論じるだけのBSI情報セキュリティ標準であるBS 7799を頼りにした。BS 25999の適用性は、政府及び民間、営利及び非営利、大規模及び小規模、あるいは産業セクタのどちらでも、種類、規模、及び業務のすべてにまで拡大された。

2007年に、BSIは、ドキュメント化された事業継続管理システム(BCMS)の実装、運用および改良のための要求を規定する、第2部、BS 25999-2「事業継続管理のための仕様」を出版した。

完全なBCPサイクルは混乱の事前、最中、及び事後に利用可能な、印刷されたマニュアルである。その目的は、中断の範囲(それがどの程度何にどんな影響するか)と期間(たとえば、何時間、何日、何ヶ月)との両方によって決まる影響を受ける不利な利害関係者を減らすことである。測定可能な事業影響分析(BIA)『ゾーン』(危険と脅威のある領域、市民、経済、自然、技術、2次的及び後続の存在)を含む領域。

BCPにおける長期的災害は、自然災害、人災、及び混乱を表すため使われる。

2001年1月1日以前、政府は2000年問題と呼ばれた、銀行、 電力、 電信、健康及び財政産業のような、重要な公的ユーティリティのインフラにおける、コンピュータ不具合を予測した。 1983年から、米国銀行協会(英語版)及び銀行管理院(英語版)などの規制機関は、彼らの支援メンバーに公的利益を守る運営継続プラクティス(後により公式なBCPマニュアルよって支援された)の行使を要求した。より新しい規制は、しばしばISO/IEC 17799又はBS 7799の下で定義された公式の標準を基盤とする。

BCPに焦点を当てた規制とグローバル事業は2000年問題解決の後、衰退した。ある人[誰?]はアメリカ同時多発テロ事件で、ニューヨークの荒廃したダウンタウンを同時テロ攻撃し、そして事業継続計画の最悪のシナリオのパラダイムを変えた時、この緩んだ姿勢が終わったと確信した[9]。

BCP方法論は、あらゆる規模とあらゆる複雑な組織のためスケーラブルである。方法論は、重要インフラ保護(英語版)をルーツに持つにもかかわらず、組織のあらゆる特徴は、一つのBCPマニュアルを作成する可能性がある。そして間違いなく、すべての組織は組織の延命を確かにするためそれを持つべきである。企業がBCPの準備に十分な時間と資源を投資しない証拠は、災害生残り統計で明らかにされる。火災は影響を受けた事業の44%を永久に凍結するため[10]。世界貿易センター爆破事件で150〜350の事業が影響を受け、その後を生残れなかった。逆に、BCPマニュアルを良く開発しテストしていたアメリカ同時多発テロ事件によって影響を受けた企業は、数日中に事業に戻ることができた[11]。

小さな組織のためのBCPマニュアルは、第1次作業場所から離れて安全に保管された、オフサイトの場所、データ、バックアップ、保管メディア、保険契約のコピー、その他の組織生残りに必要な重要書類を伴う、危機管理スタッフ、通常スタッフメンバー、クライアント、及びベンダーのための名前、アドレス、及び電話番号を含む、単純な印刷されたマニュアルである。最も複雑なところでのBCPマニュアルは、第2次作業サイト、技術要求と覚悟、規制報告要求、作業回復測定、物理的記録の再確立の手段、新しいサプライチェーン確立の手段、新しい生産センター確立の手段をアウトラインすることである。企業は、これらのBCPマニュアルが危機中に使うため現実的でかつ容易であることを確かめるべきである。このようにBCPは、危機管理と災害復旧のそばに置く、組織のリスクマネジメントの一部である。

BCPマニュアル開発は次の5つのフェーズを持つ。

分析
ソリューション設計
実装
テストと検収
維持、修理と運用
上記のリストは決定的なものではなく、事業自身の計画/マニュアルに含まれ得るその他の考慮点がいくつかある。

リスク識別マトリックス
役割と責任 (名前は残されるがタイトルは含まれることを確認する、例えばHR Manager)
最大リスクと緩和戦略の識別
資源配置のための考慮点、例えば大規模組織の技能マトリックス
インターネット上でのBCPマテリアルの多くは、BCPソリューション開発のためのフリーベース・サービスを提供するコンサルタントによってスポンサーされるが、しかし基本チュートリアルは、正しくモティベートされた組織のためのインターネット上で自由に利用可能[12]。

BCPマニュアルの開発における分析フェーズは、影響分析、脅威分析、及びBCP計画の要求ドキュメント化に帰着する影響シナリオから成る。

影響分析 編集
影響分析(事業影響分析、BIA)は利害関係者、法律、契約等を鑑み、災害が業務にどのような影響を与えるのかを分析する行為をさす。

次に、影響分析は、各重要機能のための復旧要求に帰着する。復旧要求は下記の情報から成る。

重要機能の復旧のための事業要求
重要機能の復旧のための技術要求
脅威分析 編集

復旧要求の定義の後、可能性のある脅威の文書化が特定災害に固有な復旧ステップを詳細化するために推奨されている。幾つかの一般的脅威は以下を含む。

疫病
地震
火災
洪水
サイバーテロ
サボタージュ(内外の脅威)
ハリケーン又は大きな嵐
停電
テロリズム
窃盗(内外の脅威、重要な情報及び物品)
基幹システムの偶発的故障
上の例にある全ての脅威は、共通の影響(組織インフラへの被害の可能性)を共有する。その影響は純粋に人間として考えられ、技術とビジネスソリューションで緩和されることもある。しかしながら、もしこれら復旧計画の裏にある人間が災害によって影響を受けるとすると、そこでプロセスは失墜し得る。

2002-2003年のSARS発生の間、ある組織はスタッフを別々のチームにグループ化し、そのチームごとの災害の潜伏期間を均等化するため、輪番周期で、1次及び2次作業サイト間で交代させた。その組織はまた、勤務時間及び非勤務時間を問わず、相手チームメンバー間の対面的接触を禁止しました。そのような分離によって組織は、もし契約されたチーム又は災害に露出した人物がいても、政府支持の防疫対策の脅威に対する彼らの回復性を増大させることができた。

洪水からの被害はまた固有な特徴を持つ。もし(例えば、配管の破裂の出来事で)、事務所環境が汚染されていない淡水で浸水したなら、装置は徹底的に乾燥すればまだ機能する可能性を持っているからである。

影響シナリオの定義

潜在的な脅威定義の後、事業復旧計画の基盤を形づくる影響シナリオの文書化が推奨される。一般に最も広範囲に及ぶ災害あるいは混乱の計画化は、ほとんどすべての小規模問題が大規模災害の部分的要素であるように、より小規模問題を計画する方が望ましい。「ビル喪失」のような典型的な影響シナリオは、すべての重要な事業機能、及びあらゆる潜在的脅威からの最悪の潜在的な結果を包括する。

事業継続計画は、もし組織が一つ以上のビルを保持するなら、追加的影響シナリオもまた文書化することができる。たとえば、あるビルの特定のフロアの一時的あるいは永久的喪失のためのシナリオのような、その他のより特定な影響シナリオもまた文書化することもできる。組織は時には、一つの現場から他に移動するため必要なスペースを低く見積もります。現場を移動することは問題を持たないため、組織はそれらを計画段階で考慮することが不可欠である。

復旧要求ドキュメント 編集
分析フェーズ完了の後、事業と技術の計画要求は実装フェーズを始めるため文書化される。良い資産管理プログラムは、これへの大きな援助となり、資源の素早い利用性の識別と再配置可能性を可能にし得ます。一つのオフィスベース、情報技術集約的事業のため、計画要求は、ICE(英語版)データとしてクラス化される以下の要素を網羅することができる。

2次的場所における、一時事業所の外で求められる固定あるいは共用のいずれの、机の種類と数
復旧に係わる個人の連絡先と技術的詳細を伴う努力
重要な事業機能のため2次的場所の机から要求されるアプリケーションとアプリケーションデータ
ワークアラウンド解決のマニュアル
アプリケーションに許される最大停止時間
プリンター、 コピー機、 ファックス、電卓、紙、ペン等のような周辺機器要求
生産、配送、倉庫などのその他の事業環境は、これらの要素を網羅する必要があるが、混乱の出来事に続く管理する追加的課題を持つ。

ソリューション設計フェーズの目標は、影響分析ステージからの主要な2つの要求にこたえる最もコスト効果的な災害復旧ソリューションを識別することである。ITアプリケーションのためにこれは次のように共通に表現される。

最低のアプリケーションとアプリケーションデータ要求
最低のアプリケーション及びアプリケーション・データが利用可能にならなければいけない時間フレーム
災害復旧計画はまた、例えば、ハードコピー形式での情報の保存、技能スタッフの管理、あるいはプロセスプラントに組み込まれた技術の復旧のような、ITアプリケーション以外の領域にも要求される。

このBCPフェーズは、ディザスタリカバリ方法論とオーバーラップします。ソリューションフェーズでは以下を決める。

危機管理コマンド構造
2次作業サイトの場所(必要な場合)
1次と2次作業サイト間の電信アーキテクチャ
1次と2次作業サイト間のデータ複製方法
2次作業サイトで要求されるアプリケーションとソフトウエア
2次作業サイトでの物理的データ要求の種類

実装フェーズは単純で、ソリューション設計フェーズで識別された設計要素を実行することです。ワークパッケージ『テスト』は、ソリューションの実装期間中に行われることもあるが、ワークパッケージ『テスト』は組織的テストのところでは行われない。

テストの目的は、事業継続ソリューションが組織の復旧要求を充たす組織的受入れに到達することである。計画は、不十分あるいは不正確な復旧要求、ソリューション設計、あるはソリューション実装エラーのために失敗する場合がある。テストは以下を包括する。

危機指令チーム呼出しチーム
1次から2次作業場所への技術スイングテスト
2次から1次作業場所への技術スイングテスト
アプリケーションテスト
ビジネスプロセステスト
最低限テストは、半年度あるいは年度スケジュールで一般に実行されます。初期テスト段階で識別された問題は、維持段階にロールアップされ、次期テストサイクル中に再テストすることができる。

英国規格協会(BSI)によって発行された2008年の本『Exercising for Excellence』[13]で危機ソリューションは、事業継続計画をテストする際採用される次の3つの試験のタイプを識別した。

単純試験 編集
単純試験はしばしば「デスクトップ」あるいは「ワークショップ」と呼ばれる。それは典型的に、おそらく5〜20の少人数が係わり、事業継続計画の特定の局面、あるいは特定の主題領域(例えば、人的資源、情報技術あるいはメディア)に集中して行われる。しかしながら、単純試験の美しさは、事業の様々な領域から完全なチームを容易に対応させることができることである。その数は、そのロジスティックとともに増大されることもあるが、その目的は変わらない。

あるいは、全体チームが参加する必要よりむしろ、複数チームから一つの代表が係わることができる。それは、仮想世界の環境や日々の資源以外の必要性の提供が伴われない。一般的に、参加者は単純なシナリオを与えられ、その後会社のBCPの特定局面を議論するため招かれる。例えば、作業時間外に発見された火災では、「手順から現在の呼び出しはなにか」、「どのように事故管理チームが活性化されるか」、「どこにこれが合致しないか」、「現在の文書化された手順はすべての不測の事態をカバーするか」などである。

それはおそらく、3時間以内で最終化され、それぞれ異なったテーマに集中した2つないし3つのセッションにしばしば分離される。この場合、2つないし3つの異なったシナリオのいずれもが使われ、一つのシナリオは、アドレスされるべきニーズのテーマを導入するため進歩的に開発され得る。実時間のプレッシャーは、単純試験の通常の要素ではない。質問は、ファシリテーターが議論が生産的で出来事の目的に対して適切であることを確かにするため、時間に先だって作業されることが必要である。

中間検査 編集
中間検査は、常に仮想世界内で実行され、通常は複数の部門、チーム、あるいは専門分野で同時に行われる。それは一般的にチーム間のBCPを促す複数の側面に集中する。

中間試験のスコープは、一つのビルを共有する一つの組織の少数のチームから、分散した場所の複数のチームの広範囲におよぶ。試みは実行可能と同じ程度の現実的環境を作り出すべきで、参加者の数は現実的状況を反映すべきである。要求される現実性の度合いに依存し、それは、シミュレートされたWebサイトとともに、シミュレートされたニュース放送を生じるのに必要となる。

中間試験は数日間にわたって取り組まれますが、通常2〜3時間で最終化されるでしょう。 それらは典型的に、情報を提供し行動を促すことの試験を通してプリスクリプトされた射出で導かれたシナリオセルに関わる。

複合試験 編集
複合試験はおそらく、可能な限り少数の境界として持つことを目的として定義することが困難である。それはおそらく中間試験の一部とより多くの局面を含む。試験の要素は、必然的に仮想世界内で残されなければならないが、しかし全ての試みが現実性達成するためになされるべきである。これは、災害復旧(DR)サイトの、通知なしの起動、実際の避難、及び呼び出しを含む。

開始時間とカットオフ時間が同意されなければならない一方で、もし出来事がリアルタイムでそれらのコースを実行することを許されるなら、試験の実際期間は未知となる。もしそれが期待される45分の代わりにDRサイトを得るため2時間が必要なら、試験はこれを扱うため、十分に柔軟でなければなりません。もし主要なプレイヤーが対応できないなら、代理者がそれに備えなければなりません。

定義 編集
これらの定義は、利用可能な試験のタイプについて幅広いガイダンスを提供するが、それは考慮すべき「エッジのぼかし」があり得ることを認識すべきである。それは、異なった次元を追加することによって、復旧サイトで単純試験を実行することは可能であるが、これは必ずしも中間試験をするため必要ではない。分類に関わらず、試験の重要性は、その定義された目的を達成することにあるのである。

BCPマニュアルの維持は、3つの周期的活動に分解される。

最初の活動は、役割が対応と復旧において重要と認識される個人のための自覚と特定のトレーニングのため、全てのスタッフに次々現れる、マニュアルにおける情報の確認である。
2番目の活動は、復旧オペレーションのための確立された技術的ソリューションのテストと検証である。
3番目の活動は、文書化された組織復旧手順のテストと検証です。半年あるいは1年の維持サイクルが一般である。
情報更新とテスト 編集

全ての組織は時間を超えて変化します。そのためBCPマニュアルは、その組織に適切さを保持するため変化しなければなりません。一旦データ精度が検証されたら、通常ツリーと呼ばれるテストが、連絡先データの精度と同じように、通知計画の効率を評価することため実行される。マニュアルで識別され更新されるべき変更の幾つかのタイプは以下を含む。

スタッフ変更
スタッフ人材
重要なクライアントと彼らの連絡先の詳細の変更
重要なベンダー/サプライヤと彼らの連絡先詳細の変更
新規、閉止、又は基本的に変更された部門のような部門的変更
会社の投資ポートフォリオとミッション表明における変更
サプライヤ経路における上流/下流の変更
技術ソリューションのテストと検証 編集
進行中の維持の一部として、あらゆる特別課された技術の配備は、機能性のためチェックされねばならない。幾つかのチェック項目は下記を含む。

コンピュータウイルス定義の配布
アプリケーション・セキュリティとサービスのパッチの配布
ハードウエア運用性のチェック
アプリケーション運用性のチェック
データ検証
データ・アプリケーション
組織的復旧手順のテストと検証 編集