(57)【要約】      （修正有）【課題】任意形式のログ情報から業務仕様が再生可能となるように支援する情報処理装置を提供する。【解決手段】情報処理装置１の制御部１１は、設定ファイル生成部１１１と標準ログ生成部１１２を備える。設定ファイル生成部は、業務仕様再生システムによる業務仕様の再生対象となるＷｅｂログ１５１の事前処理（標準ログ１５５に記述されることになる必須情報を選択する等）を行った結果と、ログレイアウト情報１５２が示す標準ログのレイアウトに従って、Ｗｅｂログを加工して設定ファイル１５３を生成する。標準ログ生成部は、Ｗｅｂログのうち、業務仕様再生システムによる業務仕様の再生の有効部分を洗い出し、設定ファイルを読み込み、設定ファイルに含まれる、業務仕様再生に有効なＷｅｂログを変換して標準ログを生成する。【選択図】図１
2018136636.tif 000002
【特許請求の範囲】
【請求項１】
ユーザの業務上の操作を記録した操作ログを処理する情報処理装置であって、
前記操作ごとに、当該操作を行ったユーザと、当該操作が行われた日時と、当該操作による処理内容とを特定し、
前記特定したユーザと、日時と、処理内容とに基づいて、当該処理内容として実行される作業を複数組み合わせた案件を設定し、
前記設定した案件ごとに、当該案件を実行したユーザと、当該案件を構成する複数の作業と、当該作業の各々の開始日時および終了日時とを関連付けた操作ログを生成する制御部、を備える、
ことを特徴とする情報処理装置。
【請求項２】
前記制御部は、
前記処理内容に記述されているアクセス先を辿って遷移可能となる複数の作業を組み合わせることで１つの案件を設定する、
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記案件の区切りを象徴する作業を区切り作業として予め登録しており、
前記制御部は、
前記区切り作業としての第１の区切り作業が実行されてから、前記区切り作業としての第２の区切り作業が実行されるまでに実行された作業を複数組み合わせることで１つの案件を設定する、
ことを特徴とする請求項１に記載の情報処理装置。
【請求項４】
前記制御部は、
前記処理内容として実行される第１の作業が実行された日時と、前記第１の作業の後に実行される第２の作業が実行された日時との間隔が所定時間を超える場合には、前記第１の作業の終了を当該第１の作業を含む案件の終了とみなして、１つの案件を設定する、
ことを特徴とする請求項１に記載の情報処理装置。
【請求項５】
前記情報処理装置が処理する操作ログは、Ｗｅｂログである、
ことを特徴とする請求項１から請求項４のいずれか１項に記載の情報処理装置。
【請求項６】
ユーザの業務上の操作を記録した操作ログを処理する情報処理装置のおける情報処理方法であって、
前記情報処理装置の制御部が、
前記操作ごとに、当該操作を行ったユーザと、当該操作が行われた日時と、当該操作による処理内容とを特定するステップと、
前記特定したユーザと、日時と、処理内容とに基づいて、当該処理内容として実行される作業を複数組み合わせた案件を設定するステップと、
前記設定した案件ごとに、当該案件を実行したユーザと、当該案件を構成する複数の作業と、当該作業の各々の開始日時および終了日時とを関連付けた操作ログを生成するステップと、を実行する、
ことを特徴とする情報処理方法。
【請求項７】
前記制御部は、
前記処理内容に記述されているアクセス先を辿って遷移可能となる複数の作業を組み合わせることで１つの案件を設定する、
ことを特徴とする請求項６に記載の情報処理方法。
【請求項８】
前記案件の区切りを象徴する作業を区切り作業として予め登録しており、
前記制御部は、
前記区切り作業としての第１の区切り作業が実行されてから、前記区切り作業としての第２の区切り作業が実行されるまでに実行された作業を複数組み合わせることで１つの案件を設定する、
ことを特徴とする請求項６に記載の情報処理方法。
【請求項９】
前記制御部は、
前記処理内容として実行される第１の作業が実行された日時と、前記第１の作業の後に実行される第２の作業が実行された日時との間隔が所定時間を超える場合には、前記第１の作業の終了を当該第１の作業を含む案件の終了とみなして、１つの案件を設定する、
ことを特徴とする請求項６に記載の情報処理方法。
【請求項１０】
前記情報処理装置が処理する操作ログは、Ｗｅｂログである、
ことを特徴とする請求項６から請求項９のいずれか１項に記載の情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置および情報処理方法に関する。
【背景技術】
【０００２】
旧システムから新システムに移行する際において、そのリプレースに伴うシステム開発（リプレース開発）が必要となる。リプレース開発では、新システムが旧システムの仕様を踏襲する部分が多くの割合を占め、旧システムの正確なドキュメントが残されていることが稀な場合がある。このような場合、旧システムのソースを解析することにより、その旧システムの仕様を再生させることが行われているが、システムレベルの仕様はソースから再生することができても、業務レベルの仕様（以下、業務仕様とよぶ場合がある）の再生は困難である場合が多い。したがって、従来では、業務レベルの仕様は、ユーザへのヒアリングや手順書などのドキュメントにより再生していることが多いが、ユーザの主観、手順書のメンテナンスがされていないなどの理由により、正確な仕様は把握できていない。
【０００３】
このような問題点に鑑み、例えば、特許文献１では、指定されたURLを起点として、Webページを取得、画面キャプチャ、ページに含まれるリンク抽出、リンク先のページ取得、という手順を再帰的に行うことでページ遷移を自動的に取得している。また、特許文献２では、プリンタや複合機の印刷を指示したユーザのＩＤ及び印刷した文書の画像を示す画像ログを蓄積し、この情報をもとに登録されたログレコード群に含まれる画像ログ同士の比較から、同一の個別業務に属するログレコードの集合を求め、その類似画像の処理時刻とユーザ情報等の属性により個別業務に対応する業務フローを推定している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−７９３４２号公報
【特許文献２】特開２００９−２２４９５８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、業務仕様を再生する場合には、業務仕様を再生するのに必須となるデータが、業務仕様を再生する計算機に入力されることが前提となっている。また、システムを運用して生成されるログ情報は、決められた規格を持たない任意形式であり、業務仕様を再生するのに必須となるデータを含むとは限らない。しかし、特許文献１，２には、業務仕様を再生するのに必須となるデータを取得する方法について記載も示唆もないため、任意形式のログ情報から業務仕様を再生することが困難となっている。
そこで、本発明は、このような事情に鑑みてなされたものであり、任意形式のログ情報から業務仕様が再生可能となるように支援することを目的とする。
【課題を解決するための手段】
【０００６】
前記目的を達成するために、本発明は、
ユーザの業務上の操作を記録した操作ログを処理する情報処理装置であって、
前記操作ごとに、当該操作を行ったユーザと、当該操作が行われた日時と、当該操作による処理内容とを特定し、
前記特定したユーザと、日時と、処理内容とに基づいて、当該処理内容として実行される作業を複数組み合わせた案件を設定し、
前記設定した案件ごとに、当該案件を実行したユーザと、当該案件を構成する複数の作業と、当該作業の各々の開始日時および終了日時とを関連付けた標準ログを生成する制御部、を備える、
ことを特徴とする。
また、本発明は、
ユーザの業務上の操作を記録した操作ログを処理する情報処理装置のおける情報処理方法であって、
前記情報処理装置の制御部が、
前記操作ごとに、当該操作を行ったユーザと、当該操作が行われた日時と、当該操作による処理内容とを特定するステップと、
前記特定したユーザと、日時と、処理内容とに基づいて、当該処理内容として実行される作業を複数組み合わせた案件を設定するステップと、
前記設定した案件ごとに、当該案件を実行したユーザと、当該案件を構成する複数の作業と、当該作業の各々の開始日時および終了日時とを関連付けた操作ログを生成するステップと、を実行する、
ことを特徴とする。
その他の手段については後記する。
【発明の効果】
【０００７】
本発明によれば、任意形式のログ情報から業務仕様が再生可能となるように支援することができる。
【図面の簡単な説明】
【０００８】
【図１】本実施形態の情報処理装置の機能構成図である。
【図２】Ｗｅｂログの具体例である。
【図３】標準ログの具体例である。
【図４】遷移チェーンの作成例１の説明図である。
【図５】遷移チェーンの作成例２の説明図である。
【図６】遷移チェーンの作成例３の説明図である。
【図７】遷移チェーンの作成例４の説明図である。
【図８】標準ログ生成処理のフローチャートである。
【発明を実施するための形態】
【０００９】
以下、本発明の好適な例となる実施形態について添付の図面を参照しながら詳細に説明する。
【００１０】
≪構成≫
図１に示すように、本実施形態の情報処理装置１は、特開２０１６−１３９１７８号公報（以下、参考文献という）の業務仕様再生システムが業務フロー（業務仕様書を作成するための情報）を生成する（業務仕様を再生する）ために用いる情報を出力する装置である。なお、本実施形態では、参考文献の業務仕様再生システムが業務フローを生成する手順そのものについては、説明を省略する。情報処理装置１は、制御部１１と、通信部１２と、入力部１３と、出力部１４と、記憶部１５とを備えたコンピュータである。
【００１１】
制御部１１は、情報処理装置１が実行する処理全体を制御する。制御部１１は、例えば、ＣＰＵ（Central Processing Unit）である。通信部１２は、ネットワーク（図示せず）を介して他のコンピュータと情報をやり取りするときのインターフェースとして機能する。入力部１３は、オペレータからの情報の入力を受け付ける。入力部１３は、例えば、キーボートやポインティングデバイスである。出力部１４は、制御部１１による処理結果を出力する。出力部１４は、例えば、ディスプレイである。記憶部１５は、制御部１１による処理結果を記憶する。記憶部１５は、例えば、ＨＤＤ（Hard Disk Drive），ＲＯＭ（Read Only Memory），ＲＡＭ（Random Access Memory）である。
記憶部１５上に読み込んだプログラムを制御部１１が実行することで、制御部１１が有する機能（後記）が実現される。
【００１２】
制御部１１は、設定ファイル生成部１１１と、標準ログ生成部１１２とを備える。設定ファイル生成部１１１は、後記する設定ファイル１５３を生成する。標準ログ生成部１１２は、後記する標準ログ１５５を生成する。
【００１３】
記憶部１５は、Ｗｅｂログ１５１と、ログレイアウト情報１５２と、設定ファイル１５３と、再生可能統計結果１５４と、標準ログ１５５とを記憶する。
Ｗｅｂログ１５１は、ユーザがユーザ端末を用いて業務を実行したことで、当該ユーザの業務上の操作を記録した操作ログである。操作ログは、ユーザ端末がアクセスするＷｅｂサーバ（図示せず）に記憶されるアクセスログとなる。情報処理装置１は、Ｗｅｂサーバから操作ログを取得してＷｅｂログ１５１として記憶部１５に記憶する。このようなＷｅｂログ１５１は、参考文献の業務仕様再生システム向けに生成されたログではなく、つまり、業務仕様再生システムに直ちに入力可能となる形式を有するログではない。
【００１４】
ログレイアウト情報１５２は、標準ログ生成部１１２が生成する標準ログ１５５のレイアウトを規定する情報である。レイアウトの態様は周知であり、詳細な説明は省略する。
【００１５】
設定ファイル１５３は、標準ログ生成部１１２が標準ログ１５５を生成する処理を実行する際に、標準ログ生成部１１２に読み込ませるファイルである。設定ファイル１５３は、ログレイアウト情報１５２のレイアウトに従ってＷｅｂログ１５１を加工したファイルである。設定ファイル１５３にて、参考文献の業務仕様再生システムが業務フローを生成するために必須となる必須情報が指定されている。本実施形態では、必須情報を、（１）業務上実行される案件の案件ＩＤ、（２）案件を実行するときにユーザ端末に表示されている画面の画面ＩＤ、（３）案件を実行するための操作を行うユーザ、（４）案件を実行するための操作の開始日時、（５）案件を実行するための操作の終了日時とする。案件は、１操作を特定できるユニークなものであり、複数の作業（操作による処理内容）の組み合わせに等しい。案件ＩＤは、１操作を特定できるユニークなＩＤを付番したものである。画面ＩＤは、ユーザが案件を構成する複数の作業のうち１つを実行する際にユーザ端末に表示されている画面のＩＤであり、作業の各々を識別する機能を持つ。必須情報はこれらの５種類に限定されない。必須情報の指定は、例えば、情報処理装置１のオペレータからの入力で実現することができる。
【００１６】
再生可能統計結果１５４は、Ｗｅｂログ１５１に記録された操作が行われる業務の内容および件数を集計したデータである。再生可能統計結果１５４によって特定されている業務は、参考文献の業務仕様再生システムの再生対象となる業務仕様に係る業務である。再生可能統計結果１５４は、標準ログ生成部１１２によって標準ログ１５５とともに生成される。
【００１７】
標準ログ１５５は、参考文献の業務仕様再生システムに入力可能となるようにＷｅｂログ１５１を変換した操作ログである。標準ログ１５５は、中間生成ログであり、業務情報を仕様化するために必要な入力情報である。標準ログ１５５は、設定ファイル１５３にて指定されている必須情報を、操作ごとに含む。
【００１８】
図２に示すように、Ｗｅｂログ１５１は、ユーザの業務上の１操作を１行で表現し、複数行分まとめて記述されている。図２では、Ｗｅｂログ１５１の一部分だけを示す。Ｗｅｂログ１５１の各行は、ＩＰアドレス（符号２１）と、アクセス日時（符号２２）と、リクエスト（符号２３）と、ＵＲＬ（符号２４）と、リファラ（符号２５）とを含む。
【００１９】
また、図３に示すように、標準ログ１５５は、Ｗｅｂログ１５１とは別態様でユーザの業務上の１操作を１行で表現し、複数行分まとめて記述されている。標準ログ１５５の各行は、ユーザＩＤ（符号３１）と、案件ＩＤ（符号３２）と、画面ＩＤ（符号３３）と、開始日時（符号３４）と、終了日時（符号３５）とを含む。
【００２０】
標準ログ生成部１１２は、標準ログ１５５を生成する際、Ｗｅｂログ１５１のＩＰアドレス（符号２１）を利用してユーザＩＤ（符号３１）を生成する。もし、Ｗｅｂログ１５１からＩＰアドレス（符号２１）を取得できない場合は、標準ログ生成部１１２は、セッションＩＤ（図２のリファラ（符号２５）の構成要素）を利用してユーザＩＤ（符号３１）を生成することができる。
【００２１】
また、標準ログ生成部１１２は、標準ログ１５５の各操作（行）について、同じ案件に対して行われていると推定できる操作群をグループ化して同じ案件ＩＤ（符号３２）を付すことができる。つまり、異なる操作群に対しては異なる案件ＩＤを付して、案件を区切り、標準ログ１５５に含まれる案件を画定することができる。リファラ（符号２５）は、案件の画定の一手段となり得る。案件の区切りの方法は、図４〜図７を参照して後記する。
【００２２】
また、標準ログ生成部１１２は、Ｗｅｂログ１５１のＵＲＬ（符号２４）を利用して画面ＩＤ（符号３３）を生成する。ＵＲＬ（符号２４）の名称が存在する場合には、図３に示すように、画面ＩＤ（符号３３）を日本語で表記することも可能である。
【００２３】
また、標準ログ生成部１１２は、Ｗｅｂログ１５１のアクセス日時（符号２２）を利用して開始日時（符号３４）と、終了日時（符号３５）とを生成する。開始日時（符号３４）は、アクセス日時（符号２２）が示す日時と同じにする。Ｗｅｂログ１５１には、終了日時（符号３５）に相当する日時が元々記録されないため、終了日時（符号３５）は、開始日時（符号３４）と同じ日時を便宜上設定する。
【００２４】
なお、図３中の符号３６は、各操作を行うユーザの役職を示す値（例：申請者、承認者）が入力される欄である。Ｗｅｂログ１５１中のＩＰアドレスで特定されるユーザの役職（ロール）が判明している場合には、当該役職を符号３６の欄に入力することができる。Ｗｅｂログ１５１中のＩＰアドレスで特定されるユーザの役職が判明していない場合、図３に示すように、符号３６の欄には、“不明”が入力される。情報処理装置１は、役職（ロール）が判明しているユーザごとに、ユーザと役職とを関連付けたロール対応表を記憶部１５に記憶することができる。また、設定ファイル１５３は、標準ログ１５５において、案件を実行するための操作を行うユーザに対して、当該ユーザの役職も記録するか否かを決定するフラグを有してもよい。
【００２５】
＜案件の区切りの方法＞
図３に示す標準ログ１５５中の複数のログに対して、案件ＩＤ（符号３２）を付し、案件を区切る方法はさまざまであり、遷移チェーンという考え方を導入する。遷移チェーンは、ユーザが行った1回の作業を纏めたものである。遷移チェーンの例としては、１ログイン〜ログアウトであったり、申請・承認などの作業を１つとしたものであったり、時間差に基づいて１つでくくることも出来るものであったりする。遷移チェーンは、同じ案件にて行われたと推定された操作群をグループ化する機能を有する。
【００２６】
（遷移チェーンの作成例１）
図２に示すリファラ（符号２５）を用いて遷移チェーンを作成することができる。図４に示すように、紙面下方向がアクセス日時（図２符号２２参照）の昇順となるＷｅｂログ１５１の操作ごとに、リクエスト元と、リクエスト（図２符号２３参照）とが定められている場合について説明する。なお、リクエスト元は、Ｗｅｂログ１５１のリファラ（図２符号２５参照）に記述されている。この場合、最後のリクエスト元から直前の操作ログのリクエストを辿る（図４にて矢印で図示）といった手順を繰り返し、辿ることができなくなった操作ログで案件を区切り、辿ることができた操作ログ群について１つの遷移チェーンを設定する。以降、遷移チェーンが設定されていない最後のリクエスト元に対して上記の手順を繰り返す。
【００２７】
上記によれば、リクエスト元に所定の値を有しない（図４では「−」で図示））操作ログは、遷移チェーンが設定された操作ログ群のうち最初の操作ログとなり、案件の区切りの目印となる。図４によれば、３行目の操作ログのリクエスト元がブランクであるため、３行目の操作ログから新たな案件についての操作が開始したと推定することができる。このため、２行目の操作ログを以って案件を区切り、１行目〜２行目の操作ログ群に対して１つの遷移チェーンを設定する。その結果、図４に示すように、１行目〜２行目の操作ログ群に対して「CHAIN1」という名称の案件ＩＤが付される。
【００２８】
また、６行目の操作ログのリクエスト元がブランクであるため、６行目の操作ログから新たな案件についての操作が開始したと推定することができる。このため、５行目の操作ログを以って案件を区切り、３行目〜５行目の操作ログ群に対して１つの遷移チェーンを設定する。その結果、図４に示すように、３行目〜５行目の操作ログ群に対して「CHAIN2」という名称の案件ＩＤが付される。以下、同様にして、案件を区切るたびに、「CHAIN3」、「CHAIN4」という名称の案件ＩＤが付される。
なお、案件ＩＤの名称の付け方はユニークであれば任意である。
【００２９】
（遷移チェーンの作成例２）
Ｗｅｂログ１５１中に、案件の区切りを象徴するリクエスト（作業）を発見した場合、遷移チェーンを作成することができる。例えば、ユーザがログインの操作や、ポータル画面を表示する操作をした場合には、当該ユーザが作業中の案件を終了したと推定することができる。そこで、ログインやポータル画面などのリクエストを、案件の区切りの象徴するリクエストとして記憶部１５または標準ログ 生成部１１２用のプロパティファイルに予め登録する。
【００３０】
図５に示すように、紙面下方向がアクセス日時（図２符号２２参照）の昇順となるＷｅｂログ１５１の操作ごとにリクエスト（図２符号２３参照）が定められている場合について説明する。案件の区切りの象徴するリクエストは、「ログイン」、「ポータル画面」であり、図５では、画面名による区切り条件として例示されている。
【００３１】
図５によれば、３行目の操作ログのリクエストが「ログイン」であるため、３行目の操作ログから新たな案件についての操作が開始したと推定することができる。このため、２行目の操作ログを以って案件を区切り、１行目〜２行目の操作ログ群に対して１つの遷移チェーンを設定する。その結果、図５に示すように、１行目〜２行目の操作ログ群に対して「CHAIN1」という名称の案件ＩＤが付される。
【００３２】
また、６行目の操作ログのリクエストが「ポータル画面」であるため、６行目の操作ログから新たな案件についての操作が開始したと推定することができる。このため、５行目の操作ログを以って案件を区切り、３行目〜５行目の操作ログ群に対して１つの遷移チェーンを設定する。その結果、図５に示すように、３行目〜５行目の操作ログ群に対して「CHAIN2」という名称の案件ＩＤが付される。以下、同様にして、案件を区切るたびに、「CHAIN3」、「CHAIN4」という名称の案件ＩＤが付される。
【００３３】
（遷移チェーンの作成例３）
Ｗｅｂログ１５１中のクエリを用いて遷移チェーンを作成することができる。クエリは、リクエストに付随するパラメータである。作成例３は、作成例２と併せて使用することができる。例えば、クエリに特定のユーザを示す値が示されている場合、当該特定のユーザが作業中の案件を終了したことを推定することができる。そこで、特定のユーザなどを示唆する特定のクエリを、案件の区切りの象徴するクエリとして記憶部１５または標準ログ生成部１１２用のプロパティファイルに予め登録する。
【００３４】
図６に示すように、紙面下方向がアクセス日時（図２符号２２参照）の昇順となるＷｅｂログ１５１の操作ごとにリクエスト（図２符号２３参照）が定められている場合について説明する。リクエストにクエリが付随する場合、リクエストの後に「？」を付し、クエリが入力される。案件の区切りの象徴するリクエストは、「ログイン」、「ポータル画面」を採り上げ、図６では、画面名による区切り条件として例示されている。また、案件の区切りの象徴するクエリは、「userA」（ユーザＡを示す）、「userB」（ユーザＢを示す）を採り上げ、図６では、付随情報による区切り条件として例示されている。
【００３５】
図６によれば、３行目の操作ログのリクエストが「ログイン」であり、クエリが「id=userB」（ユーザＢを示すクエリ）であるため、３行目の操作ログから、ユーザＢに関する新たな案件についての操作が開始したと推定することができる。このため、２行目の操作ログを以って案件を区切り、１行目〜２行目のユーザＡに関する操作ログ群に対して１つの遷移チェーンを設定する。その結果、図６に示すように、１行目〜２行目のユーザＡに関する操作ログ群に対して「userA1」という名称の案件ＩＤが付される。
【００３６】
また、６行目の操作ログのリクエストが「ポータル画面」であるため、６行目の操作ログから新たな案件についての操作が開始したと推定することができる。このため、５行目の操作ログを以って案件を区切り、３行目〜５行目のユーザＢに関する操作ログ群に対して１つの遷移チェーンを設定する。その結果、図６に示すように、３行目〜５行目のユーザＢに関する操作ログ群に対して「userB2,CHAIN3」という名称の案件ＩＤが付される。以下、同様にして、案件を区切るたびに、「CHAIN4」、「userB2」、という名称の案件ＩＤが付される。
【００３７】
（遷移チェーンの作成例４）
図２に示すアクセス日時（符号２２）を用いて遷移チェーンを作成することができる。対象の操作ログのアクセス日時が、直前の操作ログのアクセス日時と大きく離れている場合、当該直前の操作ログを以って案件が終了し、当該対象の操作ログから新たな案件が開始したと推定することができる。そこで、隣接するアクセス日時の時間差の閾値を記憶部１５または標準ログ生成部１１２用のプロパティファイルに予め登録する。
【００３８】
図７に示すように、紙面下方向がアクセス日時（図７では単に「日時」）の昇順となるＷｅｂログ１５１の操作ごとに、画面名（リクエスト（図２符号２３参照）と同等。“？”以降は付随情報（クエリ））が定められている場合について説明する。隣接するアクセス日時の時間差の閾値は、例えば、３０分とし、図７では、時間差による区切り条件として例示されている。
【００３９】
図７によれば、６行目の操作ログの日時（2016/07/20_10:05）と、７行目の操作ログの日時（2016/07/20_11:10）との時間差が３０分以上であるため、７行目の操作ログから新たな案件についての操作が開始したと推定することができる。このため、６行目の操作ログを以って案件を区切り、１行目〜６行目の操作ログ群に対して１つの遷移チェーンを設定する。その結果、図７に示すように、１行目〜６行目の操作ログ群に対して「CHAIN1」という名称の案件ＩＤが付される。
【００４０】
また、１２行目の操作ログの日時（2016/07/20_11:15）と、１３行目の操作ログの日時（2016/07/21_10:30）との時間差が３０分以上であるため、１３行目の操作ログから新たな案件についての操作が開始したと推定することができる。このため、１２行目の操作ログを以って案件を区切り、７行目〜１２行目の操作ログ群に対して１つの遷移チェーンを設定する。その結果、図７に示すように、１行目〜６行目の操作ログ群に対して「CHAIN2」という名称の案件ＩＤが付される。以下、同様にして、時間差で案件を区切り、「CHAIN3」という名称の案件ＩＤが付される。
【００４１】
標準ログ生成部１１２は、上記の作成例１〜４に従って、標準ログ１５５（図３参照）を生成する。その際、個々の案件が特定されることになるので、標準ログ生成部１１２は、特定された案件に係る業務の内容と件数を、再生可能統計結果１５４として出力する。
【００４２】
≪処理≫
図８に示すように、情報処理装置１がＷｅｂログ１５１を変換して標準ログ１５５を生成するための標準ログ生成処理は以下の通りである。
まず、情報処理装置１は、参考文献の業務仕様再生システムによる業務仕様の再生対象となるＷｅｂログ１５１の事前処理を行う（ステップＳ１）。具体的には、標準ログ１５５に記述されることになる必須情報を選択する。また、業務上の作業を、当該作業が行われるときにユーザ端末に表示されている画面の画面ＩＤ（またはＵＲＬ）に対応付ける。また、ユーザの役職を標準ログ１５５に記録する場合には、ユーザと役職とを関連付けたロール対応表を記憶部１５に記憶する。その他、標準ログ１５５を参考文献の業務仕様再生システムに入力できるように、設計事項としてＷｅｂログ１５１を微編集する。
【００４３】
次に、情報処理装置１は、設定ファイル生成部１１１によって、ログレイアウト情報１５２が示す標準ログ１５５のレイアウト、および、ステップＳ１の事前処理の結果に従って、Ｗｅｂログ１５１を加工して設定ファイル１５３を生成する（ステップＳ２）。
【００４４】
次に、情報処理装置１は、標準ログ生成部１１２によって、Ｗｅｂログ１５１のうち、参考文献の業務仕様再生システムによる業務仕様の再生の有効部分を洗い出す（ステップＳ３）。具体的には、設定ファイル１５３に含まれている画像データ、ＣＳＳ（Cascading Style Sheets）データ、その他のノイズ情報を削除する。その結果、設定ファイル１５３に含まれるＷｅｂログ１５１は、業務仕様再生に有効なＷｅｂログ１５１となる。また、標準ログ生成部１１２は、業務仕様再生に有効なＷｅｂログ１５１を解析して、再生可能統計結果１５４を出力する。
【００４５】
次に、情報処理装置１は、標準ログ生成部１１２に設定ファイル１５３を読み込ませ、設定ファイル１５３に含まれる、業務仕様再生に有効なＷｅｂログ１５１を変換して標準ログ１５５を生成する（ステップＳ４）。具体的には、標準ログ生成部１１２は、Ｗｅｂログ１５１中の各操作ログから必須情報に相当する値を抽出する。また、標準ログ生成部１１２は、当該抽出した値を、参考文献の業務仕様再生システムに入力可能な値（図３参照）となるように編集する。また、標準ログ生成部１１２は、編集後の操作ログに対して、すでに説明した遷移チェーンの作成例１〜４（図４〜図７）に従って案件ＩＤを付す。
以上で、標準ログ生成処理が終了する。
【００４６】
本実施形態によれば、参考文献の業務仕様再生システム向けに生成されていない操作ログを、当該業務仕様再生システムに入力可能な標準ログ１５５に確実に変換することができる。
したがって、任意形式のログ情報から業務仕様が再生可能 となるように支援することができる。
【００４７】
また、操作ログに含まれる複数の操作から、複数の案件を設定する際に、案件を区切る方法は複数種類用意することができ、その方法を適切に選ぶことで、業務仕様再生システムによる業務仕様の再生の精度を向上させることができる。
【００４８】
また、操作ログがＷｅｂログ１５１である場合、Ｗｅｂログ１５１がどのような形式であっても業務仕様が再生可能となるように支援することができる。
【００４９】
（変形例）
本発明は、上記実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で、変更実施が可能であり、例えば、次の（ａ）、（ｂ）のようなものがある。
（ａ）：本実施形態の情報処理装置１が処理する操作ログは、本実施形態で説明したＷｅｂログであってもよいし、他の種類の記録媒体に記録された操作ログであってもよい。また、Ｗｅｂログの場合、本実施形態で説明したApache（登録商標）アクセスログでもよいし、他の種類のアクセスログでもよい。また、本実施形態の情報処理装置１は、操作ログに限らず、アプリケーションから出力されるログ等も処理することができる。つまり、情報処理装置１は、これらのログを包含する業務ログを処理することができる。アプリケーションの性能や業務ログの欠損などのために、本実施形態で説明した必須情報の一部または全部が業務ログに含まれていない場合がある。この場合、必須情報の一部または全部を含むデータを外部から入力し、業務ログに含める処理を行うことができる。
（ｂ）：操作ログで記録される操作のうち、業務の実行を事実上構成しない操作は除外してもよい。例えば、図５において、案件ＩＤとして「CHAIN1」が付されたリクエスト群（１行目と２行目）からなる案件は、ログイン画面でログインした後直ちにログアウトしただけであって、結局、ログインしたユーザは何ら作業を実行していない。この場合、情報処理装置１は、１行目と２行目のリクエスト群に案件ＩＤを付さないように処理してもよい。具体的には、情報処理装置１の記憶部１５に案件除外リストを記憶させ、案件除外リストに除外対象となる操作群（例えば、ログインと、ログインの直後のログアウトからなるリクエスト群）を登録すればよい。これにより、標準ログ１５５には、除外した案件が記録されず、参考文献の業務仕様再生システムに入力されることもないので、業務仕様再生システムによる業務仕様の再生の精度を向上させることができる。
【００５０】
また、本実施形態で説明した種々の技術を適宜組み合わせた技術を実現することもできる。
本実施形態で説明したソフトウェアをハードウェアとして実現することもでき、ハードウェアをソフトウェアとして実現することもできる。
その他、ハードウェア、ソフトウェア、フローチャートなどについて、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。
【符号の説明】
【００５１】
１      情報処理装置
１１    制御部
１２    通信部
１３    入力部
１４    出力部
１５    記憶部
１１１  設定ファイル生成部
１１２  標準ログ生成部
１５１  Ｗｅｂログ
１５２  ログレイアウト情報
１５３  設定ファイル
１５４  再生可能統計結果
１５５  標準ログ
【図１】
2018136636.tif 000003
【図２】
2018136636.tif 000004
【図３】
2018136636.tif 000005
【図４】
2018136636.tif 000006
【図５】
2018136636.tif 000007
【図６】
2018136636.tif 000008
【図７】
2018136636.tif 000009
【図８】
2018136636.tif 000010