TOP特許意匠商標
特許ウォッチ DM通知 Twitter
公開番号2019149151
公報種別公開特許公報(A)
公開日20190905
出願番号2019000206
出願日20190104
発明の名称リスク収束フレームワーク
出願人株式会社LEXAR
代理人
主分類G06Q 10/06 20120101AFI20190809BHJP(計算;計数)
要約【課題】リスク収束フレームワークによるリスク抽出を容易に行う方法を提供する。
【解決手段】方法は、システム事象からリスク事象を抽出するステップと、抽出したリスク事象に対する対策を立案するステップと損害レベル別サービス事象と損害レベル別サービス事象に対応する頻度別対応レベルから対策が該当する対応レベルの最大値を選択するステップと、対策による効果・対策による制約・費用性・対応レベル値・残存リスクから対策を選択するステップ及び受容できない残存リスクが残る場合、対策の立案、選定と残存リスクの抽出を再帰的に繰り返すステップを有する。
【選択図】図1
特許請求の範囲約 850 文字を表示【請求項1】
損害程度と損害程度に応じた対応レベルを定義するステップとシステム事象と損害レベル別サービス事象と対応レベルを関連付けるステップとリスクの抽出と対策の立案及び選択を残存リスクが収束するまで再帰的に行うステップを特徴としたリスク分析方法と適切な対策選択方法
【請求項2】
損害レベル別サービス事象・発生頻度・損害種別から損害程度を定義するステップと損害程度から対応レベルを選択するステップを特徴とした請求項1の損害程度と損害程度に応じた対応レベルを定義する方法
【請求項3】
システム事象と損害レベル別サービス事象と損害レベル別サービス事象に対応する頻度別対応レベルを関連付けるステップを特徴としたシステム事象と損害レベル別サービス事象と頻度別対応レベルを関連付ける方法
【請求項4】
システム事象からリスク事象を抽出するステップと抽出したリスク事象に対する対策を立案するステップと損害レベル別サービス事象と損害レベル別サービス事象に対応する頻度別対応レベルから対策が該当する対応レベルの最大値を選択するステップと対策による効果・対策による制約・費用性・対応レベル値・残存リスクから対策を選択するステップと受容できない残存リスクが残る場合、対策の立案及び選定と残存リスクの抽出を再帰的に繰り返すステップを特徴とした請求項1のリスクの抽出と対策の立案及び選択を残存リスクが収束するまで再帰的に行う方法
【請求項5】
システムリスクを分析して対策を立案するステップにおいて、サービス事象から損害種別を定義するステップとサービス事象からシステム事象を定義するステップを特徴とする損害種別とシステム事象の定義方法
【請求項6】
請求項1で選択した対策のうち、運用工程において人の手の介在を必要とするものを抽出するステップと対策の結果、運用工程で必要になる作業を定義するステップを特徴とした運用要件の定義方法

発明の詳細な説明約 7,600 文字を表示【技術分野】
【0001】
本発明はシステムにおけるリスクマネジメントの方法に関する。
【背景技術】
【0002】
リスクマネジメントとは起きてほしくないことが起きることで、損害が発生することを避けることであり、リスクとは損害を発生させる要因を指す。システムにおけるリスクには、機能リスクと非機能リスクがある。本発明では、機能が要件通りに実装されないリスクを機能リスクと呼び、非機能リスクとは、機能以外の可用性や性能、セキュリティ、移行等に分類されるリスクのことをいう。リスクを分析し、対策していく過程はISOなど多くの標準で示されている。しかし、そこではリスクの識別や評価など大きなステップを紹介しているだけで、具体的な手順は示していない。最適なリスクマネジメントを行うには、リスク識別と対策選択を行う過程の全てが論理的でなければならない。現状、このステップを全て論理的に説明できる方法は存在しない。
【0003】
非機能要求グレードは、非機能に特化して対策項目別に対策レベルを選択する簡易ツールである。リスク識別は含まれておらず、対策選択は表から選択するだけで、合理的な選択手法を提案していない。
【0004】
ゴール指向は、ゴールを設定して要求を具現化する手法である。ゴール指向は、機能要求や非機能要求の抽出を対象とするが、リスク識別方法が属人的になってしまいがちであり、対策選択において合理的な選択手段を取ることができない。
【0005】
フォルトツリー解析は、故障や事故の分析手法でゴール指向同様リスク識別方法が属人的になりがちで、合理的な対策選択手段も取ることができない。
【先行技術文献】
【特許文献】
【0006】
特開2001−222420
特許第3872689号
【非特許文献】
【0007】
システム基盤における非機能要求の見える化ツール 独立行政法人情報処理推進機構
組織の情報セキュリティ対応を支援するモデルの提案とその適用可能性の検討 −ISO/IEC27001:2013及びISO/IEC27002:2013適合モデルとその運用手法について−
情報処理学会研究報告IPSJ SIG Technical Report ゴール指向を用いたセキュリティ要件の定義手法の提案
「マルチメディア、分散、協調とモバイル(DICOMO2016)シンポジウム」 平成28年7月 イベントツリーとディフェスを併用したリスク分析における共通事象を考慮した計算法の提案
【発明の概要】
【発明が解決しようとする課題】
【0008】
システム開発におけるリスクマネジメントは、品質・コスト・納期を大きく左右する重要な要素である。しかし、システムに関するリスクは複雑で目に見えにくいため、どのリスクにどのくらい費用をかけて対策するかは経験と勘に頼ってきた。本来であれば、どのリスクにどの程度費用をかけるのか、残存リスクは何を受容するかは発注者側が選択できなければならないが、経験と勘でリスクマネジメントされるため、どのリスクにどの程度費用をかけるのかは受注者主導で検討され、発注者はコストコントロール出来ず、残存リスク認識もできない。このようなすれ違いが多くのシステムにおいて、プロジェクトの失敗・システム障害・セキュリティ事故を引き起こしてきた。
【0009】
本来、リスクマネジメントの目的はビジネス上必要となる残存リスクレベルまで残存リスクを低下させることとそれに必要な対策を受容できる予算内で実現することである。しかし、リスクマネジメントに関する要求は、方法論が無いこととリスク要求への理解不足からリスクマネジメントとして扱われて来なかった。これにより、発注者側はリスクを識別することが出来ないまま、受注者側の提案通りにリスクへの対策がなされ、本来発注者が得たいはずの最適な対策の選択が出来ていなかった。リスクマネジメントの本来の目的はビジネスが求めるリスクレベルまで残存リスクを低下させることであるから、残存リスクの識別が出来ていないという事は、本来対策するべきリスクが他にもあるのに、そこには対策せずにコストを使いきってしまう可能性があるということである。
【0010】
システム開発は、よく品質・コスト・納期で評価されると言うが、この品質を達成するということは、リスクの低下目標を達成するということと同義である。品質とは、バグ率が低い事でもなければ設計書がきれいにかけることでもない。品質とは、開発されたシステムが運用開始されてから損害を出さずに動き続けることである。このような本来の目的をはき違えているシステム開発が横行している根本原因は、本来の目的を達成するための手段が無かったことによる。
【0011】
リスク識別は、現在でもプロジェクトマネジメントの標準などでステップは提案されており、ISOなどでもリスク識別を行うステップを提案している。しかし、これらは、大きなステップの提案だけで、具体的な手順は提案していない。リスクには様々な粒度のリスクがある。例えばサービス全体のダウンもリスクであり、その原因となるサーバ停止もリスクである。さらにサーバ停止の原因となるCPUの故障もリスクである。このようにリスクは親子関係を持つこともあり、非常に複雑な構造になるため、全体像を明確にすることは難しく、リスクの抽出を困難にしている。
【0012】
更に対策の選択は、様々な要素を総合して判断する必要があるが、これも判断材料を抽出することが難しく、手法がないため、出来ていないケースが多い。セキュリティ対策手段の決定手法の中には、脅威の発生確率・損害発生時の金額などを数値化し、損害の期待値を数値化する手法がある。しかし、実際のシステム開発の現場で脅威発生時の損害金額算定は発注者にしかできず、最も秘密度の高いそのような情報をベンダに渡すことは非常に障壁が高い。また、損害額の算定は発注者にとっても負担が大きい。更に損害の発生確率はその分子や分母となる情報を正しく集めることが不可能に近く、脅威期待値を求めることは現実的でない。
【0013】
プロジェクトマネジメントでは、進捗の管理手段として設計書やプログラムのステップ数、構築したサーバ類の数などを管理してきた。また品質基準としては、バグ率を管理するのが一般的であった。しかし、リスクに関してはこれらを管理した所でリスクの達成基準にはならない。このように十分にリスク対策が出来ていない状態で次の工程に進むことも多く、これがプロジェクト失敗の要因にもなっている。
【課題を解決するための手段】
【0014】
リスクに対応するには、リスクが現実化した時の損害を定義し、その損害にそなえるためにどの程度コストをかけるのかを決める必要がある。これが1つのリスクに対して複数ある対策案を選択する際の予算感となる。
本発明では、この予算感を対応レベルで定義している。
【0015】
本発明では、複雑なリスクを単純化するため、システムの状態とそれを引き起こすリスクに分解して定義することで、リスクを定義しやすくしている。具体的には、前者のシステムの状態とは、サービスの状態を示すサービス事象、サービスを構成する個々のアプリケーション・インフラストラクチャ・データの状態を示すシステム事象である。また、システム事象を引き起こすリスクをリスク事象として定義している。
【0016】
リスクを最小化するには、任意のリスクに対する対策案を抽出して、対策案による制約・対策案にかかるコスト・対策しても残る残存リスク・リスクにかけられる予算感を総合して対策を選択する必要がある。これにより、費用対効果の高い最適な対策選択が出来るようになる。
【0017】
これらのリスクと対策の関係は、開発前に実施するだけではない。開発フェーズに入っても設計や開発・テストの結果、当初想定とリスクと対策の関係が変わることがあるため、これを更新する必要がある。
【0018】
更にこれまでのプロジェクトマネジメントでは、リスクの低下状況を監視することは出来なかったが、リスクと対策の関係を明確に出来るようになったことで、生産量と同様にリスク量を監視できるようになる。
【0019】
運用フェーズでも、新たな脅威が発現したり、ビジネス環境によって損害の重さの定義が変わったりとリスクと対策の状況は変わる。このような変化に合わせて、リスクと対策の関係を見直す必要がある。本発明の手法を用いればこのような変化にも追従できるようになる。
【0020】
本発明における用語の定義を図10に示す。
【発明の効果】
【0021】
リスク収束フレームワーク(以下、RCFという)では、複雑なリスクを識別しやすいようにリスクをサービス事象・システム事象・リスク事象に分解している。これによりリスクは抽出しやすくなっている。
これまで出来なかった適切な対策選択についても、対策・制約・予算感(対応レベル)・費用性(コスト)を総合して判断するステップになっており、適切に対策が選択できるようになっている。
RCFは全てのステップが論理的な関係になっているため、属人性が極めて低い。これにより、論理的な思考が苦手なエンジニアでもリスクマネジメントに取り組めるようになっている。
RCFによって、残存リスクが適切に認識出来るようになると、今まで目に見えなかった開発するシステムの品質要件を見える化することができるようになる。これは、品質要件のコスト適正化を支援するだけでなく、プロジェクトマネジメントにおける品質要件の準拠性確認を定量的に確認することも支援する。
このように、品質要件を見える化することでプロジェクト失敗やシステム障害・セキュリティ事故による損害を極小化出来るようになる。更に品質を見える化するということは、品質要件が生む開発量増加を適切にコントロールすることにもつながり、発注者がシステム開発コストをコントロール出来るようになることにもつながる。
【図面の簡単な説明】
【0022】
本発明のプロセス全体像
サービス事象の定義を行うマトリックス
損害種別の定義を行うマトリックス
損害レベルの定義を行うマトリックス
システム事象の定義を行うマトリックス
対応レベルの定義を行うマトリックス
損害程度に応じた対応レベルの設定を行うマトリックス
システム事象と損害レベル別サービス事象と対応レベルの関連付けを行うマトリックス
リスク収束マトリックス
用語の定義
【符号の説明】
【0023】
本発明の具体的手順を形態に示す。
【発明を実施するための形態】
【0024】
図1は、本発明を実施するためのプロセスの全体像である。101「サービス事象の定義」では、損害の原因となるロールから見たシステムに起こる不具合の定義を行う。102「損害種別の定義」では、101を入力に、あるサービス事象によって発生する損害の定義を行う。103「システム事象の定義」では、102を入力にサービス事象の原因となるインフラストラクチャ・アプリケーション・データの状態を定義する。104「対応レベルの定義」では、対策にどのように費用をかけるかレベル分けを行う。105「損害レベルの定義」では、損害の大小を抽象的に定義する。106「損害程度に応じた対応レベルの設定」では、101・102・104・105を入力に損害程度に応じた対応レベルの設定を行う。107「システム事象と損害レベル別サービス事象と対応レベルの関連付け」では、103・105・106を入力にシステム事象と損害レベル別サービス事象と対応レベルの関連付けを行う。108「リスク事象の抽出」では、103を入力にリスク事象の抽出を行い、109「対策の立案・選択」では、107と108を入力に対策の立案・選択を行い、110「残存リスクの抽出」では、109を入力に残存リスクの抽出を行う。残存リスクが無い又は受容できないリスクが残る場合は、残る残存リスクを108として108〜109のプロセスを再帰的に繰り返す。対策を選択したら、運用工程において人の介在が必要な作業を運用要件として洗い出す。
【0025】
図2はサービス事象の定義ステップである。201「ロール部」には、システムを取り巻くロールのうち、発注者がそのロールに不利益が発生すると困るロールを定義する。 202「事象分類部」には、システムの外から見た性質を定義する。203「サービス事象部」には、システム事象の発生により各ロールが認識する事象を定義する。203は、201と202の各項目に該当する内容を定義する。
【0026】
図3は損害種別の定義ステップである。301「ロール部」は図2の201と同じロールを定義する。302「事象分類部」には、図2の202と同じ性質を定義する。303「損害種別」には、301と302の各項目に該当するサービス事象によって発注者に発生する損害を定義する。
【0027】
図4は、損害レベルの定義ステップである。401「損害レベル文字列定義部」では、大中小等任意の文字列を定義する。402「損害レベルの内容定義部」では、損害を抽象的にレベル分けして定義する。
【0028】
図5は、システム事象の定義ステップである。501「ロール部」は、図2の201のロールのうちの1つを設定する。502「事象分類部」は、図2の202「サービス性質部」と同じ性質を定義する。503「サービス事象部」は、図2の203「サービス事象部」と同じ性質を定義する。504「損害レベル別サービス事象部」は、図4と503を入力に損害レベル別にサービス事象を定義する。505「システム事象部」には、サービス事象が発生する原因となるシステムに発生する故障などの事象を定義する。506「損害レベル別サービス事象に該当するシステム事象部」には、損害レベル別サービス事象に該当するシステム事象に〇を記入する。
【0029】
図6は、対応レベルの定義ステップである。601「対応レベル文字列部」では、整数等任意の文字列を定義する。602「対応レベルの内容部」では、対策にどのように費用をかけるかレベル分け定義を行う。
【0030】
図7は、損害程度に応じた対応レベルの設定を行うステップである。701「ロール部」では、図2の201のロールのうちの1つを設定する。702「事象分類部」では、図2の202と同じ性質を定義する。703「サービス事象部」では、図2の203と同じ事象を定義する。704「損害種別部」では、図3の303と同じ種別を定義する。705「損害レベル別サービス事象部」では、図5の504と同じ事象を定義する。706「頻度部」では、損害が発生する頻度を定義する。707「頻度別損害部」では、706で定義した頻度別に704で定義された損害種別を具体化する。708「頻度別対応レベル部」では、707で具体化した損害に対してどの程度費用をかけるか図6で定義した対応レベルから対応レベル文字列を1つ選択する。
【0031】
図8は、システム事象と損害レベル別サービス事象と対応レベルの関連付けを行うステップである。801「ロール部」では、図2の201のロールのうちの1つを設定する。803「事象分類部」では、図2の202と同じ性質を定義する。802「システム事象部」では、図5からの505からシステム事象を選択する。804「損害レベル別サービス事象部」では、図5の504と同じ事象を定義する。805「頻度部」は、図7の705に対応した706を設定する。806「頻度別対応レベル部」は、図7から804と805に対応した708を設定する。
【0032】
図9は、リスクの収束マトリックスである。901「ロール部」では、図2の201のロールのうちの1つを設定する。902「損害レベル別サービス事象部」では、804の事象を記載する。903「システム事象部」では、図8の802から1つを選択する。904「リスク識別子部」では、904を一意に識別できる識別子を付番する。905「リスク内容部」では、903に対するリスクを抽出する。906「前提対策部」では、907の前提となる対策識別子を記載する。907「対策識別子部」では、907を一意に識別できる識別子を付番する。908「対策内容部」では、904に対する対策を立案する。909「対策による効果部」では、908による効果を算定する。910「対応レベル部」では、図8の対応レベルについて、列を損害レベル・行を頻度として配列化して記載し、908が該当する対応レベルについてはグレーアウトする。911「対応レベル値部」では、910でグレーアウトしたもののうち最大値を選択する。912「採否部」では、対策を選択する場合は〇を記載する。913「否理由部」では、対策を選択しない場合の理由を記載する。914「制約部」では、対策による制約を記載する。915「費用性部」では、対策によって発生する費用を定量的又は定性的に記載する。916「リスク識別子部」では、残存リスクを一意に識別できる識別子を付番する。904とは連番とする。917「リスク内容部」では、残存リスクを記載する。918「リスク識別部」では、残存リスクが無いものは”無し”、受容できるものは”受容”、対策を選択しないものは”回避”、残存リスクをリスク事象として更に対策を検討するものは“再帰”と記載する。対策を選択したら、919「運用要件部」において運用工程において人の介在が必要な作業を運用要件として洗い出す。

関連特許

株式会社LEXAR
リスク収束フレームワーク
株式会社LEXAR
リスク収束フレームワーク
個人
画像処理装置
個人
葉書の作成方法
個人
情報管理装置
個人
相続財産比較システム
個人
汎用人工知能実現方式
凸版印刷株式会社
表示装置
個人
支援装置
株式会社ニコン
サーバ
株式会社クボタ
支援装置
キヤノン株式会社
電子機器
株式会社東芝
支援システム
個人
買い物代行サービスシステム
株式会社ミツトヨ
入力装置
株式会社LIXIL
支援装置
株式会社リコー
画像形成装置
日本電気株式会社
ノード
飛島建設株式会社
宅配システム
株式会社デンソー
検証端末
個人
掲載データのクリッピングシステム
株式会社半導体エネルギー研究所
電子機器
株式会社リコー
文書操作機構
個人
ユーザパフォーマンス判定装置