JP7428190B2 - リソース配分算出装置、リソース配分算出方法およびリソース配分算出プログラム - Google Patents

Description

本発明は、リソース配分算出装置、リソース配分算出方法およびリソース配分算出プログラムに関する。

企業や官公庁などの組織では、製品やサービスを生産または提供する事業を営んでいる。自然災害やサイバー攻撃などにより、機器や拠点などの事業を実現するための要素が被害を受けるインシデントが発生すると、当該要素を利用する業務では遅延や停止が生じ、事業のサービスレベルが社会から期待されるレベルもしくは組織が目標とするレベルを下回ることがある。

インシデント発生時には、複数の要素で被害が同時多発的に起こることがある。組織全体としての被害を抑えかつ早期に復旧するには、事業における重要度という観点から、対応するべき物事の優先順位を付けて、限られたリソースを効率的・効果的に配置する必要がある。このような判断を迅速にできるようにする方法として、事業継続計画が知られている（例えば、非特許文献１）。

"事業継続ガイドライン－あらゆる危機的事象を乗り越えるための戦略と対応－"、[online]、内閣府、[２０２０年１月２０日検索]、＜http://www.bousai.go.jp/kyoiku/kigyou/pdf/guideline03.pdf＞

しかしながら、上記した従来の技術では、インシデント発生時において、リソースを適切に配分できない場合があるという課題があった。例えば、上述した事業継続計画では、基本方針を策定し、事業影響度とリスクを分析・評価し、事業継続戦略と対策を検討する、という手順を踏むことで策定される。事業影響度の分析の具体的な手順は、事業中断による影響度を評価し、その結果を踏まえて優先的に継続・復旧すべき重要業務を絞り込んで目標復旧時間と目標復旧レベルを設定し、それぞれの重要業務の実施に不可欠となる重要な要素を把握してボトルネックを抽出する、という手順で構成される。

リスクの分析の具体的な手順は、事業中断を引き起こす可能性がある発生事象を洗い出し、それらの事象の発生の可能性及び発生した場合の影響度を評価して優先的に対応すべき発生事象を絞り込んで、事業影響度の分析で選定した重要業務に対して発生事象による被害を検討して目標復旧時間と目標復旧レベルを推定する、という手順で構成される。

従来技術に従うと、インシデント発生時には、インシデント発生時の状況と事業継続計画の内容とを照らし合わせることで、被害を受けている要素が重要業務に関係しているかどうかを判別し、次に、目標復旧時間と目標復旧レベルを参照して、対応の優先順位とそれに伴うリソース配分を判断する。

ただし、そのとき組織が利用できるリソースには限りがあるため、目標復旧時間と目標復旧レベルを達成するには、インシデント発生による被害を受けていない業務に割り当てているリソースを借りなければならないことがある。このような場合に、リソースを貸し出すという選択を取ると、目標復旧時間と目標復旧レベルは達成できる一方で、リソースを貸し出した業務ではサービスレベルが低下する。

上述した課題を解決し、目的を達成するために、本発明のリソース配分算出装置は、障害が発生した事業について、該事業の復旧のために必要なリソースを決定する決定部と、障害が発生していない他の事業における余剰リソース量を算出する算出部と、前記算出部によって算出された余剰リソースを基に、障害が発生した事業に配分可能なリソースに関する情報を出力する出力部とを有することを特徴とする。

本発明によれば、インシデント発生時において、リソースを適切に配分することができるという効果を奏する。

図１は、第１の実施形態に係るリソース配分算出装置を含むシステムの構成を説明するための図である。 図２は、事業、業務プロセスリストおよび業務フローチャートの一例を示す図である。 図３は、業務フローチャートおよび必要リソース定義リストの一例を示す図である。 図４は、業務支援システムフローチャートおよび業務支援システムリストの一例を示す図である。 図５は、予実管理リストにおける売上管理に関するデータ例を示す図である。 図６は、予実管理リストにおける作業管理に関するデータ例を示す図である。 図７は、リソース管理リストにおけるリソースの状態概要に関するデータ例を示す図である。 図８は、リソース管理リストにおけるリソースの状態詳細に関するデータ例を示す図である。 図９は、各要素の紐づけについて説明する図である。 図１０は、事業継続計画の一例を示す図である。 図１１は、暫定対応手順および復旧手順の一例を示す図である。 図１２は、第１の実施形態に係るリソース配分算出装置における処理の流れの一例を示すフローチャートである。 図１３は、各ステップの処理結果の例を示す図である。 図１４は、トレードオフを考慮したリソース提供の算出処理について説明する図である。 図１５は、出力されるデータ例を示す図である。 図１６は、リソース配分算出プログラムを実行するコンピュータを示す図である。

以下に、本願に係るリソース配分算出装置、リソース配分算出方法およびリソース配分算出プログラムの実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態により本願に係るリソース配分算出装置、リソース配分算出方法およびリソース配分算出プログラムが限定されるものではない。

［第１の実施形態］
以下の実施の形態では、第１の実施形態に係るリソース配分算出装置１０を含むシステム１の構成、リソース配分算出装置１０の処理の流れを順に説明し、最後に第１の実施形態による効果を説明する。

［リソース配分算出装置の構成］
図１は、第１の実施形態に係るリソース配分算出装置を含むシステムの構成を説明するための図である。図１に例示するように、本実施形態のリソース配分算出装置１０は、複数の業務支援システムＮ_Ｓ（Ｎ_Ｓ＝１，…，ｊ）と複数の異常検知システムＮ_Ａ（Ｎ_Ａ＝１，…，ｋ）と、複数の必要リソース管理システムＮ_Ｒ（Ｎ_Ｒ＝１，…，ｌ）、複数の業務計画管理システムＮ_Ｍ（Ｎ_Ｍ＝１，…，ｍ）との情報を用いて、後述するリソース配分算出処理を行う。ここで、ｊ、ｋ、ｌ、ｍは互いに異なる数値でもよい。

リソース配分算出装置１０は、例えばサーバ装置である。リソース配分算出装置１０は、障害が発生した事業について、該事業の復旧のために必要なリソースを決定し、障害が発生していない他の事業における余剰リソース量を算出し、算出された余剰リソースを基に、障害が発生した事業に配分可能な余剰リソースに関する情報を出力する。

リソース配分算出装置１０は、インシデント発生時に、被害を受けている業務と被害を受けていない業務との間で適切にリソースを配分することを支援するために、インシデントの被害状況と目標復旧レベル、事業影響度とを比較して、リソース配分を効果的に実行することができる。

業務支援システムＮ_Ｓは、事業を遂行する組織において、業務を実施するために利用されるＩＴシステムである。各業務支援システムＮ_Ｓは、システムログやエラーログを記憶している。システムログは、当該業務支援システムＮ_Ｓの動作履歴である。エラーログには、異常が発生した場合に、当該業務支援システムＮ_Ｓの業務機能のいずれの異常状態かを示す障害情報が含まれる。

異常検知システムＮ_Ａは、業務支援システムＮ_Ｓの異常を検知するためのシステムである。それぞれあるいは複数の業務支援システムＮ_Ｓに対応して、１以上の異常検知システムＮ_Ａが存在する。各異常検知システムＮ_Ａは、それぞれの対象の業務支援システムＮ_Ｓの異常を検知した場合の履歴である異常検知ログを記憶している。異常検知ログには、対象の業務支援システムＮ_Ｓの業務機能のいずれの異常状態かを示す障害情報が含まれる。

必要リソース管理システムＮ_Ｒは、各事業において必要となるリソースを管理するためのシステムである。それぞれあるいは複数の業務支援システムＮ_Ｓに対応して、１以上の必要リソース管理システムＮ_Ｒが存在する。各必要リソース管理システムＮ_Ｒは、各業務手順を実施するために必要なリソースの情報を含むリソース管理リストを記憶している。リソース管理リストには、各業務手順を実施するために必要なリソースの利用状況や残数などの一覧が含まれる。

業務計画管理システムＮ_Ｍは、事業を遂行する組織における事業や業務プロセス、業務手順の計画および実績を管理するためのシステムである。各業務計画管理システムＮ_Ｍは、予実管理リストを記憶している。予実管理リストには、事業や業務プロセス、業務手順の計画および実績の一覧が含まれる。

また、図１に示すように、リソース配分算出装置１０は、外部データ入力部１１、障害事象入力部１２、紐付け部１３、判定部１４、決定部１５、算出部１６、出力部１７および記憶部１８を有する。

記憶部１８は、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。

本実施形態において、記憶部１８は、リソース配分算出式、事業リスト、事務プロセスリスト、業務フローチャート、業務支援システムリスト、業務支援システムフローチャート、必要リソース定義リスト、事業継続計画、復旧手順、暫定対応手順および緊急時対応必要リソース定義リストを記憶する。

これらの情報は、後述するリソース配分算出処理に先立って業務支援システムＮ_Ｓ等から収集され、記憶部１８に記憶される。なお、これらの各種情報は、リソース配分算出装置１０の記憶部１８に記憶される場合に限定されず、例えば、後述するリソース配分算出処理が実行される際に収集されてもよい。

リソース配分算出式は、各々の目標復旧時間と目標復旧レベルを達成するために必要な対応策を実施するために必要なリソースを算出するための算出式である。事業リストは、組織で行っている全業務の一覧である。

業務プロセスリストは、各事業を構成する業務プロセスの一覧である。業務フローチャートは、各業務プロセスの業務手順を記述した一覧である。業務支援システムリストは、各業務プロセスで利用するシステムの一覧である。

業務支援システムフローチャートは、各業務プロセスの各業務手順で利用する業務支援システムＮ_Ｓおよび業務支援システムＮ_Ｓの業務機能を記述した一覧である。必要リソース定義リストは、各業務手順を一回当たり実施するために必要なリソースを記述した一覧である。ここで「必要リソース定義リスト」とは、単位あたりの必要なリソースを記述したもので、「必要リソース」とは、実際に必要なリソースの数（単位×業務手順の実行回数で導出されるリソース）を記述したものとする。

事業継続計画は、インシデントが発生したときの目標復旧レベルと目標復旧時間、目標復旧レベルに達するための対応策、対応体制と対応手順を示した情報である。復旧手順は、サービスレベルを通常の正常なレベルまでに完全に回復するための実施事項とその実施順序を示した情報である。

暫定対応手順は、サービスレベルの完全復旧に至るまでの途中の過程として、段階的な目標復旧レベルとそれを達成するために必要な実施事項とその実施順序を示した情報である。緊急時対応必要リソース定義リストは、復旧手順および暫定対応手順を実施するために必要なリソースを記述した一覧である。ここで「緊急時対応必要リソース定義リスト」とは、「必要リソース定義リスト」と比較すると、実際に必要なリソースの数を意味するものとする。

外部データ入力部１１は、業務支援システムＮ_Ｓから出力されたシステムログとエラーログ、異常検知システムＮ_Ａから出力された異常検知ログ、必要リソース管理システムＮ_Ｒから出力されたリソース管理リスト、業務計画管理システムＮ_Ｍから出力された予実管理リストなどの、外部システムまたは外部記憶媒体からのデータを、リソース配分算出装置１０に取り込むためのインタフェースである。

障害事象入力部１２、インシデント発生による事業や業務などの被害状況を手動入力できるインタフェースである。

紐付け部１３は、事業、業務プロセス、業務手順および必要リソースの紐づけを行い、その後、必要リソースとリソース状況の紐付けを行う。また、紐付け部１３は、事業継続計画、緊急時対応および緊急時対応必要リソースの紐付けを行う。

［事業・業務プロセス・業務手順・必要リソースの紐付け］
ここで、図２および図３の例を用いて、事業と業務プロセス、業務手順、必要リソースとを紐付ける処理について説明する。図２は、事業、業務プロセスリストおよび業務フローチャートの一例を示す図である。図３は、業務フローチャートおよび必要リソース定義リストの一例を示す図である。

図２に例示するように、事業リストには、事業の一覧が記録されているものとする。業務プロセスリストには、各事業と各事業を構成する業務プロセス群を紐付けた一覧と、各業務プロセス群を構成する各業務プロセスとその順序関係が記録されているものとする。

業務フローチャートには、各業務プロセスと各業務プロセスを構成する業務手順群を紐付けた一覧と、各業務手順群を構成する各業務手順とその順序関係が記録されているものとする。

また、図３に例示するように、必要リソース定義リストには、各業務手順を実現するために必要な、リソース種別（例：人員、ツール、時間など）と、リソース名、リソース必要数、リソース再利用周期などが記録されている。なお、必要リソース定義リストは、他にも、リソースのスペック（人員に求められるスキル、機器に求められるスペックなど）などが記録されていてもよい。

各リストおよび各フローチャートに含まれる要素は、一意に識別可能なように、要素名や要素ＩＤが定義されているものとする。また、各事業を構成する業務プロセス群および各業務プロセスを構成する業務手順群に対しても同様に、一意に識別可能なように、要素名や要素ＩＤを定義してもよい。

例えば、紐付け部１３では、記憶部１８からリソース配分算出式を呼び出し、事業リスト、業務プロセスリスト、業務フローチャート、必要リソース定義リストを入力として、要素名や要素ＩＤに基づき各リストと各フローチャートに含まれる要素を紐付けることで、「事業⇔業務プロセス⇔業務手順⇔必要リソース」のようにリストやフローチャートをまたいで各要素を紐付ける。

この紐付けを行うことで、リソース配分算出装置１０は、ある業務手順を１回実行するために必要なリソースを算出できる。また、リソース配分算出装置１０は、この算出結果を用いると、事業リスト、業務プロセスリスト、業務フローチャートにおいて、事業を実現するために必要な各業務プロセスの反復回数や、各業務プロセスを実行するために必要な各業務手順の反復回数が定義されている場合には、事業や業務プロセス、業務手順を実現するために必要なリソースの小計および総量を算出できる。

［必要リソース・リソース状況の紐付け］
図４～図９の例を用いて、事業と業務プロセス、業務手順、必要リソースとを紐付ける処理について説明する。図４は、業務支援システムフローチャートおよび業務支援システムリストの一例を示す図である。図５は、予実管理リストにおける売上管理に関するデータ例を示す図である。図６は、予実管理リストにおける作業管理に関するデータ例を示す図である。図７は、リソース管理リストにおけるリソースの状態概要に関するデータ例を示す図である。図８は、リソース管理リストにおけるリソースの状態詳細に関するデータ例を示す図である。図９は、各要素の紐づけについて説明する図である。

図４に例示するように、業務支援システムリストには、各業務手順で利用する業務支援システムと各業務支援システムＮ_Ｓが提供する業務機能を紐付けた一覧が記録されているものとする。また、業務支援システムフローチャートには、各業務手順と各業務手順で利用する各業務支援システムＮ_Ｓと各業務支援システムＮ_Ｓの各業務機能を紐付けた一覧が記録されているものとする。

業務支援システムのシステムログとエラーログ、および異常検知システムの異常検知ログには、あるログがどの業務支援システムまたは業務機能に関するものであるかを判別できるように、業務支援システムおよび業務機能を一意に識別ための要素名や要素ＩＤを含んでいるものとする。

また、予実管理リストには、各事業や各業務プロセス、各業務手順の実行期間と実行回数などの計画と実績が記録されているものとする。例えば、図５に例示するように、予実管理リストには、各事業の任意の期間の売上の目標と実績が記録されている。また、例えば、図６に例示するように、予実管理リストには、各業務プロセスの任意の期間の実行回数の計画と実績、各業務手順の任意の期間の実行回数の計画と実績が記録されている。

リソース管理リストには、予実管理リストにて計画している各業務手順を実現するために必要なリソースの状態概要やリソースの状態詳細などが記録されているものとする。

リソースの状態概要とは、例えば、図７に例示するように、人員や時間に関しては、ある期間に必要なリソースの残数と、確保しているリソースとを比較することで、正常/異常（ＯＫ／ＮＧ）などが判定されているものとする。ツールに関しては、システムログやエラーログ、異常検知ログに含まれる要素名や要素ＩＤに基づき、正常/異常などが判定されているものとする。

また、リソースの状態詳細とは、例えば、図８に例示するように、ある日に業務手順２００１を１２０回実行する予定である場合に、必要なリソースの計画値と現時点までに費やしたリソースの実績値、残りの回数を実行するために必要なリソースの残数、確保しているリソースの数が該当する。なお、図８の例示は、図７の例示におけるリソース状況の判定を行うために用いる要素となっている。

各リストおよび各フローチャートに含まれる要素は、一意に識別可能なように、要素名や要素ＩＤが定義されているものとする。紐付け部１３では、記憶部１８からリソース配分算出式を呼び出し、上述した事業・業務プロセス・業務手順・必要リソースの紐付け処理の結果と、必要リソース定義リスト、業務支援システムリスト、業務支援システムフローチャートと、外部データ入力部が取り込んだシステムログ、エラーログ、異常検知ログ、予実管理リスト、リソース管理リストを入力として、要素名や要素ＩＤに基づき各リストと各フローチャートなどに含まれる要素を紐付ける。これにより、図９に例示するように、紐付け部１３は、下記のようにリストやフローチャートをまたいで各要素を紐付けることができる。
「事業⇔業務プロセス⇔業務手順⇔必要リソース⇔リソース状況⇔システムログ・エラーログ・異常検知ログ・予実管理リスト」

［事業継続計画・緊急時対応・緊急時対応必要リソースの紐付け］
図１０および１１の例を用いて、事業継続計画と緊急時対応の各種手順と各種手順の実行に必要なリソースとを紐付ける処理について説明する。図１０は、事業継続計画の一例を示す図である。図１１は、暫定対応手順および復旧手順の一例を示す図である。

図１０に例示するように、事業継続計画には、各事業の緊急時対応と各事業の各目標復旧レベルとその目標復旧時間を紐付けた一覧と、各目標復旧レベルとその達成判断基準を紐付けた一覧が記録されているものとする。なお、各事業の各目標復旧レベルには、各事業の重要度に基づき、絶対的または相対的な優先度が定められているものとする。

また、図１１に例示するように、暫定対応手順には、事業継続計画が定める目標復旧レベルに関連付けられる対応策の一覧と、各対応策と各対応策を構成する暫定対応手順を紐付けた一覧が記録されているものとする。また、各暫定対応手順と後述の緊急時対応必要リソース定義リストとを紐づけた一覧を含んでいてもよい。

また、図１１に例示するように、復旧手順には、事業継続計画が定める目標復旧レベルに関連付けられる対応策の一覧と、各対応策と各対応策を構成する復旧手順を紐づけた一覧が記録されているものとする。また、各復旧手順と後述の緊急時対応必要リソース定義リストとを紐づけた一覧を含んでいてもよい。

緊急時対応必要リソース定義リストには、緊急時の各種手順を実現するために必要な、リソース種別（例：人員、ツール、時間など）と、リソース名、リソース必要数、リソース再利用周期が記録されているものとする。各リストおよび各手順に含まれる要素は、一意に識別可能なように、要素名や要素ＩＤが定義されているものとする。

紐付け部１３では、リソース配分算出式を呼び出し、事業継続計画、暫定対応手順、復旧手順、緊急時対応必要リソース定義リストを入力として、要素名や要素ＩＤに基づき各リストと各手順に含まれる要素を紐づけることで、「目標復旧レベル⇔対応策⇔対応策の詳細（暫定対応手順、復旧手順）⇔緊急時対応必要リソース」のようにリストや各手順をまたいで各要素を紐付ける。紐付け部１３では、この紐付けを行うことで、ある目標復旧レベルを実現するために必要な手順とその手順を実現するために必要なリソースの小計と全体で必要なリソースの総量を算出できる。

判定部１４は、障害が発生した事業を判定する。例えば、判定部１４は、業務支援システムＮ_Ｓから出力されたシステムログやエラーログ、異常検知システムＮ_Ａから出力された異常検知ログ、または障害事象入力部１２にて入力された障害情報を入力することで、障害発生箇所を判定する。ここで、障害事象入力部１２にて入力される障害情報とは、リソース管理リストで管理されるリソース状況が異常であることを示す情報であるとする。なお、判定結果である「リソース状況」の値を入力してもよいし、より正確には、図８で示されるリソース状況の判定に用いる各要素を障害情報として入力してもよい。

決定部１５は、障害が発生した事業について、該事業の復旧のために必要なリソースを決定する。具体的には、決定部１５は、判定部１４によって障害が発生したと判定された事業について、該事業の復旧のために必要なリソースを決定する。

算出部１６は、障害が発生していない他の事業における余剰リソース量を算出する。また、算出部１６は、障害が発生していない他の事業が複数ある場合には、複数の他の事業について、余剰リソース量をそれぞれ算出し、算出された各余剰リソースのうち、余剰リソース量が最も多い他の事業の余剰リソースを優先的に配分可能な余剰リソースとして決定してもよい。

また、算出部１６は、他の事業に余剰リソースがない場合には、障害が発生していない他の事業について、障害が発生した事業にリソースを提供した場合に事業に与える影響度をそれぞれ算出し、影響度が少ない事業のリソースを優先的に配分可能なリソースとして決定してもよい。

出力部１７は、算出部１６によって算出された余剰リソースを基に、障害が発生した事業に配分可能なリソースに関する情報を出力する。具体的には、出力部１７は、算出部１６によって決定された配分可能なリソースに関する情報を出力する。例えば、出力部１７は、リソースの拠出元とリソースの拠出量、リソースを拠出したことによるサービスレベルの低下の度合いとそれに該当する目標復旧レベルを出力する。なお、判定部１４、決定部１５、算出部１６および出力部１７のより詳しい処理については、下記の処理手順において説明する。

［リソース配分算出装置の処理手順］
次に、図１２を用いて、第１の実施形態に係るリソース配分算出装置１０における処理の流れを説明する。図１２は、第１の実施形態に係るリソース配分算出装置における処理の流れの一例を示すフローチャートである。

図１２に例示するように、リソース配分算出装置１０の紐付け部１３は、事業、業務プロセス、業務手順および必要リソースの紐づけを行い（ステップＳ１）、その後、必要リソースとリソース状況の紐付けを行う（ステップＳ２）。また、紐付け部１３は、事業継続計画、緊急時対応および緊急時対応必要リソースの紐付けを行う（ステップＳ３）。

続いて、判定部１４は、障害の箇所を判定する（ステップＳ４）。そして、判定部１４は、緊急性のある障害が発生しているか判定する（ステップＳ５）。この結果、判定部１４は、緊急性のある障害が発生していると判定した場合には（ステップＳ５肯定）、ステップＳ６に進む。また、判定部１４は、緊急性のある障害が発生していないと判定した場合には（ステップＳ５否定）、そのまま処理を終了する。

より詳細に説明すると、判定部１４では、リソース配分算出式を呼び出し、ステップ２の結果と、業務支援システムから出力されたシステムログやエラーログ、異常検知システムから出力された異常検知ログ、または障害事象入力部にて入力された障害情報を入力することで、障害発生箇所を判定する。

ここで、障害事象入力部にて入力される障害情報とは、リソース管理リストで管理されるリソース状況が異常であることを示す情報であるとする。判定部１４は、例えば、業務機能４００１で障害が発生しているときは、業務支援システムのエラーログまたは異常検知システムの異常検知ログに、その障害情報が含まれるので、業務機能４００１で障害が発生していると判定する。続いて、判定部１４では、リソース状況の判定結果とステップ２の結果とを比較して、任意の期間において業務機能４００１の障害により業務手順、業務プロセス、事業の障害が発生しているかを判定する。

例えば、判定部１４では、業務機能４００１で障害が発生していて、業務機能４００１を利用する業務手順２００１の作業計画がある場合には、業務手順および業務プロセス、事業には障害が発生していると判定する。また、判定部１４では、業務機能４００１を利用する業務手順２００１の作業計画がない場合には、業務手順および業務プロセス、事業には障害が発生していないと判定する。

また、業務機能４００１で障害が発生しているが、業務機能４００１を利用する業務手順２００１の作業計画がない場合には、確かに業務機能４００１の障害を解消する必要があるが、このような復旧対応は緊急度が高くないということを意味する。あくまで本実施形態は緊急度が高いときに、リソース配分をどうするかに焦点を当てているため、緊急度の高くない復旧対応の対応計画およびリソース配分は扱わない、という意味で、判定部１４は「緊急性のある障害が発生していない」と判定する。なお、「緊急性のある障害が発生していない」と判定した場合には、出力部１７が、「緊急性の高い障害ではないが、障害は発生している」と出力をしてもよい。

図１２のＳ６の説明に戻って、決定部１５は、緊急時対応の目標復旧レベルを判定して必要リソースを決定する（ステップＳ６）。そして、決定部１５は、緊急時対応に必要なリソースの過不足を判定する（ステップＳ７）。

より詳細に説明すると、決定部１５は、リソース配分算出式を呼び出し、ステップ３の結果と、ステップ４の判定結果を入力することで、目標復旧レベルを判定し、目標復旧レベルを実現するための対応策、対応策の詳細として暫定対応手順または復旧手順と、緊急時対応必要リソースを算出する。例えば、決定部１５は、業務機能４００１での障害のために業務手順２００１、業務プロセス１００１で障害が発生していて、目標復旧レベルの達成判断基準が低い、すなわち、満たさなければならない条件が少ない順から目標復旧レベル５１０１、目標復旧レベル５１０２、・・・と存在するとき、「業務プロセス１００１で障害が発生している」ことから、まずは目標復旧レベル５１０１が復旧における第一次目標であると判定する。目標復旧レベルが定まれば、ステップ３の結果から、目標復旧レベル５１０１にひもづく対応策、対応策の詳細として暫定対応手順または復旧手順と、緊急時対応必要リソースが定まる。

続いて、決定部１５は、緊急時対応に必要なリソースが不足しているか判定する（ステップＳ８）。この結果、決定部１５は、緊急時対応に必要なリソースが不足していると判定した場合には（ステップＳ８肯定）、ステップＳ９に進む。また、決定部１５は、緊急時対応に必要なリソースが不足していないと判定した場合には（ステップＳ８否定）、そのまま処理を終了する。

そして、算出部１６は、余剰リソースの有無および余剰リソース量を算出する（ステップＳ９）。そして、算出部１６は、緊急時対応に必要なリソースの過不足を判定する（ステップＳ１０）。

より詳細に説明すると、算出部１６は、リソース配分算出式を呼び出し、ステップ２の結果と、ステップ６の結果と、リソース管理リストを入力とすることで、緊急時対応に必要なリソースの過不足を判定する。例えば、業務機能４００１での障害のために業務手順２００１、業務プロセス１００１、事業０００１で障害が発生しているとき、事業継続計画および暫定対応手順において、第一次目標として目標復旧レベル５１０１が定められているとする。

目標復旧レベル５１０１を実現するための方法として、業務手順２００１の代替手段として暫定対応手順７１０１と暫定対応手順７２０２が定められていて、暫定対応手順７１０１の実行には延べ２人・延べ２時間、暫定対応手順７２０２の実行には延べ３人・延べ３時間、合計で述べ５人・延べ５時間のリソースが必要とされているとする。

図１３に例示するように、目標復旧レベル５１０１の目標復旧時間が１時間以内とされている場合には、１時間あたり５人以上の人員が必要となる。仮に、業務手順２００１を実行する人員が、暫定対応手順７１０１と暫定対応手順７２０２を実行する場合には、リソース管理リストを参照すると、業務手順２００１を実行するために確保している人員数は４人・４時間であるため、算出部１６は、リソースが１人・１時間分不足していると判定する。

算出部１６は、リソースが不足していると判定した場合には（ステップＳ１０肯定）、トレードオフを考慮したリソース提供を算出する（ステップＳ１１）。なお、算出部１６は、リソースが足りていないと判定した場合には（ステップＳ１０否定）、そのまま処理を終了する。

より詳細に説明すると、算出部１６は、ステップＳ１１では、緊急時対応を実行するために不足しているリソースの拠出元と拠出量を算出する。算出部１６は、リソース配分算出式を呼び出し、ステップ７の判定結果と、ステップ２の結果、ステップ４の判定結果、リソース管理リスト、事業継続計画を入力とすることで、不足分のリソースを補充するためのリソースの拠出元とリソースの拠出量を算出する。算出の処理順序の例を次の（１）、（２）のように示す。

（１）余剰リソースの有無・余剰リソース量の判定
本実施形態では、リソースの拠出元について、余剰リソースを抱えている箇所がある場合には、そこから優先的にリソースを拠出する。リソースが余剰しているかどうかの判定と、拠出してよいリソース量の算出については、算出部１６が、リソース管理リストに基づき判定および算出を行う。まず、算出部１６は、ステップ４の結果とステップ２の結果とを比較することで、障害が発生していない事業、業務プロセス、業務手順を抽出する。次に、算出部１６は、これらに紐づくリソース管理リストを参照し、ある期間における必要リソースの残数、リソース確保数、業務手順などの期間（完了期限）を用いて、余剰リソースの有無を判定し、余剰リソース量を算出する。

例えば、事業０００２に紐づく業務手順２１０１の完了期限が残り４時間（２４０分）で、予定している残りの実行回数が６０回で、１回あたり１人／回・各１ツール（業務機能４００１、業務機能４００２、業務機能４００３、予実管理リスト）・５分／回のリソースを必要とするとき、必要なリソースの残数は延べ６０人・３００分である。なお、業務手順２１０１で用いるツールのリソース再利用周期はいずれも十分に短いため、ツールが利用可能な状況であれば延べ利用回数とそれに伴う利用時間は無視できるとしている。

このとき確保している人員が５人であれば、６０（回）／５（人）＝１２（回／人）の計算により、１人あたり１２回実行すれば業務手順２１０１は予定回数を完了でき、全員が同時に実行すると、５分／回×１２回＝６０分で完了できる。完了期限に間に合わせるために必要な最少人数Ｘは、例えば、（延べ時間：３００分）／Ｘ≦（完了期限までの残り時間：２４０分）を解くことで求められ、Ｘ＝１．２５人となる。もしくは、１回あたりの所要時間が５分であることから、１分あたりの実行回数は１/５＝０．２回となり、完了期限に間に合わせるために必要な最少人数Ｘは、（１分あたりの実行回数：０．２回／分）×（完了期限までの残り時間：２４０分）×Ｘ≧（残りの実行回数：６０回）を解くことでも同様にＸ＝１．２５人と求められる。

これらのような計算から、例えば、算出部１６は、業務手順２１０１のために確保している人員５人のうち、Ｘ＝１．２５人＝（１＋０．２５）人であることから、１人は業務手順２１０１を実行するために２４０分必要であり、１人は２４０×０．２５＝６０分間は業務手順２１０１を担当し残りの１８０分間はリソースを拠出してもよく、残りの３人は２４０分の間すべて拠出してもよいリソースであると算出できる。したがって、業務手順２１０１から拠出可能な人員・時間は、３．７５人・３．７５時間である。ステップ７の判定結果から、暫定対応手順７１０１と暫定対応手順７２０２を実行するために不足しているリソースは１人・１時間分である場合には、拠出可能リソース（３．７５人・３．７５時間）＞必要リソース（１人・１時間分）であるため、算出部１６は、業務手順２２１０のサービスレベルを下げることなく、暫定対応手順７１０１と暫定対応手順７２０２を実行するために必要な不足リソース分を拠出して補給できると算出する。

リソース配分算出装置１０は、余剰リソースを抱えている箇所が複数ある場合には、拠出元の順位と拠出量の配分方法は任意の方法で決定してよい。例えば、リソース配分算出装置１０は、余剰リソース量が他よりもより多い箇所から他の余剰リソース量と同程度になるまで拠出し、それでもまだ緊急時対応を実行するために必要なリソースが不足な場合には、余剰リソース量がある他の箇所から任意のルールに従って拠出するとしてもよい。

また、例えば、リソース配分算出装置１０は、余剰リソースがなくなるまで優先的にリソースを拠出する箇所を定めておきそこから優先的にリソースを拠出し、その箇所から拠出できる余剰リソースがなくなっても緊急時対応を実行するために必要なリソースがまだ不足している必要な場合には、余剰リソース量がある他の箇所から任意のルールに従って拠出するとしてもよい。

（２）トレードオフを考慮したリソース提供の算出
本実施形態では、余剰リソースがない場合の、リソースの拠出元とリソースの拠出量は、リソースを拠出することで生じるサービスレベルの低下による事業影響度が少ない箇所から優先的にリソースを拠出する。まず、算出部１６は、ステップ４の結果とステップ２の結果とを比較することで、障害が発生していない事業、業務プロセス、業務手順を抽出する。次に、算出部１６は、これらに紐づくリソース管理リストを参照し、仮に必要リソースの残数を下回った場合の業務手順、業務プロセス、事業に与える影響を算出する。

例えば、事業０００３に紐づく業務手順２２１１の完了期限が残り４時間（２４０分）で、予定している残りの実行回数が６０回で、１回当たり１人／回・２０分／回のリソースを必要とするとき、必要なリソースの残数は延べ６０人・１２００分である。完了期限に間に合わせるために必要な最少人数Ｙは、１２００／Ｙ≦２４０を解くことで求められ、Ｙ＝５人となる。１人あたり１時間あたりの実行回数は、６０（分）／２０（分／回）＝３回であるため、５人よりも１人下回るごとに業務手順２２１１の実行回数は１時間あたり３回減少する。続いて、算出部１６は、事業継続計画を参照し、このサービスレベルの低下の度合いが、事業０００３でインシデントが発生した場合の目標復旧レベルのうちどのレベルに該当するかを判定する。

例えば、事業０００３は、業務プロセス１２０１から構成され、業務プロセスは業務手順２２１１から構成されているとする。予実管理リストの分析から予め、業務手順２２１１を１日あたり６０回実行することで事業０００３は１日あたり５０万円の売り上げを実現していることが判明しているとき、暫定対応手順７１０１と暫定対応手順７２０２を実行するために不足しているリソース１人・１時間を、業務手順２２１１から拠出した場合には、業務手順２２１１は３回分実行できなくなるため、３回／６０回＝０．０５の計算により売上は５％低下する。

算出部１６は、この売上の５％低下というサービスレベルが、事業０００３でインシデントが発生した場合の目標復旧レベルのうち、どの段階に該当するかを判定する。算出部１６は、事業継続計画で、目標復旧レベルが５０％、８０％、１００％と段階的に定められているとすると、サービスレベルは１００－５＝９５％であるので、最低限クリアしているという意味で「８０％」に該当すると判定する。つまり、図１４に例示するように、事業０００３のリソースを提供した場合には、事業０００３のサービスレベル低下により復旧優先順位が「６」となる。算出部１６は、必要リソースを下回った場合のサービスレベルの低下の度合いと、それに対応する目標復旧レベルの算出を、障害が発生していない事業、業務プロセス、業務手順のすべてについて実行する。

続いて、算出部１６は、これらの必要リソースを下回った場合のサービスレベルの低下の度合いと、事業継続計画に記載の各事業の各目標復旧レベルの絶対的または相対的な優先度とを比較することで、必要リソースを下回った場合のサービスレベルの低下の度合いがより低い目標復旧レベルに該当するものから順にリソースを拠出すると判定する。

つまり、図１４の例では、事業０００３のサービスレベルの低下により復旧優先順位が「６」となり、必要リソースを下回った場合のサービスレベルの低下の度合いが他の事業０００２よりも低く、第一次目標の復旧優先順位が「１」であり、第一次目標の優先度の方が高いことから、算出部１６は、事業０００３のリソースを拠出すると判定する。なお、目標復旧レベルよりも、ある箇所からリソースを拠出することで低下するサービスレベルの度合いに対応する目標復旧レベルの優先度の方が高い場合には、その箇所からリソースの拠出は行わない、という判定となる。

図１２のフローチャートの処理が終了した後、出力部１７では、ステップＳ１１までのリソース配分算出結果を表形式などで出力する。また、出力部１７は、ステップ４の判定結果に基づき、障害発生箇所と障害発生の影響を受けている業務手順および業務プロセス、事業を出力する。

なお、図１２のフローチャートの処理が終了した後、ステップＳ４の処理に戻って繰り返し処理を行うようにしてもよい。つまり、リソース配分算出装置１０は、フローチャートの処理を繰り返し行うことで、その都度の障害発生状況やリソース復旧状況に合わせて適切なリソースの配分を計算することができる。

また、出力部１７は、ステップ６の判定結果に基づき、目標復旧レベルと目標復旧時間、対応策、対応策の詳細として暫定対応手順または復旧手順、緊急時対応必要リソースを出力する。また、出力部１７は、ステップ７の判定結果に基づき、暫定対応手順または復旧手順の実行に必要なリソースが足りているかどうかと、足りていない場合は不足量を出力する。

また、出力部１７は、ステップＳ１１の判定結果に基づき、リソースの拠出元とリソースの拠出量、リソースを拠出したことによるサービスレベルの低下の度合いとそれに該当する目標復旧レベルを出力する。

例えば、出力部１７は、図１３に例示するように、サービスレベル概況、復旧目標、対応策、対応策の詳細、リソース充足状況、リソース拠出元候補およびリソース供出元への影響について出力してもよい。また、例えば、出力部１７は、図１４に例示するように、復旧優先順位、リソース拠出順位および目標復旧レベルについて、表形式で出力してもよい。また、例えば、出力部１７は、図１５に例示するように、各事業の現状評価や目標復旧レベル等をグラフ形式で表示するようにしてもよい。

これらのリソース配分算出結果の出力により、リソース配分算出装置１０の利用者は、インシデント発生時の対応策の実施に必要なリソースの確保方法を効果的に把握できるようになる。

すなわち、リソース配分算出装置１０が、業務支援システムＮ_Ｓや異常検知システムＮ_Ａのログ、手動入力した障害事象の障害情報、予実管理リストに基づき、障害発生箇所と障害による業務手順、業務プロセス、事業への影響を短時間で精度よく判定する。また、リソース配分算出装置１０が、事業継続計画や復旧手順、暫定対応手順、リソース管理リストに基づき目標復旧レベルを実現するための対応策の詳細と対応策の実行に必要なリソース、リソースの拠出元とリソースの拠出量を提示する。これにより、リソース配分算出装置１０の利用者は、インシデント発生時に組織全体としてのサービスレベルの低下を最小限に抑えて組織内のリソースを効果的に配分できるようになる。

また、リソース配分算出装置１０の利用者は、複数のインシデントが同時多発的に発生した場合にも、対応策の優先順位と対応策の実施に必要なリソースの確保方法を効果的に把握できるようになる。すなわち、１つまたは複数の事業において、各事業の構成要素である業務機能の一つまたは複数の個所で障害が発生し、一つまたは複数の業務プロセスや業務手順が実施できないとき、リソース配分算出装置１０は、目標復旧レベルの優先順位に基づき、対応策の優先順位を判定し、目標復旧レベルを達成するための対応策を実行するために必要なリソース、リソースの拠出元とリソースの拠出量を提示することができる。

さらに、リソース配分算出装置１０の利用者は、上記フローチャートのステップＳ１からステップＳ１１を利用して、インシデント発生時の段階的な目標復旧レベルにおける対応策と対応策の実施に必要なリソースの確保方法をシミュレーションすることができる。

例えば、直近の目標復旧は「目標復旧レベル５００１」であり、これを達成した場合の次の目標復旧は「目標復旧レベル５００２」であるが、「目標復旧レベル５００２」を円滑に実施するために必要なリソースを事前に把握して調達しておきたい場合に、「目標復旧レベル５００２」における対応策としての暫定対応手順または復旧手順と、対応策を実行するために必要なリソース、リソースの拠出元とリソースの拠出量を確認することができる。

なお、このシミュレーションに関しては、リソース配分算出装置１０が自動実行してもよいし、障害事象入力部１２で、「目標復旧レベル５００１」に到達している状況を入力して、「目標復旧レベル５００２」を実現するために必要なリソース、リソースの拠出元とリソースの拠出量を提示するとしてもよい。

上述したステップＳ１～Ｓ８の各処理は、インシデント発生時に実施してもよいし、それぞれ異なるときに実施してもよい。例えば、ステップＳ１～ステップＳ３は、平常時に任意のタイミングで実行し、結果をリソース配分算出システムの内部の記録装置もしくは外部の記録装置に保持しておき、ステップＳ４～ステップＳ１１を実行するときに、記憶部１８からステップＳ２、ステップＳ３の結果を読み込む方法を採用してもよい。また、リソース配分算出装置１０は、インシデント発生時の対応策検討のために利用してもよいし、事業継続計画の策定・修正のために利用してもよい。

［第１の実施形態の効果］
第１の実施形態に係るリソース配分算出装置１０は、障害が発生した事業について、該事業の復旧のために必要なリソースを決定し、障害が発生していない他の事業における余剰リソース量を算出し、算出された余剰リソースを基に、障害が発生した事業に配分可能な余剰リソースに関する情報を出力する。これにより、リソース配分算出装置１０は、インシデント発生時において、リソースを適切に配分することが可能である。

第１の実施形態に係るリソース配分算出装置１０は、インシデント発生時に、被害を受けている業務と被害を受けていない業務との間で適切にリソースを配分することを支援するために、インシデントの被害状況と目標復旧レベル、事業影響度とを比較して、リソース配分を効果的に実行することが可能になる。

つまり、組織が利用できるリソースには限りがあるため、目標復旧時間と目標復旧レベルを達成するには、インシデント発生による被害を受けていない業務に割り当てているリソースを借りなければならないことがある。このような場合に、リソースを貸し出すという選択を取ると、目標復旧時間と目標復旧レベルは達成できる一方で、リソースを貸し出した業務ではサービスレベルが低下するというトレードオフが発生する。

このようなトレードオフを可能な限り減らすには、通常のサービスレベルを実現するために必要な分よりも余剰なリソースを抱えている業務から優先的にリソースを拠出し、もし通常のサービスレベルを下回ってでもリソースを拠出しなければならないときには、組織全体として事業影響度がなるべく小さくなるように、リソースの拠出元とリソースの拠出量を調整することが望ましい。

そこで、第１の実施形態に係るリソース配分算出装置１０では、インシデント発生時に、被害を受けている業務と被害を受けていない業務との間で適切にリソースを配分することを支援するために、インシデントの被害状況と目標復旧レベル、事業影響度とを比較して、リソース配分を効果的に実行することができる。

（システム構成等）
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、本実施の形態において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

（プログラム）
また、上記実施形態において説明したリソース配分算出装置が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。例えば、実施形態に係るリソース配分算出装置１０が実行する処理をコンピュータが実行可能な言語で記述したリソース配分算出プログラムを作成することもできる。この場合、コンピュータがリソース配分算出プログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、かかるリソース配分算出プログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたリソース配分算出プログラムをコンピュータに読み込ませて実行することにより上記実施形態と同様の処理を実現してもよい。

図１６は、リソース配分算出プログラムを実行するコンピュータを示す図である。図１６に例示するように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有し、これらの各部はバス１０８０によって接続される。

メモリ１０１０は、図１６に例示するように、ＲＯＭ（Read Only Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、図１６に例示するように、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、図１６に例示するように、ディスクドライブ１１００に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１１００に挿入される。シリアルポートインタフェース１０５０は、図１６に例示するように、例えばマウス１１１０、キーボード１１２０に接続される。ビデオアダプタ１０６０は、図１６に例示するように、例えばディスプレイ１１３０に接続される。

ここで、図１６に例示するように、ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、上記の、リソース配分算出プログラムは、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、例えばハードディスクドライブ１０９０に記憶される。

また、上記実施形態で説明した各種データは、プログラムデータとして、例えばメモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出し、各種処理手順を実行する。

なお、リソース配分算出プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限られず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、リソース配分算出プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等）を介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

１０ リソース配分算出装置
１１ 外部データ入力部
１２ 障害事象入力部
１３ 紐付け部
１４ 判定部
１５ 決定部
１６ 算出部
１７ 出力部
１８ 記憶部

Claims (6)

1. 障害が発生した事業について、該事業の復旧のために必要な、人数および時間で表されるリソースを決定し、当該リソースが不足しているか判定する決定部と、
   前記決定部によって前記リソースが不足していると判定された場合には、障害が発生していない他の事業における、人数および時間で表されるリソースのうち、前記障害が発生した事業の復旧のために拠出してよい余剰リソース量を算出する算出部と、
   前記算出部によって算出された余剰リソースのうち、前記障害が発生した事業に配分可能なリソースに関する人数および時間で表される情報を出力する出力部と
   を有することを特徴とするリソース配分算出装置。
2. 前記算出部は、障害が発生していない他の事業が複数ある場合には、複数の他の事業について、前記余剰リソース量をそれぞれ算出し、算出された各余剰リソースのうち、余剰リソース量が最も多い他の事業の余剰リソースを優先的に配分可能なリソースとして決定し、
   前記出力部は、前記算出部によって決定されたリソースに関する情報を出力することを特徴とする請求項１に記載のリソース配分算出装置。
3. 前記算出部は、前記他の事業に余剰リソースがない場合には、障害が発生していない他の事業について、前記障害が発生した事業にリソースを提供した場合に事業に与える影響度をそれぞれ算出し、前記影響度が少ない事業のリソースを優先的に配分可能なリソースとして決定し、
   前記出力部は、前記算出部によって決定されたリソースに関する情報を出力することを特徴とする請求項１に記載のリソース配分算出装置。
4. 障害が発生した事業を判定する判定部をさらに有し、
   前記決定部は、前記判定部によって障害が発生したと判定された事業について、該事業の復旧のために必要なリソースを決定することを特徴とする請求項１に記載のリソース配分算出装置。
5. リソース配分算出装置によって実行されるリソース配分算出方法であって、
   障害が発生した事業について、該事業の復旧のために必要な、人数および時間で表されるリソースを決定し、当該リソースが不足しているか判定する決定工程と、
   前記決定工程によって前記リソースが不足していると判定された場合には、障害が発生していない他の事業における、人数および時間で表されるリソースのうち、前記障害が発生した事業の復旧のために拠出してよい余剰リソース量を算出する算出工程と、
   前記算出工程によって算出された余剰リソースのうち、前記障害が発生した事業に配分可能なリソースに関する人数および時間で表される情報を出力する出力工程と
   を含むことを特徴とするリソース配分算出方法。
6. 障害が発生した事業について、該事業の復旧のために必要な、人数および時間で表されるリソースを決定し、当該リソースが不足しているか判定する決定ステップと、
   前記決定ステップによって前記リソースが不足していると判定された場合には、障害が発生していない他の事業における、人数および時間で表されるリソースのうち、前記障害が発生した事業の復旧のために拠出してよい余剰リソース量を算出する算出ステップと、
   前記算出ステップによって算出された余剰リソースのうち、前記障害が発生した事業に配分可能なリソースに関する人数および時間で表される情報を出力する出力ステップと
   をコンピュータに実行させることを特徴とするリソース配分算出プログラム。

Images