JP5302798B2 - 保守管理方法、プログラムおよび保守管理装置 - Google Patents

Description

本発明は、保守管理方法、プログラムおよび保守管理装置の技術に関する。

従来、医療現場の事故についてリスク評価を行い、一定の期間に発生する損失の期待値を計算できるようにした技術が提案されている。例えば、特許文献１には、以下の処理を行うことで非期待損失を算出するリスク評価装置およびプログラムなどが提案されている。
すなわち、リスク評価装置は、医療システムの故障モードについて、頻度、潜在度、危険度、および影響度を入力し、入力された頻度に対応する頻度確率、潜在度に対応する潜在確率、危険度に対応する危険度確率をそれぞれデータベースから読み出し、単位期間あたりに事故が発生する確率を算出する。そして、リスク評価装置は、この単位期間あたりに事故が発生する確率に基づいて、計測期間Ｔにおいて事故が発生する確率の分布が示す値と損失量の値とから非期待損失を算出する。

特開２００７−３１６７５３号公報

ところで、近年、システム開発においてプロジェクト管理、特にリスク分析の重要性が高まってきている。このようなリスク分析において、システム開発時の障害案件の数が一定の割合に収まっている場合は、それらを人間系だけで把握することは可能である。しかし、障害案件の件数が増えてくると、障害多発によるスパイラルに陥り、プロジェクトの問題（タスクをこなせる担当者の人数の問題、新任担当者の能力の問題、障害解決までの納期の問題など）により、それらすべての不良を人間系だけで把握することは非常に困難である。

一般的に、トラブルを多く抱えるシステム開発プロジェクトにおいては、障害案件が数多く発生している。その対策方法としては、開発担当者独自の基準で優先／非優先の判断を行い、各々の障害案件の完了予定日や納期に応じて順番に対策に取り掛かる場合がほとんどである。そのため、致命的な障害を後回しにして、納期の迫っている案件から先行して着手し、被害が拡大することが散見されている。このように混乱しているプロジェクトにおいては、致命的な障害をいかに早期に検出し、対応改善できるかが問題解決の鍵となる。

しかしながら、特許文献１に記載の技術のように、混乱していない正常プロジェクトのシステム開発におけるリスク評価方法は存在するが、障害案件の乱立により混乱している状態下での、優先障害案件と非優先案件を切り分けする技術に関しては、確立されていない。

このような背景に鑑みて本発明がなされたのであり、本発明は、障害案件の優先度をユーザに明示することを目的とする。

前記課題を解決するため、本発明は、システム障害の保守を管理する保守管理装置による保守管理方法であって、過去における障害案件に関する情報が、前記障害案件が生じた日付に対応付けられて格納されている障害案件実績情報と、プロジェクトに係る要員である、複数のＰＪ（Project）要員のスキルに関する情報とが記憶部に格納されており、前記障害案件実績情報における過去に発生した障害案件に関する情報と、該障害案件が生じた日付とを基に、入力部を介して入力された所定の期間における前記障害案件の発生確率を算出し、前記算出した発生確率を基に、障害がプロジェクトに与える影響の度合いである障害影響度を、前記発生確率が大きいほど、当該障害影響度が大きくなるように設定された式を用いて算出し、すべてのＰＪ要員について、現在の日付を基に、前記障害案件の保守に費やすことのできる作業残日数を算出し、前記ＰＪ要員のスキルに関する情報を基に、当該ＰＪ要員が前記障害案件の保守に費やす作業日数を算出し、前記作業残日数から前記作業日数を減算した要員可能残日数を算出し、前記要員可能残日数が０以上の値となった場合、当該障害案件を対応可能と判定し、前記要員可能残日数が負の値となった場合、処理対象となっているＰＪ要員では、該当する障害案件を対応不可能と判定する判定処理を行った後、前記障害案件に関する情報を前記障害影響度でソートし、対応可能な障害案件に関する情報と、対応不可能な障害案件に関する情報とを区別して表示する表示処理を行うことを特徴とする。
その他の解決手段については、実施形態中において記述する。

本発明によれば、障害案件の優先度をユーザに明示することができる。

本実施形態に係る保守管理システムの構成例を示す図である 本実施形態に係る保守管理システムのハード構成例を示すブロック図である。 本実施形態に係るリスク情報管理ＤＢ登録処理の手順を示すフローチャートである。 本実施形態に係る発生頻度集計処理の手順を示すフローチャートである。 本実施形態に係るリスク情報管理ＤＢ検索処理の手順を示すフローチャートである（その１）。 本実施形態に係るリスク情報管理ＤＢ検索処理の手順を示すフローチャートである（その２）。 本実施形態に係るリスク情報管理ＤＢ更新処理の手順を示すフローチャートである。 本実施形態に係る障害案件切り分け処理の手順を示すフローチャートである（その１）。 本実施形態に係る障害案件切り分け処理の手順を示すフローチャートである（その２）。 本実施形態に係る障害案件切り分け処理の手順を示すフローチャートである（その３）。 本実施形態に係る現象コードＤＢのテーブルメンテナンス処理の手順を示すフローチャートである。 本実施形態に係る原因コードＤＢのテーブルメンテナンス処理の手順を示すフローチャートである。 本実施形態に係るＰＪ要員ＤＢのテーブルメンテナンス処理の手順を示すフローチャートである。 初期画面例を示す図である。 プロジェクトデータ登録処理画面例を示す図である。 発生頻度集計機能画面例を示す図である。 障害データ一覧画面例を示す図である（その１）。 プロジェクト障害データ更新画面例を示す図である。 障害データ一覧画面例を示す図である（その２）。 現象コードＤＢ一覧画面例を示す図である。 現象コードＤＢ登録画面例を示す図である。 原因コードＤＢ一覧画面例を示す図である。 原因コードＤＢ登録画面例を示す図である。 ＰＪ要員ＤＢ一覧画面例を示す図である。 ＰＪ要員ＤＢ登録画面例を示す図である。 リスク情報管理ＤＢ、障害Ｎｏ．退避ワークテーブルの例を示す図である。 リスク情報管理ＤＢ、発生頻度ＤＢワークテーブル、発生頻度ＤＢの例を示す図である。 リスク情報管理ＤＢの例を示す図である。 発生頻度ＤＢおよびワークテーブルＡの例を示す図である。 ワークテーブルＡおよびリスク情報管理ＤＢの例を示す図である。 ＰＪ要員ＤＢの例を示す図である（その１）。 ワークテーブルＢの例を示す図である（その１）。 ワークテーブルＢの例を示す図である（その２）。 ワークテーブルＢの例を示す図である（その３）。 ワークテーブルＢの例を示す図である（その４）。 ワークテーブルＢの例を示す図である（その５）。 ワークテーブルＢの例を示す図である（その６）。 ワークテーブルＢの例を示す図である（その７）。 ワークテーブルＢの例を示す図である（その８）。 ワークテーブルＢの例を示す図である（その９）。 ワークテーブルＢの例を示す図である（その１０）。 ワークテーブルＢの例を示す図である（その１１）。 ワークテーブルＢの例を示す図である（その１２）。 ワークテーブルＢの例を示す図である（その１３）。 ワークテーブルＢの例を示す図である（その１４）。 ワークテーブルＢの例を示す図である（その１５）。 ワークテーブルＢの例を示す図である（その１６）。 ワークテーブルＢの例を示す図である（その１７）。 ワークテーブルＢの例を示す図である（その１８）。 ワークテーブルＢの例を示す図である（その１９）。 現象コードＤＢの例を示す図である（その１）。 現象コードＤＢの例を示す図である（その２）。 原因コードＤＢの例を示す図である（その１）。 原因コードＤＢの例を示す図である（その２）。 ＰＪ要員ＤＢの例を示す図である（その２）。 ＰＪ要員ＤＢの例を示す図である（その３）。 ＩＴＳＳレベル‐スキル補正係数対応テーブルの例を示す図である。 ユーザ要望対応テーブルの例を示す図である。

次に、本発明を実施するための形態（「実施形態」という）について、適宜図面を参照しながら詳細に説明する。

《システム構成例》
図１は、本実施形態に係る保守管理システムの構成例を示す図である。
この保守管理システム１００は、入出力機能１０１と、リスク情報管理ＤＢ（Data Base）１１０と、発生頻度ＤＢ１１１と、ＰＪ（Project）要員ＤＢ１１２（ＰＪ要員のスキルに関する情報）と、ワークテーブルＡ １１３（リスク管理情報）と、ワークテーブルＢ １１４と、現象コードＤＢ１１５と、原因コードＤＢ１１６と、リスク情報管理ＤＢ登録機能１２０と、リスク情報管理ＤＢ更新機能１２１と、リスク情報管理ＤＢ検索機能１２２と、発生頻度集計機能１２３と、障害案件切り分け機能１２４（処理部）と、テーブルメンテナンス機能１２５とを有している。入出力機能１０１は、各プロジェクトの管理者（例えば、チームリーダ：運用管理者）がプロジェクトの障害情報をリアルタイムに登録し、更新などを行う機能を有する。リスク情報管理ＤＢ１１０は、過去または現在開発中の詳細なプロジェクトの障害情報を蓄積し、管理する。発生頻度ＤＢ１１１には、一定期間に同様の障害が発生する頻度が格納されている。ＰＪ要員ＤＢ１１２には、システム開発に携わるプロジェクト要員全員に関する情報（要員のスキルに関する情報など）が登録されている。ワークテーブルＡ １１３およびワークテーブルＢ １１４は、障害案件の検索結果を表示するためのデータ退避領域である。現象コードＤＢ１１５は、障害案件のエラーの状態が体系化してまとめている。原因コードＤＢ１１６は、障害案件のエラーを起こす原因が体系化してまとめられて格納されている。

リスク情報管理ＤＢ登録機能１２０は、入出力機能１０１から入力された情報をリスク情報管理ＤＢ１１０に登録する機能を有する。リスク情報管理ＤＢ更新機能１２１は、入出力機能１０１から入力された情報を基に、リスク情報管理ＤＢ１１０を更新する機能を有する。リスク情報管理ＤＢ検索機能１２２は、リスク情報管理ＤＢ１１０を検索し、障害案件の障害影響度を算出し、ワークテーブルＡ １１３をソートして、その結果をワークテーブルＡ １１３へ格納したり、ディスプレイなどに表示する機能を有する。発生頻度集計機能１２３は、リスク情報管理ＤＢ１１０を基に、障害案件の発生頻度を集計し、その集計結果を発生頻度ＤＢ１１１へ格納する機能を有する。障害案件切り分け機能１２４は、ＰＪ要員ＤＢ１１２、ワークテーブルＡ １１３を基に、障害案件の対策可否を判定し、判定結果をワークテーブルＢ １１４へ格納する機能を有している。テーブルメンテナンス機能１２５は、入出力機能１０１から入力された情報を基に、現象コードＤＢ１１５や、原因コードＤＢ１１６や、ＰＪ要員ＤＢ１１２の各種ＤＢをメンテナンスする機能を有する。

《ハードウェア構成》
図２は、本実施形態に係る保守管理システムのハード構成例を示すブロック図である。なお、図２において、図１と同様の構成要素については同一の符号を付して説明を省略する。
図２において、サーバ設置エリア２０１、運用管理エリア２０２を示している。サーバ設置エリア２０１にはＡＰ（Application）サーバ２１０、ＤＢサーバ２３０が設置されている。運用管理エリア２０２には運用管理者が使用する運用管理端末２５０（結果表示端末）が設置されている。ＡＰサーバ２１０、ＤＢサーバ２３０および運用管理端末２５０は通信回線（ＬＡＮ（Local Area Network）など）で互いに接続されている。

ＡＰサーバ２１０はＣＰＵ（Central Proccesing Unit）２１１、ＲＡＭ（Ramdom Access Memory）などのメモリ２１２、ＨＤ（Hard Disk）や、ＲＯＭ（Read Only memory）や、フラッシュメモリなどの記憶装置２１３、ディスプレイ２２０、キーボード２２１、マウス２２２を有している。記憶装置２１３には、リスク情報管理ＤＢ登録機能１２０、リスク情報管理ＤＢ更新機能１２１、リスク情報管理ＤＢ検索機能１２２、発生頻度集計機能１２３、障害案件切り分け機能１２４、テーブルメンテナンス機能１２５がプログラムとして記憶されており、このプログラムがメモリ２１２に読み込みされ、ＣＰＵ２１１によって実行されることにより、各機能１２０〜１２５が具現化する。

ＤＢサーバ２３０はＣＰＵ２３１、ＲＡＭなどのメモリ２３２、２１２、ＨＤや、ＲＯＭや、フラッシュメモリなどの記憶装置２３３、ディスプレイ２４２、キーボード２４３、マウス２４４を有している。記憶装置２３３には、リスク情報管理ＤＢ１１０、発生頻度ＤＢ１１１、ＰＪ要員ＤＢ１１２、ワークテーブルＡ１１３、ワークテーブルＢ１１４、現象コードＤＢ１１５、原因コードＤＢ１１６が記憶されている。各ＤＢ１１０〜１１２，１１５，１１６および各テーブル１１３，１１４の構成は後記する。

運用管理端末２５０は、ＣＰＵ２５１、ＲＡＭなどのメモリ２５２、ＨＤや、ＲＯＭや、フラッシュメモリなどの記憶装置２５３、ディスプレイ２５９、キーボード２６０、マウス２６１を有している。記憶装置２５３には、リスク情報管理ＤＢ登録画面２５４、リスク情報管理ＤＢ更新画面２５５、リスク情報管理ＤＢ検索画面２５６、発生頻度集計画面２５７、テーブルメンテナンス画面２５８に関する各情報が記憶されており、これらの情報がメモリ２５２に読み込みされ、ＣＰＵ２５１によって実行されることにより、各画面２５４〜２５８が運用管理端末２５０のディスプレイ２５９に表示される。運用管理者（チームリーダ）は、ディスプレイ２５９を参照し、キーボード２６０や、マウス２６１などを介して情報を入力することにより、リスク情報管理ＤＢ１１０の登録と更新と検索、発生頻度ＤＢ１１１の生成、ＰＪ要員ＤＢ１１２と現象コードＤＢ１１５と原因コードＤＢ１１６のマスタメンテナンスなどを行う。

なお、本実施形態では、ＡＰサーバ２１０、ＤＢサーバ２３０および運用管理端末２５０を別の装置としているが、これに限らず、これらの装置２１０，２３０，２５０のうち、少なくとも２つの装置が一体となっていてもよい。

《フローチャート》
次に、図３〜図５５を参照して、各処理の手順を説明する。なお、本実施形態において、入力情報は運用管理端末２５０のキーボード２６０や、マウス２６１を使用して入力された情報がＡＰサーバ２１０に送信され、出力情報は、ＡＰサーバ２１０から運用管理端末２５０のディスプレイ２５９に表示されるが、これに限らず、ＡＰサーバ２１０のキーボード２２１や、マウス２２２を介して入力情報が入力され、ＡＰサーバ２１０のディスプレイ２２０に出力情報が表示されてもよい。

（リスク情報管理ＤＢ登録処理）
図１、図２、図１１、図１２および図２３を参照しつつ、図３に沿ってリスク情報管理ＤＢ登録処理の手順を説明する。
図３は、本実施形態に係るリスク情報管理ＤＢ登録機能処理の手順を示すフローチャートであり、図１１は、初期画面例を示す図であり、図１２は、プロジェクトデータ登録処理画面例を示す図であり、図２３は、リスク情報管理ＤＢ、障害Ｎｏ．退避ワークテーブルの例を示す図である。なお、図１２のプロジェクトデータ登録処理画面は、図２のリスク情報管理ＤＢ登録画面２５４に相当する画面である。
まず、ステップＳ３００にて、運用管理端末２５０のディスプレイ２５９に表示されている初期画面（図１１）におけるラジオボタン「障害データ登録機能」が選択されたのち、「実行」ボタンが押下されることにより、リスク情報管理ＤＢ登録機能１２０は、ラジオボタン「障害データ登録機能」選択のイベントを検知する。
そして、ステップＳ３０１にて、リスク情報管理ＤＢ登録機能１２０は、プロジェクトデータ登録処理画面（図１２）を運用管理端末２５０のディスプレイ２５９に表示する。
次に、ステップＳ３０２にて、リスク情報管理ＤＢ登録機能１２０は、画面の各項目に入力されている「プロジェクトコード」〜「ヘルプデスク工数」の情報までを、運用管理端末２５０を介することで、プロジェクトデータ登録処理画面（図１２）から取得する。
なお、ステップＳ３０２の段階において、リスク情報管理ＤＢ登録機能１２０は、プロジェクトデータ登録処理画面より取得したユーザ要望度の文字列を、ユーザ要望対応テーブル（図５５）を参照して数値に変換する。
ここで、ユーザ要望度は、プロジェクトデータ登録処理画面においてプルダウンメニューから選択入力される。すなわち、プログラムデータ登録処理画面のユーザ要望度のプルダウンメニューには「最優先」「優先」「通常」「低位」の文字列が表示され、ユーザがマウスによって、これらの文字列のうち、いずれかを選択することによってユーザ要望度の文字列がリスク情報管理ＤＢ登録機能１２０に入力される。
また、ユーザ要望度の文字列は、キーボードを介した入力でもよい。

ここでユーザ要望度は、障害案件の対策優先度を示す指標であり、「最優先」「優先」「通常」「低位」の４つの値をユーザ要望対応テーブルに保持している（図５５）。それぞれの数値を「最優先」の場合「２．０」、「優先」の場合「１．５」、「通常」の場合「１．０」、「低位」の場合「０．８」として定義する。
具体例を示すと、「最優先」は、通常業務に非常に深刻な影響があり即時対応が必要な場合や、本稼働システムが完全にダウンしている場合や、この障害により重大な損失が発生する可能性がある場合を対象とする。「優先」は、通常業務に深刻な影響がある場合や、機能不良によって本稼働システム全体に影響を及ぼしできるだけ迅速な対応が必要な場合を対象とする。「通常」は、通常業務に影響がある場合や、システムの機能が正しく実行しない場合や、実行できない場合を対象とする。「低位」は、通常業務に影響が少ない場合、または全く影響がない場合を対象とする。リスク情報管理ＤＢ検索機能１２２は、運用管理端末２５０を介して入力された「最優先」や、「通常」など対策優先度に関する情報を、ユーザ要望対応テーブルに格納されている、対応するユーザ要望度（「２．０」，「１．５」など）へと変換する。

続いて、ステップＳ３０３にて、リスク情報管理ＤＢ登録機能１２０は、取得した「プロジェクトコード」をキーにして、リスク情報管理ＤＢ１１０（図２３（ａ））を検索し、障害Ｎｏ．を取得する。
そして、ステップＳ３０４にて、リスク情報管理ＤＢ登録機能１２０は、取得した障害Ｎｏ．を障害Ｎｏ．退避ワークテーブルに一括退避する（図２３（ｂ））。
次に、ステップＳ３０５にて、リスク情報管理ＤＢ登録機能１２０は、障害Ｎｏ．退避ワークテーブルの件数分、障害Ｎｏ．の末尾３桁を取得し、障害Ｎｏ．退避ワークの枝番に格納する処理を繰り返す（図２３（ｃ））。
そして、ステップＳ３０６にて、リスク情報管理ＤＢ登録機能１２０は、障害Ｎｏ．退避ワークテーブルに対し枝番で降順ソートを行い、第１レコードの枝番（最も大きい枝番）を取得する。

続いて、ステップＳ３０７にて、リスク情報管理ＤＢ登録機能１２０は、取得した枝番に対して１を加算し、この数値をリスク情報管理ＤＢ１１０に新たに登録する「障害Ｎｏ．」とする。
そして、ステップＳ３０８にて、プロジェクトデータ登録処理画面（図１２）の登録ボタン押下のイベントを検知したリスク情報管理ＤＢ登録機能１２０は、ステップＳ３０７で生成した障害Ｎｏ．に該当するレコードをリスク管理情報ＤＢ１１０に新規追加し、ステップＳ３０２で取得した「プロジェクトコード」〜「ヘルプデスク工数」までの情報をリスク管理情報ＤＢ１１０に書き込む（図２３（ｄ）の符号５０１）。新規登録するレコードのステータスはデフォルトで「未完了」とする。リスク情報管理ＤＢ１１０は、１日１回業務が始まる時間前にチームリーダにより、発生した障害案件を随時登録する運用とする。あるいは、リスク情報管理ＤＢ１１０は、障害が発生するとチームリーダにより、入出力機能１０１を介してリアルタイムに障害案件が登録されてもよい。

（発生頻度集計処理）
次に、図１、図１１、図１３、図２４、図４８〜図５１を参照しつつ、図４に沿って発生頻度集計処理の手順を説明する。
図４は、本実施形態に係る発生頻度集計処理の手順を示すフローチャートであり、図１３は、発生頻度集計機能画面例を示す図であり、図２４は、リスク情報管理ＤＢ、発生頻度ＤＢワークテーブル、発生頻度ＤＢの例を示す図であり、図４８および図４９は、現象コードＤＢの例を示す図であり、図５０および図５１は、原因コードＤＢの例を示す図である。なお、図１３の発生頻度集計機能画面は、図２の発生頻度集計画面２５７に相当する画面である。また、図２４（ａ）のリスク情報管理ＤＢ１１０は、図２３（ｄ）の状態から、さらにデータが追加され、さらに一部のデータが変更された状態を示している。
まず、ステップＳ４００にて、運用管理端末２５０のディスプレイ２５９に表示されている初期画面（図１１）のラジオボタン「発生頻度集計機能」が選択された後、「実行」ボタンが押下されることにより、発生頻度集計機能１２３は、ラジオボタン「発生頻度集計機能」選択のイベントを検知する。
次に、ステップＳ４０１にて、発生頻度集計機能１２３は、発生頻度集計機能画面（図１３）を運用管理端末２５０のディスプレイ２５９に表示する。
そして、ステップＳ４０２にて、発生頻度集計機能１２３は、運用管理端末２５０を介することで、発生頻度集計画面（図１３）に入力されている障害発生の「対象年月」を発生頻度集計画面（図１３）から取得する。

続いて、ステップＳ４０３にて、発生頻度集計機能１２３は、取得した「対象年月」をキーにリスク情報管理ＤＢ１１０の発生年月を検索し（図２４（ａ））、該当するプロジェクトコードと発生日付と現象コード（障害の種類に関する情報）と原因コード（障害の原因に関する情報）を一括取得する。ここで、発生日付は先頭６バイトを取得し、その値を発生月度とする。また現象コード、原因コードは、リスク情報管理ＤＢ１１０に障害案件ごとに定義されている。現象コードは障害案件のエラーの状態を体系化したコードで、原因コードは障害案件のエラーを起こした原因を体系化してまとめたコードである。リスク情報管理ＤＢ１１０で定義される現象コードおよび原因コードは、それぞれ図４８や図４９に示す現象コードＤＢ１１５または図５０や図５１に示す原因コードＤＢ１１６を用いて参照される。

次に、ステップＳ４０４にて、発生頻度集計機能１２３は、リスク管理情報ＤＢ１１０を参照して、取得したプロジェクトコードと発生月度と現象コードと原因コードの毎に、発生件数をカウントし、発生頻度ＤＢワークテーブルに格納する（図２４（ｂ））。
そして、ステップＳ４０５にて、発生頻度集計機能１２３は、算出した発生件数を３０［日］（＝約１ヶ月）で除算し、障害の発生確率を算出する。
続いて、ステップＳ４０６にて、発生頻度集計機能１２３は、プロジェクトコードと、発生月度と、現象コードと、原因コードと、算出した発生確率を発生頻度ＤＢ１１１に書き込む（図２４（ｃ））。

（リスク情報管理ＤＢ検索処理）
次に、図１、図１１、図１４、図２５、図２６、図２７（ａ）、図５５を参照しつつ、図５Ａおよび図５Ｂに沿ってリスク情報管理ＤＢ検索処理の手順を説明する。
図５Ａ、図５Ｂは、本実施形態に係るリスク情報管理ＤＢ検索処理の手順を示すフローチャートであり、図１４は、障害データ一覧画面例を示す図であり、図２５は、リスク情報管理ＤＢの例を示す図であり、図２６および図２７（ａ）は、発生頻度ＤＢおよびワークテーブルＡの例を示す図であり、図５５は、ユーザ要望対応テーブルの例を示す図である。なお、図１４に示す障害データ一覧画面は、図２のリスク情報管理ＤＢ検索画面２５６に相当する画面である。また、図２６（ａ）の発生頻度ＤＢ１１１は、図２４（ｃ）の状態より、データが追加され、さらにデータの一部が変更された状態である。
まず、図５ＡのステップＳ５００にて、リスク情報管理ＤＢ検索機能１２２は、運用管理端末２５０のディスプレイ２５９に表示されている初期画面（図１１）のラジオボタン「障害データ一覧表示」が選択された後、「実行」ボタンが押下されることにより、リスク情報管理ＤＢ検索機能１２２は、初期画面（図１１）のラジオボタン「障害データ一覧表示」選択のイベントを検知する。このとき、リスク情報管理ＤＢ検索機能１２２は、初期画面（図１１）の「障害データ一覧表示」の下のプロジェクトコード入力フォームに入力されたプロジェクトコードを取得する。
次に、ステップＳ５０１にて、リスク情報管理ＤＢ検索機能１２２は、システム日付（現在の日付）を取得する。このシステム日付は、後記する障害案件切り分け処理で使用する残日数を算出する際に必要となる。
残日数は、（プロジェクトコードに対応する対策予定日）−（システム日付）から算出するためである。

そして、ステップＳ５０２にて、リスク情報管理ＤＢ検索機能１２２は、初期画面（図１１）に入力されたプロジェクトコードをキーにリスク情報管理ＤＢ１１０（図２５）を検索する。このとき、リスク情報管理ＤＢ検索機能１２２は、リスク情報管理ＤＢ１１０のステータスが「未完了」のデータを抽出対象とし、取得したデータに関して、上から順にステップＳ５０３〜Ｓ５０６の処理を繰り返す。

次に、ステップＳ５０３にて、損害規模を算出する。損害規模は、以下の式（１）のように、リスク情報管理ＤＢ１１０の「リカバリ工数」と、「影響を受ける人数」と、「ユーザ時間単価」を乗算することで算出できる。

損害規模＝（リスク情報管理ＤＢ１１０のユーザのリカバリ工数［ｈ／人］）×（リスク情報管理ＤＢ１１０のユーザ時間単価［Ｋ￥／ｈ］）×（リスク情報管理ＤＢ１１０の影響人数［人］）・・・（１）

ここで、リカバリ工数は障害を復旧するためにユーザ１人当たりが費やす工数（日数）であり、ユーザ時間単価は１時間当たりのユーザの単価であり、影響人数は障害によって影響を受ける（障害復旧に携わる）ユーザの人数を示す。

そして、ステップＳ５０４にて、リスク情報管理ＤＢ検索機能１２２は、リスク情報管理ＤＢ１１０において、取得したプロジェクトコードに対応している「発生日付」の先頭６バイトを取得し、「発生月度」とする。
次に、ステップＳ５０５にて、リスク情報管理ＤＢ検索機能１２２は、ステップＳ５００の段階で取得したプロジェクトコードと、処理対象と、発生月度と、現象コードと原因コードの組み合わせをキーに、発生頻度ＤＢ１１１（図２６（ａ））を検索し、該当する発生頻度を取得する。現象コードおよび原因コードは、現在、処理対象となっているデータに対応するコードがそれぞれリスク情報管理ＤＢ１１０から、リスク情報管理ＤＢ検索機能１２２によって取得される。
続いて、ステップＳ５０６にて、リスク情報管理ＤＢ検索機能１２２は、障害影響度を算出する。障害影響度は、以下の式（２）で算出できる。ここで、ユーザ要望度は、現在、処理対象となっているデータに対応するユーザ要望度がリスク情報管理ＤＢ１１０から、リスク情報管理ＤＢ検索機能１２２によって取得される。

障害影響度＝ユーザ要望度×損害規模×発生頻度・・・（２）

次に、図５ＢのステップＳ５０７にて、リスク情報管理ＤＢ検索機能１２２は、ステップＳ５０２〜Ｓ５０６で取得した情報をワークテーブルＡ １１３に格納する（図２６（ｂ））。
そして、ステップＳ５０８にて、リスク情報管理ＤＢ検索機能１２２は、ワークテーブルＡ １１３に対して、ソート条件として、障害影響度を第１キーに降順ソート、対策予定日を第２キーに昇順ソートをかける（図２７（ａ）：符号５１１〜５１４は後記）。
続いて、ステップＳ５０９にて、ワークテーブルＡ １１３の内容（図２７（ａ））を障害データ一覧画面（図１４）として運用管理端末２５０のディスプレイ２５９に表示する。このとき、ワークテーブルＡ １１３すべての項目を障害データ一覧画面に表示する必要はなく、図１４に示されるように、必要な項目が表示されていればよいものとする。

ステップＳ５１０では、障害データ一覧画面が表示された以降のイベント処理について記載している。図１４に示すように、障害データ一覧画面の各レコードにはラジオボタンが表示されており、運用管理端末２５０のマウス２６１を介して各レコードのラジオボタンのいずれかが選択され、「更新」ボタンが押下された場合は、リスク情報管理ＤＢ更新機能１２１が呼び出され、図６の処理へ進み、リスク情報管理ＤＢの更新を行う。また「足切り」ボタンを押下した場合は、障害案件切り分け機能１２４が実行され、図７の処理へ進み、足切り線を引くことによって障害案件の優先／非優先の切り分けを行う。

図５の処理はプロジェクトの障害案件に対し、現在未完了である障害案件を検索する処理であり、この検索処理を実行するのはチームリーダだけではなく、プロジェクトメンバ全員可能とする。ステップＳ５０８におけるソートの結果、障害データ一覧画面で上位に表示される案件ほど障害が解決できない場合の被害額が大きいと判断できるため、プロジェクト内でのリスク意識の共有が可能となる。

（リスク情報管理ＤＢ更新処理）
次に、図１、図１４、図１５、図２５、図２７（ｂ）、図２７（ｃ）を参照しつつ、図６に沿ってリスク情報管理ＤＢ更新処理の手順を説明する。
図６は、本実施形態に係るリスク情報管理ＤＢ更新処理の手順を示すフローチャートであり、図１５は、プロジェクト障害データ更新画面例を示す図であり、図２７（ｂ）、図２７（ｃ）は、リスク情報管理ＤＢの例を示す図である。なお、図１５に示すプロジェクト障害データ更新画面は、図２のリスク情報管理ＤＢ更新画面２５５に相当する画面である。
まず、ステップＳ６００にて、リスク情報管理ＤＢ更新機能１２１は、運用管理端末２５０における図１４の障害データ一覧画面において、ラジオボタンが選択された上での「更新」ボタン押下のイベントを検知する。
次に、ステップＳ６０１にて、リスク情報管理ＤＢ更新機能１２１は、ラジオボタンが選択されたレコードに対して障害Ｎｏ．を運用管理端末２５０から取得する。
そして、ステップＳ６０２にて、リスク情報管理ＤＢ更新機能１２１は、取得した障害Ｎｏ．をキーにして、リスク情報管理ＤＢ１１０（図２５）を検索する。ステップＳ６０２の結果、リスク情報管理ＤＢ更新機能１２１は、リスク情報管理ＤＢ１１０における該当するレコードを取得する（図２７（ｂ））。

次に、ステップＳ６０３にて、リスク情報管理ＤＢ更新機能１２１は、取得したリスク情報管理ＤＢ１１０の内容をプロジェクト障害データ更新画面（図１５）として運用管理端末２５０のディスプレイ２５９に表示する。このとき、障害Ｎｏ．とプロジェクトコードについてはグレイアウトされており、更新不可とする。
ステップＳ６０４にて、リスク情報管理ＤＢ更新機能１２１は、運用管理端末２５０における図１５のプロジェクト障害データ更新画面における「実行」ボタン押下のイベントを検知する。
そして、ステップＳ６０５にて、リスク情報管理ＤＢ更新機能１２１は、入力されたプロジェクト障害データ更新画面（図１５）の障害Ｎｏ．をキーとして、プロジェクト障害データ更新画面（図１５）の内容にリスク情報管理ＤＢ１１０のデータを更新する。ここでは、更新を行いたいプロジェクト障害データ更新画面（図１５）のレコードに対し、１レコードずつラジオボタン選択後更新ボタンを押下すると更新が行われる仕組みで、チームリーダ等が主体となり更新作業を行うことにより、リスク情報管理ＤＢ１１０が更新される運用となる。この処理で行われる作業の例としては、図２７（ｂ）の符号５２１に示すようなステータスが「未完了」の障害案件を、図２７（ｃ）の符号５２２に示すように「完了」に修正する作業があげられる。
なお、リスク情報管理ＤＢ更新処理ではステータスの他にも、発生日付、ユーザ要望度、対策予定日、現象コード、原因コード、１人あたりのリカバリ工数（リカバリ工数／人）、影響を受ける人数、ユーザ時間単価、ＳＥ（System Engineering）工数、ＰＧ（Progrmming）
工数、インフラ工数などの値を更新することができる。つまり、プロジェクト障害データ更新画面（図１５）においてグレイアウトしている項目以外の項目について、更新することができる。これらの値の入力方法は、プロジェクトデータ登録処理画面（図１２）と同様であるため、説明を省略する。
また、図１５に図示していないが、ヘルプデスク工数およびコンサル工数の項目をプロジェクト障害データ更新画面（図１５）に表示させることによって、ヘルプデスク工数およびコンサル工数を更新することもできる。

（障害案件切り分け処理）
次に、図１、図１４、図１６、図２８〜図４７を参照しつつ、図７Ａ、図７Ｂ、図７Ｃに沿って障害案件切り分け処理の手順を説明する。
図７Ａ、図７Ｂ、図７Ｃは、本実施形態に係る障害案件切り分け処理の手順を示すフローチャートであり、図１６は、障害案件切り分け処理の実行後における障害データ一覧画面例を示す図であり、図２８は、ＰＪ要員ＤＢの例を示す図であり、図２９〜図４７は、ワークテーブルＢの例を示す図である。
まず、図７ＡのステップＳ７００にて、障害案件切り分け機能１２４は、運用管理端末２５０における図１４の障害データ一覧画面の「足切り」ボタン押下のイベントを検知する。
次に、ステップＳ７０１にて、障害案件切り分け機能１２４は、以下２つの抽出条件をもとにＰＪ要員ＤＢ１１２を検索し、必要なＰＪ要員に関するデータを取得する。ここでは、コンサル要員のデータを取得することとする。１つ目の抽出条件は、現在の日付であるシステム日付がアサイン開始日とアサイン終了日の範囲に存在することで、２つ目の抽出条件は、ＰＪ要員ＤＢ１１２の担当業務が「コンサル」であることである。この結果、図２８の符号５３１に示されるデータが取得される。ここでは、まず担当業務が「コンサル」であるＰＪ要員から処理を行っているが、「コンサル」のＰＪ要員についての処理が終了した後、「ＳＥ」や、「ＰＧ」や、「インフラ工」に関する他のＰＪ要員についても処理を行う。

そして、ステップＳ７０２にて、障害案件切り分け機能１２４は、取得したＰＪ要員ＤＢ１１２のデータ（図２８の符号５３１）をワークテーブルＢ １１４に退避する（図２９）。このとき、スキルの高い要員が障害影響度の高い案件に優先的に割り当てられるように、障害案件切り分け機能１２４は、スキル補正係数をキーにしてワークテーブルＢ １１４に降順ソートをかける。スキル補正係数とは、前記ＰＪ要員のスキルに関する情報は、平均的なＰＪ要員の作業効率を１としたときにおける該当するＰＪ要員作業効率を示した値である。

次のステップＳ７０３〜Ｓ７１４までは、ワークテーブルＡ １１３のデータ（図２７（ａ）参照）に関して、上から順に繰り返す処理となる。
ステップＳ７０４にて、障害案件切り分け機能１２４は、図２７（ａ）に示す図５ＢのステップＳ５０８にてソートされたワークテーブルＡ １１３の先頭レコード（図２７（ａ）の符号５１１）の「コンサル工数」を取得する。ここで、「コンサル工数」を取得するのは、ステップＳ７０１で前記したように担当業務を参照する順番がコンサル要員からはじまるためである。対象となるＰＪ要員が、例えばＳＥ要員であれば、ステップＳ７０４で取得するのは、「ＳＥ工数」となる。
このとき、取得したレコードにおけるコンサル工数が０ならば、すなわち、対象となっているＰＪ要員であるコンサル要員を必要としないならば、以下処理を行わずワークテーブルＡ １１３の次レコードに進む。取得したレコードにおけるコンサル工数が０以外ならば、次処理（ステップＳ７０５）へ進む。なお、ワークテーブルＡ １１３のデータが無くなればステップＳ７１５へ進む。

ステップＳ７０５〜Ｓ７１０までは、ワークテーブルＢ １１４のデータ（図２９）が無くなるまでの繰り返し処理となる。なお、当繰り返し処理の中で、ワークテーブルＡ １１３の対策予定日がワークテーブルＢ １１４のアサイン開始日と、アサイン終了日の間に存在しない場合は、障害案件切り分け機能１２４は、処理を行わずに、ワークテーブルＡ １１３における次のレコードを取得する。

ステップＳ７０６にて、障害案件切り分け機能１２４は、ワークテーブルＡ １１３の対策予定日と、図５ＡのステップＳ５０１で取得したシステム日付から「残日数」（作業残日数）を算出し、ワークテーブルＢ １１４の残日数を更新する。ここで、残日数は、対策予定日までどのくらいの余裕があるかを示す日数であり、残日数＝ワークテーブルＡ １１３の対策予定日−システム日付で計算される。処理対象となっている図２７（ａ）の符号５１１における対策予定日は２００８／０８／２０であり、前記したようにシステム日付を２００８／０８／１７とすると、残日数は「３」となる（図３０の符号５３２）。

次に、図７ＢのステップＳ７０７にて、障害案件切り分け機能１２４は、ワークテーブルＢ １１４における対象となっているＰＪ要員のインクリメントカウンタの値（図３１の符号５３３）を同一レコードのカウンタワーク（図３１の符号５３４）に退避する。
そして、ステップＳ７０８にて、障害案件切り分け機能１２４は、ワークテーブルＡ １１３において、処理対象となっているコンサル工数を、ワークテーブルＢ １１４において、処理対象となっているメンバのスキル補正係数で割った値（小数点第１位を切り上げ）を、ワークテーブルＢ １１４の当該メンバのインクリメントカウンタとして加算する（図３２の符号５３５）。ここでは、図２７（ａ）に示すワークテーブルＡ １１３の符号５３１におけるレコードのコンサル工数が「１」で、図３２に示すワークテーブルＢ １１４の要員Ｉにおけるスキル補正係数が１．５なので、インクリメントカウンタは１／１．５ ＝ ０．６６６・・・≒１と算出できる。つまり、要員Ｉは、平均的なコンサル要員であれば１日で終わる工程（コンサル工数）を０．６６６・・・日で終えることができることになり、ステップＳ７０８で算出される値は、ＰＪ要員のスキルに応じた保守の作業日数である。ここで、小数点１位を切り上げている理由は、障害案件の解決に０．６６日の工数がかかるとしても、障害内容の理解、引継ぎなどで実際には０．６６日以上工数を割かれることが予想されるため、作業のバッファを考慮するためである。

ここで、ステップＳ７０９でワークテーブルＢ １１４における前レコードが０未満となった場合、ワークテーブルＡ １１３のコンサル工数からワークテーブルＢ １１４における前レコードの要員が対応した工数分を差し引いたものが本来の工数となるが、現在はワークテーブルＢ １１４における最初の要員であり、前レコードが存在しないので、この処理は行わない。なお、この処理は後記して説明する。

次に、ステップＳ７０９にて、障害案件切り分け機能１２４は、ワークテーブルＢ １１４において処理対象となっている残日数から、同じＰＪ要員のインクリメントカウンタの値を減算する（図３３の符号５３６：要員可能残日数）。このとき、障害案件切り分け機能１２４は、以下の分岐処理（α）、（β）、（γ）を行う。
（α）減算した値（残日数）が０以上（＞＝０）の場合、障害案件切り分け機能１２４は、当該メンバで対応可能と判断し、ワークテーブルＡ １１３（同一担当業務）の次レコードに進む（処理７０４に戻る）。つまり、ここでは、コンサル要員Ｉを処理対象メンバとしたまま、図２７（ａ）のワークテーブルＡ １１３における符号５１２（「障害案件１３」）について、ステップＳ７０４〜Ｓ７０９の処理を繰り返す。
（β）減算した値が０未満（＜０）の場合、障害案件切り分け機能１２４は、当該メンバだけでは対応できないと判断し、ステップＳ７１０に進む（このとき残日数は更新しない）。
（γ）ワークテーブルＢ １１４の最終レコードになった場合、障害案件切り分け機能１２４は、ワークテーブルＢ １１４の残日数を更新してステップＳ７１４に進む。

図３３の符号５３６を参照すると、残日数が「２」であり、要員Ｉだけで対応可能と判断できるため、この場合はワークテーブルＢ １１４の次レコード（つまり、要員Ｊ）に進まず、図２７（ａ）の符号５１２のレコードに対しステップＳ７０４に戻る（Ｓ７０９：分岐α）。

障害案件切り分け機能１２４は、ステップＳ７０４，Ｓ７０５を行ったあと、ステップＳ７０６にて、ワークテーブルＡ １１３の対策予定日とシステム日付から「残日数」を算出し、ワークテーブルＢ １１４の残日数を更新する（図３４の符号５３７）。図２７（ａ）の符号５１２における対策予定日は、「２００８／８／２０」であり、前記したようにシステム日付は、「２００８／８／１７」とするので、障害案件切り分け機能１２４は、「３」を図３４の符号５３７に格納する。

そして、ステップＳ７０７にて、障害案件切り分け機能１２４は、ワークテーブルＢ １１４のインクリメントカウンタの値（図３５の符号５３８）を同一レコードのカウンタワーク（図３５の符号５３９）に退避する。
次に、ステップＳ７０８にて、障害案件切り分け機能１２４は、ワークテーブルＡ １１３のコンサル工数をワークテーブルＢ １１４の処理対象メンバのスキル補正係数で割った値（小数点第１位を切り上げ）を、当該メンバのインクリメントカウンタとして加算する（図３６の符号５４０）。図２７（ａ）の符号５１２におけるコンサル工数は、「１」であり要員Ｉのスキル補正係数が１．５であるため、「１÷１．５＝０．６６・・・≒１」を要員Ｉのインクリメントカウンタに加算することで、図３６の符号５４０のようになる。

次に、ステップＳ７０９にて、ワークテーブルＢ １１４の残日数からインクリメントカウンタの値を減算する（図３７の符号５４１）。図３７の符号５４０に示すように、残日数が「１」となり、この案件も要員Ｉだけで対応可能と判断できるため、この場合もワークテーブルＢ １１４の次レコードに進まない（ステップＳ７０９における分岐α）。

従って、障害案件切り分け機能１２４は、図２７（ａ）の符号５１３（障害案件１１）について、ステップＳ７０４〜Ｓ７０９の処理を行う。
障害案件切り分け機能１２４は、ステップＳ７０４，Ｓ７０５を実行した後、ステップＳ７０６に進む。

ステップＳ７０６にて、障害案件切り分け機能１２４は、ワークテーブルＡ １１３の対策予定日とシステム日付から「残日数」を算出し、ワークテーブルＢ １１４の該当する残日数を更新する（図３８の符号５４２）。図２７（ａ）の符号５１３を参照すると、対策予定日は「２００８／８／２０」であり、前記したようにシステム日付は「２００８／８／１７」であるので、残日数は図３８の符号５４２で示すように「３」となる。

そして、ステップＳ７０７にて、障害案件切り分け機能１２４は、ワークテーブルＢ １１４において、処理対象となっているインクリメントカウンタの値（図３９の符号５４３）を、同一レコードのカウンタワーク（図３９の符号５４４）に退避する。
ステップＳ７０８にて、障害案件切り分け機能１２４は、ワークテーブルＡ １１３において処理対象のコンサル工数をワークテーブルＢ １１４の処理対象メンバのスキル補正係数で割った値（小数点第１位を切り上げ）を、ワークテーブルＢ １１４の該当メンバのインクリメントカウンタとして加算する（図４０の符号５４５）。図２７（ａ）の符号５１３を参照すると、コンサル工数は「３」である。従って、障害案件切り分け機能１２４は、コンサル要員Ｉのスキル補正係数「１．５」でコンサル工数「３」を除算した結果「２」を図４０の符号５４５に加算する。

次に、ステップＳ７０９にて、障害案件切り分け機能１２４は、ワークテーブルＢ １１４の残日数から、インクリメントカウンタの値を減算する。図４０の符号５４６の残日数が「３」で、図４０の符号５４５のインクリメントカウンタが「４」なので、減算処理を行うと「−１」となり、０未満になる。この場合、障害案件切り分け機能１２４は、要員Ｉだけでは対応できないと判断し、この減算結果（「−１」）を、ＡＰサーバ２１０の記憶装置２１３に一時保存し、残日数を更新せず、ステップＳ７１０に進む。つまり、ステップＳ７０９で分岐（β）となる。

ステップＳ７１０にて、障害案件切り分け機能１２４は、ワークテーブルＢ １１４の残日数（図４０の符号５４６）からカウンタワーク（図４０の符号５４７）の値を減算し（３−２＝１）、ワークテーブルＢ １１４のカウンタワークを減算した結果に更新する（図４１の符号５４８）。
そして、ステップＳ７１１にて、障害案件切り分け機能１２４は、ワークテーブルＢ １１４の残日数を、ワークテーブルＢ １１４の同一レコードのインクリメントカウンタに退避する（図４２の符号５４９）。

次に、ステップＳ７１２にて、障害案件切り分け機能１２４は、ステップＳ７０９で一時保存していた減算の結果（「−１」）を残日数として更新し（図４３の符号５５０）、ワークテーブルＢ １１４（同一担当業務）の次レコード（要員Ｊのレコード）に進む。

ステップＳ７１３においては、障害案件切り分け機能１２４は、ステップＳ７０５へ戻り、要員Ｊに関してステップＳ７０４〜Ｓ７０９までの処理を繰り返す。なお、ここでワークテーブルＡ １１３については、図２７（ａ）の符号５１３のレコードが処理対象となる。
要員Ｊについて、ステップＳ７０４，Ｓ７０５の後、ステップＳ７０６にて、障害案件切り分け機能１２４は、ワークテーブルＡ １１３の対策予定日とシステム日付から「残日数」を算出し、ワークテーブルＢ １１４の残日数を更新する（図４４の符号５５１）。具体的には、障害案件切り分け機能１２４は、図２７（ａ）の符号５１３における対策予定日「２００８／８／２０」からシステム日付「２００８／８／１７」を減算することにより残日数「３」を算出し、図４４の符号５５１に格納する。

そして、ステップＳ７０７にて、障害案件切り分け機能１２４は、ワークテーブルＢ １１４のインクリメントカウンタの値（図４５の符号５５２）を同一レコードのカウンタワークに退避する（図４５の符号５５３）。
次に、ステップＳ７０８にて、障害案件切り分け機能１２４は、ワークテーブルＡ １１３のコンサル工数をワークテーブルＢ １１４のメンバのスキル補正係数で割った値（小数点第１位を切り上げ）を、ワークテーブルＢ １１４の当該メンバのインクリメントカウンタとして加算する。ここで、ステップＳ７０９でワークテーブルＢ １１４における前レコードが０未満となった場合、ワークテーブルＡ １１３のコンサル工数からワークテーブルＢ １１４における前レコードの要員が対応した工数分を差し引いたものが本来の工数となる。具体的には、前記したステップＳ７０９で、ワークテーブルＢ １１４の前レコード（ここでは、要員Ｉ）の減算値が０未満（「−１」）となっているため、ワークテーブルＡ １１３のコンサル工数は、ワークテーブルＢ １１４の前レコード（ここでは、要員Ｉ）のスキル補正係数１．５と、ワークテーブルＢ １１４の前レコード（ここでは、要員Ｉ）のカウンタワーク値「１」を乗算した１．５の工数分を差し引いたものになる。例えば、処理対象となっているワークテーブルＡ １１３のコンサル工数は、図２７（ａ）の符号５１３のレコードから「３」であるため、ワークテーブルＢ １１４の前レコードの要員Ｉ対応分「１．５」を減算した「１．５」が残コンサル工数となる。そして、障害案件切り分け機能１２４は、残コンサル工数「１．５」をワークテーブルＢ １１４におけるの要員Ｊのスキル補正係数「０．５」で割った「３」をインクリメントカウンタに加算する（図４６の符号５５４参照）。つまり、要員Ｊは、ワークテーブルＢ １１４における前レコードの要員Ｉが対応しきれない部分をカバーする。

次に、ステップＳ７０９にて、障害案件切り分け機能１２４が、ワークテーブルＢ １１４において、処理対象となっているレコードにおける残日数からインクリメントカウンタの値を減算する（図４７の符号５５６）。具体的には、図４６の符号５５５の値から符号５５４の値を減算した値が「０」となり、ステップＳ７０９における０以上の場合の処理に分岐できるため（分岐（α））、この障害案件は要員Ｉと要員Ｊの２人で対応可能と判断し、ワークテーブルＢ １１４の繰り返し処理から抜け、ワークテーブルＡ １１３（同一担当業務）の次レコード（符号５１４）に進む（ステップＳ７０４に戻る）。そして、障害案件切り分け機能１２４は、図２７（ａ）の符号５１４について、ステップＳ７０４〜Ｓ７０９の処理を行うが、ステップＳ７０９において減算した値が０未満となり、かつワークテーブルＢ １１４の最終レコードであるため、ステップＳ７０９において分岐γが選択され、ステップＳ７１４の処理へ進む。
このように、ステップＳ７１４については、ステップＳ７０９の結果、減算した値が０未満になった場合、かつワークテーブルＢ １１４の最終レコードになった場合に処理を行う。

ステップＳ７１４にて、障害案件切り分け機能１２４は、ワークテーブルＢ １１４の最終レコードの残日数を判定して、ワークテーブルＢ １１４の最終レコードの残日数が０未満の場合、ワークテーブルＡ １１３の障害案件の切捨フラグに「×」をセットする。ここでは、図２７（ａ）の符号５１４以下のレコードの切捨フラグに「×」がセットされる（図示せず）。
保守管理システム１００は、ワークテーブルＡ １１３の切捨フラグに「×」が立った障害案件を、このプロジェクトのリソースでは対応できないと判断し、非優先案件と判断する。

ステップＳ７１５では、障害案件切り分け機能１２４が、ＳＥ工数に関して、ステップＳ７０１〜Ｓ７１４の処理を行う。ステップＳ７１６では、障害案件切り分け機能１２４が、ＰＧ工数に関して、ステップＳ７０１〜Ｓ７１４の処理を行う。ステップＳ７１７では、インフラ工数に関して、ステップＳ７０１〜Ｓ７１４の処理行う。ステップＳ７１８では、障害案件切り分け機能１２４が、ヘルプデスク工数に関して、ステップＳ７０１〜Ｓ７１４の処理を行う。このとき、障害案件切り分け機能１２４は、ワークテーブルＡ １１３における切捨フラグにおいて新たな「×」のみを上書きする。すなわち、コンサル工数において、「×」ではないが、ＳＥ工数では「×」となった障害案件があれば、切捨フラグは「×」となるが、コンサル工数におおいて「×」であるが、ＳＥ工数では、「×」とならなかった障害案件は「×」のままとする。

ステップＳ７１９では、障害案件切り分け機能１２４が、以下のキー条件でワークテーブルＡ １１３に対して再ソートを行う。すなわち、第１キーは切捨フラグにて昇順で、第２キーは障害影響度にて降順で、第３キーは対策予定日にて昇順でソートする。
ステップＳ７２０にて、ワークテーブルＡ １１３のデータを基に、運用管理端末２５０のディスプレイ２５９に表示されている障害データ一覧画面上に足切り線を表示する（図１６）。足切り線を引く条件は、切捨フラグが立っている（「×」が登録されている）レコードと、立っていないレコードの境界に対して行う。これは、一覧表示された各障害案件に対して、優先案件と非優先案件の切り分けを行う処理である。足切り線で境界下に出力された障害案件は、グレイアウト表示する仕様のため、その障害案件は対応しなくてよいという意味となる。つまり、エンドユーザの視点からみて、どれだけ重要だと思われる障害案件でも、足切り線の下に表示されればその障害案件を無視し、足切り線より上に表示された案件を順番に対応する運用を行う必要がある。ただし、すべての障害案件に切捨フラグが立っていて足切り線が表示できない場合は、障害影響度の一番大きな案件（ワークテーブルＡ １１３の先頭レコード）を優先的に対応することとし、１件目と２件目の間に足切り線を引く。この場合は、２件目以降の障害案件はグレイアウト表示される。

なお、本実施形態では、コンサル、ＳＥ、ＰＧ、インフラについての処理を記述したが、これらだけに限らず、作業の工程であればよいことは当然である。

（テーブルメンテナンス処理：現象コードＤＢ）
次に、図１、図１１、図１７〜図２２、図４８〜図５３を参照しつつ、図８〜図１０に沿って現象コードＤＢ１１５、原因コードＤＢ１１６、ＰＪ要員ＤＢ１１２のテーブルメンテナンス処理の手順を説明する。
図８は、本実施形態に係る現象コードＤＢ１１５のテーブルメンテナンス処理の手順を示すフローチャートであり、図１７は、現象コードＤＢ一覧画面例を示す図であり、図１８は、現象コードＤＢ登録画面例を示す図である。なお、図１７の現象コードＤＢ一覧画面および図１８の現象コードＤＢ登録画面は、図２におけるテーブルメンテナンス画面２５８の１つである。
まず、ステップＳ８００にて、運用管理端末２５０において、初期画面（図１１）のラジオボタン「テーブルメンテナンス機能」の中の「現象コードＤＢ」が選択された後、「実行」ボタンが押下されることにより、テーブルメンテナンス機能１２５は、ラジオボタン「テーブルメンテナンス機能」の中の「現象コードＤＢ」選択のイベントを検知する。
次に、ステップＳ８０１にて、テーブルメンテナンス機能１２５は、現象コードＤＢ１１５（図４８）を取得する。
ステップＳ８０２にて、テーブルメンテナンス機能１２５は、取得した現象コードＤＢ１１５の内容を現象コードＤＢ一覧画面（図１７）として、運用管理端末２５０のディスプレイ２５９に表示する。
図１７に示すように、現象コードＤＢ一覧画面には、レコード毎にラジオボタンが表示されており、運用管理者が運用管理端末２５０のマウス２６１を使用して、ラジオボタンを選択した後、「削除」ボタンを押下することにより、ステップＳ８０３にて、テーブルメンテナンス機能１２５が、「削除」ボタン押下のイベントを検知し、ステップＳ８０４にて、ラジオボタンで選択されたレコードを現象コードＤＢ１１５から削除する。

また、運用管理者が運用管理端末２５０のマウス２６１を使用して、ラジオボタンを選択した後、「追加」ボタンを押下することにより、ステップＳ８０５にて、「追加」ボタン押下のイベントを検知し、ステップＳ８０６にて、テーブルメンテナンス機能１２５は、現象コードＤＢ登録画面（図１８）を運用管理端末２５０のディスプレイ２５９に表示する。
ステップＳ８０７にて、現象コード登録画面（図１８）に入力された現象コードと名称を取得し、現象コードＤＢ１１５に追加する（図４９の符号６０１）。

（テーブルメンテナンス処理：原因コードＤＢ）
図９は、本実施形態に係る原因コードＤＢのテーブルメンテナンス処理の手順を示すフローチャートであり、図１９は、原因コードＤＢ一覧画面例を示す図であり、図２０は、原因コードＤＢ登録画面例を示す図である。なお、図１９の原因コードＤＢ一覧画面および図２０の原因コードＤＢ登録画面は、図２のテーブルメンテナンス画面２５８の１つである。
ステップＳ９００にて、テーブルメンテナンス機能１２５は、運用管理端末２５０において初期画面（図１１）のラジオボタン「テーブルメンテナンス機能」の中の「原因コードＤＢ」が選択された後、「実行」ボタンが押下さることによる、ラジオボタン「テーブルメンテナンス機能」の中の「原因コードＤＢ」選択のイベントを検知する。
次に、ステップＳ９０１にて、原因コードＤＢ１１６（図５０）を取得する。
ステップＳ９０２にて、テーブルメンテナンス機能１２５は、取得した原因コードＤＢ１１６の内容を原因コードＤＢ一覧画面（図１９）として、運用管理端末２５０のディスプレイ２５９に表示する。

図１９に示すように、原因コードＤＢ一覧画面には、レコード毎にラジオボタンが表示されており、運用管理者が運用管理端末２５０のマウス２６１を使用して、ラジオボタンを選択した後、「削除」ボタンを押下することにより、ステップＳ９０３にて、テーブルメンテナンス機能１２５が、「削除」ボタン押下のイベントを検知し、ステップＳ９０４にて、テーブルメンテナンス機能１２５は、ラジオボタンで選択されたレコードを原因コードＤＢ１１６から削除する。

また、ステップＳ９０２にて、運用管理者が運用管理端末２５０のマウス２６１を使用して、ラジオボタンを選択した後、「追加」ボタンを押下することにより、ステップＳ９０５にて、テーブルメンテナンス機能１２５が、「追加」ボタン押下のイベントを検知し、ステップＳ９０６にて、テーブルメンテナンス機能１２５が、原因コードＤＢ登録画面（図２０）を運用管理端末２５０のディスプレイ２５９に表示する。
そして、ステップＳ９０７にて、テーブルメンテナンス機能１２５は、原因コード登録画面（図２０）に入力された「原因コード」と「名称」を取得し、原因コードＤＢ１１６に追加する（図５１の符号６１１）。

（テーブルメンテナンス処理：ＰＪ要員ＤＢ）
図１０は、本実施形態に係るＰＪ要員ＤＢのテーブルメンテナンス処理の手順を示すフローチャートであり、図２１は、ＰＪ要員ＤＢ一覧画面例を示す図であり、図２２は、ＰＪ要員ＤＢ登録画面例を示す図であり、図５２および図５３は、ＰＪ要員ＤＢの例を示す図である。なお、図２１のＰＪ要員ＤＢ一覧画面および図２２のＰＪ要員ＤＢ登録画面は、図２のテーブルメンテナンス画面２５８の１つである。
まず、ステップＳ１０００にて、テーブルメンテナンス機能１２５は、運用管理端末２５０において初期画面（図１１）のラジオボタン「テーブルメンテナンス機能」の中の「ＰＪ要員ＤＢ」が選択された後、「実行」ボタン押下のイベントを検知する。
次に、ステップＳ１００１にて、テーブルメンテナンス機能１２５は、ＰＪ要員ＤＢ１１２（図５２）を取得する。
そして、ステップＳ１００２にて、テーブルメンテナンス機能１２５は、取得したＰＪ要員ＤＢ１１２の内容をＰＪ要員ＤＢ一覧画面（図２１）として、運用管理端末２５０のディスプレイ２５９に表示する。
図２１に示すように、ＰＪ要員ＤＢ一覧画面には、レコード毎にラジオボタンが表示されており、運用管理者が運用管理端末２５０のマウス２６１を使用して、ラジオボタンを選択した後、「削除」ボタンを押下することにより、ステップＳ１００３にて、テーブルメンテナンス機能１２５が、ラジオボタン「削除」ボタン押下のイベントを検知し、ステップＳ１００４にて、テーブルメンテナンス機能１２５は、ラジオボタンで選択されたレコードをＰＪ要員ＤＢ１１２から削除する。

また、ステップＳ１００２にて、運用管理者が運用管理端末２５０のマウス２６１を使用して、ラジオボタンを選択した後、「追加」ボタンを押下することにより、ステップＳ１００５にて、テーブルメンテナンス機能１２５が、「追加」ボタン押下のイベントを検知し、ステップＳ１００６にて、テーブルメンテナンス機能１２５は、ＰＪ要員ＤＢ登録画面（図２２）を表示する。
そして、ステップＳ１００７にて、ＰＪ要員ＤＢ登録画面（図２２）に入力されたメンバＩＤと、メンバ名称と、担当業務と、スキル補正係数と、契約開始日（アサイン開始日）と、契約終了日（アサイン終了日）を取得し、ＰＪ要員ＤＢ１１２に追加する（図５３の符号６１２）。
なお、図８〜図１０の処理のうち、最も重要となる処理はＰＪのメンバを管理するＰＪ要員ＤＢ１１２のメンテナンスであり、当該メンバのプロジェクトへの参画、または離脱が決定した場合は、チームリーダ等により速やかにＰＪ要員ＤＢ１１２に反映されるようにしなければならない。ＰＪ要員ＤＢ１１２が実態の要員と乖離していると、障害案件切り分け機能によって正確な足切り線が表示されなくなるため重要である。

なお、チームリーダが、要員のレベルを入力し、保守管理システム１００が入力されたレベルを図５４のようなＩＴＳＳレベル‐スキル補正係数対応テーブル（作業レベル‐スキル補正係数情報）を利用して、スキル補正係数に換算してもよい。

《まとめ》
本実施形態によれば、混乱プロジェクトにおけるリスク評価に用いられる情報として、障害一覧を障害影響度の順序、つまり被害の大きい順に並べ替えて出力する機能を有するため、開発者の障害対応を支援することが可能となる。すなわち、障害対応を納期情報だけを判断材料に使用し、納期の差し迫っている案件順に対応していくよりも、本実施形態では被害の大きな障害かつ納期が差し迫った案件という２つの基準を統合的に判断してから着手していくため、被害が最も少ない方法で障害対応できる。ただし、障害案件がプロジェクトのリソースキャパシティ（ＰＪ要員で指定納期まで対応できる能力）を超えてしまった場合、障害一覧画面上に足切り線の表示が行われ、納期までに対応できない案件が出てくる場合が存在する。足切り線にかかった障害案件は障害影響度的にも納期的にも、被害が少ない案件とみなされ、プロジェクトでは対応しない方針とすることができる。

１００ 保守管理システム（保守管理装置）
１０１ 入出力機能
１１０ リスク情報管理ＤＢ
１１１ 発生頻度ＤＢ
１１２ ＰＪ要員ＤＢ（ＰＪ要員のスキルに関する情報）
１１３ ワークテーブルＡ
１１４ ワークテーブルＢ
１１５ 現象コードＤＢ
１１６ 原因コードＤＢ
１２０ リスク情報管理ＤＢ登録機能
１２１ リスク情報管理ＤＢ更新機能
１２２ リスク情報管理ＤＢ検索機能
１２３ 発生頻度集計機能
１２４ 障害案件切り分け機能（処理部）
１２５ テーブルメンテナンス機能

Claims (11)

1. システム障害の保守を管理する保守管理装置による保守管理方法であって、
   過去における障害案件に関する情報が、前記障害案件が生じた日付に対応付けられて格納されている障害案件実績情報と、プロジェクトに係る要員である、複数のＰＪ要員のスキルに関する情報とが記憶部に格納されており、
   前記障害案件実績情報における過去に発生した障害案件に関する情報と、該障害案件が生じた日付とを基に、入力部を介して入力された所定の期間における前記障害案件の発生確率を算出し、
   前記算出した発生確率を基に、障害がプロジェクトに与える影響の度合いである障害影響度を、前記発生確率が大きいほど、当該障害影響度が大きくなるように設定された式を用いて算出し、
   すべてのＰＪ要員について、
   現在の日付を基に、前記障害案件の保守に費やすことのできる作業残日数を算出し、
   前記ＰＪ要員のスキルに関する情報を基に、当該ＰＪ要員が前記障害案件の保守に費やす作業日数を算出し、
   前記作業残日数から前記作業日数を減算した要員可能残日数を算出し、
   前記要員可能残日数が０以上の値となった場合、
   当該障害案件を対応可能と判定し、
   前記要員可能残日数が負の値となった場合、
   処理対象となっているＰＪ要員では、該当する障害案件を対応不可能と判定する判定処理を行った後、
   前記障害案件に関する情報を前記障害影響度でソートし、
   対応可能な障害案件に関する情報と、対応不可能な障害案件に関する情報とを区別して表示する表示処理を行う
   ことを特徴とする保守管理方法。
2. 前記保守管理装置は、
   前記対応可能な障害案件に関する情報と、前記対応不可能な障害案件に関する情報とを区別して表示する際に、前記対応可能な障害案件に関する情報が上位になるよう前記障害案件に関する情報をソートする
   ことを特徴とする請求項１に記載の保守管理方法。
3. 前記障害案件を対応不可能と判定されたＰＪ要員の作業日数を差し引いて、他のＰＪ要員の要員可能残日数を算出する
   ことを特徴とする請求項１に記載の保守管理方法。
4. 前記ＰＪ要員のスキルに関する情報は、平均的なＰＪ要員の作業効率を１としたときにおいて該当するＰＪ要員作業効率を示したスキル補正係数であり、
   前記作業日数は、
   前記平均的なＰＪ要員が、処理対象となっている障害案件に係る日数である工数をスキル補正係数で除算し、当該除算の結果を小数点第１位で切り上げた値である
   ことを特徴とする請求項１に記載の保守管理方法。
5. 前記ＰＪ要員の作業効率に関するレベルである作業レベルと、前記スキル補正係数と、を対応付けている作業レベル‐スキル補正係数テーブルが、記憶部にさらに格納されており、
   前記保守管理装置は、
   前記入力部を介して、入力された前記作業レベルを、前記作業レベル‐スキル補正係数テーブルを基に、前記スキル補正係数に変換する
   ことを特徴とする請求項４に記載の保守管理方法。
6. 前記障害影響度は、
   前記障害案件の対策優先度を示す指標であるユーザ要望度と、補修にかかるコストである損害規模と、障害の発生頻度とを乗算した値である
   ことを特徴とする請求項１に記載の保守管理方法。
7. 前記対策優先度の情報と、前記ユーザ要望度と、が対応付けられているユーザ要望対応テーブルが、記憶部にさらに格納されており、
   前記保守管理装置は、
   前記入力部を介して、入力された前記対策優先度の情報を、前記ユーザ要望対応テーブルを基に、前記ユーザ要望度に変換する
   ことを特徴とする請求項６に記載の保守管理方法。
8. 前記障害案件に関する情報には、前記障害の種類に関する情報と、前記障害の原因に関する情報と、が格納されており、
   前記障害の発生頻度は、前記リスク管理情報に格納されている障害において、特定の種類および原因を有する障害が所定期間中に発生した割合である
   ことを特徴とする請求項６に記載の保守管理方法。
9. 前記ＰＪ要員のスキルに関する情報は、前記ＰＪ要員が行う作業の種類毎に格納されており、
   前記保守管理装置が、
   前記判定処理と、前記表示処理とを前記作業の種類毎に行う
   ことを特徴とする請求項１に記載の保守管理方法。
10. 請求項１から請求項９のいずれか一項に記載の保守管理方法をコンピュータに実行させることを特徴とするプログラム。
11. システム障害の保守を管理する保守管理装置であって、
    処理部と、記憶部とを有し、
    前記記憶部には、
    過去における障害案件に関する情報が、前記障害案件が生じた日付に対応付けられて格納されている障害案件実績情報と、プロジェクトに係る要員である、複数のＰＪ要員のスキルに関する情報とが格納されており、
    前記処理部は、
    前記障害案件実績情報における過去に発生した障害案件に関する情報と、該障害案件が生じた日付とを基に、入力部を介して入力された所定の期間における前記障害案件の発生確率を算出し、
    前記算出した発生確率を基に、障害がプロジェクトに与える影響の度合いである障害影響度を、前記発生確率が大きいほど、当該障害影響度が大きくなるように設定された式を用いて算出し、
    すべてのＰＪ要員について、
    現在の日付を基に、前記障害案件の保守に費やすことのできる作業残日数を算出し、
    前記ＰＪ要員のスキルに関する情報を基に、当該ＰＪ要員が前記障害案件の保守に費やす作業日数を算出し、
    前記作業残日数から前記作業日数を減算した要員可能残日数を算出し、
    前記要員可能残日数が０以上の値となった場合、
    当該障害案件を対応可能と判定し、
    前記要員可能残日数が負の値となった場合、
    処理対象となっているＰＪ要員では、該当する障害案件を対応不可能と判定する処理を行った後、
    前記障害案件に関する情報を前記障害影響度でソートし、
    対応可能な障害案件に関する情報と、対応不可能な障害案件に関する情報とを区別して表示する
    ことを特徴とする保守管理装置。

Images