システムリスクについては、これまで各国のシステム基準やISO、多くの研究論文、特許などで見える化の努力がなされてきましたが、決定的なものは有りませんでした。その原因は、これまでのアプローチが経験則によるものとロジカルシンキングツール的なものであったからです。

経験則は現在システム開発で利用されているツール類の中心です。ロジカルシンキング系ツールは、あくまで思考の補助に過ぎないため、網羅的にリスクを洗い出すこともできず、極度に属人化した分析になるため、組織としても利用できない欠陥の多いもので、殆ど現実のシステム開発では利用されていません。

では、本来システムリスク分析に必要なアプローチとはどのようなアプローチでしょうか。
システムを1つのボックスとして単純化し、周りの利用者や外部システムをそれぞれのロールとして分類して考えてみます。
経営者はシステムに投資しますが、それはシステムによって利用者を含むそれぞれのロールに何らかの便益を提供するためです。それは利用者の利便性であったり、代理店の利便性、社員の業務効率向上であったりします。

この何らかの便益を提供するという言葉には、プラス面とマイナス面の側面があります。

プラス面とは便益を正しく提供する性質で、社員の業務効率向上であれば業務効率が想定通りに改善できる機能を提供することを指します。

一方でマイナス面とは便益を提供するにあたり、想定通りに便益が提供し続けられる性質です。例えば性能が足りない、システム障害でアクセス出来ない、セキュリティ事故が発生してしまうなど、企業に何らかの損害がでてしまうことを防止するための性質です。

システムリスクとは、このマイナス面の損害を発生させる可能性のある因子のことです。

損害は、各ロールに損害が発生するということであるため、システムリスクを検討する出発点は損害でなければなりません。

次にシステムリスクが顕在化するとはどういうことでしょうか。

今度はシステムを1つのボックスとしてではなく、メモリ1枚1枚、ハードディスク1つ1つ、プログラムのコード1行などの細かいレベルで考えていきます。
例えばあるサーバのCPUが1つ壊れます。このサーバはダウンし、待機系のサーバに切り替わります。ここでのシステムリスクは何でしょうか。よくあるのは待機系のサーバに切り替わらないリスクです。更に停止期間が長いことで業務処理の影響が伝播し、復旧に多大な手間と時間を要するということもあり得るかもしれません。

当社では、言葉の整理として、ここでのCPUが壊れることをシステム事象と呼んでいます。システムの細かい構成要素が自然現象で壊れたり消えたりすることと、人為的な作業が原因で同じようにシステムの構成要素が壊れたり消えたりすることを指します。システムリスクはシステム事象による影響です。CPUが壊れてもリスクが無い場合もあります。ですからシステム事象とシステムリスクは分けて考えなければなりません。
先ほど、システムリスクの出発点は損害でした。システムリスクは損害とシステム事象が有機的に結びついて初めて抽出することが出来ます。

これまでの手法は、このように損害・システムリスク・システム事象を明確に分けてきませんでした。このことが分析を困難にしてきた根本原因です。なぜなら、普通に考えたら必要なことがフレームワークとして準備されていないからです。

更にこの損害・システムリスク・システム事象を結びつけるのは、実はちょっと考えただけでは出来ません。
これを出来るようにしたのが当社のリスク収束フレームワーク(RCF)です。