こんばんわ、稲田商会です。
さきほどふと思いついたので、ＢＣＰ（業務継続計画）に関連した話を書きます。
○事の起こりは
以前に居た会社で、業務継続計画の一部、社内ＬＡＮに関する部分を自分なりに考えたことがあります。
それは、ファイルサーバのバックアップをひとまず設定した後に、上司と次のようなやり取りをしたからです。
上司：「これでファイルのバックアップは上手く行くな」
自分：「そうですね。でも、異常発生時にバックアップから本来のサーバに戻すとかの人為的操作の部分はこれから考えないといけませんね。」
上司：「そういえば社長から、ＢＣＰの作成を言われていたわ。そんときは協力してよ。」
自分：「ＢＣＰって、なにかあったときにどう業務を続けるかってやつですか？」
上司：「そうそう。まあ、なんか考えてみてや。」
私には、ファイルサーバのバックアップを考える際に、「どのような状態が発生しうるのか」「その状態をどの程度許容するか」「その状態への対策にどの程度のコストが掛けられるのか」などの条件を設定するのがとても難しく感じたので、「ＢＣＰなんてとても考えられそうにない」と思ったものです。
○すこし考えてみる－リスクの洗い出し
上司に言われたので、少しは考えてみようと思い、頭の整理をしてみました。
まず、ＢＣＰとは何ぞやと調べてみました。
すると、「何かが起きた」際に「どのようにしよう」を予め想定して取りまとめたもののようです。
ほかに、リスク管理、危機管理などの文言も見られます。
そのあたりをキーワードにして、ぐぐる先生に導かれながらふらふらとさまよったのち、次のように考えるようになりました。
・はじめに「リスクの定義」
「リスクの大きさは、そのリスクの発生確率と、発生したことによる影響の大きさを掛け合わせたものである」との表現を見たように思います。
それをみて「なるほどなあ」と感心しました。
なにか危機管理の話をするときに、「○○について考える必要がある」「それはほとんど起きないだろう」「でも起きたら重大な事態になる」「そこまで考える必要はない」のやりとりが頻繁に発生するように思います。
そのときに、「じゃあ、リスクの大きさで決めよう」と言えば話が先に進む訳です。
「そうか、話の土俵がしっかりしていなかったのか」と納得しました。
・比較できるように「序列をつける」
リスクの大きさを比べるためには、何らかの形で序列をつける必要があります。
ここでいう序列は、“上位グループ”、“中位グループ”、“下位グループ”や“頻繁に起こる”、“たまに起こる”、“ごく稀に起こる”などの「順序のあるグループ分け」程度の意味です。
実体験として、この「序列をつける」ことは、大変重要と考えます。
というのも、話をしている相手との認識が合わないとき、一番問題になるのが「程度」の認識が合わないことです。
共通のスケールとして「序列をつける」ことで、「これはＣランクだから、一旦おいておこう」「これはＡランクだからすぐ対応しよう」などの認識を合わせることができ、それによって議論をすることが出来るようになります。
・対象にするのは全ての「ステークスホルダー」
リスクを考えるときに誰を対象に考えるかで、結果が全く異なります。
ステークスホルダーについて、Ｗｉｋｉｐｅｄｉａから引用します。
ステークホルダー（英: stakeholder）とは、企業・行政・NPO等の利害と行動に直接・間接的な利害関係を有する者を指す。 また、日本語では利害関係者という。具体的には、消費者（顧客）、従業員、株主、債権者、仕入先、得意先、地域社会、行政機関など。
引用元：
http://ja.wikipedia.org/wiki/%E3%82%B9%E3%83%86%E3%83%BC%E3%82%AF%E3%83%9B%E3%83%AB%E3%83%80%E3%83%BC
よくリスクを考えるときに、対策にお金を出す人を一番に思い浮かべますが、それ以外に直接、間接に利益を受けている人、不利益を被る人も含めたステークスホルダー全てを考える必要があります。
先ほどの「序列をつける」際に、対策費用の面では差がなくとも利便性の面で大きな差がある場合、対策にお金を出す人のみの場合と不利益を被る人を含める場合では結果は大きく異なるでしょう。
・納得してもらえなくても「知っておいてもらうく」
ステークスホルダーを対象と考える場合、全ての人に合意してもらえる結果が得られないこともあると思います。
そのとき、最終決断を責任者が下すのは当然なのですが、それを全てのステークスホルダーが知っている必要があります。
大抵何か意見を言って、そのものごとが進んでいくと「あぁ、自分の意見で進んでいるんだな」と考えるものです。
また、議論が大きく揺れた後決着すると、途中段階の議論までを記憶して結果と思い込むこともあります。
必ず、方向性が決まった場合などの節目でステークスホルダーへの周知をして、納得してもらえなくても「知っておいてもらう」ことが必要です。
できれば問題が発生した場合の訓練などを行い、その際に「○○との考えで、□□の対策を行います」など改めて説明し、理解してもらうことが望ましいです。
・議論のテーブルに「全てのリスクを並べる」
日本人の感性として、「言葉にするとそれが本当になるとの“言霊”信仰」があると思います。
なので、非常に稀で、重大なリスクについては「そんなことを言うな」「縁起でもない」「人々を不安にする」などとして、否定してしまうところがあると思います。
ですが、それでは「想定外の事態」が発生する可能性が高くなってしまいます。
「可能性が低いから議論のテーブルに載せない」ではなく、「議論のテーブルに載せたうえで、リスクが小さいことから対策しない」と考えるべきです。
それから、「全てのリスクを並べる」というと極端な例ばかりを並べると考える方がおられますが、それは違います。
“全ての”ですから、「影響度は小さいものの頻繁に起こること」も「影響度は中くらい頻度も中くらいのこと」も全てを並べる必要があります。
なぜなら、先ほどのリスクの大きさの定義
「リスクの大きさは、そのリスクの発生確率と、発生したことによる影響の大きさを掛け合わせたものである」
を考えると、「影響度は小さいものの頻繁に起こること」や「影響度は中くらい頻度も中くらいのこと」の方がリスクが大きい場合が出てくるからです。
偏らず、先に判断せず、「全てのリスクを並べる」ようにしてください。
以上のことを踏まえると、リスクを洗い出すことが出来ると思います。
○さらに考えてみる－対策について
ＢＣＰをリスク管理と考えて、まずリスクの洗い出しを行いました。
つぎは、洗い出したリスクへの対策の検討です。
・「諦める」も対策の一つ
影響度の大きな問題を考えるとき、「そんな事態を考えても、どうしようもないのだから考える必要が無い」とのスタンスになることがあります。
本当にそうでしょうか。
例えば、「計画停電の時どうするか」を考えるとき「自家発電でまかなう」ことは非常に困難ですから「計画停電は考えない」ことになるのでしょうか。
「計画停電自体は避けられないため諦める（＝直接の対策はしない）。そのかわり、周囲への影響を抑えるため事前に計画停電の連絡をしておく。」との対応を取ることは十分可能でしょう。
「考えても仕方ない」として、「対策自体を考えない」となるとこのような「次善の策」が考えられなくなります。
対策を考えるのは、対策の範囲と程度を明らかにしていく作業だと思います。
どうしようもないこと、制約条件によって対処できないことは、「諦める」のも対策の一つです。
・よく忘れがちな「時間軸」
「ちょっとの停電」は無停電電源で対策する、「ずーっと停電」は諦めることにしたとして、その境界はどこなのでしょう。
先ほど対策を考えるのは、対策の範囲と程度を明らかにしていく作業だと書きましたが、範囲は空間的な意味の他に時間的な意味も含んでいます。
「ちょっとの停電」を「３０分以内の停電」、「ずーっと停電」を「３０分を超す停電」と定義すればより明確に考えられます。
特に対策が復旧作業を指す場合、復旧作業の所要時間や必要人員数などが時間として、また対策費用に反映してきます。
時間軸も含めて対策を考えてください。
・考えるべき「優先順位」
対策を考える際に、全てを一度に復旧するのは、困難なことです。
ましてや、非常時でも確保するべき事項が多いと対策が非常に困難になります。
救急医療などでは、「トリアージ」という言葉があります。
トリアージ（仏: triage）は、対応人員や物資などの資源が通常時の規模では対応しきれないような非常事態に陥った場合において、最善の結果を得るために、対象者の優先度を決定して選別を行うこと。語源は選別を意味するフランス語の「triage（トリアージュ）」である。トリアージュともいう。
引用元：
http://ja.wikipedia.org/wiki/%E3%83%88%E3%83%AA%E3%82%A2%E3%83%BC%E3%82%B8
対策を行う際に「優先順位」に従って作業対象を「トリアージ」すれば、必要なことを速やかに行うことが出来るようになります。
事前に対策についての「優先順位」を決めておいてください。
・変更するときは「対策全体の見直し」をする
よくある話ですが、「○○という条件を満たすのに××の費用が掛かります」「××の費用は無理だからその８割でするように」「わかりました、８割の費用で対策します」となることがあります。
これは、正しくありません。
本当なら、「わかりました、８割の費用で対策します」ではなく、「わかりました、８割の費用となるよう対策の条件を見直します」になるべきです。
つまり、「制約条件によって十分ではない対策をする」のではなく「制約条件を踏まえて十分な対策の範囲、程度を決める」のです。
「なんだ、当り前じゃないか」とも思われるかもしれませんが、対策範囲、程度を決める際には色々なステークスホルダーの調整で成立したはずですから、それを見直すのは至極困難なことだと思います。
ですが、ＢＣＰの整合性を持たせるためには、「全てのリスクに対して十分な対策（勿論“諦める”を含みます）を行っている」必要があり、ストーリーの流れる方向にも逆方向にも齟齬の無いようにしないといけません。
そのためには、もう一度対策の範囲、程度を決定した過程を見直し、ステークスホルダーとの合意形成をきちんとするべきです。
○案を考えてみたけれど
上記の考え方で、社内ＬＡＮおよびファイルサーバ内の情報について、ＢＣＰ的なものを作成してみることができました。
ただし、作成出来たのは試案の私案で、ステークスホルダーとの打ち合わせは全く出来ていない状態でした。
一度上司に見てもらい、「ふむ、この方向で進むにしても一度皆で話をする必要があるな」となってからステークスホルダーと話をするつもりだったのです。
で、上司に見せると「お、色々書いてあるな。一度見せてもらうわ。」と言われて預けたのですが、その後何か動いている様子がないままとなってしまいました。
「あれではステークスホルダーとの合意は出来ていないだろうになあ」と思ったものです。
その意味で、次のことは重要だと思います。
・計画を立てることへの「責任と権限が集中していること」
「この作業の責任者はあなたです」と言われることは無いにしても、ある程度の責任と権限が誰にあるかを明らかにして、作業する必要があります。
ステークスホルダーがある程度こちらの話を聴き、指示に従う程度にならなければ、議論も出来ません。
また、もし計画を実施する側に渡した後変更されてしまうと計画の中の整合性が失われてしまう可能性があります。
責任と権限を有するのが一人である必要はありませんが、ある程度の範囲に集中していないと調整のしようがありません。
作業の開始時に、責任や権限がどのようになっているか確認しておくべきでしょう。
読まれた方にはよくわからない文章になっているかもしれませんが、書いてみてすっきりしたように感じられます。
修正が必要な個所は後日修正することとします。
それでは、今回はこのへんで。