(57)【要約】      （修正有）【課題】システム開発において、経験と勘に頼らず最適なリスクマネジメントを行うためのリスク収束表を提示するリスク収束フレームワークを提供する。【解決手段】リスク収束表は、リスク事象を４０１「サービス事象部」、４０２「リスク事象部」、４０３「システム事象部」に分類し、４０４「対応レベル値部」には対応レベル値を記載し、４０７「対策内容部」では対策案を抽出する。４０８「費用性部」では対策費用を記載し、４０９「制約部」ではマイナス要因を記載する。複数の対策案が出てきた場合は４０８や４０９や４１０から実際に施す対策を選択する。【選択図】図４
2019149157.tif 000002
【特許請求の範囲】
【請求項１】
サービス事象を定義するステップと損害を定義するステップと対応レベルを定義するステップとシステム事象を定義するステップとリスク事象を定義するステップと対策案を抽出するステップと対策案の中から対策を選択するステップを特徴としたリスクマネジメント方法
【請求項２】
サービス事象を定義するステップと損害を定義するステップと対応レベルを定義するステップとリスク事象を定義するステップと対策案を抽出するステップと対策案の中から対策を選択するステップを特徴としたリスクマネジメント方法
【請求項３】
損害を定義するステップと対応レベルを定義するステップとリスク事象を定義するステップと対策案を抽出するステップと対策案の中から対策を選択するステップを特徴としたリスクマネジメント方法
【請求項４】
サービス事象を定義するステップと損害を定義するステップと対応レベルを定義するステップとシステム事象を定義するステップとリスク事象を定義するステップを特徴としたリスク分析方法
【請求項５】
サービス事象を定義するステップと損害を定義するステップと対応レベルマトリックスを定義するステップを特徴としたリスクに関する要求の定義方法
【請求項６】
システム事象を定義するステップとリスク事象を定義するステップと            リスク事象の該当レベルを定義するステップと対策案を抽出するステップと対策案の中から対策を選択するステップを特徴としたリスクに関する要件の定義方法
【請求項７】
請求項1から請求項5の対応レベルを定義するステップにおいてサービス事象の頻度及び程度ごとに対応レベルを定義するステップを特徴とした対応レベルマトリックスの定義方法
【請求項８】
請求項1，請求項2，請求項3，請求項6の対策案の中から対策を選択するステップにおいて，費用性，制約，残存リスク，対応レベル値から対策を選択するステップ      を特徴とした対策案の中から対策を選択する方法
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はシステムにおけるリスクマネジメントの方法に関する．
【背景技術】
【０００２】
リスクマネジメントとは起きてほしくないことが起きることで，損害が発生することを避けることであり，リスクとは損害を発生させる要因を指す．本発明で対象とするリスクとは，システムに求める効果を実現するための機能仕様を決められないリスクを含まず，システムが移行を含む運用開始から損害を発生させないように稼働するためのリスクマネジメントを対象とする．対象とするリスクマネジメントには，プロジェクトマネジメントなど開発方法等の対策も含まれる．これまで，この種のリスクを分析し，対策していく過程はISOなど多くの標準で示されている．しかし，そこではリスクの識別や評価など大きなステップを紹介しているだけで，具体的な手順は示していない．最適なリスクマネジメントを行うには，リスク識別と対策選択を行う過程の全てが論理的でなければならない．これまでの手法では，これらのステップを全て論理的に説明するのは困難である．
【０００３】
本来，リスクマネジメントは発生してほしくない損害の発生を防ぐものであるから，損害が何なのかを定義しなければならない．損害はサービスの状態がもたらすため，損害を定義するには，サービスがどのような状態になったら困るのか，損害毎に定義する必要がある．
また，昨今の複雑化したシステムにおいて限られた予算の中で残存リスクが全くない状態で移行や運用を進められることは皆無と言える．そうなると，如何に限られた予算で残存リスクを小さくするかが重要になる．残存リスクを小さくするには，どの対策にコストをかけるのかバランスを決める必要があるが，これは受注者側だけでは決められない．発注者側は事業や会社の置かれた環境からどのリスクに対応していくのか方針を示さなければならない．
これまでのアプローチでは，リスクの抽出とリスク対策，リスク識別を中心的に扱ってきた．しかし，実際は損害の定義，損害となるサービスの状態の定義，最適な対策の選択，残存リスクの認識というステップが欠かせない．
【０００４】
非機能要求グレードは，非機能に特化して対策項目別に対策レベルを選択する簡易ツールである．リスク識別は含まれておらず，対策選択は表から選択するだけである．従って，リスクの抽出はされておらず，リスク対策のみを簡易的に選択している．当然リスク識別も行わない．更に本来必要な損害の定義，損害となるサービスの状態の定義，最適な対策の選択，残存リスクの認識も出来ない．
【０００５】
ゴール指向は，ゴールを設定して要件を具現化する手法である．ゴール指向は，機能要件や非機能要件の抽出を対象とするが，損害やサービスの状態を考慮に入れずに，ツリー状にリスクと対策をつなげていくロジカルシンキングの補助ツールに過ぎない．従って本来必要な損害の定義，損害となるサービスの状態の定義がなされないため，最適な対策の選択は出来ない．更にリスクの抽出方法についても本発明のようにシステムの状態と，その要因となる自然現象及び人為事象とを分けていないため，リスクという１つの大きな纏まりとして扱われ，リスク抽出が属人化しやすい．属人化は，抽出漏れや再利用性の低下を生む．
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００１−２２２４２０
【特許文献２】特許第３８７２６８９号
【非特許文献】
【０００７】
【非特許文献１】システム基盤における非機能要求の見える化ツール  独立行政法人情報処理推進機構
【非特許文献２】組織の情報セキュリティ対応を支援するモデルの提案とその適用可能性の検討  −ＩＳＯ／ＩＥＣ２７００１：２０１３及びＩＳＯ／ＩＥＣ２７００２：２０１３適合モデルとその運用手法について−
【非特許文献３】情報処理学会研究報告ＩＰＳＪ  ＳＩＧ  Ｔｅｃｈｎｉｃａｌ  Ｒｅｐｏｒｔ  ゴール指向を用いたセキュリティ要件の定義手法の提案
【非特許文献４】「マルチメディア，分散，協調とモバイル（ＤＩＣＯＭＯ２０１６）シンポジウム」  平成２８年７月  イベントツリーとディフェスを併用したリスク分析における共通事象を考慮した計算法の提案
【発明の概要】
【発明が解決しようとする課題】
【０００８】
システム開発におけるリスクマネジメントは，品質・コスト・納期を大きく左右する重要な要素である．しかし，システムに関するリスクは複雑で目に見えにくいため，どのリスクにどのくらい費用をかけて対策するかは経験と勘に頼ってきた．本来であれば，どのリスクにどの程度費用をかけるのか，残存リスクは何を受容するかは発注者側が選択できなければならないが，経験と勘でリスクマネジメントされるため，どのリスクにどの程度費用をかけるのかは受注者主導で検討され，発注者はコストをコントロール出来ず，残存リスク認識もできない．このようなすれ違いが多くのシステムにおいて，プロジェクトの失敗・システム障害・セキュリティ事故を引き起こしてきた．
【０００９】
本来，リスクマネジメントを行うには，ビジネス上必要となる残存リスクレベルまで残存リスクを低下させ，それに必要な対策を受容できる予算内で施さなければならない．しかし，リスクマネジメントに関する要求は，方法論が無いこととリスク要求への理解不足からリスクマネジメントとして扱われて来なかった．これにより，発注者側はリスクを識別することが出来ないまま，受注者側の提案通りにリスクへの対策がなされ，本来発注者が実現したいはずの最適な対策の選択が出来ていなかった．リスクマネジメントの本来の目的はビジネスが求めるリスクレベルまで残存リスクを低下させることであるから，残存リスクの識別が出来ていないという事は，本来対策するべきリスクが他にもあるのに，そこには対策せずにコストを使いきってしまう可能性があるということである．
【００１０】
システム開発は，よく品質・コスト・納期で評価されると言うが，この品質を達成するということは，リスクの低下目標を達成するということと同義である．品質とは，バグ率が低い事でもなければ設計書がきれいに書けることでもない．品質とは，開発されたシステムが運用開始されてから損害を出さずに動き続けることである．このような本来の目的をはき違えているシステム開発が横行している根本原因は，本来の目的を達成するための手段が無かったことによる．
【００１１】
リスク識別は，現在でもプロジェクトマネジメントの標準などでステップは提案されており，ＩＳＯなどでもリスク識別を行うステップを提案している．しかし，これらは，大きなステップの提案だけで，具体的な手順は提案していない．リスクには様々な粒度のリスクがある．例えばサービス全体のダウンもリスクであり，その原因となるサーバ停止もリスクである．さらにサーバ停止の原因となるＣＰＵの故障もリスクである．このようにリスクは親子関係を持つこともあり，非常に複雑な構造になるため，全体像を明確にすることは難しく，リスクの抽出を困難にしている．
【００１２】
更に対策の選択は，様々な要素を総合して判断する必要があるが，これも判断材料を抽出することが難しく，手法がないため，出来ていないケースが多い．セキュリティ対策手段の決定手法の中には，脅威の発生確率・損害発生時の金額などを数値化し，損害の期待値を数値化する手法がある．しかし，実際のシステム開発の現場で脅威発生時の損害金額算定は発注者にしかできず，最も秘密度の高いそのような情報をベンダに渡すことは非常に障壁が高い．また，損害額の算定は発注者にとっても負担が大きい．更に損害の発生確率はその分子や分母となる情報を正しく集めることが不可能に近く，脅威期待値を求めることは現実的でない．
【００１３】
プロジェクトマネジメントでは，進捗の管理手段として設計書やプログラムのステップ数，構築したサーバ類の数などを管理してきた．また品質基準としては，バグ率を管理するのが一般的であった．しかし，リスクに関してはこれらを管理した所でリスクの達成基準にはならない．このように十分にリスク対策が出来ていない状態で次の工程に進むことも多く，これがプロジェクト失敗の要因にもなっている．
【課題を解決するための手段】
【００１４】
リスクに対応するには，リスクが現実化した時の損害を定義し，その損害にそなえるためにどの程度コストをかけるのかを決める必要がある．これが1つのリスクに対して複数ある対策案を選択する際の予算感となる．
本発明では，この予算感を対応レベルで定義している．この対応レベルを頻度別程度別にマトリックス化したものを対応レベルマトリックスという．対応レベルマトリックスはリスクマトリックスとは異なる．リスクマトリックスは，リスクを程度別・頻度別にマトリックス化したものである．これに対して対応レベルマトリックスは程度別・頻度別にリスクに対応すべき予算感をマトリックス化したものである．
【００１５】
本発明では，複雑なリスクを適切に抽出するため，サービスの状態であるサービス事象とシステムの状態であるシステム事象とそれを引き起こす自然現象及び人為事象であるリスク事象に分解して定義している．サービスとは，システムに投資する主体が便益を提供したい相手が便益を得るためにシステムから得るシステム動作やデータ等である．従って，サービス事象はシステムに投資する主体が便益を提供したい相手毎に変わることがある．
システム事象は，サービスを構成する個々のアプリケーション・インフラストラクチャ・データ等の状態をいう．
【００１６】
対応レベルマトリックスは最初にサービス事象と発生してほしくない損害に関連付いている．これをシステム事象及びリスク事象に関連付けする．リスク事象は程度と頻度の選択が基本的に1つになる．このリスク事象の該当マトリックスと対応マトリックスを乗することでリスク事象の対応レベル値が１つ決まる．
【００１７】
リスクに対して最適な対策を選択するには，リスク事象に対する対策案を抽出して，対策案による制約・対策案にかかるコスト感である費用性・対策しても残る残存リスク・リスクにかけられる予算感である対応レベル値を総合して対策を選択する必要がある．これにより，費用対効果の高い最適な対策選択が出来るようになる．
【００１８】
このようなリスク収束フレームワークの実行は，開発前に実施するだけではない．開発フェーズに入っても設計や開発・テストの結果，当初想定とリスクと対策の関係が変わることがあるため，これを更新する必要がある．
【００１９】
更にこれまでのプロジェクトマネジメントでは，リスクの低下状況を監視することは出来なかったが，リスクと対策の関係を明確に出来るようになったことで，開発生産量と同様にリスク量を監視できるようになる．
【００２０】
運用フェーズでも，新たな脅威が発現したり，ビジネス環境によって損害の重さの定義が変わったりとリスクと対策の状況は変わる．このような変化に合わせて，リスクと対策の関係を見直す必要がある．本発明の手法を用いればこのような変化にも追従できるようになる．
【００２１】
本発明における用語の説明を以下に示す．
ロール：
システムに投資する組織等が，システムの投資によって便益を提供したい相手の種類のこと．
例：消費者，社員，人事部門の業務担当者など
サービス：
ロールに対して直接便益を提供する手段としてのシステム機能の纏まり．
例：ショッピング機能，勤怠申請機能，長時間残業者の統計取得機能など
サービス事象：
サービスが陥ってほしくない状態
サービス事象の程度：
停止時間であれば停止時間の長短，情報漏洩であれば漏洩の範囲のように損害のレベルが変わる可能性のあるサービス事象の程度．サービス事象の程度１つ１は，対応レベルが変わらない範囲内で定義し，対応レベルが変わるサービス事象の程度は別のサービス事象の程度として定義する必要がある．
システム事象：
サービス事象を引き起こす可能性のあるインフラストラクチャ・アプリケーション・データ等システム構成要素の状態
リスク事象：
システム事象を引き起こす可能性のある自然現象及び人為事象
費用性：
対策にかかる定性的又は定量的な費用感
対応レベル：
発生してほしくない損害にどの程度費用をかけるのか，かけないのかの方針をレベル定義したもの
対応レベルマトリックス：
対応レベルを頻度別，サービス事象の程度別に横軸と縦軸でマトリックス化したもの
対応レベル値：
対応レベルマトリックスのうち該当するリスク事象が唯一とる値
該当レベルマトリックス：
頻度別，サービス事象の程度別に横軸と縦軸でマトリックスを作成し，リスク事象が該当する頻度とサービス事象の程度を１，その他を０としたマトリックス
リスク収束：
リスク事象に対策を施して最終的に残るリスクのリスク識別が受容かリスク無しになること
【発明の効果】
【００２２】
本発明を用いてシステムの企画・開発・運用を行えば，リスクマネジメント面においてシステムの費用対効果・品質・納期及び円滑なプロジェクト進行を飛躍的に向上する．
これまでのシステム開発ではリスク分析を網羅的に行うことなく，対策有無を要件定義工程でヒアリングしたり，開発に入ってからリスク対策方法を検討していた．そのため，要件定義時点でシステムにかかる費用とリスク対策による効果を天秤にかけることが出来なかった．本発明を用いれば，開発前にリスク対策にかかる費用感とリスク対策による効果を天秤にかけることが出来るようになるため，費用対効果を最大化することが出来るようになる．また，システム品質は施す対策を明確にすることで，曖昧性を排除することが出来，達成すべき品質ゴールを明確にすることができるようになる．更に品質達成をサポートするプロジェクトマネジメント上の要件も明確に出来るようになるため，円滑なプロジェクト推進と納期の遵守がしやすくなる．
【００２３】
システム開発において残存リスクが全く無いケースは殆ど無く，多くのシステムにおいて残存リスクは必ず存在する．リスク対策はシステム開発のコストを大きく左右する要素であるため，リスク対策のレベルを下げることはコストを下げることにつながる．しかし，このコスト削減策が利用者サイドの合意が出来る内容かどうかを判断する方法はこれまでなかった．本発明は，これまで殆どブラックボックスであったリスクに対する対策要否の判断方法をホワイトボックス化することに成功した．これより，発注者は品質とコストをコントロールすることが出来るようなり，受注者側も要件を明確にすることで開発後に認識のずれが発覚して大きな問題になることを事前に防ぐことができるようになる．
【００２４】
これまでのシステム開発では，リスク分析を網羅的に行う方法もリスク対策案を発注者側が適切に判断する方法もなかった．そのため，発注者側は対策後の残存リスクを把握することが出来なかった．これにより，寝耳に水のシステム障害やセキュリティ事故が起こることがあった．本発明を用いれば，基本的にこのようなシステム障害やセキュリティ事故は発注者側がリスクを受容したものだけが残るため，寝耳に水のリスクは残らない．残存リスクを認識出来るようになれば，可能なタイミングで追加投資をして残存リスクを無効化する等の対策が打てるようになる．
【００２５】
プロジェクトマネジメントは，リスクマネジメントが非常に重要かつ中心的な管理対象であるにも関わらず，その管理は定例報告や課題管理や進捗報告やバグ率の報告といった方法で報告されてきた．一方でリスクはＰＪ開始時が一番大きく，ＰＪ進行とともに低減していくと言われている．現状では，ＰＪ開始時が一番大きいリスクを可視化する方法はなく，各自の思い付きでリスクを抽出している．そのため，その管理方法も定例報告や課題管理や進捗報告やバグ率の報告といった方法で行われており，リスクの低下状況も可視化出来ない．
本発明を用いれば，リスクは可視化されるため，ＰＪ進行とともにその低下状況を把握することが可能になる．また，リスクの状態を常に監視・管理することでその変動状況も追跡できるようになり，適切なプロジェクトマネジメントが出来るようになる．
【００２６】
本発明はシステムの企画開発運用における要求マネジメントと要件マネジメントの分解を可能とした．本発明にける要求とは，損害を明らかにし，どの損害にどの程度費用をかけるのかという方針である．要件とは，要求を元にリスクを網羅的に抽出して最適な対策を選択する取り組みである．機能仕様に関しては一般的に発注側が要求を定義し，受注者側は要件を定義して発注者が承認する．リスクマネジメントに関しては，この要求と要件の関係を実現する手法はなかった．しかし，本発明を用いることによって，要求と要件を完全に分離することが出来るようになるため，システムの企画開発運用における発注者側の役割と受注者側の役割を明確に出来るようになる．
【図面の簡単な説明】
【００２７】
【図１】損害とサービス事象と対応レベルマトリックスの定義
【図２】システム事象の定義と対応レベルマトリックスの関連付け
【図３】リスク事象の定義と対応レベルマトリックスの関連付け
【図４】リスク収束表
【符号の説明】
【００２８】
本発明の一例として具体的手順を形態に示す．
【発明を実施するための形態】
【００２９】
図１では，損害とサービス事象と対応レベルマトリックスを定義する．まず，サービスに発生してほしくない状態を１０２「サービス事象部」として定義する．このサービス事象によって損害が発生することがあるが，損害はサービス事象の程度によって異なる．サービス事象がどの程度悪化すれば，損害がどのように変わっていくのか，１０３「サービス事象の程度部」と１０４「損害部」を同時に定義する．１０５「対応レベルマトリックス」では，横軸として左から右へ極希少頻度での発生，希少頻度での発生，頻回に発生などの発生頻度を，縦軸として１０３のサービス事象をとり，０：問題ない，１：対応が必要だがコストは多くかけられない，２：多少コストをかけても対応が必要，３：コストがかかっても対応が必要というように損害に対してどの程度コストをかけて良いかの指標を定義する．この指標は定量的でも定性的でも良い．この０から３までの指標数値を対応レベルと呼び，対応レベルが横軸に頻度，縦軸にサービス事象の程度としてマトリックスとして配置されたものを対応レベルマトリックスと呼ぶ．
図２では，システム事象を定義し，定義したシステム事象に対応レベルマトリックスを関連付ける．２０１「システム事象部」では，システム事象を定義する．２０２「サービス事象部」では，図１で定義したサービス事象を記載する．２０３「システム事象に対応した関連した対応レベルマトリックス部」では，サービス事象とシステム事象に関連した対応レベルマトリックスを記載する．サービス事象に対応するシステム事象のうち，該当するシステム事象がないものには，該当する対応レベルマトリックスもない．
図３では，リスク事象を定義し，定義したリスク事象に対応レベルマトリックスを関連付ける．３０１「サービス事象部」では，図１で定義したサービス事象を記載する．３０２「リスク事象部」では，システム事象を引き起こす自然現象及び人為事象を洗い出す．３０３「該当レベルマトリックス部」では，横軸に頻度，縦軸にサービス事象の程度をとり，このうち該当のサービス事象が該当する頻度及びサービス事象に１を記入する．この際，1つの該当レベルマトリックスには１は１つだけで他の要素はゼロでなければならない．１が複数ある場合は別のリスク事象として取り扱う．３０６「システム事象に対応した対応レベルマトリックス部」では，３０５「システム事象部」に該当するリスク事象について２０３の対応レベルマトリックスと３０３の該当レベルマトリックスのアダーマル積をとる．
図４では，図１から図３までで関連付けてきたサービス事象とシステム事象とリスク事象を４０１「サービス事象部」４０２「リスク事象部」４０３「システム事象部」に記載する．４０４「対応レベル値部」では図３の３０６で導出される値を記載する．４０７「対策内容部」ではリスク対策になりえる対策案を抽出する．４０８「費用性部」では対策に必要となる費用感または実際の費用を記載する．図の例では費用感として，０はコストがほとんどかからない，１は多少コストがかかる，２はコストがかかる，３はコスト影響が大きい，４はコスト影響が著しく大きいと例示した．４０９「制約部」では費用性以外に使用性や性能が犠牲になったり，運用の手間が増えたりなどのマイナス要因を記載する．４０１「残存リスク部」では，対策しても残る残存リスクの内容とそのリスクに対する識別方法を記載する．リスク識別は，再帰の場合は再度リスク事象として取り扱い，対策を抽出する．リスク識別が受容の場合はその残存リスクは受容し対策をそれ以上施さない．リスク識別が無しの場合は，残存リスクが無い場合である．複数の対策案が出てきた場合は４０８や４０９や４１０から実際に施す対策を選択し，４０５「対策選択部」に〇と記載する．
【図１】
2019149157.tif 000003
【図２】
2019149157.tif 000004
【図３】
2019149157.tif 000005
【図４】
2019149157.tif 000006