BCPとは？

　BCPとは日本語では事業継続計画と呼ばれ、英語ではBusiness Continuity Planの略称です。企業においてはリスクマネジメント活動の一環として実施されるBCP策定ですが、その目的は災害等の非常時においても事業を止めることなく継続することで、顧客の信頼を獲得できる、ビジネスチャンスを逃さずに収益を上げることができる、さらにはセキュリティを担保することができるというメリットを期待するものです。

　BCPの策定や検証は企業におけるリスクマネジメント活動の一環として実施されるため、大手企業や金融機関などリスクマネジメントの専門部署であるリスク管理部が存在する場合にはリスク管理部が担当しますが、多くの企業においては総務部が担当することが一般的です。

　BCPが整っていることはプライバシーマークやISO27001（いわゆるISMS）等においても評価項目となっているため、企業における情報セキュリティの確保という意味でも重要視されています。

BCP策定の意義

　BCPを策定することには様々なメリットがありますが、よく例示されるのは以下のようなメリットです。

１．事業継続に対するリスクが軽減される

　適切に策定・管理されているBCPは飾りではありません。企業の非常時において、事業を継続するために必要な計画が詳細に記されており、実効性を担保できるように日常的に検証と訓練が繰り返されています。災害などの非常事態においても、事業を継続し、必要な収益を確保することを担保するのが適切なBCPです。

２．企業としての信頼が増す

　近年ではBCPの取り組みを対外的に公開することで企業としてのガバナンス体制を示し、利用者や投資家等の利害関係者からの信頼を勝ち得ています。コンビニエンスストアなどが災害時においても営業を継続し、被災地への物資供給の拠点となることは珍しくありませんが、これらの業務をみて、消費者は企業への信頼を深め、企業はブランドを構築することができます。

３．従業員の安心感が増す

　BCPには事業を継続するためには必須である従業員の安全管理も含まれています。かつて自分が勤めた会社が大震災に見舞われて、自宅への帰宅が困難になったことがありましたが、会社から食料や寝具など、非常事態に備えた物資が支給され、オフィスに数日の間、留まったことがあります。後に聞いたことですが、これらの対応はBCPのシナリオに含まれていた事態に対する対応であったそうです。

　総合して考えると、BCPを策定する意義はガバナンス改善を通じた企業価値の向上にあります。つまり、企業活動を継続するためにリスクとなり得る事象を特定し、それらに対する適切な対応をとるための体制や手順をあらかじめ整えておくことで、非常時においても安定した業務の遂行およびサービスの提供が可能となる企業統治を備えることこそがBCP策定の意義と言えます。

チーム組成から始めよう

　BCPの策定において、まず初めに大事になることが「チームの組成」です。BCPは企業統治（コーポレートガバナンス）の一部であり、リスクマネジメントの領域にも該当します。とはいえ、コーポレートガバナンスやリスクマネジメントの専門部署を持つ企業は金融機関など特殊な業種に限られ、一般的な事業を行う企業であれば、これらの専門部署を持つ企業は大企業にも多くないでしょう。それがゆえに、BCPは「どの部署が担当するのか？」という点が不明確になりやすく、チームを組成するのも大変です。

　そのような事情から、多くの企業においては総務部が担当する場合も多いので、困ったらまず総務にお願いしてみるのがいいでしょう。もしそれも難しいようであれば、各部署から集めたプロジェクトチームやタスクフォースからスタートすることもまた考えられます。

　もしあなたがBCPの策定をする責任者に任命されたなら、まずはチームの組成をして、責任が誰にあるのかを明確にする必要があります。そして、そのスポンサーとなる役員や上席者からの支援も忘れずに取り付けましょう。

BCP策定の手順

　前述の通り、BCPの策定は企業におけるリスクマネジメントの一環であるため、その策定の手順は以下の通り、リスクマネジメントの基本的な手順と同じになります。

　これらの４つのステップを毎年、もしくは３年に一回などのペースで繰り返すことになります。

Step1 リスクを特定する

　BCP策定に限らず、リスクマネジメントにおいては、リスクを特定することから作業が開始されます。企業の事業継続を脅かすリスクとは何かを幅広く検討します。業種に限らないリスクもあれば、その業種だからこそ発生するリスクも存在します。

リスクの例

業種に限らないリスク

・　地震、火災、津波、疫病（パンデミック）等の災害

業種によっては発生するリスク

・　免許制や許可制などの事業における免許もしくは許可の取り消し

・　小売業や製造業におけるサプライチェーンの分断

　ここで挙げた例は、BCPの策定において特定されるリスクの一例にすぎません。その他にも、会社の事業の特性により様々なリスクが存在するはずです。検討していないリスクについては対策がなされない結果となるため、最初のリスクの特定作業は全ての作業の中で最も重要な作業になるといっても過言ではありません。それゆえ、この作業を軽視せず、しっかりと取り組むことが重要となります。

では、リスクの特定においては具体的にどのような作業を実施すればよいのでしょうか。これはBCPの策定にどれくらいの工数をかけて実施するかによって、いくつかの選択肢があります。

１．ワークショップ形式でブレインストーミングを実施する

　全員の時間を合わせて、オンラインもしくはオフラインでブレインストーミングを実施する方法で、最も実施コストが高いですが、リスク特定という意味では最も効果が高い方法となります。災害等の一般的な事業継続のリスク以外にも、それぞれの会社の事業に特有のリスクの洗い出しを行うためには事業理解度の高いメンバーの参加を促す必要があります。

２．BCP策定担当者レベルで検討し、事業を理解する役員や他部署にもインタビューを実施する

　ワークショップを開催する方法は全員の時間を合わせる必要があるため、実施するには全員の日程調整を必要とするなど、多くの準備が必要となります。そのため、個別にインタビューを実施しながら回答を集め、BCP策定を担当するチームでリスクを集約し、まとめるという方法がとられることがあります。この方法では断片的な意見を集約し、繋げながらリスクを特定するため、BCP策定のチームには高いレポート作成力と意見を引き出すファシリテーション力が求められます。

３．BCP策定担当者レベルで検討し、事業を理解する役員や他部署に文書で質問し、回答を得る

　最も労力が少ない方法として、質問票を回覧しながら各人の回答を集め、リスクを特定していくという方法があります。この方法であればインタビューのように時間を固定せず、空いた時間に回答してもらうことができますので、回答する各部署の担当者の負担は少なくなります。一方、質問票の作成にはそれなりの時間が掛かり、質問していること以外には回答者は答えてくれないので、質問票の作成にはかなりの時間を要する可能性があります。

　個人的によく見かける方式は、まだBCPを持たない企業がBCPを策定するために行う初回のヒアリングはワークショップ形式、もしくはインタビュー形式で実施し、その後のアップデートは質問票で行うという方式です。

リスク特定の際の注意点

リスクを特定する際の注意点としては、３つのポイントが挙げられます。

１．否定的な意見を先行させず、現実性に欠けると思う内容も真摯に検討する

　リスク特定に限りませんが、ブレインストーミングのように幅広い可能性やアイデアを検討する場合は否定的な意見を先行させてはいけません。既存の常識から考えれば、馬鹿馬鹿しく思えるほどに非現実的な内容にこそ、真摯に検討する価値があるかもしれません。ウィルスによってパンデミックが起きる可能性など、コロナ禍以前であれば真面目に検討するに値しないと考える人もいたと思いますが、そういった意見もリスクとして特定していくべきです。

２．部署内等の狭い範囲の人材で検討せず、必ず事業を理解する役員や部署の責任者にも話を聞く

　バックオフィスが主体で取り組むBCP策定によくあるお話ですが、バックオフィスの人だけで検討が進み、前線で事業に取り組む営業やカスタマーサクセス、生産管理等の現場に対するインタビューを実施しないことがあります。

　バックオフィスの人たちが事業を理解していないとは考えませんが、日々、現場で業務に取り組む人たちは環境の些細な変化やリスク等を敏感にとらえています。残念ながらバックオフィスと現場では事業に対する情報感度が異なるというのが事実です。

　当然、十分な準備をしてインタビュー等に臨むことは重要なことですが、役員や他部署の責任者の時間を使うことに対して遠慮や委縮をすることなく、何らかの形でヒアリングを実施しましょう。

３．リスクの特定は３年毎や毎年など定期的に実施する

　一度、十分なリスクの特定を行えば、その後のリスク特定は実施しなくても良いと考えている方が稀にいますが、それは間違いです。日々変化する事業環境により、企業が抱えているリスクもまた変化します。新規の事業を買収した、規制強化が起きて対応するべき内容が増えた等、今日のビジネス環境では事業に変化が起きる可能性は高いです。

　こういった変化によって新たに発生したリスクの特定を漏らさないように、リスクの特定作業は３年に一度や毎年など、定期的に実施することをルールとすることをお勧めいたします。

大変すぎて手に負えないと思ったら。。。

　もし上記のリスク特定が手に負えないほどに大変な作業だなと思ったら、まずはスタートすることが大事です。私がお勧めする簡単な方法は、「過去の事例から推測するシナリオ作成」です。過去に起こった大規模な事象をもとに、事業継続に決定的な影響を及ぼす可能性があるシナリオを4つ考えることから始めてください。

例えば、

・コロナウィルスの蔓延によるパンデミックの発生
・東日本大震災規模の大地震の発生
・戦争勃発によるサプライチェーンの分断
・主要な事業の免許の取り消し

といったところでしょうか。まずはこれら４つのシナリオをベースに後続の手続きを進めてみるのが最も簡単な方法です。

STEP2 リスクを評価する

　リスクの特定が終わったら、次に実施するのがリスクの評価です。もしあなたがリスクの特定に真摯に取り組んだのであれば、その手元にはゆうに100を超えるリスクが特定されているはずです。それらすべてのリスクに対して対応策を考え、備えの準備をしていては1年あっても時間が足りません。

　リスク評価の目的はリスクに対して優先順位を付けることです。限られた時間の中で、特定したリスクのうち、どのリスクから対応していくべきなのかを考えるためにリスクの重要性を決定して行く作業がリスク評価となっています。

　リスク評価の手法はひとつではありません。場合によっては複数の手法を組み合わせたり、自社の事情を汲み取ったうえで独自の評価手法を利用したりします。ここでは、よく用いられる典型的なリスク評価手法をご紹介します。

４象限を利用する方法

よく見られる簡便的な手法として、「影響の重要性（Magnitude)」と「発生可能性（Probability）」の２軸を利用する４象限を設定する手法があります。

　この手法においては発生した場合に影響の重要性が「高い」のか「低い」のか、特定したリスクが顕在化する可能性が「高い」のか「低い」のかを評価することでリスクを４つの象限に分類します。

　後の手続きとしてリスクへの対応を決定する必要がありますが、例えば、影響の重要性が狭く、発生の可能性も低いリスクは受容可能なリスクだとして、何も対応しないと決定することもできるなど、対応を決定するプロセスとの連携も簡単で良く用いられる手法となっています。

メリット

• ４象限によりビジュアル化が簡単であるため、リスクの分類が簡単

• ４象限によりビジュアル化が簡単であるため、知識があまりない人にも理解しやすい

• ２軸を基本に評価が進むため、手続きが簡単

デメリット

• ２軸を「高い・低い」という極端な２択で評価するため、リスクに対して精緻な評価をすることが難しい

スコアリングする方法

　４象限を利用する方法のデメリットである、精緻な評価ができないという問題を解決するのがスコアリングを利用する方法です。４象限法で紹介したのは影響の重要性と発生可能性でしたが、これらをもう少し分解すると、例えば「影響の重要性」は「影響の範囲」と「影響の深度」に分けることができます。

　これを軸に加えて、それぞれに対するスコアを１から５までの間、もしくは１から１０までの間で決め、全てのスコアを乗じることでリスクを評価する手法です。

　例えば、発生した場合に影響の重要性が高い場合はスコアを「5」、その影響範囲が広い場合は「5」、但し、発生可能性が低い場合は「1」と評価するとそれらの掛け算の結果は「5×5×1×＝25」となります。

　スコアの水準別に対応を決めておく等することで、評価したリスクに対する対応もスムーズに決めることができます。

メリット

• リスクを評価する軸の数に制限がない

• 数字というなじみがある尺度で評価結果がでるため、誰にでも理解しやすい

デメリット

• 評価モデルが複雑化する

• 評価項目が増えるので、評価に時間が掛かる

• 数字であるため、感覚的な評価に根拠を求められやすい

　このように、評価の手法は複数ありますが、これにしなくてはいけないという手法が決まっているわけではありません。適切にリスクを評価できるのであれば、より複雑な統計的な計算を用いる手法から、より簡便な方法も認められます。

STEP3 リスクに対応する

　リスクに対応する対策を検討する場合、一般的にリスクマネジメントの観点からは4つの選択肢があります。4つのTと呼ばれる「Terminate：回避」「Treat：軽減」「Transfer：移転」「Toralate：受容」がそれに該当します。

受容（Toralate）

　もしリスクが特定されたとしても、その重要性によっては何もせずにリスクを受容するという選択肢をとることが可能です。継続的な監視が必要とはなりますが、発生可能性とその影響度もともに低い場合、それに対して特別な対策を実施することは会社としては合理的ではありません。その場合は、リスクを受容するという選択肢をとりましょう。

軽減（Treat）

　リスクが特定されたときに、最も多く選択されるのが軽減です。情報が漏洩するリスクが特定された場合は、内部統制を強化し、複数人によるチェック体制を敷く、もしくはシステムを導入することでリスクを軽減するといった行為が軽減に該当します。例えば、電子メールの誤送信を防止するために添付ファイルにパスワードをかけて、別のメールで送信するという会社のポリシーがこれに該当します。時にはシステムを導入し、添付ファイルには必ずバスワードが設定されるようにするなどの対策をとる場合もあり、リスクを軽減する手段は様々、存在します。予算やリスクの重要性を考慮して、どういった対策をもってリスクを軽減するかを決める必要があります。

移転（Transfer）

　移転はその名の通り、特定したリスクを第三者に移転する選択肢です。リスクの移転には多くの場合、保険やアウトソース（外注）という手段が用いられます。例えば、ＩＴシステムからの情報漏洩のリスクが検出された場合、リスクへの対応としてサイバー保険に加入する、会社として業務をこなす人員を確保することに不安がある場合、特定の業務をアウトソースしてしまうといった対応がこれに該当します。

回避（Terminate）

　回避は究極の選択であり、最も意思決定が難しい選択肢です。特定したリスクが会社として受容できない、もしくはリスクをとった結果として得られる利益をリスクが上回ると判断した場合に選択されます。例えば、新規事業のリスクが大きい場合にはその事業から撤退するといった場合がこれに該当します。

　上記の4つのTを参考に、リスクに対する対応を決めましょう。これらの対応においては、このリスクレベルだから、この選択をしなくてはならないというルールがあるわけではありません。会社としてどの選択肢が合理的なのかは、現在の会社のリソース（社員数や予算）や戦略など、様々な要素を考慮して決まります。

STEP4 検証する

　では、リスクの特定、評価、そしてその対応までを終えたなら次に実施することは検証です。決められたリスクへの対応策は本当に実行可能性があるものなのか、本当にリスクに耐えられるものなのかを検証し、もし、もし現状でその対策に実行可能性がないのであれば、実行できるように訓練をする、もしくは別の対応策に変更するなどの意思決定を改めてする必要があります。

　この章では検証の作業とはどういうものなのかを具体的に想像できるように、これまで筆者が見てきた実例を紹介します。

Case 1　金融機関

　大手金融機関においては大量の書類を事務処理するという作業が存在します。それらの書類は毎日数千という単位で指定拠点へと届き、大量のオペレーターによりシステムへとデータ入力されていました。BCPという観点で考えた場合、このデータ入力の作業は全ての処理の起点となっていて、これが滞れば、サービスの提供が止まるという非常にリスクが高い業務と評価されていました。

ここで特定されていたリスクを紹介すると以下の通りです。

• パンデミックによりデータ入力オペレーターの半数超が欠勤する

• 地震や津波の発生により半数超のオペレーターが出勤できない状況になる

　これに対する対策として会社が選択していた対応は「軽減」であり、オペレーターの半数が出勤できない場合は、事業継続の観点から一時的に業務が停止しても構わない営業等の他部署の人員がデータ入力の事務作業を代行できるようにする体制をとることとしていました。

　ここで行われた検証は「ランダムに選択された営業部の社員が本当に業務に必要な速度でデータ入力業務を実施することができるのか？」をテストするという内容でした。結果、残念ながら選ばれたほとんどの営業部の社員はそのテストをクリアすることができず、この対策の実効性を高めるため、営業部の社員は年に一度のデータ入力業務の研修受講が必須となりました。

　同時に会社はさらに実効性を高めるための対策として、データ入力をOCR等の技術を用いて自動化し、人に対する依存を低めるという選択もしました。その結果、1年後にはデータ入力の部署の人員は半数以下に削減され、データ入力業務は半数以下の人員でも継続することができる体制となり、大幅なコスト削減も実現しました。

Case 2　IT企業

　IT企業においてSaaSによりサービスを提供する場合、サービス提供のためのデータの保持は必須条件となっています。こういった会社ではデータをバックアップしておいて、データが何らかの理由により消失した場合には、バックアップデータを復元できるようにしておくという対策をとることが一般的です。

　しかし、これらのデータのバックアップが保存されていたとしても、それを適切に復元できるかどうかはわかりません。顧客が求める時間内に復元できるのか、技術的に本当にバックアップからデータを復元することができるのかなどの内容は実際にその検証をしてみないとわからないことも多いです。

　この企業では３年に一度の検証項目として、検証環境におけるバックアップを利用したデータ復元が設定されており、バックアップからデータの復元までのプロセスが何度も検証されていました。

　その他、ITサービスでたびたび問題になるのがクラウド事業者への過度な依存です。マネージドサービスと呼ばれるクラウド事業者が用意するサービスを利用することでシステム構築が簡単になる反面、特定のクラウド事業者への依存が強くなるため、もし利用する事業者のサービスが停止した場合には、自社のサービスも停止する事態は避けられません。

　とあるSaaSを提供するIT企業ではBCPの観点からマネージドサービスの利用を取りやめるよう、アーキテクチャをすべて見直しました。その上で、サービスをクラウド事業者間の移行が可能になるアーキテクチャに再構築し、クラウド事業者のサービス停止というシナリオへの対応を行いました。当然ながら、数年に一度は移行の検証を行っています。

最後に

　検証を行った結果、自分たちが設定した対応が実はリスクに適切に対処できていないということがわかることがあります。これらの問題が検出されることはBCPが不適切であったということを意味しません。

　BCPの策定において最も重要なことはリスクの特定から評価、対応、検証というサイクルを繰り返し、そのBCPの実効性を高めることにあります。そのサイクルを継続的に回すことでBCPは洗練され、非常時における企業そして、社員の行動を促す羅針盤となるのです。大事なことは、まず簡単にでもBCPを策定し、求められるサイクルを回すことです。そのスタートを切ることができれば、そのBCPはいずれ他社には簡単に模倣することができないあなたの会社の競争力となります。

　そして、非常事態が発生したときにBCPが見事に機能する企業とそうではない企業の間では顧客からのブランド認知に大きな差が発生し、企業に競争力をもたらすのです。きっとこの記事を読んでいる人たちも災害時に営業を続けるコンビニエンスストアを見て、そのブランドへの信頼を深めた経験があるはずです。

　「BCPへの取り組みはまだ早い」とは考えずに、まずは簡単にでも計画の策定をスタートしてみましょう。