JP2017097781A - 工数推定プログラム、工数推定方法及び工数推定装置 - Google Patents

Abstract

【課題】新たな事象についての工数を推定することを目的とする。
【解決手段】事象に対する１以上の対処情報を事象毎に記録した事象情報から前記対処情報の数に応じて前記事象情報を複数のカテゴリに分類し、分類したカテゴリ毎に前記事象情報に含まれる単語毎の発生頻度を算出し、新たな事象の受け付けに応じて、前記新たな事象の事象情報に含まれる単語と、算出した前記単語毎の発生頻度とに基づき、前記新たな事象が含まれるカテゴリを推定する、処理をコンピュータに実行させる工数推定プログラムが提供される。
【選択図】図２

Description

本発明は、工数推定プログラム、工数推定方法及び工数推定装置に関する。

所定のシステムにて発生した、サービスレベルの低下の原因となり得る事象(以下、「インシデント」ともいう。)に関する情報と、その対処情報とを、発生した事象毎に管理するインシデント管理が知られている（例えば、特許文献１〜３参照）。

インシデント管理とは、インシデント処理担当者が、インシデントに対して適切な暫定的な対処や恒久的な対処等の対処を実施し、システムを正常な状態に保つための一連の作業を実行することをいう。インシデントは、ユーザが操作したユーザ機器からの問い合わせや、システムから送信されるアラートメッセージ等に応じて発生する。インシデントは、事象の発生時刻、対処完了時刻、事象の内容及び事象に対する対処情報等を記録したインシデントチケットにより管理される。インシデントチケットは、新たなインシデントが発生したときに発行される。インシデント処理担当者は、類似した過去インシデントチケットを検索し、そのインシデントチケットの内容を考慮して新たなインシデントの対処を行う。

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

しかしながら、過去インシデントチケットに記録されている対処情報では、対処にどの程度の時間や工数を要したのかがわからない。そのため、インシデント管理者は、類似したインシデントの対処情報を参照して新たなインシデントの対処を行うのに、どの程度の時間や工数を要するのかを予測することは困難である。このため、インシデント管理者が新たなインシデントの対処を行うインシデント処理担当者を配備する際の指標となる情報が望まれる。

そこで、一側面では、本発明は、新たな事象についての工数を推定することを目的とする。

一つの案では、事象に対する１以上の対処情報を事象毎に記録した事象情報から前記対処情報の数に応じて前記事象情報を複数のカテゴリに分類し、分類したカテゴリ毎に前記事象情報に含まれる単語毎の発生頻度を算出し、新たな事象の受け付けに応じて、前記新たな事象の事象情報に含まれる単語と、算出した前記単語毎の発生頻度とに基づき、前記新たな事象が含まれるカテゴリを推定する、処理をコンピュータに実行させる工数推定プログラムが提供される。

一側面によれば、新たな事象についての工数を推定することができる。

一実施形態にかかる工数推定装置の機能構成の一例を示す図。 一実施形態にかかる工数推定の流れを説明するための図。 一実施形態にかかるインシデントチケットの一例を示す図。 一実施形態にかかる過去インシデント情報ＤＢのデータ構成の一例を示す図。 一実施形態にかかる過去インシデント情報ＤＢのデータ構成の一例を示す図。 一実施形態にかかるカテゴリの分類の一例を示す図。 一実施形態にかかるインシデント管理処理の一例を示すフローチャート。 一実施形態にかかる尤度関数算出処理の一例を示すフローチャート。 一実施形態にかかる単語発生頻度情報ＤＢ及び尤度関数に基づくカテゴリの推定を説明するための図。 一実施形態にかかる対応工数推定処理の一例を示すフローチャート。 一実施形態にかかる工数推定装置のハードウェア構成の一例を示す図。

以下、本発明の実施形態について添付の図面を参照しながら説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複した説明を省く。

［インシデント管理］
インシデント管理は、システム運用管理においてサービスレベルの維持に最も重要かつ困難な作業の一つである。インシデント管理では、インシデント処理担当者が、インシデントに対して適切な対処を実施し、システムを正常な状態に保つための一連の作業を実行する。過去のインシデントに基づき、新規インシデントに関する対処に必要な工数を推定できれば、効率的なインシデント管理の実現が可能になる。

例えば、過去のインシデントの中から工数のかかるインシデントの特徴を抽出できれば、それらと同じ又は類似する特徴を有する新規インシデントの対処及び工数の見積もりに過去のインシデントの対処及び工数を応用することができる。この場合、新規インシデントの特徴に応じて、新規インシデントの対処を集中的に行ったり、新規インシデントの対応工数を大幅に削減したりすることができる。また、例えば、負荷の大きそうな新規インシデントが発生したら、経験のあるインシデント処理担当者や比較的工数に余裕のあるインシデント処理担当者に対処を振り分けることにより、運用工数の平準化や解決時間の短縮に貢献することができる。

ところが、過去インシデントの対処にかかった工数は、インシデントチケットに記録されていない等の理由により、直接的に計測することは困難である。よって、新規インシデントに対し、その工数を予測することは困難となる。

また、一般的に工数と関連があるとして用いられる情報として、インシデント生成（発生）時刻（Open Time）からインシデント対処完了（収束）時刻（Close Time）までの時間が用いられることがある。しかし、これは必ずしも工数を反映しているとは限らない。その理由の一つとしては、各インシデントの対処は、インシデントが生成されるとすぐに始まるとは限らないことが挙げられる。例えば、サーバの部品の交換などは、故障時に即時対処を行うのではなく、壊れたものは停止させておき、月1回などの定期的な頻度で複数台分をまとめて実施することがある。この際、定期交換の直前と直後に起こった故障は、ほぼ同一の工数であっても、インシデントが終了するまでの期間に大きな差異が発生する。

また、他の理由としては、インシデントにおいては問題解決のために、関係者（ユーザなど）に問い合わせを行うことがあるが、Ｅ−ｍａｉｌによる連絡では、関係者からのレスポンスのタイミングは個人によって異なることが挙げられる。このために、同じ１通のメールのやり取りが入っただけでも、各インシデントの終了までの時間が大きく異なる場合がある。そこで、以下では、新たな事象についての工数を推定する工数推定装置の一実施形態について説明する。

［機能構成］
まず、本発明の一実施形態に係る工数推定装置１の機能構成の一例について、図１及び図２を参照しながら説明する。本実施形態に係る工数推定装置１は、例えば、社内の給料管理システム等のシステムのインシデント管理について、各インシデントの工数を推定することが可能な情報処理装置の一例である。ただし、インシデント管理対象のサービスは、社内の給料管理システムに限らず、所定のアプリケーションが動作することで行われるいかなるサービスであってもよい。サービスは、社内の従業員やサービスの提供を受け得るユーザに提供される。

本実施形態に係る工数推定装置１は、受付部１０、インシデント管理部１１、解析部１２、分類部１３、算出部１４、推定部１５、出力部１６及び記録部１７を有する。受付部１０は、図２に示すように、ユーザが操作するユーザ機器２からの問い合わせ４又はシステム３から送信されるアラートメッセージ５等を受け付ける。

インシデント管理部１１は、ユーザ機器２からの問い合わせ４やアラートメッセージ５等の受け付けに応じて、新規インシデントチケットをオープン（生成）する。インシデント管理部１１は、新規インシデントチケットの対処が完了した場合、新規インシデントチケットをクローズ（対処完了）する。インシデントは、所定のシステムにて発生したサービスレベルの低下の原因となり得る事象をいう。インシデントは、事象の発生時刻、対処完了時刻、事象の内容及び事象に対する対処情報等を記録したインシデントチケットにより管理される。インシデント管理者は、新たなインシデントが発生したときに、類似したインシデントチケットを検索し、そのインシデントチケットの情報に基づき、新たなインシデントの対処を行う。

インシデントチケットは、図３に示すようにインシデントに関わる情報を記録する。例えば、インシデントチケット３０には、以下の項目（ａ）〜（ｅ）が記録される。インシデントチケットの以下の項目は、インシデントの内容及びインシデントに対する１以上の対処情報を含む事象情報の一例である。
（ａ）インシデントＩＤ３１ 各インシデントに対して一意に割り振られる番号
（ｂ）ＯｐｅｎＴｉｍｅ３２ インシデント生成（発生）時刻
（ｃ）ＣｌｏｓｅＴｉｍｅ３３ インシデント対処完了（収束）時刻
（ｄ）Ａｄｍｉｎ ｎａｍｅ３４ インシデントの処理担当者の名前
（ｅ）Ｄｅｓｃｒｉｐｔｉｏｎ３５ インシデントの内容（１以上の対処情報を記録）
Ｄｅｓｃｒｉｐｔｉｏｎ３５（以下、「インシデント記述３５」ともいう。）は、インシデントの内容として、発生事象や対処の経過等が記録される。よって、インシデントチケット３０は、進捗によって書き換えられる（更新される）可能性がある。更新されるタイミングの一例としては、Ｃｌｏｓｅ Ｔｉｍｅ３３の欄へのインシデントクローズ日時の記入、Ａｄｍｉｎ ｎａｍｅ３４の欄への担当者の変更の記入、対応経過の記入（メンテナンスモード移行、問題の原因発見等）が挙げられる。図３では、対応経過として、３回の更新情報３６，３７，３８がインシデントチケット３０に記入されている。このように、インシデントチケット３０のインシデント記述３５を参照すれば、そのインシデントの更新回数が判定できる。

そこで、本実施形態は、インシデント記述３５の内容の更新回数を利用して、インシデント対応作業の負荷を予測する。つまり、インシデントチケットにおける、対処内容の更新回数が多い場合、そのインシデントの対処に多くの作業が必要であるとみなし、インシデントの対応工数が大きい、すなわち、インシデント対応作業の負荷が高いとみなす。

図２の枠内に示すインシデント対応作業の負荷の予測は、図１の主に解析部１２、分類部１３、算出部１４又は推定部１５が、（１）〜（３）に示すステップを実行することにより行われる。

（１）では、解析部１２が、インシデントチケットの更新回数を算出し、分類部１３が、算出した更新回数に基づき、インシデントチケットを複数のカテゴリに分類する。また、算出部１４は、各インシデントチケット内の単語の出現回数をカウントする。

（２）では、算出部１４が、分類したカテゴリと単語の種類毎の発生頻度との相関を求める。例えば、算出部１４は、各カテゴリにおける単語の発生傾向を、ＴＦ−ＩＤＦ等の指標を使用して算出する。これにより、各カテゴリに含まれるインシデントに特有の単語（キーワード）等を抽出することができる。

（３）では、推定部１５が、新規インシデントについて、例えば、更新回数の大きい又は小さいインシデントに分類された複数のカテゴリのいずれのカテゴリに特有のキーワードを多く含むか否かで、新規インシデントがいずれのカテゴリの特徴に近いかを推定する。そして、推定部１５は、新規インシデントの特徴に近いカテゴリに含まれる過去インシデントの更新回数から、新規インシデントの対応工数を推定してもよい。

出力部１６は、新規インシデントに対して推定された対応工数を出力する。これにより、インシデント管理者は、複数のインシデント処理担当者のどの人に発生した新規インシデントを割り当てるかを判断することができる。

記録部１７は、図１に示すように、過去インシデント情報ＤＢ２０、単語発生頻度情報ＤＢ２１、インシデント管理プログラム２２、尤度関数算出プログラム２３、工数推定プログラムを記録する。

図４は、一実施形態にかかる過去インシデント情報ＤＢ２０のデータ構成の一例を示す。過去インシデント情報ＤＢ２０は、インシデントＩＤ２０１、更新回数２０２、インシデント記述２０３の各項目を有する。インシデントＩＤ２０１には、インシデントチケット３０のインシデントＩＤ３１が記録される。更新回数２０２には、インシデント記述３５に記録された更新情報の回数が記録される。インシデント記述２０３には、初回、及び更新されるごとにインシデント記述３５に記録された内容が記録される。

例えば、図４の過去インシデント情報ＤＢ２０には、インシデントＩＤ２０１が「ＩＤ０００１」のインシデントは、更新回数２０２が「２回」であることが記録されている。また、そのインシデントのインシデント記述２０３には、初回に「ネットワークが無反応」と記録され、更新1回目に「スイッチの状態を確認。異常なし。」と記録され、更新２回目に「ケーブルの断線を発見。交換で復旧。」と記録されている。

図５は、一実施形態にかかる過去インシデント情報ＤＢ２０のデータ構成の他の一例を示す。過去インシデント情報ＤＢ２０は、インシデントＩＤ２０１、更新回数２０２、単語出現回数２０４の各項目を有する。単語出現回数２０４には、インシデント記述３５に記録された単語の出現回数が、単語の種類毎に記録される。なお、解析部１２が、インシデント記述３５に記録された内容を解析し、算出部１４が、単語の抽出及び単語の種類毎の出現回数をカウントする。

例えば、図５の過去インシデント情報ＤＢ２０には、インシデントＩＤ２０１が「ＩＤ０００１」のインシデントは、更新回数２０２が「２回」であることが記録されている。また、そのインシデントの単語出現回数２０４には、単語「ネットワーク」の出現回数が１回、単語「が」の出現回数が１回、単語「無反応」の出現回数が１回、・・・と記録されている。

以上に説明した、過去インシデント情報ＤＢ２０に記録されたインシデント毎の更新回数２０２に基づき、各インシデントチケットが複数のカテゴリに分類される。図６を参照して、分類部１３が実行するインシデントチケットをカテゴリに分類する方法の一例を説明する。分類部１３は、インシデントの更新回数のよるインシデントチケットの分類にあたり、予め、インシデントの更新回数の多い又は少ないを切り分ける閾値（例えば、３）を設定する。分類部１３は、設定された閾値に基づき、過去インシデント情報ＤＢ２０に記録されたインシデントチケットを、更新回数の少ない第１グループ４０と、更新回数の多い第２グループ５０とに分類する。第１グループ４０のカテゴリには、更新回数が３未満のインシデントチケットが含まれる。第２グループ５０のカテゴリには、更新回数が３以上のインシデントチケットが含まれる。

分類部１３は、複数の閾値を指定することにより、インシデントチケットを３以上のグループに分けてもよい。たとえば、分類部１３は、第1及び第２閾値を設定し、第１閾値は、更新回数が少ない（例えば、０〜２）インシデントチケットと、更新回数が中程度（例えば、３〜５）のインシデントチケットとを分類するために使用してもよい。第２閾値は、更新回数が中程度（例えば、３〜５）のインシデントチケットと、更新回数が多い（例えば、５以上）のインシデントチケットとを分類するために使用してもよい。

しかしながら、閾値の決定方法は、これに限られず、複数の方法を利用することができる。例えば、閾値は、所定の固定値に設定されてもよい。例えば、分類部１３は、閾値を「３」と予め設定し、更新回数が３回未満のインシデントチケットは更新回数の少ないカテゴリに分類し、更新回数が３回以上のインシデントチケットは更新回数の多いカテゴリに分類してもよい。

また、閾値は、所定の統計量を用いて設定されてもよい。例えば、閾値は、インシデントチケット全体のＸ％が更新回数Ｙ以下である等の関係を利用して「Ｘ」及び「Ｙ」の値から決定されてもよい。例えば、インシデントチケット全体の９０％が更新回数４回以下であった場合、更新回数が４回以下のインシデントチケット（全体の９０％）は更新回数の少ないカテゴリに分類してもよい。更新回数が５回以上のインシデントチケット（全体の１０％）は更新回数の多いカテゴリに分類してもよい。

また、閾値は、システム管理者がインシデントを割り当てるインシデント処理担当者のインシデント対処能力に基づき算出されてもよい。この場合、分類部１３は、インシデント処理担当者の対処能力を数値化してカテゴリに分け、その比率に応じてインシデントの分配を行う。例えば、能力値が「０．５（低い）」の担当者が６人含まれるグループ（グループＡ）と、能力値が「１．０（高い）」の担当者が２人含まれるグループ（グループＢ）があった場合について例示する。それぞれのグループの能力値は、グループＡが「３．０」（＝６×０．５）、グループＢが「２．０」（＝２×１．０）である。よって、全体のインシデントチケットのうち、更新回数が少ない６０％（＝３．０／（３．０＋２．０））のインシデントチケットをグループＡに割り当てるように閾値が設定されてもよい。具体的には、例えば、インシデントチケット全体の６０％が更新回数３回以下であった場合、更新回数が３回以下のインシデントチケット（全体の６０％）は更新回数の少ないカテゴリに分類してもよい。更新回数が４回以上のインシデントチケット（全体の４０％）は更新回数の多いカテゴリに分類してもよい。

図１に戻り、記録部１７が記録するインシデント管理プログラム２２は、インシデント管理処理を工数推定装置１に実行させるためのプログラムである。インシデント管理プログラム２２には、主に図７のインシデント管理処理に示される各ステップが記述される。

尤度関数算出プログラム２３は、尤度関数算出処理を工数推定装置１に実行させるためのプログラムである。尤度関数算出プログラム２３には、主に図８の尤度関数算出処理に示される各ステップが記述される。

工数推定プログラム２４は、対応工数推定処理を工数推定装置１に実行させるためのプログラムである。工数推定プログラム２４には、主に図１０の対応工数推定処理に示される各ステップが記述される。

［インシデント管理処理］
次に、本実施形態に係るインシデント管理処理について、図７を参照して説明する。図７は、本実施形態にかかるインシデント管理処理の一例を示すフローチャートである。本処理が開始されると、受付部１０は、ユーザ機器２からの問い合わせ又はシステム３から送信されるアラートメッセージ等を受け付ける（ステップＳ１０）。

次に、インシデント管理部１１は、前記問い合わせ等を受け付けると、新規インシデントチケットをオープン（生成）する（ステップＳ１２）。次に、インシデント管理部１１は、インシデント処理担当者が何等かの対処を行ったかを判定する(ステップＳ１４)。インシデント管理部１１は、インシデント処理担当者が何等かの対処を行ったと判定した場合、新規インシデントチケットに対処内容を記録して、その新規インシデントチケットを更新し（ステップＳ１６）、ステップＳ１８に進む。具体的には、図３のインシデントチケット３０のインシデント記述３５に対処内容を記録して更新する。インシデント管理部１１は、インシデント処理担当者が何等かの対処を行われなかったと判定した場合、直ちにステップＳ１８に進む。

次に、インシデント管理部１１は、新規インシデントの対処が完了したかを判定する（ステップＳ１８）。インシデント管理部１１は、対処が完了していないと判定した場合、ステップＳ１４に戻り、対処が完了するまでステップＳ１４〜Ｓ１８の処理を繰り返す。インシデント管理部１１は、対処が完了したと判定した場合、インシデント管理部１１は、新規インシデントチケットの対処が完了した場合、新規インシデントチケットをクローズ（対処完了）し（ステップＳ２０）、本処理を終了する。

以上のようにして生成及び管理されるインシデントチケットを用いた尤度関数算出処理、尤度関数を用いた対応工数推定処理について順に説明する。

［尤度関数算出処理］
本実施形態に係る尤度関数算出処理について、図８及び図９を参照して説明する。図８は、本実施形態にかかる尤度関数算出処理の一例を示すフローチャートである。図９は、本実施形態にかかる尤度関数の算出の一例を説明するための図である。

本処理が開始されると、算出部１４は、新規インシデントチケットがクローズされたかを判定する（ステップＳ３０）。算出部１４は、新規インシデントチケットがクローズされていないと判定した場合、何も処理せずに本処理を終了する。算出部１４が、新規インシデントチケットがクローズされたと判定した場合、記録部１７は、クローズした新規インシデントチケットに記録された事象情報（事象内容）を過去インシデント情報ＤＢ２０に保存する。過去インシデント情報ＤＢ２０に保存する事象情報の一例としては、図３に示すインシデントＩＤ３１、更新情報３６、３７、３８に応じた更新回数、インシデント記述３５が挙げられる。Ｏｐｅｎ Ｔｉｍｅ３２、Ｃｌｏｓｅ Ｔｉｍｅ３３、Ａｄｍｉｎ ｎａｍｅ３４を過去インシデント情報ＤＢ２０に保存してもよい。

図８に戻り、次に、算出部１４は、クローズした新規インシデントチケットに含まれる単語の出現回数をカウントする（ステップＳ３２）。算出部１４は、インシデント記述３５に記録された単語の出現回数を単語の種類毎にカウントしてもよい。

次に、算出部１４は、各カテゴリにおける各単語の出現傾向を示す尤度関数を算出する（ステップＳ３６）。記録部１７は、算出した尤度関数の情報に基づき算出される、カテゴリ別の単語の種類毎の出現頻度を単語発生頻度情報ＤＢ２１に保存し（ステップＳ３８）、本処理を終了する。

（尤度関数）
ステップＳ３６において、算出部１４が実行する尤度関数の算出方法の一例について説明する。算出部１４は、更新回数が多いカテゴリと少ないカテゴリの２つのカテゴリと、各カテゴリのインシデントチケットに含まれる単語の発生頻度との相関をカテゴリ毎に特定する。算出部１４は、カテゴリ毎の単語の発生頻度の傾向を、ＴＦ−ＩＤＦなどの指標を用いて算出する。

算出において、過去のインシデントチケットの集合をＴ＝｛t_1,t_２・・・｝（例えば、t₁=ID0001、t₂=ID0002_・・・）で示す。また、チケット全体に含まれる単語の集合をＷ＝｛w_1,w_２・・・｝（例えば、w₁="サーバ"、w₂="接続"_・・・）で示す。式（１）のｉは、すべてのインシデントで出現する単語の種類のそれぞれを示す。ｗは、すべてのインシデントで出現する単語の種類の総数を示す。
（Ａ）ｔｆの算出
まず、算出部１４は、以下の式（１）に基づき、ｔｆ（term frequency）を算出する。

ｔｆは、インシデントチケットのテキストtjに単語w_iがどれだけ多く出現するかを表した指標である。ｔｆが高い程、インシデントチケットに出現する頻度が高い単語であることを示す。例えば、インシデントＩＤが「ID0002」のインシデントチケットのインシデント記述３５に記録されたテキストに、「サーバ に ログイン できない。ログイン エラー 発生」の７単語が含まれている場合、「サーバ」、「ログイン」の各単語のｔｆは以下のように算出される。

ｔｆ（"サーバ"、ID0002）＝１／７
ｔｆ（"ログイン"、ID0002）＝２／７
（Ｂ）ｉｄｆの算出
しかし、どのインシデントチケットにも沢山出てくる単語は、特定のインシデントチケットに特有の単語ではない。つまり、どのインシデントチケットにも沢山出てくる単語は、ｔｆが高くても重要ではないと判定できる。そこで、算出部１４は、以下の式（２）に基づき、ｉｄｆ（inverse document frequency）を算出する。

ｉｄｆは、インシデントチケットの集合全体で見たときに、単語w₁がどれだけ出現頻度が低いか、つまり、ある特有のインシデントチケットでのみ使用されている単語であるかを表す。ｉｄｆが高い程、特定のインシデントチケットに対して特有な(頻度が高い)単語であることを示す。例えば、全部で１００個のインシデントチケットのうち、"サーバ"の単語が１０インシデントチケットに出現していた場合、インシデントＩＤがＩＤ０００２の、"サーバ"の単語のｉｄｆは以下のように算出される。

ｉｄｆ（"サーバ"、ＩＤ０００２）＝ｌｏｇ（１００／１０）
式（２）のδ（ｗ_１、ｔ_ｋ）が１のとき、インシデントチケットのテキストｔ_ｋが単語ｗ_１を含むことを示す。δ（ｗ_１、ｔ_ｋ）が０のとき、インシデントチケットのテキストｔ_ｋが単語ｗ_１を含まないことを示す。
（Ｃ）ｆの算出
次に、算出部１４は、各カテゴリにおける単語の発生傾向の一例を示す、ＴＦ−ＩＤＦを算出する。ＴＦ−ＩＤＦは、上記ｔｆとｉｄｆとを乗算したものであり、ｆ_i、jで示される。算出部１４は、以下の式（３）に基づき、ｆ_i、jを算出する。

ｆ_i、jは、単語w₁とインシデントチケットのテキストtjとの相関の高さを示す。単語w₁がインシデントチケットのテキストtjにおいて出現頻度が高く、かつ、他のインシデントチケットのテキストで出現頻度が低いと大きくなる。例えば、ＩＤ０００２のインシデントチケットt₂の"サーバ"の単語のｆ_i、jは、以下のように算出される。

ｆ_{サーバ、ID0002}＝ｔｆ（"サーバ"、ＩＤ０００２）・ｉｄｆ（"サーバ"）＝１／７・ｌｏｇ（１００／１０）＝０．１４３
なお、ｆの計算は、各カテゴリに属するすべてのインシデントチケットのテキストに対して行われる。
（Ｄ）尤度関数θ
次に、算出部１４は、更新回数が多いカテゴリと少ないカテゴリの各カテゴリについて、各単語の出現傾向を尤度として算出する。尤度関数は、各カテゴリにおける単語の出現傾向を示す。具体的には、算出部１４は、以下の式（４）に基づき、更新回数が多いカテゴリと少ないカテゴリの各カテゴリに属するインシデントチケットのテキストにおいて、単語w_ｉが出現する傾向(尤度)を算出する。

式（４）のｌ（t_ｊ）がｓｍａｌｌの場合は、インシデントチケットのテキストtjの更新回数が閾値未満の場合を示し、ｌ（t_ｊ）がｌａｒｇｅの場合は、インシデントチケットのテキストtjの更新回数が閾値以上の場合を示す。尤度関数θは、各カテゴリにおける単語の出現回数として、例えば、図９に示す単語発生頻度情報ＤＢ２１のカテゴリ２１１毎の単語２１２に記録される。図９の例では、カテゴリ２１１が「第１カテゴリ（ｓｍａｌｌ：更新回数少）に含まれるインシデントチケットの単語"サーバ"の発生頻度は、「０．８」であることが記録されている。

［対応工数推定処理］
次に、本実施形態に係る対応工数推定処理について、図１０を参照して説明する。図１０は、本実施形態にかかる対応工数推定処理の一例を示すフローチャートである。

本処理が開始されると、推定部１５は、新規インシデントチケットがオープンされたかを判定する（ステップＳ４０）。推定部１５は、新規インシデントチケットがオープンされていないと判定した場合、何も処理せずに本処理を終了する。新規インシデントチケットがオープンされたと判定された場合、推定部１５は、尤度関数を用いて、オープンした新規インシデントチケットが属するカテゴリを推定する（ステップＳ４２）。次に、出力部１６は、推定した新規インシデントチケットが属するカテゴリを出力し（ステップＳ４４）、本処理を終了する。

（工数推定）
ステップＳ４２において、推定部１５が実行するカテゴリの推定方法の一例について説明する。推定部１５は、ステップＳ４２において、以下の式（５）に基づき、新規インシデントチケットのテキストt_newが属するカテゴリの推定結果を数値化する。つまり、推定部１５は、新規インシデントチケットがどちらのカテゴリに属するのがもっともらしいかを、式（５）に基づき演算で求める。

式（５）のd_iは、新規インシデントチケットのテキストt_newにおける単語w_ｉの出現回数を示す。式（５）では、すべてのカテゴリに対して、Σｄ・ｌｏｇθの値を算出し、算出した値の最大値をカテゴリの推定結果として出力する。

例えば、図９の例では、図８のステップＳ３４において、算出部１４は、新規インシデントチケット３０Ｎのテキスト「サーバに接続できない」に対して、単語の出現回数を、「サーバ」、「に」、「接続」及び「できない」のそれぞれが１回とカウントする。

この場合、推定部１５は、新規インシデントチケット３０Ｎと各カテゴリとの相関値を、尤度関数を用いて次のように演算する。

第１カテゴリ（Ｓｍａｌｌ）との相関値
＝1×log(0.8)+1×log(0.1)+1×log(0.9)+1×log(0.5)
＝−１．４４４
第２カテゴリ（Ｌａｒｇｅ）との相関値
＝1×log(0.1)+1×log(0.1)+1×log(0.4)+1×log(0.5)
＝−２．６９９
以上から、図９の例では、推定部１５は、新規インシデントチケット３０Ｎが、相関値が高い第１カテゴリ（Ｓｍａｌｌ）に属すると推定し、第１カテゴリ（Ｓｍａｌｌ）に属する過去インシデントチケットと同様に対応工数が少ないと推定する。出力部１６は、新規インシデントチケット３０Ｎが属すると推定されるカテゴリの名前（更新回数少、更新回数多など）を出力する。

以上に説明したように、一実施形態に係る工数推定装置１は、カテゴリ毎にインシデント記述３５の欄にどのような単語がどの程度の出現頻度で現れるかを算出する。これにより、算出した単語毎の出現頻度に基づき、新規インシデントチケットが分類されるカテゴリを推定することができる。これにより、推定されたカテゴリから新規インシデントチケットの対応工数を予測することができる。この結果、システム管理者は、複数のインシデント処理担当者のどの人に発生した新規インシデントを割り当てるかを判断することができる。

（ハードウェア構成）
最後に、本実施形態に係る工数推定装置１のハードウェア構成の一例について、図１１を参照して説明する。工数推定装置１は、入力装置１０１、表示装置１０２、外部Ｉ／Ｆ１０３、ＲＡＭ（Random Access Memory）１０４、ＲＯＭ（Read Only Memory）１０５、ＣＰＵ（Central Processing Unit）１０６、通信Ｉ／Ｆ１０７、及びＨＤＤ（Hard Disk Drive）１０８などを備え、それぞれがバスＢで相互に接続されている。

入力装置１０１は、キーボードやマウスなどを含み、工数推定装置１に各操作信号を入力するために用いられる。表示装置１０２は、ディスプレイなどを含み、各種の処理結果を表示する。通信Ｉ／Ｆ１０７は、工数推定装置１をネットワークに接続するインターフェースである。これにより、工数推定装置１は、通信Ｉ／Ｆ１０７を介して、他の機器（△端末等）とデータ通信を行うことができる。

ＨＤＤ１０８は、プログラムやデータを格納している不揮発性の記憶装置である。格納されるプログラムやデータには、工数推定装置１の全体を制御する基本ソフトウェア及びアプリケーションソフトウェアがある。例えば、ＨＤＤ１０８には、各種のデータベースやプログラム等が格納されてもよい。

外部Ｉ／Ｆ１０３は、外部装置とのインターフェースである。外部装置には、記録媒体１０３ａなどがある。これにより、工数推定装置１は、外部Ｉ／Ｆ１０３を介して記録媒体１０３ａの読み取り及び／又は書き込みを行うことができる。記録媒体１０３ａには、ＣＤ（Compact Disk）、及びＤＶＤ（Digital Versatile Disk）、ならびに、ＳＤメモリカード（SD Memory card）やＵＳＢメモリ（Universal Serial Bus memory）等がある。

ＲＯＭ１０５は、電源を切っても内部データを保持することができる不揮発性の半導体メモリ（記憶装置）である。ＲＯＭ１０５には、ネットワーク設定等のプログラム及びデータが格納されている。ＲＡＭ１０４は、プログラムやデータを一時保持する揮発性の半導体メモリ（記憶装置）である。ＣＰＵ１０６は、上記記憶装置（例えば「ＨＤＤ１０８」や「ＲＯＭ１０５」など）から、プログラムやデータをＲＡＭ１０４上に読み出し、処理を実行することで、装置全体の制御や搭載機能を実現する演算装置である。

かかる構成により、本実施形態に係る工数推定装置１では、ＣＰＵ１０６が、ＲＯＭ１０５やＨＤＤ１０８内に格納されたデータ、インシデント管理プログラム２２、尤度関数算出プログラム２３、工数推定プログラム２４及びその他のプログラムを用いてインシデント管理処理、尤度関数算出処理及び対応工数推定処理を実行する。なお、過去インシデント情報ＤＢ２０及び単語発生頻度情報ＤＢ２１に記憶された情報は、ＲＡＭ１０４、ＨＤＤ１０８、又はネットワークを介して工数推定装置１に接続されるクラウド上のサーバ等に格納され得る。

以上、工数推定プログラム、工数推定方法及び工数推定装置を上記実施形態により説明したが、本発明にかかる工数推定プログラム、工数推定方法及び工数推定装置は上記実施形態に限定されるものではなく、本発明の範囲内で種々の変形及び改良が可能である。また、上記実施形態及び変形例が複数存在する場合、矛盾しない範囲で組み合わせることができる。

例えば、上記実施形態に係る工数推定装置の構成は、本発明の範囲を限定するものではなく、用途や目的に応じて様々な構成例があることは言うまでもない。例えば、工数推定装置がネットワークを介して互いに接続されているシステム形態は、インシデント管理を行う１又は複数のアプリケーションのそれぞれにおいて、工数を推定するアプリケーション（工数推定プログラム）を実行する１台又は複数台の装置で構成され得る。工数推定装置は、データセンタ内の装置、又はクラウド上のサーバ等で構成されていてもよい。

以上の説明に関し、更に以下の項を開示する。
（付記１）
事象に対する１以上の対処情報を事象毎に記録した事象情報から前記対処情報の数に応じて前記事象情報を複数のカテゴリに分類し、
分類したカテゴリ毎に前記事象情報に含まれる単語毎の発生頻度を算出し、
新たな事象の受け付けに応じて、前記新たな事象の事象情報に含まれる単語と、算出した前記単語毎の発生頻度とに基づき、前記新たな事象が含まれるカテゴリを推定する、
処理をコンピュータに実行させる工数推定プログラム。
（付記２）
推定した前記新たな事象のカテゴリに関する情報を出力する、
付記１に記載の工数推定プログラム。
（付記３）
事象に対する１以上の対処情報を事象毎に記録した事象情報から前記対処情報の数に応じて前記事象情報を複数のカテゴリに分類し、
分類したカテゴリ毎に前記事象情報に含まれる単語毎の発生頻度を算出し、
新たな事象の受け付けに応じて、前記新たな事象の事象情報に含まれる単語と、算出した前記単語毎の発生頻度とに基づき、前記新たな事象が含まれるカテゴリを推定する、
処理をコンピュータが実行する工数推定方法。
（付記４）
推定した前記新たな事象のカテゴリに関する情報を出力する、
付記３に記載の工数推定方法。
（付記５）
事象に対する１以上の対処情報を事象毎に記録した事象情報から前記対処情報の数に応じて前記事象情報を複数のカテゴリに分類する分類部と、
分類したカテゴリ毎に前記事象情報に含まれる単語毎の発生頻度を算出する算出部と、
新たな事象の受け付けに応じて、前記新たな事象の事象情報に含まれる単語と、算出した前記単語毎の発生頻度とに基づき、前記新たな事象が含まれるカテゴリを推定する推定部と、
を有する工数推定装置。
（付記６）
推定した前記新たな事象のカテゴリに関する情報を出力する出力部を有する、
付記５に記載の工数推定装置。

１ 工数推定装置
２ ユーザ機器
１０ 受付部
１１ インシデント管理部
１２ 解析部
１３ 分類部
１４ 算出部
１５ 推定部
１６ 出力部
１７ 記録部
２０ 過去インシデント情報ＤＢ
２１ 単語発生頻度情報ＤＢ
３０ インシデントチケット
３０Ｎ 新規インシデントチケット
３１ インシデントＩＤ
３２ インシデント生成時刻
３３ インシデント完了時刻
３５ インシデントの内容
３６，３７，３８ 更新情報

Claims (4)

1. 事象に対する１以上の対処情報を事象毎に記録した事象情報から前記対処情報の数に応じて前記事象情報を複数のカテゴリに分類し、
   分類したカテゴリ毎に前記事象情報に含まれる単語毎の発生頻度を算出し、
   新たな事象の受け付けに応じて、前記新たな事象の事象情報に含まれる単語と、算出した前記単語毎の発生頻度とに基づき、前記新たな事象が含まれるカテゴリを推定する、
   処理をコンピュータに実行させる工数推定プログラム。
2. 推定した前記新たな事象のカテゴリに関する情報を出力する、
   請求項１に記載の工数推定プログラム。
3. 事象に対する１以上の対処情報を事象毎に記録した事象情報から前記対処情報の数に応じて前記事象情報を複数のカテゴリに分類し、
   分類したカテゴリ毎に前記事象情報に含まれる単語毎の発生頻度を算出し、
   新たな事象の受け付けに応じて、前記新たな事象の事象情報に含まれる単語と、算出した前記単語毎の発生頻度とに基づき、前記新たな事象が含まれるカテゴリを推定する、
   処理をコンピュータが実行する工数推定方法。
4. 事象に対する１以上の対処情報を事象毎に記録した事象情報から前記対処情報の数に応じて前記事象情報を複数のカテゴリに分類する分類部と、
   分類したカテゴリ毎に前記事象情報に含まれる単語毎の発生頻度を算出する算出部と、
   新たな事象の受け付けに応じて、前記新たな事象の事象情報に含まれる単語と、算出した前記単語毎の発生頻度とに基づき、前記新たな事象が含まれるカテゴリを推定する推定部と、
   を有する工数推定装置。

Images