BCP(事業継続計画)とは?災害時にも事業を継続する為に知っておきたいこと

    年々脅威を増す自然災害の備えとして、『BCP』『事業継続計画』という言葉を耳にする機会が増えてきました。本記事では、「BCP(事業継続計画)とは何か」「BCM(事業継続マネジメント)との違い」など言葉の定義から、BCPの必要性や実際の策定の流れについて、システム障害が発生した場合を例にあげてわかりやすく解説しています。記事の後半では、システムのBCPにおいてのポイントもご紹介しています。

    BCP(事業継続計画)とBCM(事業継続マネジメント)

     企業に事業中断を引き起こさせる要因には、外部、内部ともにさまざまなものがあり、それらの発生を見越して、万一の際にも事業を継続できるよう行う対策がBCP、あるいはBCMです。似た言葉ですがそれぞれの違いについて解説します。

    BCPとは

    BCPとは、Business Continuity Planの略で事業継続計画の事を指します。災害や火災、テロなどの緊急事態において事業の損害を最小限に抑え、継続あるいは早期の復旧を実現する為の計画を指します。一言でいうと、事業を中断してしまわないための、備えやリスクマネジメントのことです。

    BCPは国際規格(ISO)や日本国内の規格(JIS)にも標準的に指定され、対策や検討すべきものだといえるでしょう。

    BCMとは

    BCMとは、Business Continuity Managementの略で事業継続マネジメントを指します。企業がBCP(事業継続計画)に取り組むうえで、その計画の運用・見直しという改善を含む、包括的・統合的なマネジメントのことです。

    英国規格協会:BSIでは、「組織を脅かす潜在的なインパクト(脅威)を認識し、利害関係者の利益、名声、ブランドおよび価値創造活動を守るため、復旧力及び対応力を構築するための有効な対応を実施するフレームワーク、包括的なマネジメントプロセス」と定義されています。

    BCPは、事業停止のリスクが発生した際の対策について具体的な具体的な計画を策定する事を指します。たとえばシステムの冗長化や遠隔地へのバックアップ、災害に耐えうる設備の実現、避難経路や重要書類の保護をどうやって行うかなどを具体的に計画します。そしてBCMは、BCPの内容を定期的に見直しながら運用していくことを指します。

    BCPとBCM

    BCP(事業継続計画)取り組みの例

    では、実際にどのような取り組みをするのか、例を挙げてみます。
    いつどこで起きる変わらない万が一の事態に備え、何が必要か、何を優先するべきか常に考えアップデートする必要があります。

    例)震災・津波

    ・社員やその家族の安否確認システムの導入
    ・発生する被害の想定
    ・事業再開までの時間など目標の制定
    ・避難マニュアルの作製・配布
    ・業務システムが停止した際ののデータバックアップや、切替先について

    上記以外にも台風や火災、テロ、感染症から、サービスの停止や品質不良まであらゆるリスクに対して対策を立てます。

     

    BCP(事業継続計画)が注目されている3つの理由

    今、なぜBCPの必要性が問われるのでしょうか。注目される背景を見ていきましょう。

    1.大規模な自然災害や新型感染症の発生

    事業を継続できなくなる外的要因には、さまざまな要因があります。そのひとつが大規模な自然災害や事件・事故です。ゲリラ雷雨や台風による被害は年々大きくなっていますし、地震も頻発しています。物理的に社屋やシステムが被害を受けるケースも少なくありません。

    また、テロによる影響や、新型コロナウィルスのまん延による事業停止も記憶に新しいところです。企業にとって、事業停止のリスクを把握し、有事の際の対策を明確にしておくことは喫緊の課題といえます。

    2.企業における拠点の集約化

    他の要因として、コスト削減と効率化を目的とした事業の集約化が挙げられます。一時期はコスト削減のために海外を含めた拠点の分散化が進んでいましたが、コストメリットが少なくなったことで、生産拠点や物流拠点、取引先などの集約が進んでいます。このため、集約された拠点に障害が発生した場合の事業停止のリスクが増加しています。

    3.業務のシステム化

    IT化の進展による業務のシステム化も要因のひとつです。受発注処理から工場での生産、社内外との連絡、経理、また通販や電子決裁の発展もありほとんどの業務がITシステムとネットワークの上で行われています。このため、ステム障害やネットワーク障害などが発生すると、たちまち業務に影響をきたします。

    また、こうした障害は外的な原因に限らず、業務拡大における新社屋への引っ越しや新工場の稼働、メンテナンスなど、本来企業が成長するためのことでも停止する可能性があります。

     

    企業は、こうしたさまざまな事業停止のリスクに対し、それぞれ対策をする必要があります。社員が出社できない場合はどう業務を遂行するか、停電した場合にITシステムの電源をどう確保するか、社屋が物理的なダメージを受けた場合にはどう対処するかなど、考えるべきことはたくさんあります。

    BCPやBCMは、万一の事態に対処するための施策で、投資も必要になります。そのため、事業停止の危機に直面しないと、その必要性が実感できないかも知れません。しかし、そうなったときには手遅れなのです。まずは企業のトップが事業停止のリスクを認識し、平常時から万一の事態を想定して備えておくことが重要です。

    また、BCPやBCMといった対策を公表することは、関連企業やステークホルダー、お客様などに対する安全さのアピールにもなります。これは社員に対しても同様で、BCPやBCMを策定することで安心して業務ができる環境を構築できます。人材流出の遠因にならないためにも必要な対策といえるでしょう。

     

    BCP(事業継続計画)における4つのフェーズ

    BCPには、大きく分けて4つのフェーズがあります。それぞれの段階を踏まえた計画が必要です。ここからはシステム障害が起きた場合を例に取ってご紹介します。

     

    1.BCP発動フェーズ

    第一ステップのBCP発動フェーズでは、災害などの発生により、状況確認や初期動作を実施します。迅速に対策本部を起ち上げ、正確な情報を収集しつつ、基本方針を再決定しなければなりません。

    基本方針には、業務の優先順位や、要員・経営資源の配置計画などがあります。まず、どの業務を死守しなければならないか、影響度合いなどを見ながら検討していきましょう。人員配置も重要であり、システム管理者など、スキルのある要員や決定権を持つ管理者が必要です。BCP対策を発動するタイミングや範囲も決めておくとよいでしょう。これがなければ、対策本部を収集する際にためらってしまう可能性があります。

    とはいえ、全てのリソースをBCPに割くと大変です。状況に応じて対策範囲や人員の収集範囲を決定しておけば、最小限の部分的な対策ができます。さらに、顧客への対応方法や復旧目標・計画を立て、初期対応を実施します。

    2.業務再開フェーズ

    業務再開フェーズでは、予備機や待機系サーバの利用、手作業などの代替手段で運用を再開するステップです。あらかじめ決めた基本方針や手順に従い、復旧作業を推進します。進捗管理だけでなく、BCP基本方針の見直しも重要です。

    しかし、いざ代替手段での業務を再開しても、普段慣れない運用をするため、ミスが発生しやすくなるおそれがあります。事前に手順書を作ったり、全社的に訓練したりするなど、緊急措置に備えるのも有効です。

    3.業務回復フェーズ

    運用の停止が致命傷となる重要業務を再開できた後は、他の業務の再開を検討する必要があります。しかし、急な範囲の拡大は現場の混乱を招いてしまうため、慎重に判断することがポイントです。

    利害関係者やマスコミから全面的な復旧の目途について、情報を開示するよう求められる時期でもあります。臨時体制を敷いている中で、どこまで業務再開を拡大できるか、見極めが重要になるでしょう。

    もし障害が起きているシステムを復旧させるのであれば、人員と物品を確保しなければなりません。また、システムを復旧させるだけでよいのか、機能の追加や更改をするのか、業務から撤退するのかを戦略的に判断・決定します。このように、全面的解決に向けたシナリオとマニュアル・手順書の作成が必要になります。

    4.全面復旧フェーズ

    最後は全面復旧フェーズです。これまでの代替手段での臨時業務から、平常運転へ切り替えます。復旧切り替え時にミスや業務を停止してしまうリスクがあるため、綿密な計画を立てなければなりません。どこにどのような影響があるかを洗い出し、部署の垣根を越えて関係者を集め、レビューをすると漏れを減らせます。

    また、代替手段の運用を実施したために制限された業務やデータを把握し、通常業務に戻した際の影響も考慮が必要です。基幹系のシステムであれば、データ全面復旧のタイミングで、差分の手入力など修復作業も発生するでしょう。全ての状況が元に戻ったら、BCPの振り返りです。計画した内容や実施した対策は有効的だったか、改善点はないかと振り返ります。

    今後同じような事象が起きた場合に備え、より影響を及ぼさないBCPを策定しましょう。

     

    BCP(事業継続計画)構築・策定の流れ

    BCPやBCMを構築する目的は、事業停止のリスクとなることが発生した際に、「いかに事業を継続させるか」、あるいは「いかに事業の停止時間を短くするか」となります。このため、対象範囲となるのは基本的にすべての事業、業務、施設、人員となります。とはいえ、いきなりすべてを対象に対策を練るのは難しいため、たとえば対象を基幹業務や重要な業務のみ、あるいは人員の安全確保などに限定するといいでしょう。

    対応チームの編成

    まずはBCP、BCMのための責任者と対応チームを編成します。緊急時において最高意思決定機関として位置づけられ、BCPの指揮を執ります。各フェーズにおいて、意思決定をしたり、状況の把握や進捗管理をしたりしなければなりません。

    そのため、チームには、なるべく経営の視点を持つ「Cクラス(CEOやCTO、CMOなど)」の人間と、部署を横断したメンバーを集めるべきでしょう。また、普段は各自の業務を実施し、必要なときや緊急時にチームを編成できるようにします。構成メンバーに総務部や情報システム部を加えようとすると、社内外の混乱に対応する業務に稼働を取られ、招集できなかったり、機能しなかったりするおそれがあります。

    このようなことをあらかじめ想定し、それぞれの部署で機能別にチームを分けておくとよいでしょう。対策本部の設置は、事が起きてからでは後手に回る可能性が高くなります。自然災害など予見できないものは仕方がありませんが、大規模なシステム更改など、あらかじめ混乱が予想されるイベントがあれば、事前にメンバーを招集しておきましょう。

    リスクの洗い出し・対策方法の検討

    チームを編成したら、継続すべき業務の優先度を決定し、それに対して起きうるリスクと継続のための対策法を立てていきます。具体的な検討項目の例を挙げてみましょう。

    (1)優先して継続・復旧すべき中核事業を特定する

    (2)緊急時における中核事業の目標復旧時間を定めておく

    (3)緊急時に提供できるサービスのレベルについて顧客とあらかじめ協議しておく

    (4)事業拠点や生産設備、仕入品調達等の代替策を用意しておく

    (5)すべての従業員と事業継続についてコニュニケーションを図っておく

    これ以外にも、有事の際の連絡網設定や、社外の連絡すべき場所もピックアップしておくとよいでしょう。また、大規模なシステム障害やウイルス感染、情報漏えいなどの場合には、警察や経済産業省など、関連省庁への連絡も必要になります。あらゆるケースを想定しておくことが重要です。BCPを策定したら、シミュレーションをして定期的にその内容を見直していきます。そのPDCAのサイクルがBCMであるといえます。そして、BCPの意識を全社に広げていくことが重要です。

    BCP策定までの流れ

     

    厚生労働省など政府が策定したマニュアル・ガイドライン

    このほか、BCPの取り組みに関する情報開示も義務づけられています。2003年3月には、「企業内容等の開示に関する内閣府令」等が改正され、有価証券報告書において「事業等のリスクに関する情報」の記載が義務付けられた。単にリスクを開示するだけでなく、BCPの取組みについて触れる報告書も多く、この流れは今後加速していくでしょう。

    厚生労働省や経済産業省、金融庁はBCPについてマニュアルやガイドラインを策定しています。それぞれ見ていきましょう。

    厚生労働省

    厚生労働省では、社会福祉施設や事業所において新型インフルエンザが発生した場合のガイドラインを設けています。

    厚生労働省 感染対策マニュアル・業務継続ガイドライン等

    内容には、発生段階の定義や、そのステージに応じた対策が記載されています。施設によって予防方法などを変え、業務を継続するためのポイントも提示しています。ガイドラインの目的や「BCPとは何か」といった基礎知識も含まれているため、誰が見ても分かりやすく、BCPを知らない人にとっても読みやすくなっています。

    経済産業省(中小企業庁)

    このほか、経済産業省がBCPおよびBCMについてのガイドラインを公開しているほか、業界ごとにガイドラインが策定されています。関係省庁の情報を調べてみるとよいでしょう。

    中小企業BCP策定運用指針

    書類での情報提供だけでなく、動画配信サービスなどを利用して、危機管理について学べる映像も視聴できるようになっています。有識者へのヒアリングや、各企業へのアンケート結果も豊富に提示しているため、自社の取り組みにおいて、参考になる情報があるでしょう。

    また、BCP対策の訓練テキストなどを利用して、セミナーも開催しています。

    金融庁

    金融業界では金融庁が危機管理体制の構築を求めているほか、BCPやコンティンジェンシープランなどに関する取り組みについての情報開示を自主的に行っているケースもあります。

    金融庁 BCP(業務継続計画)等について

    例えば、金融庁のホームページにBCP対策における着眼点として、バックアップセンターの配置や、冗長ネットワーク経路の確保が掲載されています。その他、危機管理マニュアルの策定や風評リスクに対する体制の整備も推奨しています。

    BCPやBCMの策定は、万一の事態が発生しても事業を継続するための重要な施策であり、企業価値を高めるものでもあります。それは単に紙上のものだけでなく、有事の際に実際に遂行できる内容が求められます。事業停止のリスクは、業界や規模に関係なくすべての企業に存在します。他人ごとだと思わず、自社の評価を落とさないためにも必要な施策なのです。

     

    システムのBCP(事業継続計画)に重要な2つの指標

    システムのBCPにおいて、気に掛けるべき重要な指標が2つあります。これらの評価を上げるのであれば、それなりの投資が必要です。

    RPO(目標復旧時点)

    RPO(Recovery Point Objective)とは、どの時点まで復旧させるかの目標値です。障害が発生した際、時間の流れをどの地点までさかのぼったシステムのデータを復旧させるかを表します。

    例えば、午前1時にバックアップを取得し、午後7時にサーバがクラッシュすると、その日の業務で蓄積したデータがほぼ全て失ってしまいます。伝票などの帳票で手入力復旧が可能、もしくは業務的に許容できるのであればそのままでよいかもしれません。しかし、許容できないのであれば、バックアップ間隔を短くするなど、RPOを短くする必要があります。

    しかし、日中帯のバックアップはネットワークやサーバに負荷をかけてしまい、業務に影響を与えてしまう可能性が高くなります。そのため、メンテナンス用ネットワークを実装するなどの、コストがかかるでしょう。データの損失が全く許容できないのであれば、リアルタイムでレプリケーションを作る、更新するたびにストレージの同期を図るなどの対策が必要です。

    このように、RPOを高めようとすると、一般的には高度技術の投入やスペックのよい機器などの投資を増やさなければなりません。

    RTO(目標復旧時間)

    RTO(Recovery Time Objective)とは、いつまでに復旧するかの目標値です。障害によって破損したデータをいつまでに復旧するのかを表します。

    例えばRTOが「3時間」であれば、システムの復旧を3時間以内に行うということ。RTOは、事業を継続させるという観点から、BCP策定の際にも重要視されます。秒単位から日単位で表し、一般的に時間が短ければ短いほど高い投資が必要となります。もし、RTOの間隔が長くて良ければ、予備機などをコールドスタンバイ状態にしておき、障害発生時にサーバの起動とリカバリをする余裕があるかもしれません。

    しかし、業務の停止がほとんど許されない状況だと、クラスタ構成にしつつ、障害を検知した際に待機系サーバに自動で切り替えるなどの技術が必要です。稼働系サーバと同じ状態にする必要があれば、常に同期を取らなければなりません。そのためには、ネットワークを強化したり、サーバを高スペックにしたりしなければならないでしょう。

     

    ソフトウェアを利用したシステムを止めない仕組み

    では、実際にどんな対策をしていくべきなのか。先述したように、多くの業務やサービスがシステムに頼っています。システムに障害が起きると業務もサービスも動かなくなってしまう。そういった、BCPの観点で止まっては困るシステムの可用性を向上させる手段はいくつかあります。

    その一つがHAクラスタリングソフトウェアを使用したHAクラスタリング構成というものです。1台のサーバーでは得られない可用性の向上を目的とし、複数台のサーバを相互接続し連携構成(クラスタ)化するものです。つまり一か所が停止しても待機していたサーバーが自動で引継ぎ、事業継続を実現するのです。

    ・データレプリケーション構成

    ・共有ディスク構成

     

    詳しい仕組みや構成については下記の「HAクラスタ―とは」をご覧ください。

    可用性やHAクラスタリング構成についてご相談したい場合はお気軽にお問い合わせください。

     

    SNSでもご購読できます。