WEBマガジン

「リスクをどのようにして見つけますか?」

2011.10.04 株式会社オージス総研  栗田 健史

 皆さんは、リスクをどのようにして見つけていますか?
 と、言ってもこれでは一般的過ぎて分かりにくいので"リスク"と"見つける"をそれぞれ分けて考えて見ましょう。

 先ず、 "リスク"ですが、皆さんはこの言葉をどのように説明されますか?改めて説明しようとするとなかなか説明のし難い言葉ではないでしょうか?例えば、"何か悪いことが起こりそうだ"とか"このままだとまずいことになる"とかでしょうか。リスクには純粋リスク(発生した場合に損失のみをもたらす可能性があるリスク)と投機リスク(発生した場合に損失あるいは利益をもたらす可能性があるリスク)に分類されますが、ここでは純粋リスクについて考えます。取り敢えず既知の情報を調べてみましょう。

 これからリスクは、

 の組合せと言えます。
 一般的には、「リスク = 発生確率 × 事象の結果(損害)」の式で表されます。

 これでもまだ分かりにくいと思いますのでリスクを"見える化"してみましょう。

リスクの概念図
図 1 リスクの概念図

 この筆者が考案した概念図では、"目標、あるべき姿"と"実績、現実"が現時点では乖離していないが、将来のある時点で乖離することを示しています。その乖離した状態が"事象"であり、その乖離幅(GAP)を損害として表しています。この図では""実績、現実"が徐々に"目標、あるべき姿"から乖離していますが、実際には地震災害のように急に乖離する場合もあります。
 なお、現時点で"目標、あるべき姿"と"実績、現実"が乖離している場合は"問題"です。"リスク"は、将来発生する可能性のある"問題"とも言えます。"リスク"についてはイメージが高まったでしょうか。

 さて、次は"見つける"です。
 "見つける"と言うと、何かあるものを探すように思われそうですが、上記のとおり現在においては乖離が無い状態であり、不確実な発生確率ということになると、なかなか"見つける"のは難しそうです。

 リスクマネジメントのプロセスは様々な文献で示されていますが、概ねリスク識別→リスク評価→リスク対応のプロセスになります。"見つける"プロセスは、これらの文献ではリスク(因子)の特定、リスクの識別、事象の識別などと表現されています

 前回の「内部統制におけるアクセスコントロールの効率化」でも触れましたが、リスクをコントロールするには、何を対象にするのかを明確にすることが重要です。では、情報システムでリスクを考えるにはどのような対象があるのでしょうか?ここで一つの考え方としては、情報システム全体像を捉えたITガバナンスが参考になります。ITガバナンスの全体像を下図に示します。

ITガバナンスの全体像
図 2 ITガバナンスの全体像
日本ITガバナンス協会の「取締役会のためのITガバナンスの手引き第2版」のITガバナンスの重点領域、
「COBIT実践ガイドブック」のITガバナンスライフサイクルを参考に筆者が作成

 この図では

  1. ITとビジネス戦略の整合を図る体制を構築し、プロセスと戦略を推進する計画を立て
  2. IT資源を活用し、
  3. ITとしての価値の提供(価値の最大化)、と
  4. リスク管理(リスクの最小化)を並行して進め、
  5. その成果をモニタリングし、改善していく

 PDCAサイクルを示しています。

 このプロセスを実現・実行するために必要なものが情報資本です。こちらのページに解説があります。 http://www.ogis-ri.co.jp/rad/r-01bic-itgc.html

 情報資本には、マネジメントインフラと物理インフラがありますが、言い換えれば"プロセス"と"もの"です。これらを対象にリスクを考えていくことが分かり易いでしょう。

 では、具体的にはどうすれば良いのでしょうか?

 まず、 "もの"はどうでしょうか。リスクアセスメントの方法としてGMITS ( Guideline for the Management of IT Security Part 3 )では、4つのアプローチが紹介されていますが、ここでは詳細リスク分析アプローチを取り上げます。
 GIMTSでは情報資産を対象にリスク因子を特定することとしています。情報資産とは主には以下のものです。

 これらの情報資産を棚卸しし、個々の情報資産について、脅威と脆弱性を評価します。この方法では対象とする情報資産の量が多い場合は、分析作業は膨大になります。

 一方、"プロセス"はどうでしょうか。例えば、開発プロセスではどのようなリスクがあるのでしょうか?プロセスのリスクを発見する方法は、J-SOX導入当時に一般的になったプロセスフローとリスクコントロールマトリクス(RCM)があります。例えば開発業務を可視化してフロー上にリスクのある箇所を特定し、洗い出されたリスクへの対応策を一覧化してRCMを作成します。さて、こうして書くと簡単にできそうですね?業務を可視化するのは問題なさそうですが、「フロー上にリスクのある箇所を特定する」はどうでしょうか。この部分が"リスク"を"見つける"ですが、実際にはフローに書かれていない(コントロールが存在しない)部分にリスクがあることもあり、簡単ではありません。では、どうするか?
 ここで"銀の弾丸"はありません。地道に、失敗したことに対する改善などの実経験を活用することが有効です。しかし、個人の経験値だけでは情報量が少なすぎるので、有識者や先人の知恵を使うことです。具体的には有識者や専門家の意見を聞く、あるいは過去の経験・実績から作成されたチェックリストなどを使うことです。以下に参考になるものを上げておきます。

 また、プロセスということではプロジェクトマネジメントのプロセスでもリスク管理は重要であり、PMBOKの知識エリアの一つとして"プロジェクト・リスク・マネジメント"が取り上げられています。PMBOKのリスク特定では、専門家や経験者とのブレーンストーミング、合意形成(デルファイ法)、インタビューおよびチェックリストによる分析などをツールと技法としています。ここでは上記のチェックリスト類も参考になりますが、プロジェクトは固有の目的に対して実施されるものであり、個別のプロジェクトでヒントになるものは限られます。参考になるものとしては『ITプロジェクトの「見える化」』 (SEC BOOKS) 情報処理推進機構(IPA・SEC)を上げておきます。プロジェクトの上流・中流・下流それぞれに問題を定性的に把握するチェックシートや失敗事例と対応策、プロジェクトの状況を定量的に捉えるための測定リストが過去の経験から作成されており、有効です。実際に会社で利用する場合は、これらのチェックリストを参考に自社の経験値から独自に作成するのが良いでしょう。弊社では、過去のプロジェクトマネジメントの教訓を『リスク事例ハンドブック』として作成し、リスクの顕在化を未然に防止するために利用しています。

*本Webマガジンの内容は執筆者個人の見解に基づいており、株式会社オージス総研およびさくら情報システム株式会社、株式会社宇部情報システムのいずれの見解を示すものでもありません。

『WEBマガジン』に関しては下記よりお気軽にお問い合わせください。

同一テーマ 記事一覧

「システム監査の進め方」

2017.08.28 ITガバナンス 株式会社オージス総研  栗田 健史

「内部統制におけるアクセスコントロールの効率化 その3」

2013.11.11 ITガバナンス 株式会社オージス総研  栗田 健史

「内部統制におけるアクセスコントロールの効率化 その2」

2012.09.11 ITガバナンス 株式会社オージス総研  栗田 健史

「内部統制におけるアクセスコントロールの効率化」  

2010.10.03 ITガバナンス 株式会社オージス総研  栗田 健史