JP6275542B2 - 分析装置およびコンピュータプログラム - Google Patents

Description

本発明はデータ処理技術に関し、特に情報システムの運用状況を分析する技術に関する。

情報システムの運用サービスにおいては、運用の責任者とユーザ（情報システムのオーナー等）との間でサービスレベルアグリーメント（以下、「ＳＬＡ」と呼ぶ。）が定められることがある（例えば特許文献１参照）。

国際公開第２０１２／１４４２０４号

従来、情報システムの運用コストの見積は運用担当者の経験や勘に頼る部分が大きかった。近年、情報システムの運用コストに対する圧縮要請が強まってきており、精度の高い運用コストの見積が求められている。本発明の主な目的は、情報システムの運用コストの予測を支援する技術を提供することにある。

上記課題を解決するために、本発明のある態様の分析装置は、実システムの運用に要するオペレータの業務量を示す情報を取得する第１取得部と、オペレータの運用能力を示す情報を取得する第２取得部と、実システムに対するオペレータによる運用実績を示す情報を取得する第３取得部と、オペレータの業務量および運用能力にもとづいて特定される第１変数と、オペレータの運用実績にもとづいて特定される第２変数との間の回帰係数を導出する回帰分析部と、予測対象のシステムで想定されるオペレータの業務量と、仮に定められたオペレータの運用能力と、回帰分析部により導出された回帰係数にしたがって、予測対象のシステムに対するオペレータによる運用状態を推定する推定部と、を備える。

本発明の別の態様もまた、分析装置である。この装置は、実システムの運用に要するオペレータの業務量を示す情報を取得する第１取得部と、オペレータの運用能力を示す情報を取得する第２取得部と、実システムに対するオペレータによる運用実績を示す情報を取得する第３取得部と、オペレータの業務量および運用能力にもとづいて特定される第１変数と、オペレータの運用実績にもとづいて特定される第２変数との間の回帰係数を導出する回帰分析部と、予測対象のシステムで想定されるオペレータの業務量と、予測対象のシステムに要求されるオペレータによる運用状態と、回帰分析部により導出された回帰係数にしたがって、予測対象のシステムで必要となるオペレータの運用能力を推定する推定部と、を備える。

なお、以上の構成要素の任意の組合せ、本発明の表現を、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、情報システムの運用コストの予測を支援することができる。

情報システムの運用に関わる装置群を示す図である。 図１の分析装置の機能構成を示すブロック図である。 図３（ａ）はシステム定義情報を示す図であり、図３（ｂ）はエラーメッセージログを示す図である。 図４（ａ）はオペレータ基本情報を示す図であり、図４（ｂ）は作業実績情報を示す図であり、図４（ｃ）は定義申請情報を示す図である。 運用効率情報の構成を示す図である。 オペレータ評価情報の構成を示す図である。 サービスレベル情報の構成を示す図である。 運用効率情報画面を示す図である。 オペレータ評価情報画面を示す図である。 サービスレベル情報画面を示す図である。 図１１（ａ）は第１回帰分析に用いる各システムの情報を示す図であり、図１１（ｂ）は第２回帰分析に用いる各システムの情報を示す図である。 図１２（ａ）は第１回帰分析の結果を示し、図１２（ｂ）は第２回帰分析の結果を示し、図１２（ｃ）は第３回帰分析の結果を示す図である。 予測処理における入力値と予測結果の例を示す図である。

実施の形態の分析装置の構成を説明する前に概要を説明する。
近年、情報システムの運用コストの圧縮要請は強まる傾向にあるが、運用対象となるシステムの規模はむしろ増大傾向にあり、運用コストの圧縮は容易でない状況である。このような背景を踏まえ、本発明者は、運用コストを顧客へ説明する際の説明能力の向上が必要であると認識し、（１）情報システムの運用実績の可視化と、（２）運用コスト見積の精度向上、が必要であると考えた。

（１）情報システムの運用実績の可視化について：
これまで、運用実績の集計は運用担当者による手作業でなされ、集計者の作業負荷も大きかった。また、運用に関する少数の情報しか集計できず、集計した情報が既に古い内容になっていることもあった。また、運用実務の要員（以下「オペレータ」とも呼ぶ。）の評価基準も限られており、例えば勤続年数等による評価に留まるものであった。

そこで実施の形態の分析装置は、運用監視装置からシステム定義とシステムエラーログを自動的に収集し、また、運用サービスデスク装置から運用のオペレーションログを自動的に収集する。分析装置は、これらのデータを集計して、運用規模とオペレーション実績に整形し紐付けて蓄積し、運用効率・サービスレベル・オペレータ評価のビューを提供する。これにより、情報システムの運用に関する広範囲な情報を可視化し、また情報鮮度の向上を実現し、運用部門での情報活用、また顧客への説明能力向上を支援する。

（２）運用コスト見積もりの精度向上について：
これまで、情報システムの運用コストの見積は運用担当者の経験や勘に頼る部分が大きく、その精度は必ずしも高くなかった。本発明者は、実際にシステム運用業務に携わる中で、現実の情報システムの運用におけるオペレータの業務量および運用能力と、オペレータの運用実績との間に相関があることに想到した。

実施の形態の分析装置は、現実の情報システムの運用におけるオペレータの業務量および運用能力と、オペレータの運用実績との間の回帰関係を示す回帰モデルを生成し、新規システムの運用コスト見積にその回帰モデルを適用する。これにより、新規システムの運用コスト見積に、現実のシステム運用実績を反映し、見積もりの精度向上を実現する。

なお、回帰分析の前提となるオペレータの業務量の数値化は、以下の本発明者の着想にもとづく。すなわち、オペレータ業務は、予め定められた業務フローで規定されており、誰がオペレータの場合でも同じやり方で同じ結果が返るという特徴を持つ。例えば、オペレータでなく後述するシステム担当者の場合、システムの障害に対して個人毎に異なるアプローチをとることがある。具体例として複数のサーバで作業する際に、１台ずつログインして作業する者もいれば、リモートシェルで対応する者もいる。このように各システム担当者の業務のやり方が異なるため時間を計っても無意味であり、複数のシステム担当者に亘って共通の基準で業務量を数値化することは困難である。しかしオペレータ業務は誰がオペレータでも同じ作業になるという特徴があるため、複数のオペレータに亘って共通の基準で業務量を数値化することができる。したがって、複数のオペレータが運用に携わる複数の情報システムの運用実績にもとづく回帰分析が可能になる。

図１は、情報システムの運用に関わる装置群を示す。監視対象システム１０で総称される監視対象システム１０ａ、監視対象システム１０ｂ、監視対象システム１０ｃ、監視対象システム１０ｄ、監視対象システム１０ｅのそれぞれは、企業等の様々な業務を支援する情報処理を実行するサーバ群である。例えば、１つの監視対象システム１０は、１台のサーバで実現されるものから、数百台のサーバが連携するものまで含む。

運用監視装置１２で総称される運用監視装置１２ａ、運用監視装置１２ｂは、公知の運用監視ソフトウェアがインストールされた情報処理装置である。運用監視装置１２ａは、監視対象システム１０ａ、監視対象システム１０ｂ、監視対象システム１０ｃに対する運用監視処理を実行し、運用監視装置１２ｂは、監視対象システム１０ｄ、監視対象システム１０ｅに対する運用監視処理を実行する。

運用監視装置１２が実行する運用監視処理は、監視対象システム１０の動作状態監視、監視対象システム１０に発生したエラーの検出、サービスデスク装置１４へのエラー通知を含む。また、監視対象システム１０に対するジョブの設定とジョブの実行制御、監視対象システム１０へのコマンド送信を含む。なお実施の形態におけるエラーは、各種の障害や動作停止、動作異常、正常状態からの逸脱等を含む。運用監視装置１２は、複数の監視対象システム１０のそれぞれに関するシステム定義情報（後述の図３（ａ））、エラーメッセージログ（後述の図３（ｂ））を保持する。

サービスデスク装置１４は、公知のサービスデスクソフトウェアがインストールされた情報処理装置である。サービスデスク装置１４は、運用監視装置１２で検出されたエラーに対応すべきオペレータの業務を支援する。オペレータは、例えば、システム運用のアウトソーシングサービスを提供するＳＩｅｒの運用部門の担当者であり、オペレータ端末１６を操作する。

またサービスデスク装置１４は、オペレータに関する種々の情報を保持する。例えば、オペレータの基本的な属性を示すオペレータ基本情報（後述の図４（ａ））、オペレータによる作業実績を示す作業実績情報（後述の図４（ｂ））、オペレータによる運用監視装置１２への種々の登録内容を示す定義申請情報（後述の図４（ｃ））を保持する。

監視対象システム１０でエラーが発生すると、監視対象システム１０はエラーメッセージを運用監視装置１２へ送信し、または、運用監視装置１２が自律的にエラーの発生を検出する。運用監視装置１２は、エラーメッセージをサービスデスク装置１４へ送信する。サービスデスク装置１４は、予め定められた切り分け条件にしたがって、エラー内容をオペレータ端末１６へ通知し、表示させる。このとき、ナビゲーションメッセージとして、エラー内容に応じたオペレータが実施すべき作業内容や、システム担当者（エラーの解析やバグの修正を実施すべき開発者等）の連絡先もオペレータ端末１６へ通知する。

オペレータは、オペレータ端末１６に表示されたエラー内容に応じて、影響範囲を識別し、システム担当者へのコール（電話連絡）を行い、適宜障害復旧作業を実施する。サービスデスク装置１４は、エラーメッセージを逐次記録する。また、オペレータの作業内容や、エラー対応に要した時間、エラー対応におけるミスの有無等をオペレータ端末１６から取得して逐次記録する。

管理者端末１８は、運用部門の管理者により操作される情報端末である。後述のオペレータ評価の一部は、管理者により入力され、管理者端末１８から分析装置２０へ登録される。

分析装置２０は、ＬＡＮ・ＷＡＮ・インターネット等を含む通信網を介して運用監視装置１２、サービスデスク装置１４、オペレータ端末１６、管理者端末１８と接続される。分析装置２０は、運用監視装置１２およびサービスデスク装置１４から取得したデータにもとづいて、（１）監視対象システム１０に対する運用実績の可視化処理、（２）運用コストの見積支援処理を実行する。

図２は、図１の分析装置２０の機能構成を示すブロック図である。分析装置２０は、各種データ処理を実行する制御部５０と、制御部５０により参照または更新されるデータの記憶領域であるデータ保持部３０を備える。また図２には不図示だが、分析装置２０は、所定の通信プロトコルにしたがい通信網２２を介して外部装置と通信する通信部と、キーボードやマウス等の入力装置を介した操作入力を検出する操作検出部と、ディスプレイ２６の表示内容を制御する表示制御部を備える。図２の各機能ブロックは、通信部を介して外部装置とデータを送受し、操作検出部を介して操作者による入力情報を受け付け、表示制御部を介してディスプレイに画像を表示させる。

本明細書のブロック図で示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵやメモリをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。

例えば、制御部５０の各機能ブロックに対応するソフトウェアモジュールを備える分析アプリケーションが分析装置２０のストレージへインストールされてもよい。分析装置２０のＣＰＵは、各ソフトウェアモジュールをメインメモリへ読み出して実行することにより、制御部５０の各機能ブロックの機能が発揮されてもよい。また、データ保持部３０の各機能ブロックは、ストレージやメモリ等の記憶装置がデータを記憶することにより実現されてもよい。

データ保持部３０は、実システム情報保持部３２、運用実績保持部３４、運用効率情報保持部３６、評価基準保持部３８、オペレータ評価保持部４０、ＳＬＡ情報保持部４１、サービスレベル保持部４２、回帰モデル保持部４４、新規システム情報保持部４６、予測結果保持部４８を含む。

実システム情報保持部３２は、現在運用中の複数の監視対象システム１０（「実システム」とも呼ぶ。）のそれぞれについて、各システムに関する属性情報であるシステム定義情報を保持する。また、各システムで発生したエラーを示すエラーメッセージの蓄積情報であるエラーメッセージログを保持する。図３（ａ）はシステム定義情報を示し、図３（ｂ）はエラーメッセージログを示す。図３（ａ）の監視対象サーバＩＤ、サーバ設定情報、監視内容は、１つの監視対象システム１０内のサーバ単位に設定される。

図２に戻り、運用実績保持部３４は、現在運用実務に携わっている複数のオペレータのそれぞれについて、各オペレータに関する属性情報であるオペレータ基本情報を保持する。また、各オペレータによるエラー対応作業の実績を示す作業実績情報と、各オペレータによる定義申請作業の実績を示す定義申請情報を保持する。図４（ａ）はオペレータ基本情報を示し、図４（ｂ）は作業実績情報を示し、図４（ｃ）は定義申請情報を示す。

図４（ｂ）の作業実績情報の発生時刻は、監視対象システム１０で発生したエラーを監視対象システム１０または運用監視装置１２が検出した日時であってもよい。また対応時刻は、オペレータからシステム担当者へのコール、例えば電話等の所定の連絡手段を用いた障害発生の連絡が完了した日時であってもよい。また対応記録におけるコールミスは、適切なコールができなかったことを意味し、連絡先の間違い、連絡内容の間違い、予め定められた時間内に連絡ができなかったこと等を含む。

定義申請情報の「定義」は、監視対象システム１０の運用において、監視対象システム１０や運用監視装置１２に対して指示する１単位の情報を意味する。「定義申請」は、監視対象システム１０の運用のための各種情報を監視対象システム１０や運用監視装置１２に対して登録することを意味する。例えば、監視対象システム１０に実行させるべきジョブを運用監視装置１２へ新規登録し、また変更することを含む。また、監視対象システム１０の監視項目を新規登録し、また変更することを含む。また、監視対象システム１０の各サーバの設定変更を含む。オペレータは、オペレータ端末１６から、監視対象システム１０や運用監視装置１２へアクセスし、定義申請の作業を実施する。

図２に戻り、運用効率情報保持部３６は、後述の運用効率評価部６２により生成された運用効率情報（図５）を保持する。評価基準保持部３８は、オペレータの運用実績を評価する際の基準を示すデータを保持する。例えば、オペレータによる作業実績にもとづき導出された値と、複数段階の評価値との対応関係を保持する。オペレータ評価保持部４０は、後述のオペレータ評価部６４により生成されたオペレータ評価情報（図６）を保持する。

ＳＬＡ情報保持部４１は、複数の監視対象システム１０のそれぞれで定められたＳＬＡ情報を保持する。例えば、平均コール時間やコールミス回数の上限等、運用状態の目標を示す値を保持する。サービスレベル保持部４２は、後述のサービスレベル評価部６６により生成されたサービスレベル評価情報（図７）を保持する。

回帰モデル保持部４４は、後述の回帰分析部７４により生成された回帰モデル、すなわち回帰係数および回帰式を示すデータを保持する。新規システム情報保持部４６は、新規システムの運用コスト見積のための基礎情報となる新規システムに関する属性情報を保持する。例えば、新規システムについて想定される運用規模、仮に定められたオペレータの運用能力（例えば人数やスキルレベル）を保持する。また、新規システムで予定されるＳＬＡ情報（例えば平均コール時間、コールミス割合）を保持する。予測結果保持部４８は、新規システムについて回帰モデルによる予測結果・推定結果を示す情報を保持する。

制御部５０は、実システム情報取得部５２、運用実績取得部５４、新規システム情報取得部５６、運用状況可視化部６０、予測部７０を含む。実システム情報取得部５２は、複数の監視対象システム１０のそれぞれに関するシステム定義情報とエラーメッセージログを運用監視装置１２ａおよび運用監視装置１２ｂから取得して実システム情報保持部３２へ格納する。運用実績取得部５４は、複数人のオペレータのそれぞれに関するオペレータ基本情報、作業実績情報、定義申請情報をサービスデスク装置１４から取得して運用実績保持部３４へ格納する。

新規システム情報取得部５６は、入力装置２４から入力された新規システムの属性情報を取得し、また、オペレータや運用部門管理者が入力してオペレータ端末１６や管理者端末１８から送信された新規システムの属性情報を取得する。新規システム情報取得部５６は、新規システムの属性情報を新規システム情報保持部４６へ格納する。

運用状況可視化部６０は、監視対象システム１０に対する運用実績の可視化処理を実行する。運用状況可視化部６０は、運用効率評価部６２、オペレータ評価部６４、サービスレベル評価部６６、分析結果表示部６８を含む。

運用効率評価部６２は、実システム情報保持部３２に格納されたデータと、運用実績保持部３４に格納されたデータの両方を参照して、複数の監視対象システム１０のそれぞれに対する運用の効率性を示す運用効率情報を生成する。運用効率情報は、運用コストの単位量あたりの運用実績を示す情報とも言え、運用コスト効率情報とも言える。運用効率評価部６２は、生成した運用効率情報を運用効率情報保持部３６へ格納する。

図５は運用効率情報の構成を示す。図５の情報項目欄の値は、運用効率情報保持部３６に格納される運用効率情報の項目を示している。図５の情報ソース欄の値は、運用効率評価部６２が、各項目へマッピングする元情報を示し、また、各項目の情報を生成するためのアルゴリズムを示している。

運用効率評価部６２は、実システム情報保持部３２に格納されたシステム定義情報の監視対象システムＩＤを、運用効率情報のシステムＩＤとして識別する。以下では１つの監視対象システム１０に割当てられたＩＤを特定システムＩＤと呼び、１つの監視対象システム１０についての運用効率情報の設定方法を説明する。

運用効率評価部６２は、システム定義情報において特定システムＩＤに対応付けられた監視対象サーバＩＤの個数をカウントし、その個数を運用効率情報の対象サーバ数として識別する。また、運用実績保持部３４に格納されたオペレータ基本情報において特定システムＩＤに対応付けられたオペレータＩＤの個数をカウントし、その個数を運用効率情報のオペレータ数として識別する。また、対象サーバ数をオペレータ数で除算した結果を、運用効率情報の１人あたりサーバ数として識別する。

また運用効率評価部６２は、実システム情報保持部３２に格納されたエラーメッセージログ（運用実績保持部３４に格納された作業実績情報でもよい）において特定システムＩＤに対応付けられたメッセージＩＤの個数をカウントする。そして、その個数をオペレータ数で除算した結果を、運用効率情報の１人あたりメッセージ数として識別する。また、運用実績保持部３４に格納された定義申請情報において特定システムＩＤに対応付けられた申請ＩＤの個数（ただし対応ステータスが「済」のレコードに限る）をカウントする。そして、その個数をオペレータ数で除算した結果を、運用効率情報の１人あたり定義登録数として識別する。

以下では特に言及しないが、運用状況可視化部６０および予測部７０の処理では、エラーメッセージログ、作業実績情報、定義申請情報のレコードのうち、所定の単位期間内（例えば一箇月）に記録されたレコードが集計対象となる。したがって、後述の平均コール時間、コールミス回数、定義登録期限超過数等は、直近の一箇月の値である。

ここで、監視対象システム１０におけるサーバの台数やメッセージの総数（エラー発生数とも言える）が大きくなるほど、監視対象システム１０の運用に要する作業量は増大する。したがって、これらの値は監視対象システム１０の運用に要する作業量、すなわち運用規模を示す指標値と言える。１人あたりサーバ数、１人あたりメッセージ数（すなわち１人あたりエラー対応数）、１人あたり定義登録数は、１人のオペレータのコストでまかなわれる運用作業量と言え、監視対象システム１０の運用効率を示す指標値と言える。また、１人のオペレータの業務量を示す指標値とも言え、１人のオペレータの繁忙度合いを示す指標値とも言える。

図２に戻り、オペレータ評価部６４は、運用実績保持部３４に格納されたデータを参照して、複数のオペレータのそれぞれに関するオペレータ評価情報を生成する。オペレータ評価情報は、各オペレータによるオペレーション実績にもとづいて各オペレータの運用能力を可視化した情報と言える。オペレータ評価部６４は、生成したオペレータ評価情報をオペレータ評価保持部４０へ格納する。

図６はオペレータ評価情報の構成を示す。図６の情報項目欄の値は、オペレータ評価保持部４０に格納されるオペレータ評価情報の項目を示している。図６の情報ソース欄の値は、オペレータ評価部６４が、各項目の情報にマッピングする元情報を示し、また、各項目の情報を生成するためのアルゴリズムを示している。

例えば、オペレータ評価部６４は、運用実績保持部３４に格納されたオペレータ基本情報のオペレータＩＤを、オペレータ評価情報のオペレータＩＤとして識別する。以下では１人のオペレータに割当てられたオペレータＩＤを特定オペレータＩＤと呼び、１人のオペレータについてのオペレータ評価情報の設定方法を説明する。

オペレータ評価部６４は、運用実績保持部３４に格納された作業実績情報のレコードのうち特定オペレータＩＤに対応付けられたレコード（「特定レコード」と呼ぶ。）を識別する。そして、各特定レコードに記録された発生時刻から対応時刻までの対応所要時間を合計し、その合計時間を特定レコードの数（特定オペレータＩＤに対応付けられたメッセージＩＤの個数とも言える）で除算した結果を平均コール時間として算出する。また、その平均コール時間と対応付けられた評価値を評価基準保持部３８から取得する。

またオペレータ評価部６４は、対応記録にミスが記録された特定レコード数を識別し、そのレコード数をオペレータ評価情報のコールミス件数として識別する。また、ミスのないコール件数（特定レコード総数からコールミス件数を減算した値）を特定レコード総数で除算した結果を、オペレータ評価情報の正確なコール割合として識別する。そして、その割合と対応付けられた評価値を評価基準保持部３８から取得する。

またオペレータ評価部６４は、運用実績保持部３４に格納された定義申請情報のレコードのうち特定オペレータＩＤに対応付けられたレコード（「特定レコード」と呼ぶ。）を識別する。そして、その特定レコード数をオペレータ評価情報の定義登録数として識別する。また、特定レコードのうち対応期限超過有が記録されたレコード数をオペレータ評価情報の期限超過数として識別する。また、定義登録数または期限超過数、もしくはそれらの組み合わせと対応付けられた評価値を評価基準保持部３８から取得する。

またオペレータ評価部６４は、管理者端末１８から送信された、各オペレータについての開発部門との適切な協業の評価値、業務改善力の評価値、評価者コメントを取得し、それぞれをオペレータ評価保持部４０へ記録する。これらのデータは、ローカルの入力装置２４から入力されてもよいことはもちろんである。

またオペレータ評価部６４は、コールの迅速性評価値、コールの正確性評価値、定義登録数評価値、開発部門との適切な協業の評価値、業務改善力の評価値の合計を、オペレータ評価情報の総合得点として識別する。各項目の評価値が５点満点の場合、総合得点は２５点満点となる。オペレータ評価部６４は、総合得点を評価項目数（例えば５）で除算した結果である平均評価値をオペレータ評価情報のスキルとして識別する。

またオペレータ評価部６４は、複数のオペレータそれぞれの総合得点を比較し、各オペレータのランキングを識別する。また、所定の記憶領域に格納された、総合得点とランキングの組み合わせと、オペレータに割当てるべき架空の称号との対応関係を参照して、各オペレータの総合得点とランキングに応じて各オペレータの称号を識別する。称号は、運用実務能力の相対的な高低を示す呼び名とする。予め定められた仮想世界における身分や階級を示す呼び名であってもよい。例えばランクが低い方から「タマゴ」「見習い」「職人」「達人」「英雄」等の称号が定められてもよい。

オペレータ評価保持部４０は、各オペレータの過去の評価情報を評価日時に対応付けて蓄積する。オペレータ評価部６４は、前回の評価情報と今回の評価情報の差分を識別し、その差分を示すデータを前回との差分としてオペレータ評価情報へ記録する。評価情報の差分は、平均コール時間や定義登録数等の作業実績の変化量や、評価値やランキングの変化量であってもよい。

図２に戻り、サービスレベル評価部６６は、実システム情報保持部３２、運用実績保持部３４、オペレータ評価保持部４０、ＳＬＡ情報保持部４１のデータを参照して、複数の監視対象システム１０それぞれのサービスレベル情報を生成する。サービスレベル情報は、各監視対象システム１０に対するオペレーション実績にもとづいてシステムを単位としたサービスレベルを評価し、可視化した情報と言える。基本的には、オペレータ評価情報をシステム単位に集計し、ＳＬＡの観点から評価したものである。サービスレベル評価部６６は、生成したサービスレベル情報をサービスレベル保持部４２へ格納する。

図７はサービスレベル情報の構成を示す。図７の情報項目欄の値は、サービスレベル保持部４２に格納されるサービスレベル情報の項目を示している。図７の情報ソース欄の値は、サービスレベル評価部６６が、各項目へマッピングする元情報を示し、また、各項目の情報を生成するためのアルゴリズムを示している。

サービスレベル評価部６６は、実システム情報保持部３２に格納されたシステム定義情報の監視対象システムＩＤを、サービスレベル情報のシステムＩＤとして識別する。以下では、１つの監視対象システム１０に割当てられたＩＤを特定システムＩＤと呼び、１つの監視対象システム１０についてのサービスレベル情報の設定方法を説明する。

サービスレベル評価部６６は、運用実績保持部３４に格納されたオペレータ基本情報を参照して、特定システムＩＤに対応付けられたオペレータのＩＤ（「特定オペレータＩＤ」と呼ぶ。）を識別する。１つの監視対象システム１０の運用を複数のオペレータが担当する場合、複数の特定オペレータＩＤを識別する。サービスレベル評価部６６は、オペレータ評価保持部４０に格納されたオペレータ評価情報のうち特定オペレータＩＤに対応付けられた複数のオペレータ評価情報を識別し、各オペレータの平均コール時間の平均値を、コール実績時間として識別する。また、そのコール実績時間を、ＳＬＡ情報保持部４１に格納されたコール目標時間と比較し、目標の達成有無を判定する。

またサービスレベル評価部６６は、特定オペレータＩＤに対応付けられた複数のオペレータ評価情報に記録されたコールミス回数の合計を、コールの全回数で除算した結果をオペレーションミス発生率として識別する。コールの全回数は、実システム情報保持部３２に格納されたエラーメッセージログにおける特定システムＩＤに対応付けられたレコード数をカウントしてもよく、運用実績保持部３４に格納された作業実績情報における特定システムＩＤに対応付けられたレコード数をカウントしてもよい。またサービスレベル評価部６６は、オペレーションミス発生率を、ＳＬＡ情報保持部４１に格納されたオペレーションミス発生率の目標値と比較し、目標の達成有無を判定する。

またサービスレベル評価部６６は、特定オペレータＩＤに対応付けられた複数のオペレータ評価情報に記録された定義登録数の合計を定義登録実績として識別する。また、その定義登録実績を、ＳＬＡ情報保持部４１に格納された定義登録の目標値と比較し、目標の達成有無を判定する。

図２に戻り、分析結果表示部６８は、運用効率情報保持部３６に格納された運用効率情報を配置した運用効率情報画面を生成する。また、オペレータ評価保持部４０に保持されたオペレータ評価情報を配置したオペレータ評価情報画面を生成し、サービスレベル保持部４２に保持されたサービスレベル情報を配置したサービスレベル情報画面を生成する。分析結果表示部６８は、オペレータ端末１６、管理者端末１８から分析情報の提供要求を受け付けると、オペレータや管理者が指定した画面のデータをオペレータ端末１６、管理者端末１８へ送信して表示させる。また、入力装置２４からの表示要求に応じて、各画面をディスプレイ２６に表示させる。

分析結果表示部６８は、ウェブサーバとして機能してもよく、運用効率情報画面、オペレータ評価情報画面、サービスレベル情報画面それぞれのウェブページをオペレータ端末１６、管理者端末１８へ送信してもよい。

図８は運用効率情報画面８０を示す。図８のオペレーション規模は、運用効率情報のオペレータ数を示している。また図８で示すように、分析結果表示部６８は、運用効率情報保持部３６に保持された過去から現在まで複数回生成された運用効率情報にしたがって、運用効率の推移を示すグラフを運用効率情報画面８０に設定する。図８では、運用規模（ここではサーバ数）、オペレーション規模（ここではオペレータ数）、オペレーション効率（ここでは１人あたりサーバ数）の推移を示すグラフを設定している。

変形例として、監視対象システム１０のメッセージ数や定義登録数を運用規模としてもよく、これらとサーバ数との組み合わせにより特定される指標値を運用規模としてもよい。また、監視対象システム１０の運用を担当する１人以上のオペレータの人件費をオペレーション規模としてもよい。

図９はオペレータ評価情報画面８２を示す。図９の平均オペレーションレベルは、オペレータ評価情報に記録されたスキルの値を示している。また図９で示すように、分析結果表示部６８は、オペレータ評価保持部４０に保持された複数項目の評価値（ここでは５点満点）を示すレーダチャートをオペレータ評価情報画面８２に設定する。

図１０はサービスレベル情報画面８４を示す。図１０で示すように、分析結果表示部６８は、ＳＬＡ遵守状況エリア８６に、複数の目標それぞれの達成有無を表示させる。またＳＬＡ未達成状況詳細エリア８８に、目標が未達成の項目について、その目標値と実績値とを対応付けて表示させる。

図２に戻り、予測部７０は回帰分析による運用コストの見積支援処理を実行する。予測部７０は、変数取得部７２、回帰分析部７４、推定部７６、予測結果表示部７８を含む。

変数取得部７２は、現実のシステムの運用に要するオペレータの業務量を示す情報と、オペレータの運用能力を示す情報と、現実のシステムに対するオペレータによる運用実績を示す情報をそれぞれ取得する。具体的には、オペレータの業務量を示す情報として、監視対象システム１０に配置された監視対象サーバ数、監視対象システム１０に関するエラーメッセージ数（監視対象システム１０で発生し、運用監視装置１２が検出したエラー数とも言える）、定義登録数を取得する。また、オペレータの運用能力を示す情報として、監視対象システム１０の運用に携わるオペレータ人数、オペレータのスキル値を取得する。また、オペレータによる運用実績を示す情報として、平均コール時間、コールミス回数、定義登録期限超過数を取得する。

回帰分析部７４は、オペレータの業務量を示す情報と、オペレータの運用能力を示す情報にもとづいて説明変数を識別し、オペレータによる運用実績を示す情報にもとづいて目的変数を識別する。そして説明変数と目的変数との間の回帰係数を公知の回帰分析手法により導出する。回帰分析部７４は、導出した回帰係数および回帰式を示すデータを回帰モデル保持部４４へ格納する。

以下では３種類の回帰分析を提案し、それぞれを第１回帰分析、第２回帰分析、第３回帰分析と呼ぶ。図１１（ａ）は第１回帰分析および第２回帰分析に用いる各システムの情報を示し、図１１（ｂ）は第３回帰分析に用いる各システムの情報を示す。また図１２（ａ）は第１回帰分析の結果を示し、図１２（ｂ）は第２回帰分析の結果を示し、図１２（ｃ）は第３回帰分析の結果を示す。

図１１（ａ）を参照して第１回帰分析について説明する。
変数取得部７２は、各監視対象システム１０における監視対象サーバ数とメッセージ数（すなわちエラー発生数）を実システム情報保持部３２のシステム定義情報とエラーメッセージログからから取得する。また、各監視対象システム１０の運用に携わるオペレータ数を運用実績保持部３４のオペレータ基本情報から取得する。また、各監視対象システム１０の運用に携わる複数のオペレータそれぞれのスキル値と平均コール時間をオペレータ評価保持部４０から取得する。特に断らない場合、変数取得部７２は、運用状況可視化部６０と同様の方法でデータ保持部３０から必要な情報を取得してもよい。なお以降の例では、オペレータのスキル値を１０段階（１０点満点）に調整している。

回帰分析部７４は、監視対象サーバ数とメッセージ数（すなわちエラー発生数）を積算した結果を運用規模（コール）として識別する。監視対象サーバ数とメッセージ数は監視対象システム１０における複数のオペレータの業務量全体と正相関する。したがって、運用規模（コール）もまた監視対象システム１０における複数のオペレータの業務量全体と正相関するものであり、運用規模（コール）は業務量の多さを示す指標値である。すなわち回帰分析部７４は、監視対象システム１０における監視対象サーバ数が多いほど、または、監視対象システム１０で発生したエラー数が多いほど、オペレータの業務量を大きく判定する。

回帰分析部７４は、運用規模（コール）を、（オペレータ数×複数のオペレータのスキル平均値）で除算した結果を説明変数（ここでは「運用能力基礎数値（コール）」と呼ぶ。）として識別する。運用能力基礎数値（コール）は、オペレータ１人あたりの業務量の多さであり、各オペレータの業務の繁忙度合いを示す指標値である。監視対象システム１０における監視対象サーバ数が多いほど、監視対象システム１０で発生したエラー数が多いほど、オペレータ数が少ないほど、各オペレータのスキル値が低いほど、運用能力基礎数値（コール）は大きく算出される。また回帰分析部７４は、複数のオペレータの平均コール時間を平均し、その平均値を目的変数として識別する。

図１２（ａ）で示すように、回帰分析部７４は、複数の監視対象システム１０について識別した運用能力基礎数値（コール）と平均コール時間の間の回帰係数を回帰分析により導出する。図１２（ａ）では単回帰分析により導出した回帰式を示し、傾き「０．７８９７」、切片「１０．６８３」の回帰係数を導出したことを示している。

図１１（ａ）を参照して、第２回帰分析について説明する。第２回帰分析は、目的変数だけが第１回帰分析と異なり、第１回帰分析と重複する説明は省略する。変数取得部７２は、各監視対象システム１０の運用に携わる複数のオペレータそれぞれのコールミス回数をオペレータ評価保持部４０の作業実績情報から取得する。回帰分析部７４は、複数のオペレータのコールミス回数を平均し、その平均値を目的変数として識別する。

図１２（ｂ）で示すように、回帰分析部７４は、複数の監視対象システム１０について識別した運用能力基礎数値（コール）と平均コールミス回数の間の回帰係数を回帰分析により導出する。図１２（ｂ）では単回帰分析により導出した回帰式を示し、傾き「０．０３６７」、切片「−３．２７８」の回帰係数を導出したことを示している。

図１１（ｂ）を参照して、第３回帰分析について説明する。第３回帰分析は、説明変数と目的変数の両方が第１回帰分析と異なり、第１回帰分析と重複する説明は省略する。

変数取得部７２は、各監視対象システム１０における定義登録数を運用実績保持部３４の定義申請情報から取得し、運用規模（定義登録）として識別する。例えば、定義申請情報のレコードのうち各監視対象システム１０のＩＤが記録されたレコード数を定義登録数として取得してもよい。定義登録数は監視対象システム１０における複数のオペレータの業務量全体と正相関する。したがって運用規模（コール）と同様に運用規模（定義登録）も、監視対象システム１０における複数のオペレータの業務量全体と正相関するものであり、業務量の多さを示す指標値である。

変数取得部７２は、各監視対象システム１０の運用に携わる複数のオペレータそれぞれの定義登録期限超過数を運用実績保持部３４から取得する。例えば、定義申請情報のレコードのうち対応期限超過有りのレコード数をカウントしてもよい。回帰分析部７４は、運用規模（定義登録）を、（オペレータ数×複数のオペレータのスキルの平均値）で除算した結果を説明変数（ここでは「運用能力基礎数値（定義登録）」と呼ぶ。）として識別する。また回帰分析部７４は、複数のオペレータの定義登録期限超過数の平均値を目的変数として識別する。

図１２（ｃ）で示すように、回帰分析部７４は、複数の監視対象システム１０について識別した運用能力基礎数値（定義登録）と定義登録期限超過数の平均値の間の回帰係数を回帰分析により導出する。図１２（ｃ）では単回帰分析により導出した回帰式を示し、傾き「０．１５６４」、切片「−０．９９３」の回帰係数を導出したことを示している。

図２に戻り、推定部７６は、回帰分析部７４が生成した回帰モデルを使用して、予測対象システムの運用に関する予測処理を実行する。推定部７６は、予測処理の結果を示すデータを予測結果保持部４８へ格納する。以下、第１予測処理と第２予測処理を説明する。実施の形態では、予測対象システムを新規に運用が開始される新規システムとし、新規システムの運用コストの見積を支援する処理を実行する。

第１予測処理の説明：
推定部７６は、第１予測処理として、新規システムで想定されるオペレータの業務量と、仮に定められたオペレータの運用能力と、回帰モデル保持部４４に格納された回帰係数にしたがって、新規システムに対するオペレータによる運用状態を推定する。推定対象とする運用状態は、システム運用のサービスレベルを示すものであり、具体的にはオペレータによるコール時間やコールミス回数である。

図１３は、予測処理における入力値と予測結果の例を示す。同図では、網掛けで示す領域の値が入力値を示し、下線を付した値が予測結果を示している。

図１３（ａ）を参照して第１予測処理の例を説明する。推定部７６は、新規システム情報保持部４６に予め格納された、新規システムで想定されるオペレータの業務量を示す指標値であり、この例では監視対象サーバ数とメッセージ数の積である運用規模（コール）の想定値を取得する。新規システム情報保持部４６には、監視対象サーバ数とメッセージ数の想定値が格納されてもよく、推定部７６は、これらの想定値を積算し、その結果を運用規模（コール）として識別してもよい。また推定部７６は、新規システム情報保持部４６に予め格納されたオペレータの予定人数および予定スキルを取得する。

なお、これらの想定値や予定値は、オペレータ端末１６や管理者端末１８から通信網２２を介して分析装置２０へ入力されてもよく、入力装置２４から分析装置２０へ入力されてもよい。

推定部７６は、運用規模（コール）の想定値を、オペレータの予定人数と予定スキルの積で除算し、運用能力基礎数値（コール）を算出する。そして、その値を第１回帰分析で導出された回帰モデル（例えば図１２（ａ）の回帰式のｘ）へ入力することにより、コール時間（例えば図１２（ａ）の回帰式のｙ）を算出する。このコール時間は、新規システムにおいてエラーメッセージが出力された場合に、オペレータがシステム担当者へコールを完了するまでに要する平均コール時間の推定値である。

また推定部７６は、運用能力基礎数値（コール）を第２回帰分析で導出された回帰モデル（例えば図１２（ｂ）の回帰式のｘ）へ入力することにより、コールミス回数（例えば図１２（ｂ）の回帰式のｙ）を算出する。このコールミス回数は、所定の単位期間（例えば一箇月）において新規システムでエラーが発生した場合に、１人のオペレータがコールミスを行う回数の推定値である。推定部７６は、予測処理の入力値と予測結果を含む情報（例えば図１３（ａ）の情報）を予測結果保持部４８へ格納する。

次に図１３（ｂ）を参照して第１予測処理の例を説明する。推定部７６は、新規システム情報保持部４６に予め格納された、新規システムで想定されるオペレータの業務量を示す指標値であり、この例では所定の運用期間（例えば一箇月）においてオペレータが実施すべき定義登録数を示す運用規模（定義登録）の想定値を取得する。また、新規システム情報保持部４６に予め格納されたオペレータの予定人数および予定スキルを取得する。

推定部７６は、運用規模（定義登録）の想定値を、オペレータの予定数と予定スキルの積で除算し、運用能力基礎数値（定義登録）を算出する。そして、その値を第３回帰分析で導出された回帰モデル（例えば図１２（ｃ）の回帰式のｘ）へ入力することにより、定義登録期限超過数（例えば図１２（ｃ）の回帰式のｙ）を算出する。この定義登録期限超過数は、所定の単位期間（例えば一箇月）において１人のオペレータが定義登録作業の期限を超過してしまう回数の推定値である。推定部７６は、予測処理の入力値と予測結果を含む情報（例えば図１３（ｂ）の情報）を予測結果保持部４８へ格納する。

第２予測処理の説明：
推定部７６は、第２予測処理として、新規システムで想定されるオペレータの業務量と、新規システムに要求されるオペレータによる運用状態と、回帰モデル保持部４４に格納された回帰係数にしたがって、新規システムで必要となるオペレータの運用能力を推定する。新規システムに要求されるオペレータの運用状態は、新規システムに要求されるサービスレベルとも言え、ＳＬＡで定められた情報であってもよい。具体的には、オペレータによる平均コール時間やコールミス回数の許容値である。また、推定対象とするオペレータの運用能力は、具体的にはオペレータの人数および／またはオペレータのスキルである。

図１３（ｃ）を参照して第２予測処理の例を説明する。ここでは第１回帰分析で導出された回帰モデル（具体的には図１２（ａ）の回帰式）を使用する例を示すが、第２回帰分析または第３回帰分析で導出された回帰モデルを使用して第２予測処理を実行してもよいことはもちろんである。

推定部７６は、新規システム情報保持部４６に予め格納された、運用規模（コール）の想定値を取得する。この例ではオペレータの必要スキル（予定スキル）も格納されていることとし、推定部７６はオペレータの必要スキルも取得する。さらに推定部７６は、新規システム情報保持部４６に予め格納された新規システムに要求されるサービスレベル、ここでは平均コール時間の要求値を取得する。

推定部７６は、第１回帰分析で導出された回帰モデル（例えば図１２（ａ）の回帰式のｙ）へ平均コール時間の要求値を入力することにより、運用能力基礎数値（コール）の必要値（例えば図１２（ａ）の回帰式のｘ）を算出する。この運用能力基礎数値（コール）は、運用規模（コール）を、オペレータの必要人数と必要スキルの積で除算したものであるため、推定部７６は、算出した運用能力基礎数値（コール）と所与の必要スキルによりオペレータの必要人数を算出する。

推定部７６は、所定の記憶領域に格納されたスキル単価であり、所定の単位期間（例えば一箇月）におけるスキル毎のオペレータの人件費を規定した情報にしたがって、新規システムの運用に携わるオペレータの人件費を算出する。図１３（ｃ）の例では、スキル５のオペレータが７．５人（８人としてもよい）であるため、オペレータの人件費を７５０と算出している。このオペレータの人件費は、所定の単位期間における新規システムの運用コストの推定値と言える。推定部７６は、予測処理の入力値と予測結果を含む情報（例えば図１３（ｃ）の情報）を予測結果保持部４８へ格納する。

図２に戻り、予測結果表示部７８は、推定部７６による予測処理の結果を運用の管理者、オペレータ、外部装置へ提供する。具体的には、予測結果表示部７８は、予測結果保持部４８に格納された新規システムの運用に関する予測結果情報を配置した予測結果画面を生成し、この画面データをオペレータ端末１６、管理者端末１８へ送信し、またディスプレイ２６に表示させる。

予測結果表示部７８は、新規システムの運用に関する想定値（予定値）と予測結果の両方を含む情報であり、例えば図１３（ａ）（ｂ）（ｃ）それぞれの情報を示す予測結果画面を生成してもよい。予測結果表示部７８は、ウェブサーバとして機能してもよく、予測結果画面を示すウェブページをオペレータ端末１６、管理者端末１８へ送信し、またディスプレイ２６に表示させてもよい。

なお上記の例では、オペレータの必要スキルが事前に定められていることとしたが、これに代えてオペレータの必要人数（予定人数）が事前に定められてもよい。この場合、推定部７６は、オペレータの必要スキル、すなわち複数のオペレータのスキルの平均値を推定してもよい。また推定部７６は、オペレータの必要人数と必要スキルが不定の場合に、運用能力基礎数値（コール）を推定結果として記録してもよい。運用能力基礎数値の推定値を、必要なオペレータの運用能力として運用部門の担当者へ提示することにより、その運用基礎数値を満たすオペレータ数とスキルを担当者に検討させてもよい。

以上の構成による分析装置２０の動作を以下説明する。
先の分析処理から所定期間（例えば一箇月）が経過したことを検出すると、実システム情報取得部５２は、監視対象システム１０に対する運用監視処理を実行中の運用監視装置１２から、運用監視装置１２が管理するシステム定義情報とエラーメッセージログを取得する。運用実績取得部５４は、運用監視装置１２と連携してオペレータ支援処理を実行中のサービスデスク装置１４から、サービスデスク装置１４が管理するオペレータ基本情報、作業実績情報、定義申請情報を取得する。運用効率評価部６２、オペレータ評価部６４、サービスレベル評価部６６は、運用監視装置１２で管理された情報と、サービスデスク装置１４で管理された情報にもとづいて、運用効率情報、オペレータ評価情報、サービスレベル情報を生成する。

分析結果表示部６８は、管理者端末１８等の外部装置から特定のシステムＩＤを指定した運用効率情報画面の提供要求を受け付けると、図８で示した運用効率情報画面を外部装置へ送信し、外部装置で表示させる。また分析結果表示部６８は、オペレータ端末１６や管理者端末１８等の外部装置から特定のオペレータＩＤを指定したオペレータ評価情報の提供要求を受け付けると、図９で示したオペレータ評価情報画面を外部装置へ送信し、外部装置で表示させる。また分析結果表示部６８は、管理者端末１８等の外部装置から特定のシステムＩＤを指定したサービスレベル情報画面の提供要求を受け付けると、図１０で示したサービスレベル情報画面を外部装置へ送信し、外部装置で表示させる。

このように実施の形態の分析装置２０によると、運用監視装置１２による管理データと、サービスデスク装置１４による管理データとを対応付けて、最新の運用状況にもとづく運用効率・サービスレベル・オペレータ評価のビューを提供することができる。これにより、情報システムの運用に関する広範囲な情報を可視化し、また情報鮮度の向上を実現する。また、運用実績にもとづく客観的なオペレータ評価結果を提供でき、また、称号の付与というゲーミフィケーションの導入により、運用業務に対するオペレータのモチベーションを維持、喚起することを支援できる。

管理者端末１８や入力装置２４から所定の分析指示が入力された場合、もしくは定期的に、変数取得部７２は、運用監視装置１２が管理する情報にもとづく現実のシステムの運用でのオペレータの業務量を示す情報を取得する。また、サービスデスク装置１４が管理する情報にもとづくオペレータの運用能力を示す情報を取得し、サービスデスク装置１４が管理する情報にもとづくオペレータの運用実績を示す情報を取得する。回帰分析部７４は、オペレータの業務量と運用能力を説明変数とし、オペレータの運用実績を目的変数とした回帰分析を実行し、両者の回帰関係を示す回帰式を導出する。

新規システムの運用コストを見積もるべき担当者（例えば新規システムの開発者や運用部門の管理者等）は、新規システムの運用に関する前提条件（例えば監視対象サーバ数やＳＬＡ情報等）を分析装置２０へ入力する。新規システムの運用に関する前提条件として、オペレータの業務量の想定値とオペレータの運用能力の予定値が指定され、予測処理の開始指示が入力されると、推定部７６は、その前提条件と回帰分析部７４が導出した回帰式にしたがって、新規システムにおけるオペレータの運用状態を推定する。予測結果表示部７８は、新規システムにおけるオペレータの運用状態の予測結果を示す情報（例えば図１３（ａ）（ｂ））を担当者の端末へ送信して表示させる。

また、新規システムの運用に関する前提条件として、オペレータの業務量の想定値と新規システムで要求されるサービスレベルが指定され、予測処理の開始指示が入力されると、推定部７６は、その前提条件と回帰分析部７４が導出した回帰式にしたがって、新規システムで必要となるオペレータの運用能力、例えばオペレータの人数やスキル、人件費を推定する。予測結果表示部７８は、新規システムで必要となるオペレータの運用能力の予測結果を示す情報（例えば図１３（ｃ））を担当者の端末へ送信して表示させる。

このように実施の形態の分析装置２０によると、現実のシステム運用で、オペレータの業務量および運用能力と、オペレータの運用実績との間に存在する回帰関係を反映した、新規システムにおけるオペレータの運用状態を推定する。担当者は、推定されたオペレータの運用状態（例えば平均コール時間やコールミス回数等）が許容範囲内かを検討することで、新規システムの前提条件としたオペレータの運用能力の予定値が妥当か否かを判断することができる。

また分析装置２０によると、現実のシステム運用で、オペレータの業務量および運用能力と、オペレータの運用実績との間に存在する回帰関係を反映した、必要となるオペレータの運用能力を推定する。これにより、新規システムの運用で要求されるサービスレベルの充足に必要となるオペレータの運用能力、例えばオペレータの人数やスキル、人件費を担当者へ提示でき、妥当な運用コストの見積りを支援できる。

また、監視対象システム１０に対する運用監視処理を実行中の運用監視装置１２と、運用監視装置１２と連携してオペレータ支援処理を実行中のサービスデスク装置１４で管理された情報にもとづいて回帰式を導出することで、現実の運用状態、かつ最新の運用状態を反映した回帰式を導出する。また、監視対象システム１０における監視対象サーバ数が多いほどオペレータの業務量を示す指標値を大きくし、また、監視対象システム１０のエラー発生回数が多いほどオペレータの業務量を示す指標値を大きくすることで、現実のシステム運用に即した回帰式を導出する。

以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下変形例を示す。

第１変形例：
上記実施の形態では言及していないが、本変形例の分析装置２０は、複数の監視対象システム１０のそれぞれで発生しうる複数種類のエラーについて、各エラーに関する属性情報を各監視対象システム１０のＩＤに対応付けて保持するエラー属性保持部をさらに備える。以下、特定の監視対象システム１０について説明する。エラー属性情報は、特定の監視対象システム１０で発生しうる複数種類のエラーそれぞれの識別情報と、各エラーの重大度に応じた重み値を含む。具体的には、エラーが引き起こす結果が重大であるほど、またエラーの影響範囲が大きいほど、エラーの解決コストが大きいほど、またエラーの解決までの時間が長いほど、大きい重み値が設定される。例えば、（１）Ｊａｖａ例外：重み１、（２）タイムアウトエラー：重み２、（３）サーバＡ停止エラー：重み３、と予め定められてもよい（「Ｊａｖａ」は登録商標）。

運用効率評価部６２は、１つの監視対象システム１０に関する運用効率情報の生成において、１人あたりメッセージ数の算出に際し、各メッセージが示すエラーの重み値をエラー属性保持部から取得する。そして、割られる数であるメッセージ総数（すなわちエラー総数）を、各メッセージが示すエラーの重み値に応じて調整する。具体的には、メッセージが示すエラーの重み値が大きいほどメッセージ数を多くカウントする。例えば、Ｊａｖａ例外を示すメッセージが５個、タイムアウトエラーを示すメッセージが２個、サーバＡ停止エラーを示すメッセージが１個ある場合、メッセージ総数を単に８個（＝５＋２＋１）とするのではなく、メッセージ総数を１２（＝５×１＋２×２＋１×３）と判定する。この結果、各メッセージが示すエラーが重大であるほど１人あたりメッセージ数の値は大きく算出され、すなわち運用の効率性をより高く評価する。このように重大なエラーに対応した事実を運用効率情報へ反映する。

またオペレータ評価部６４は、１人のオペレータに関するオペレータ評価情報の生成において、平均コール時間（コールの迅速性）の算出に際し、各メッセージが示すエラーの重み値をエラー属性保持部から取得する。そして、対応所要時間の合計を割る数であるメッセージ総数（すなわちエラー総数）を、各メッセージが示すエラーの重み値に応じて調整する。具体的には上記と同様に、メッセージが示すエラーの重み値が大きいほどメッセージ数を多くカウントする。この結果、各メッセージが示すエラーが重大であるほど、平均コール時間の値は小さくなり、オペレータの運用能力をより高く評価する。なお、各オペレータの平均コール時間を集約したサービスレベル情報のコール実績時間も小さくなり、サービスレベルもより高い評価となる。このように重大なエラーに対応した事実をオペレータ評価情報およびサービスレベル情報へ反映する。

エラーの個数としては同じ１件であっても、エラーの重大度が異なればオペレータ作業の難易度や煩雑さが異なるという現実がある。第１変形例によると、より現実に即して運用実績を評価することができる。

第２変形例：
上記第１変形例ではエラーの重大度を運用実績評価に反映させる手法を提案したが、第２変形例ではエラーの重大度を運用コストの見積支援処理に反映させる手法を提案する。第２変形例の分析装置２０も、第１変形例と同様のエラー属性保持部を備える。

回帰分析部７４（変数取得部７２でもよい）は、オペレータの業務量を示す運用規模（コール）の実績値を算出する際に、各メッセージが示すエラーの重み値をエラー属性保持部から取得する。そして、各メッセージが示すエラーの重み値に応じてメッセージ総数を調整する。具体的には、第１変形例と同様に、メッセージが示すエラーの重み値が大きいほどメッセージ数を多くカウントする。この結果、各メッセージが示すエラーが重大であるほどメッセージ総数が大きくなり、運用規模（コール）の値が大きくなる。既述したように、エラーの個数としては同じ１件であっても、エラーの重大度が異なればオペレータ作業の難易度や煩雑さが異なるという現実があり、第２変形例によると、より現実に即した回帰モデルを生成することができる。

なお、第２変形例においては、新規システムで想定される複数種類のエラーの発生割合が勘案され、新規システムの運用規模（コール）の想定値が設定されてもよい。推定部７６は、エラーの重大度を勘案して設定された運用規模（コール）の想定値を使用して、第１予測処理と第２予測処理を実行してもよい。より現実に即した精度の高い予測結果を導出することができる。

第３変形例：
上記実施の形態では回帰分析部７４が、運用能力基礎数値を説明変数とする単回帰分析を実行する例を示したが、複数の説明変数を用いた重回帰分析を実行してもよい。例えば、複数の監視対象システム１０のそれぞれについて、監視対象サーバ数、メッセージ数（エラー発生数）、システム担当チーム数、オペレータ数、オペレータスキル等の複数項目を説明変数とし、サービスレベルの実績値（平均コール時間等）を目的変数とした重回帰分析を実行してもよい。

第４変形例：
上記実施の形態では、運用未開始の新規システムを運用コストの予測対象システムとしたが、変形例として、運用開始済の既存システムを予測対象システムとしてもよい。この場合、予測対象システムの前提条件として、運用規模（コール）、運用規模（定義登録）、オペレータ人数、オペレータスキルの実績値が入力されてもよい。不図示のサービスレベル比較部は、第１予測処理で出力された予測サービスレベルと、サービスレベル評価部６６が出力した現実のサービスレベルとを比較し、その差分を示す比較結果をデータ保持部３０へ格納してもよい。予測サービスレベルよりも現実のサービスレベルが悪い場合、例えばコール時間が長い、コールミス回数が多い、定義登録期限超過数が多い場合、他の既存システムと比べて予測対象の既存システムの運用に問題があることが分かる。

また不図示の運用能力比較部は、第２予測処理で出力されたオペレータの運用能力と、運用効率評価部６２が出力したオペレータ数やオペレータスキルの平均値を比較し、現実のオペレータの運用能力が過多の場合、例えばオペレータ数が多い場合、他の既存システムと比べて予測対象の既存システムの運用効率が悪いことが分かる。このように、運用開始済の既存システムを予測対象システムとする場合にも有用な情報を獲得できる。

第５変形例：
１人のオペレータが複数のシステム運用に携わる場合、オペレータの稼働実績に応じて運用効率の算出基準となるオペレータ数を調整してもよい。本変形例の運用効率評価部６２は、１つの監視対象システム１０（特定システムと呼ぶ）の運用効率情報を生成する際に、特定システムのＩＤに対応付けられた各オペレータが実際に特定システムの運用に従事した稼働量、言い換えれば、各オペレータの稼働量全体に占める特定システムの運用に従事した割合に応じてオペレータ数を算出してもよい。

例えば、１人のオペレータ（特定オペレータと呼ぶ）のＩＤに対応付けられた作業実績情報のレコード数に占める、特定システムのＩＤと特定オペレータのＩＤの両方に対応付けられたレコード数の割合を算出してもよい。その割合が０．４であれば、特定オペレータの分として０．４をオペレータ数に加算してもよい。作業実績情報に代えて定義申請情報のレコードにおける上記割合を算出してもよく、作業実績情報と定義申請情報の両方における上記割合の平均値を算出してもよい。なお、所定の勤務管理装置から、特定オペレータが複数のシステムそれぞれの運用業務にどれだけ携わったかを示す情報を取得できる場合は、その情報を使用してオペレータ数を算出してもよい。第５変形例によると、より現実に即した運用効率情報を生成することができる。

第６変形例：
第５変形例と同様に、１人のオペレータが複数のシステム運用に携わる場合、オペレータの稼働実績に応じて、運用コスト予測のための回帰分析の説明変数とするオペレータ数を調整してもよい。具体的には、第５変形例の運用効率評価部６２と同様に、変数取得部７２は、特定システムのＩＤに対応付けられた各オペレータが実際に特定システムの運用に従事した稼働量、言い換えれば、各オペレータの稼働量全体に占める特定システムの運用に従事した割合に応じてオペレータ数を算出してもよい。第６変形例によると、より現実に即した回帰モデルを生成し、より現実に即した精度の高い予測結果を導出することができる。

上述した実施の形態および変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施の形態および変形例それぞれの効果をあわせもつ。また、請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。

１０ 監視対象システム、 １２ 運用監視装置、 １４ サービスデスク装置、 ２０ 分析装置、 ５２ 実システム情報取得部、 ５４ 運用実績取得部、 ６２ 運用効率評価部、 ６４ オペレータ評価部、 ６６ サービスレベル評価部、 ７２ 変数取得部、 ７４ 回帰分析部、 ７６ 推定部。

Claims (6)

1. 実システムの運用に要するオペレータの業務量を示す情報を取得する第１取得部と、
   オペレータの運用能力を示す情報を取得する第２取得部と、
   前記実システムに対するオペレータによる運用実績を示す情報を取得する第３取得部と、
   前記オペレータの業務量および運用能力にもとづいて特定される第１変数と、前記オペレータの運用実績にもとづいて特定される第２変数との間の回帰係数を導出する回帰分析部と、
   予測対象のシステムで想定されるオペレータの業務量と、仮に定められたオペレータの運用能力と、前記回帰分析部により導出された回帰係数にしたがって、前記予測対象のシステムに対するオペレータによる運用状態を推定する推定部と、を備え、
   前記第１取得部は、前記実システムの動作状態を監視する運用監視装置に保持された情報にもとづいて特定されたオペレータの業務量を示す情報を取得し、
   前記第２取得部は、前記システムで発生し、前記運用監視装置が検出したエラーに対応すべきオペレータを支援するサービスデスク装置に保持された情報にもとづいて特定されたオペレータの運用能力を示す情報を取得することを特徴とする分析装置。
2. 実システムの運用に要するオペレータの業務量を示す情報を取得する第１取得部と、
   オペレータの運用能力を示す情報を取得する第２取得部と、
   前記実システムに対するオペレータによる運用実績を示す情報を取得する第３取得部と、
   前記オペレータの業務量および運用能力にもとづいて特定される第１変数と、前記オペレータの運用実績にもとづいて特定される第２変数との間の回帰係数を導出する回帰分析部と、
   予測対象のシステムで想定されるオペレータの業務量と、前記予測対象のシステムに要求されるオペレータによる運用状態と、前記回帰分析部により導出された回帰係数にしたがって、前記予測対象のシステムで必要となるオペレータの運用能力を推定する推定部と、を備え、
   前記第１取得部は、前記実システムの動作状態を監視する運用監視装置に保持された情報にもとづいて特定されたオペレータの業務量を示す情報を取得し、
   前記第２取得部は、前記システムで発生し、前記運用監視装置が検出したエラーに対応すべきオペレータを支援するサービスデスク装置に保持された情報にもとづいて特定されたオペレータの運用能力を示す情報を取得することを特徴とする分析装置。
3. 前記実システムに配置されたサーバの数が多いほど、または、前記実システムで発生したエラーの数が多いほど、前記オペレータの業務量が大きく設定されることを特徴とする請求項１または２に記載の分析装置。
4. 前記実システムで発生しうる複数種類のエラーそれぞれの重大度を示す情報を保持するエラー属性保持部をさらに備え、
   前記実システムで発生したエラーが重大なものであるほど、前記オペレータの業務量が大きく設定されることを特徴とする請求項３に記載の分析装置。
5. 実システムの運用に要するオペレータの業務量を示す情報を取得する機能と、
   オペレータの運用能力を示す情報を取得する機能と、
   前記実システムに対するオペレータによる運用実績を示す情報を取得する機能と、
   前記オペレータの業務量および運用能力にもとづいて特定される第１変数と、前記オペレータの運用実績にもとづいて特定される第２変数との間の回帰係数を導出する回帰分析機能と、
   予測対象のシステムで想定されるオペレータの業務量と、仮に定められたオペレータの運用能力と、前記回帰分析機能により導出された回帰係数にしたがって、前記予測対象のシステムに対するオペレータによる運用状態を推定する機能と、をコンピュータに実現させるためのコンピュータプログラムであって、
   前記実システムの運用に要するオペレータの業務量を示す情報を取得する機能は、前記実システムの動作状態を監視する運用監視装置に保持された情報にもとづいて特定されたオペレータの業務量を示す情報を取得し、
   前記オペレータの運用能力を示す情報を取得する機能は、前記システムで発生し、前記運用監視装置が検出したエラーに対応すべきオペレータを支援するサービスデスク装置に保持された情報にもとづいて特定されたオペレータの運用能力を示す情報を取得することを特徴とするコンピュータプログラム。
6. 実システムの運用に要するオペレータの業務量を示す情報を取得する機能と、
   オペレータの運用能力を示す情報を取得する機能と、
   前記実システムに対するオペレータによる運用実績を示す情報を取得する機能と、
   前記オペレータの業務量および運用能力にもとづいて特定される第１変数と、前記オペレータの運用実績にもとづいて特定される第２変数との間の回帰係数を導出する回帰分析機能と、
   予測対象のシステムで想定されるオペレータの業務量と、前記予測対象のシステムに要求されるオペレータによる運用状態と、前記回帰分析機能により導出された回帰係数にしたがって、前記予測対象のシステムで必要となるオペレータの運用能力を推定する機能と、をコンピュータに実現させるためのコンピュータプログラムであって、
   前記実システムの運用に要するオペレータの業務量を示す情報を取得する機能は、前記実システムの動作状態を監視する運用監視装置に保持された情報にもとづいて特定されたオペレータの業務量を示す情報を取得し、
   前記オペレータの運用能力を示す情報を取得する機能は、前記システムで発生し、前記運用監視装置が検出したエラーに対応すべきオペレータを支援するサービスデスク装置に保持された情報にもとづいて特定されたオペレータの運用能力を示す情報を取得することを特徴とするコンピュータプログラム。

Images