見出し画像

No322 がんばりすぎないリスク管理

前々回(No320 バックアップどうしてますか?)の中でリスク管理(危機管理)について少しお話をしました。

リスク管理や危機管理というのは様々な要素がからむ話になり、概念的でわかりにくい部分が多くなります。

だからというわけではありませんが、今までリスク管理についてはあまり書きませんでした。
リスク管理というのは情報セキュリティ管理にも大きく関わる領域で、決して無関係ではありません。

今回はリスク管理についてお話をします。


リスク管理とは何か?

そもそもリスクとは何でしょうか?

実は、リスクという言葉は厚労省の「リスクアセスメント指針」という文書の中で次のように定められています。
「危険源によって生ずるおそれのある負傷または疾病の重篤度及び発生の可能性に関する度合い」
目が見ることを拒否しそうなわかりにくい文ですが、要はリスクとは「マズいことが起きそうな確率」だ、と考えていただければOKです。
さらにその確率は以下の二つの要素を掛け算して求めることになります。
 ・重大さ(スリ傷か死亡事故か)
 ・頻度(毎日起きそうか、年に一回か)
例え小さなケガでも毎日誰かがケガしている職場は問題ありありですし、発生頻度が低くても、重大なミス(ノートパソコン紛失とか)は対策が必要です。
逆にあまり起きず、影響度も小さいリスク(たまに誰かが事務所で小さなケガをするなど)では特に対策しないケースも考えられます。

リスク管理(リスクマネジメント)というのは、こういった組織が抱えるリスクを正しく把握し、評価し、受け入れることを言います。

ここで「え?受け入れるってどういうこと?」と思われた方もおられると思います。

一般にリスク対策とは、対策を施して発生させないことと理解されています。

ですが、絶対安全など、ほとんど存在しません。
例えば、東京と大阪間で移動するにしたって、飛行機は落ちる、新幹線も薬剤ばらまき事件などがある、在来線なら脱線や衝突事故、夜行バスだって衝突事故、といった具合でリスクはあります。

上記の飛行機の例が典型的ですが、飛行機が墜落すると多数の死者が出る重大な事故となるため、航空会社は事故率を減らすために、様々な工夫をしています。

その結果、飛行機の墜落事故での死亡率は低く、自動車事故の1/4という統計(米国)もあるようです。
ちなみに、日本では1986年以降、飛行機の墜落事故は起きていませんので、さらに確率は低く、小さなリスクと言えます。

ですが、私たちは利便性と引き換えにこういった小さなリスクを受け入れています。

これは組織のリスク管理も同様です。

どうにもならないもの、手間がかかりすぎる(業務が進められなくなる)もの、発生しても影響度が低いものなどは受け入れ、そうでない重篤なもの、許容できないものは対策を施せばよいのです。

リスク管理ではリスクをなくすことを目的としていません。

リスクを把握し、何が起きそうかを知り、許容できないものには対策した上で受け入れ、許容できるものはそのまま受け入れる、これをリスク管理と言います。

リスク管理と危機管理

リスク管理と似たものに危機管理があります。

この両者は似たようなものですが、厳密にはカバー範囲が違っています。

リスク管理は文字通りリスクそのものを対象とします。
つまり、リスクの把握、リスクの評価(重要度の測定)、リスクへの対策の三つを行うことを言います。

一方で、危機管理は、リスクが顕在化した後の行動や復旧策が主眼となります。
リスクが顕在化した時点でリスクから解決が必要な危機(や課題)と呼び方が変わります。

危機管理では、危機(事故など)への対応手順の策定、(通常状態への)復旧手順、そのための訓練といった事項が管理対象となります。
一時流行した「事業継続計画(BCP)」は、危機管理のうち甚大な災害などにあった時の対応策を記載するもので、危機管理の一部となります。

今回は危機管理については言及しませんが、リスク管理と危機管理は車の両輪のようなもので、片方だけで存在するものではなく、二つを並行して進める必要があります。

あるべきリスク管理

教科書的には、リスクというのは全て洗い出しを行うところからリスク管理が行われることになっています。
ですが、今までリスク抽出やリスク評価を行ったことのない組織ではこれを独力で行うのは苦行というか、不可能です。

一応書いておきますと、本来の手順は次のようになります。

1)危険源の特定
 危険の原因となるもの(熱源、刃物など)を全て抽出する
2)アクションの抽出
 危険源に近づく作業や行動を全て抽出する。
3)リスク評価
 アクションが引き起こすトラブルの重要度や発生頻度を求める
4)リスク対策
 リスク評価の結果にもとづいて、取るべき対策を検討する。

この手順通りに進められる組織は是非がんばっていただきたいのですが、どのステップも経験者の手助けなしでは難しいのが実際です。

実際、ものの本でもこれを最初からパーフェクトにやろうと思うな、できるところから手を付けてもいい、と書かれているくらいですから。

実際的なリスク管理

このメルマガは「がんばりすぎないセキュリティ」です。

以前からの愛読者の皆さんには、耳にタコでしょうが、筆者は「がんばりすぎない」ことを重要なキーワードとしてお伝えしています。

リスク管理でもこの考えは変わりません。

本来的には、上述のように組織のかかえる全てのリスクを俎上にあげるのが正しいやりかたです。

ですが、それには多くの労力と事前準備が必要になります。
もちろん、現場の負担も大きくなります。

しかも、得られるものは効果のよくわからない文書でしかありません。

労力に対して得られる成果があまりに少なすぎ、現場が自分ごととして考えることができません。「リーダに振り回されただけだ」となっては、折角の分析結果も正当な評価を得られません。

ですので、筆者はここでも「がんばりすぎないリスク管理」を提言します。

まずは、自分たちの身の回りで「○○になった時ってどうするんだっけ?」「△△のことって誰がやるの?」「間違いそうになる作業があるけど、皆どうしてるの?」といった具体的な事例ベースで考えるのが費用対効果が見込めるものになります。

最初はリスク管理よりも、危機管理のネタの方がたくさん出てくると思います。

これはむしろ当然で、危機管理の対象は日常的に行っていて気が付きやすいからです。
リスク管理の対象の多くは潜んでいて気づきにくいことが多いのです。

それでも、活動を続けていると、除々にリスクに気付くケースが増えてきます。

「あそこの床っていつも濡れていて、滑りやすいよな」
 →床が危険源。濡れる原因は?床材の問題は?
「工場の出口の段差、何とかならんかな。荷台で運ぶ時に落としそうになるし」
 →段差が危険源。荷台だけでなく転ぶ危険は?
「こないだ、投入する薬剤を間違いそうになった。ボトルの色いっしょだし」
 →薬剤が危険源。識別できないことで生ずるリスクは?

こういったリスクが次々と指摘できるようになってきて、ようやく本格的なリスク管理を行える土台ができたと言えます。

ここで初めて、場当たり的なリスク対策では足りず、上述のような教科書的な分析が有効となってきます。

逆に言えば、ここに辿り着くまでは、個々の対策を考えるだけでも十分に効果はあるのです。

ただ、このやり方には無駄と矛盾が潜んでいます。

最初に取り組むべきリスク
一番発生確率が高く、発生事の被害が大きいリスクは、一番最初に対応するべきです。

ですが、「がんばりすぎないリスク対策」で場当たり的な進めると、目立つリスクへの対応が優先されます。

本当は重要なのに、潜んでいて気づきにくいリスクへの対応が遅くなるのです。

とはいえ、これも考え方です。
何もしなければどのリスクも残ったままです。
また、慣れないリスク分析を頑張っても、本当に重大なリスクを抽出できないかもしれません。

それなら、目立つリスクへの対応であっても、それを重ね、経験を積み、視点を磨く方が現場の納得できる活動となります。

現場が十分に経験を積んだ状態で教科書的なリスク対策を行えば、まさに鬼に金棒です。

筆者はこのような発展を夢見て「がんばりすぎないリスク管理」を提唱します。

まとめ

リスク管理というのは、事故を避ける(もしくは軽減する)ための非常に強力な手法です。

リスク管理については、多くの有識者や研究者がいて、おおむね管理手法も固まっています。本来的なリスク管理を行うには、そういった教科書に従って対応を行うのが一般的です。

もちろん、それを受け入れるだけの素地がある組織はそれがベストですが、中小企業などでいきなりリスク管理の手法を取り入れても、なかなか定着しづらいようです。

それなら、目立つところ、気付いたところからリスク対策を考える方が良いと筆者は考えています。
気づくものがなくなった時点から本格的なリスク管理を始めても遅くないのです。

「がんばりすぎないセキュリティ」ならぬ「がんばりすぎないリスク管理」ですね。

今回はリスク管理の概念的な話が中心となりましたが、次回はもう少し具体的なリスク管理のお話をしようと思います。

次回もお楽しみに。

(本稿は 2023年8月に作成しました)

このNoteは筆者が主宰するメルマガ「がんばりすぎないセキュリティ」からの転載です。
誰もが気になるセキュリティに関連するトピックを毎週月曜日の早朝に配信しています。
無料ですので、是非ご登録ください。
https://www.mag2.com/m/0001678731.html

この記事が気に入ったらサポートをしてみませんか?