JP2020064392A - 業務管理システム、業務管理方法、及びプログラム - Google Patents

Abstract

【課題】ユーザのタスク内容に変更があった際に、その旨をシステム管理者に通知することで、システムの管理者の負担の低減とタスク推定の精度の低下の防止を図ることできる業務管理システムを提供する。【解決手段】業務管理システムは、制御用プログラム２００において、ユーザの作業状況を示すワークログに対応するタスクを学習モデルに基づいて推定する推定手段と、ユーザに関連付けられているタスク内容に変更があったか否かを判断する判断手段と、前記タスク内容に変更があったと前記判断手段が判断した場合、第１の通知を行う通知手段と、を有する。【選択図】図２

Description

本発明は、オフィスなどにおいて行われるユーザの作業状況を解析し、タスクを推定する業務管理システム、業務管理方法、及びそのためのプログラムに関する。

従来、オフィスなどにおけるプロジェクトの管理業務を効率化することを目的とした業務管理システムが提案されている。このような業務管理システムにおいては、ユーザが担当しているプロジェクトの作業項目（以下、タスクという）をプロジェクト管理ツールに手動で入力する。そうすると、業務管理システムは、タスクの進捗状況をガントチャートなどを用いて見やすく可視化してシステム管理者などに提供する。
しかしながら、ユーザにとっては、日々のタスク遂行業務に加えて、自身が実施したタスクの実績や進捗状況等の入力を行わなければならないため、負担となっている。

こうした中、特許文献１には、ユーザのタスクに関する情報をあらかじめデータベースに登録しておき、データベースに登録された情報とユーザのパソコンに対する入力操作とを比較することでタスクを推定し、時間情報と共に記録する技術が開示されている。

特許第５８２５９１５号公報

しかしながら、特許文献１に開示された技術においては、タスクを推定するために、ユーザのタスクに関するすべての情報を事前にデータベースに登録する必要があった。このような手法によるタスク推定では、多種多様な業務に対して、それぞれのタスクを推定するためのルールをあらかじめ定義しておく必要があるため、非常に時間とコストがかかる。
また、ユーザのタスクは時間の経過とともに変更することがあり、こうした場合、新規のタスクに対応するために、システム管理者が各ユーザのタスクが変更になったことを随時、把握する必要がある。そのため、システム管理者の負担が大きくなってしまうという問題もある。

本発明は、ユーザの作業状況を示すワークログに対応するタスクを学習モデルに基づいて推定する推定手段と、ユーザに関連付けられているタスク内容に変更があったか否かを判断する判断手段と、前記タスク内容に変更があったと前記判断手段が判断した場合、第１の通知を行う通知手段と、を有することを特徴とする。

本発明によれば、ユーザのタスク内容に変更があった際に、その旨をシステム管理者に通知することで、システムの管理者の負担の低減とタスク推定の精度の低下の防止を図ることできる。

業務管理システムのハードウェア構成の一例を示す図である。 サーバ装置が実行する制御用プログラムの機能構成を示す図である。 パソコン操作ログ、タスク一覧ＤＢ、学習データ、タスク推定結果の例である。 学習モデル生成処理のフローチャートである。 タスク推定処理のフローチャートである。 レポート表示処理を行う過程で表示される各画面である。 レポート表示処理を行う過程で表示される各画面である。 レポート表示処理（レポート生成処理）のフローチャートである。 タスク工数の集計処理を説明する図である。 レポート出力の例である。 タスク内容変更検知処理のフローチャートである。

以下、本発明を実施するための実施形態について図面を用いて説明する。ただし、この実施形態に記載されている構成要素はあくまで例示であり、本発明の範囲をこれらに限定する趣旨のものではない。

＜業務管理システムの構成＞
図１は、本実施形態の業務管理システム１００のハードウェア構成の一例を示す図である。
業務管理システム１００は、クライアント端末１１０、サーバ装置１３０、その他のシステム１４０、マネジメント端末１５０の各装置から構成される。これらの装置はネットワーク１２０を介して互いに接続される。なお、クライアント端末１１０、サーバ装置１３０、マネジメント端末１５０は、それぞれ、単一接続ではなく複数接続された構成であってもよい。

クライアント端末１１０は、業務管理対象であるユーザ１０１の作業に伴う一連の操作を入力するためのものである。クライアント端末１１０は、ユーザ１０１の作業状況を示すデータ（以下、ワークログという）を収集してサーバ装置１３０へ送信する。また、クライアント端末１１０は、ユーザ１０１の要求に応じて作業状況を表示する。

サーバ装置１３０は、クライアント端末１１０やその他のシステム１４０から送信されてきたワークログを分析することで、ユーザ１０１のワークログに対応するタスクを推定する。また、サーバ装置１３０は、推定したタスクに基づいて、ユーザ１０１の作業状況に関するレポートを作成する。

その他のシステム１４０は、ユーザ１０１の日々の予定を管理するスケジューラ１４１を備える。さらに、その他のシステム１４０は、日々のタスクの進捗管理や、ユーザがどのようなタスクに携わっているかを管理するプロジェクト管理ツール１４３などを備える。

マネジメント端末１５０は、業務管理システム１００を管理するシステム管理者１０２の作業に伴う一連の操作入力を行うためのものである。マネジメント端末１５０は、ユーザ１０１のタスクを推定するサーバ装置１３０の操作を行う。また、マネジメント端末１５０は、システム管理者１０２の要求に応じて業務管理システム１００の状態を表示する。

これらの装置は、それぞれ単体でネットワーク１２０に接続され、サーバ装置１３０にワークログとして送信する。なお、この他にもプロジェクト管理に必要な各種装置を追加しても構わない。また、サーバ装置１３０とマネジメント端末１５０は、同一の装置であっても構わない。

ネットワーク１２０は、クライアント端末１１０、サーバ装置１３０、その他のシステム１４０の各装置を互いに接続するためのものである。ネットワーク１２０を介して、ユーザ１０１のワークログや作業実績などが送受信される。

＜クライアント端末１１０の構成＞
クライアント端末１１０は、一般的なパーソナルコンピュータ（ＰＣ）等で実現される。クライアント端末１１０は、例えば、通信部１１１、制御部１１２、記憶部１１３、操作部１１４、表示部１１５で構成される。

通信部１１１は、ＬＡＮ等で実現される。通信部１１１は、ネットワーク１２０を介してサーバ装置１３０との間でデータを送受信するためのインタフェース部である。特に、本実施形態の通信部１１１は、操作部１１４で収集したユーザのワークログ２１０（図２（ａ）参照）をサーバ装置１３０に送信する。また、ワークログ２１０の送信は、検出されたタイミングでリアルタイムに送信してもよいし、所定時間内や所定量ごとに送信してもよい。

制御部１１２は、ＣＰＵ等で実現される。制御部１１２は、記憶部１１３に格納されたプログラムに従い、クライアント端末１１０の内部で扱うデータを処理する。特に、本実施形態の制御部１１２は、操作部１１４から得られるワークログ２１０の収集及び送信を制御するための機能を有する。

記憶部１１３は、ＲＯＭ、ＲＡＭ、ＨＤＤ等で実現される。記憶部１１３は、制御部１１２がクライアント端末１１０の内部で扱うデータ及びプログラムを格納する。なお、本実施形態の記憶部１１３は、後述する操作部１１４で収集したパソコン操作ログ２１１などを一時記憶する構成であってもよい。

操作部１１４は、キーボード、マウス等で実現される。操作部１１４は、ユーザによるキー押下やマウスクリック操作などの操作入力を受信すると、その時のユーザの作業に伴うパソコン操作ログ２１１をワークログ２１０として収集する。なお、収集されるパソコン操作ログ２１１の詳細については、後述する。

表示部１１５は、ディスプレイ等で実現される。表示部１１５は、ユーザの作業に伴って実行された、文書作成、表計算、プレゼンテーション作成、スケジュール管理、プロジェクト管理などのプログラムにより作成された画面を表示する。

＜サーバ装置１３０の構成＞
サーバ装置１３０は、通信部１３１、制御部１３２、記憶部１３３で構成される。
通信部１３１は、ＬＡＮ等で実現される。通信部１３１は、ネットワーク１２０を介してクライアント端末１１０との間でデータを送受信するためのインタフェース部である。

制御部１３２は、ＣＰＵ等で実現される。制御部１３２は、記憶部１３３に格納された制御用プログラム２００に従い、サーバ装置１３０の内部で扱うデータを処理する。特に、本実施形態の制御部１３２は、通信部１３１で受信したワークログ２１０を解析するための機能を有する。

記憶部１３３は、ＲＯＭ、ＲＡＭ、ＨＤＤ等で実現される。記憶部１３３は、制御部１３２がサーバ装置１３０の内部で扱うデータ及びプログラム２００（図２（ａ）参照）を格納する。なお、本実施形態の記憶部１３３は、通信部１３１で受信したワークログ２１０や、制御部１３２で解析された結果などを一時記憶する構成であってもよい。

＜マネジメント端末１５０の構成＞
マネジメント端末１５０は、一般的なパーソナルコンピュータ（ＰＣ）等で実現される。マネジメント端末１５０は、例えば、通信部１５１、制御部１５２、記憶部１５３、操作部１５４、表示部１５５で構成される。

通信部１５１は、ＬＡＮ等で実現される。通信部１５１は、ネットワーク１２０を介してサーバ装置１３０とその他システム１４０との間でデータを送受信するためのインタフェース部である。特に、本実施形態の通信部１５１は、その他システム１４０が操作された際にその状況を受信したり、サーバ装置１３０との間でデータの送受信を行う機能を有する。

制御部１５２は、ＣＰＵ等で実現される。制御部１５２は、記憶部１５３に格納されたプログラムに従い、マネジメント端末１５０の内部で扱うデータを処理する。特に、本実施形態の制御部１５２は、その他システム１４０の状況を表示部１５５に表示する機能を有する。

記憶部１５３は、ＲＯＭ、ＲＡＭ、ＨＤＤ等で実現される。記憶部１５３は、制御部１５２がマネジメント端末１１０の内部で扱うデータ及びプログラムを格納する。

操作部１５４は、キーボード、マウス等で実現される。操作部１５４を介して、システム管理者１０２は制御部１５２に実行させるコマンドを入力できることができる。
表示部１５５は、ディスプレイ等で実現される。表示部１５５は、システム管理者１０２の作業に伴って実行された、システム管理等のプログラムによる出力画面を表示する。

＜サーバ装置１３０の制御用プログラム２００の機能構成＞
図２は、サーバ装置１３０が実行する制御用プログラム２００の機能構成を示す図である。

図２（ａ）に示す業務管理システム１００の制御用プログラム２００は、前述のように記憶部１３３に格納され、ＣＰＵが起動する時に制御部１３２によりＲＡＭ上に展開され、実行される。

ワークログ２１０は、クライアント端末１１０で収集されて送信されるデータ及び、その他のシステム１４０より取得されるデータである。ワークログ２１０は、サーバ装置１３０の通信部１３１で受信されて、記憶部１３３に格納される。ワークログ２１０の詳細については、図３を用いて後述する。

入力部２２０は、記憶部１３３に格納されたワークログ２１０を入力データとして取得する。
フィルタリング処理部２３０は、タスク推定部２４０でタスクを推定する処理、及び、学習モデル生成部２８０で学習モデル２４１を生成する処理において必要となる解析要素を、ワークログ２１０の中から抽出し、所定フォーマットに変換する。

タスク推定部２４０は、フィルタリング処理されたワークログ２１０を、機械学習を用いて解析することで対応するタスクを推定する。タスク推定部２４０は、学習モデル２４１、学習モデル処理部２４２、出力タスク推定部２４３、タスク推定結果２４４で構成される。
学習モデル２４１は、後述する学習モデル生成部２８０であらかじめ生成される。学習モデル２４１は、ワークログ２１０について対応するタスクを推定するために用いられる

学習モデル処理部２４２は、フィルタリング処理されたワークログ２１０に対して、学習モデル２４１を用いて、タスク一覧ＤＢ２６０に登録されている所定のタスクへの評価値を算出する。

出力タスク推定部２４３は、学習モデル処理部２４２で算出された評価値に基づいて、推定したタスクを出力する。
タスク推定結果２４４は、出力タスク推定部２４３が出力した推定タスクを記録する。

タスク一覧ＤＢ２６０は、ユーザが作業する可能性があるすべてのタスクが登録されたデータベースである。タスク一覧ＤＢ２６０は、記憶部１３３に格納されている。タスク一覧ＤＢ２６０の詳細については、図３を用いて後述する。

学習モデル生成部２８０は、フィルタリング処理した学習データ２７０から、所定のタスクを推定するための学習モデル２４１を生成する。学習データ２７０の詳細については、図３を用いて後述する。
タスク工数集計部２９０は、タスク推定部２４０で推定された所定期間におけるすべてのタスクに基づいて、タスクごとの実行時間を合計した実行総時間（以下、タスク工数という）を集計する。また、タスク工数集計部２９０は、集計したタスク工数に関する可視化したレポートをユーザ１０１ごとに生成する。

出力部２５０は、タスク推定部２４０で推定されたタスク、及び、タスク工数集計部２９０で算出されたタスクごとのタスク工数やレポートを、サーバ装置１３０の通信部１３１を介して、クライアント端末１１０へ送信する。

＜ワークログ２１０について＞
図２（ｂ）に、ワークログ２１０の一例を示す。本実施形態においては、ワークログ２１０として、クライアント端末１１０の操作部１１４で収集されたパソコン操作ログ２１１を用いて説明する。

図３（ａ）は、本実施形態におけるワークログ２１０である、パソコン操作ログ２１１の一例である。パソコン操作ログ２１１には、ＩＤ３１１、時刻３１２、アプリケーション名３１３、操作対象情報３１４、操作内容３１５、入力キー情報３１６、カーソル位置３１７、ファイルプロパティ３１８などのフィールド情報が含まれる。

ＩＤ３１１には、各パソコン操作ログ２１１を特定するためのＩＤが格納される。
時刻３１２には、各パソコン操作ログ２１１を完了した時の時刻が格納される。
アプリケーション名３１３は、各パソコン操作ログ２１１を実行する際に利用されたアプリケーションの名称が格納される。

操作対象情報３１４には、例えば、ドキュメント文書であれば、ファイルの保存されているパス名とファイル名が格納される。また、Ｗｅｂ閲覧であれば、ＵＲＬ及びＷｅｂページタイトルが、メールソフトであれば、送信相手及び件名などの情報が、それぞれ、格納される。
操作内容３１５には、各パソコン操作ログ２１１においてユーザ１０１が行った操作内容が格納される。
入力キー情報３１６には、各パソコン操作ログ２１１においてユーザ１０１が入力したキー情報が格納される。
カーソル位置３１７には、各パソコン操作ログ２１１においてユーザ１０１が最後に操作した際のカーソルの位置が格納される。
ファイルプロパティ３１８には、各パソコン操作ログ２１１を実行する際に用いられたファイルのプロパティが格納される。

なお、フィールド情報は、図３（ａ）に示したものに限られるものではない。例えば、ドキュメント文書やＷｅｂページの全文、メールの本文や添付ファイル名、マウス操作がなされたＧＵＩパーツ情報（メニュー項目名やボタン名など）などを収集し、新たなフィールド情報として追加してもよい。

＜タスク一覧ＤＢ２６０について＞
次に、図２（ｃ）及び図３（ｂ）を用いて、プロジェクト管理ツール１４３で管理されるタスク一覧ＤＢ２６０について説明する。

図２（ｃ）は、タスクの一覧の例であり、各テーマと、各テーマに関連するタスクの例が示されている。
例えば、製品開発に携わるユーザについては、「○○製品開発」というテーマ名称に対して、「調査」、「仕様検討」、「実装／デバッグ」、「資料作成」、「打合せ／レビュー」、「相談」などのタスク名が挙げられる。
品質保証に携わるユーザについては、「□□機能評価」というテーマ名称に対して、「調査」、「評価手法検討」、「評価」、「資料作成」、「打合せ／レビュー」などのタスク名が挙げられる。
また、営業職のユーザについては、「△△販売営業」というテーマ名称に対して、「調査」、「販売戦略検討」、「資料作成」、「打合せ／レビュー」、「商談／電話対応」、「クレーム対応／アフターフォロー」などのタスク名が挙げられる。

同様に、広報や人材管理に携わるユーザについても、それらのテーマに含まれる各種のタスク名が挙げられる。
なお、タスク一覧ＤＢ２６０は、ここで紹介した以外の職種にも適用でき、登録するテーマ名称やタスク名の種類や抽象度も自由に設定できることは言うまでもない。

そして、図２（ｃ）に示されたタスクの一覧は、図３（ｂ）に示すようなタスク一覧ＤＢ２６０にまとめられる。
タスク一覧ＤＢ２６０において、ＩＤ３５１には、各タスクを特定するためのＩＤが格納される。
また、テーマ名称３５２には、各テーマの名称が格納され、タスク名３５３には、各テーマにおける作業項目を示すタスクの名称が格納される。

＜学習データ２７０について＞
次に、図３（ｃ）に、学習データ２７０の一例を示す。
学習データ２７０は、ワークログ２１０と、タスク一覧ＤＢ２６０に登録されている中でワークログに該当する１つのタスク（以下、正解タスクという）とが対応付けられて、記憶部１３３に格納されている。
例えば、図３（ｃ）に示すように、学習データ２７０には、ＩＤ３６１、時刻３６２、ワークログＩＤ３６３、正解タスクＩＤ３６４のフィールド情報が含まれる。

ＩＤ３６１には、図３（ａ）に示されるようなパソコン操作ログ２１１における各ワークログを一意に特定するためのＩＤが格納される。
時刻３６２には、パソコン操作ログ２１１を時系列でソートした際の時刻３１２についての情報が格納される。また、ワークログＩＤ３６３には、パソコン操作ログ２１１を時系列でソートした際の各ＩＤ３１１が格納される。
正解タスクＩＤ３６４には、各ワークログに対する正解タスクのＩＤ３５１が格納される。なお、図３（ｃ）の例では、１つのワークログＩＤに対して１つの正解タスクＩＤを対応付けする場合の例を示したが、所定時間内や所定量の複数のワークログに対して１つの正解タスクＩＤを対応付けしても構わない。

＜タスク推定結果２４４について＞
次に、図３（ｄ）に、タスク推定結果２４４の一例を示す。
タスク推定結果２４４は、学習データ２７０に基づいて、学習モデル処理部２４２が算出した評価値及び出力タスク推定部２４３が出力した推定タスクを、ワークログ２１０に紐づけて記録したものである。
例えば、図３（ｄ）に示すように、タスク推定結果２４４には、ＩＤ３７１、時刻３７２、ワークログＩＤ３７３、推定タスク３７４、評価値３７５のフィールド情報が含まれる。

なお、フィールド情報はこれに限るものではなく、例えば、判定結果の正誤情報などを記録するフィールドを追加することもできる。また、ここでは１つのワークログＩＤに対して１つのタスクを推定する場合の例を示したが、所定時間内や所定量の複数のワークログに対して１つの推定タスクを推定した場合には、複数のワークログＩＤと推定タスクＩＤを対応付けしても構わない。

＜学習モデル生成処理について＞
図４は、サーバ装置１３０において、クライアント端末１１０から送信されてくるワークログ２１０に対してタスクを推定するために用いられる学習モデル２４１を生成する処理（学習モデル生成処理）の一例を示すフローチャートである。

図４のステップＳ４１０において、サーバ装置１３０の入力部２２０は、記憶部１３３から学習データ２７０（図３（ｃ））を取得する。

ステップＳ４２０において、フィルタリング処理部２３０は、後述のタスク推定処理に必要な解析要素のみを抽出するために、学習データ２７０に含まれる情報をフィルタリング処理する。そして、学習モデル処理部２４２が利用する機械学習のアルゴリズムの入力データ形式に合ったフォーマットに変換する。

例えば、クライアント端末１１０において収集されたパソコン操作ログ２１１からは、タスクの実行時間を算出するための時刻３１２、タスクに関連するソフトを検出するためのアプリケーション名３１３などの解析要素を抽出することができる。また、タスクに関連するドキュメント文書情報やＷｅｂ閲覧／メール情報を特定するための操作対象情報３１４（ファイルパス／ファイル名／メール送信先／メール件名／ＵＲＬ／Ｗｅｂサイトタイトル）などの解析要素を抽出することもできる。
他にも、ファイル本文／メール本文／Ｗｅｂサイト本文を取得することで、全文情報あるいは全文中から頻出度の高いキーワードを抽出してもよい。また、フォルダの作成者情報やファイルサイズ、ボタンやメニュー選択などの特定のＵＩ操作内容など、タスク分析に活用できる情報を抽出してもよい。

ステップＳ４３０において、学習モデル生成部２８０は、フィルタリング処理された学習データ２７０と正解タスクに基づいて、機械学習を用いて学習モデル２４１を生成する。学習モデル２４１は、フィルタリング処理された１つのワークログ、あるいは所定時間内や所定量の複数のワークログに対して、タスク一覧ＤＢに登録されたタスクとの評価値を推定するためのモデルである。ワークログと正解タスクを関連付けて学習させることで、未知のワークログに対しても、タスクとの評価値を推定できるようになる。

ステップＳ４４０において、学習モデル生成部２８０は、ステップＳ４３０で生成された学習モデルを用いた際の推定精度が十分であるか否かを判定する。
推定精度が十分であると判定された場合には、ステップＳ４５０へ進む。推定精度が不十分であると判定された場合には、学習モデル生成処理を終了する。
なお、推定精度を求めるには、例えば、交差検証手法を用いることができる。交差検証手法は、学習データを学習用と検証用のデータに分け、学習用のデータに基づいて学習モデルを生成し、検証用のデータが正解タスクとして出力される割合を判定することにより学習モデルの精度を算出する方法である。

ステップＳ４５０において、学習モデル生成部２８０は、ステップＳ４３０で生成された学習モデルを、タスク推定用の学習モデル２４１として更新する。
これで、学習データ生成処理は終了する。

＜タスク推定処理について＞
図５は、サーバ装置１３０において、クライアント端末１１０から送信されてきたワークログ２１０に対するタスク推定を行う処理（タスク推定処理）の一例を示すフローチャート図である。

図５のステップＳ５１０において、サーバ装置１３０の入力部２２０は、記憶部１３３に格納されているワークログ２１０（図３（ａ））を解析対象として取得する。

ステップＳ５２０において、フィルタリング処理部２３０は、図４のステップＳ４２０と同様の処理を行う。すなわち、ワークログ２１０に含まれる情報をフィルタリングすることにより、後述のタスク推定処理に必要な解析要素のみを抽出する。そして、フィルタリング処理部２３０は、学習モデル処理部２４２が利用する機械学習のアルゴリズムの入力データ形式に合ったフォーマットにワークログ２１０を変換する。

ステップＳ５３０において、学習モデル処理部２４２は、ステップＳ５２０でフィルタリング処理されたワークログ２１０について、事前に生成済みの学習モデル２４１を用いて、機械学習によりタスク一覧ＤＢ２６０に登録されているタスクを推定する。その際、それぞれのタスクとの関係度合いを表す評価値を合わせて算出する。なお、タスクを推定する際、１つのワークログに対して１つのタスクを推定してもよいし、所定時間内や所定量の複数のワークログに対して１つの推定タスクを推定しても構わない。

ステップＳ５４０において、出力タスク推定部２４３は、ステップＳ５３０で推定された評価値に基づいて、推定タスクを出力する。この際、評価値が所定値以上であればステップＳ５３０で推定された推定タスクを出力する。一方、評価値が所定値未満であれば、例えば、「その他」と出力する。そして、出力タスク推定部２４３は、これらの出力を、図３（ｄ）に示すように、タスク推定結果２４４に格納する。

＜レポート表示処理について＞
図７は、ユーザ１０１の業務を可視化したレポートを表示する処理（レポート表示処理）の一例を示すフローチャートである。また、図６は、レポート表示処理を行う過程において、クライアント端末１１０の表示部１１５に表示される各画面である。

図７（ａ）のステップＳ７１０において、クライアント端末１１０の表示部１１５は、図６Ａ（１）に示すような生成レポート設定画面７１１を表示する。

ステップＳ７２０において、ユーザ１０１は、操作部１１４を介して生成レポート設定画面７１１を操作することで、生成するレポートに関する設定を行う。生成レポートに関する設定の詳細については、＜生成レポート設定について＞の欄で後述する。

ステップＳ７３０において、制御部１１２は、操作部１１４から設定完了通知を受信すると、通信部１１１を介して、サーバ装置１３０に対してレポート生成要求を送信する。

ステップＳ７４０において、サーバ装置１３０は、通信部１３１でレポート生成要求を受信すると、レポート生成処理を実行する。レポート生成処理の詳細については、図７（ｂ）のフローチャートを用いて後述する。

ステップＳ７５０において、表示部１１５は、サーバ装置１３０が生成したレポートを通信部１１１で受信すると、図８Ｂ（ｃ１）〜（ｃ３）に示すようなレポート確認画面８１０を表示する。
なお、レポート確認画面８１０には、図８Ｂ（ｃ１）〜（ｃ３）に示されるように、ＯＫボタン８３０の他に、修正ボタン８４０が表示される。

ステップＳ７６０において、制御部１１２は、レポート確認画面８１０においてタスクの修正が要求されたか否かを判定する。
ＯＫボタン８３０が押下された場合は、制御部１１２は、修正なしと判断して、レポート表示処理を終了する。一方、修正ボタン８４０が押下された場合には、制御部１１２は、タスクを修正するためのタスク修正画面１０１１を表示部１１５に表示する。

図６Ｂ（１）は、ユーザ１０１Ａの日報に対して修正ボタン８４０が押下された際の、タスク修正画面１０１１の一例を示す。
タスク修正１０１１には、ユーザ１０１Ａの業務内容一覧１０１２（図６Ｂ（１）に示される例では、２１７／１２／０７（金）における業務内容）と、終了ボタン１０１５が表示される。ここで、ユーザ１０１は、タスク修正画面１０１１において、業務内容一覧１０１２の中から修正するタスクを選択し、タスクリスト１０１３から正しいタスクを選択することができる。
例えば、修正したいタスク１０１３を選択すると、図６Ｂ（２）に示すような、タスクリスト１０１７を含むタスク修正画面１０１６が表示される。そして、ユーザ１０１は、タスクリスト１０１７から正しいタスクを選択することができる。なお、タスクリスト１０１７には、タスク一覧ＤＢ２６０に記録されているタスクが表示される。
なお、修正方法は、これに限るものではなく、図６Ａ（２）に示されるように、タスク手動入力画面１０３０において、開始／終了時間とタスクを入力することにより、手動で設定するようにしても構わない。
ユーザ１０１が終了ボタン１０１８（あるいは、終了ボタン１０１５）を押下すると、タスクの修正は終了し、操作部１１４は制御部１１２へ修正完了通知を送信する。

操作部１１４から修正完了通知を受信すると、ステップＳ７７０において、制御部１１２は、サーバ装置１３０に対して修正完了通知を送信する。
その後、ステップＳ７３０へ戻り、サーバ装置１３０は、再び、レポートの生成処理を行う。

＜生成レポート設定について＞
図６Ａ（１）を用いて、ステップＳ７２０において、ユーザ１０１が生成レポートに関する設定（生成レポート設定）を行う方法について説明する。

ユーザ１０１は、レポート生成の対象者設定７１３から、生成するレポートの対象者を一人選択する。なお、レポート生成可能なユーザは、あらかじめ設定しておくことで、対象者設定７１３に表示させることが可能である。

レポート形式設定７１４では、出力するレポート形式を設定する。出力レポート形式としては、１日分の業務内容をまとめた日報、１週間単位での業務内容をまとめた週報、１ヶ月単位での業務内容をまとめた月報、の中から、いずれかを選択することができる。なお、出力レポート形式については、これらの期間に限られるものではなく、半日単位のレポートや、数か月の開発プロセス単位のレポート形式としても構わない。

レポート開始日設定７１５では、出力するレポートの解析開始日を指定する。例えば、日報であれば、指定された開始日のレポートが生成される。また、週報又は月報であれば、それぞれ、指定された開始日から１週間又は１ヶ月のレポートが生成される。

すべての設定を終えた後、レポートを生成する場合、ユーザ１０１はＯＫボタン７１６を押下する。また、レポート生成をキャンセルする場合、ユーザ１０１はＣａｎｃｅｌボタン７１７を押下してレポート表示処理を終了する。
操作部１１４は、ＯＫボタン７１６の押下を検知すると、制御部１１２に設定完了通知を送信する。

＜レポート生成処理について＞
図７（ｂ）は、ステップＳ７４０において、クライアント端末１１０からのレポート生成要求を受信した際に、サーバ装置１３０が設定された形式のレポートを生成する処理（レポート生成処理）の一例を示すフローチャートである。また、図８Ａは、タスク工数の集計処理の様子を説明するための図面である。

図７（ｂ）のステップＳ７４１において、サーバ装置１３０の制御部１３２は、設定されたレポートを生成するために必要となる、ユーザ１０１ごとの集計対象期間におけるタスク工数を記憶部１３３から取得する。なお、タスク工数は、図５で説明したようなタスク推定処理により集計され、図８Ｂ（ｃ１）〜（ｃ３）のレポートに示されるように記録されているものとする。

ステップＳ７４２において、タスク工数集計部２９０は、タスク工数を集計する際の集計精度を指定する。集計精度は、例えば、タスクを集計する際の継続実行時間として指定することができる。これにより、継続実行時間未満で断片的に行われるタスクを集計対象から除外し、継続実行時間以上行われるタスクのみを集計することができるため、集計精度の調整が可能となる。
また、集計精度は、固定で使用してもよいし、出力するレポートに応じて変更してもよい。例えば、個人の日報を生成する場合は、日々の業務内容を詳細に把握するために、継続実行時間を短く（例えば、１分）することで集計精度を高く指定することができる。また、個人の週報やチームレポートを生成する場合には、大まかな業務内容を把握することが目的となるため、継続実行時間を長く（例えば、５分）することで集計精度を低く指定することができる。その他にも、図７（ａ）のステップＳ７２０において、生成レポート設定を行う際に、集計精度を手動で指定するようにしても構わない。

ステップＳ７４３において、タスク工数集計部２９０は、ステップＳ７４１で取得したタスク情報について、選択されたユーザ１０１の日付ごとのタスク工数を、ステップＳ７４２で指定された集計精度にしたがって集計する。そして、設定された期間（例えば、日報であれば１日分、週報であれば１週間分）のタスク工数を算出する。
例えば、継続実行時間を１分に指定した場合、タスク工数集計部２９０は、図８Ａ（ａ１）、（ａ２）に示すように、推定されたタスクを時系列に集計し、それぞれ、図８Ａ（ｂ１）、（ｂ２）に示すように各タスク工数を算出する。
また、継続実行時間を５分以上に指定した場合、タスク工数集計部２９０は、図８Ａ（ａ３）に示すように、５分以下で行われたタスクは直前のタスクと同一であるとみなして集計し、図８Ａ（ｂ３）に示すように各タスク工数を算出する。

ステップＳ７４４において、タスク工数集計部２９０は、ステップＳ７２０で指定されたレポート形式に適合するように、ステップＳ７４３で集計されたタスク工数を可視化したレポートを生成する。生成されたレポートは、通信部１３１を介して、クライアント端末１１０に送信される。
図８Ｂ（ｃ１）、（ｃ２）は、それぞれ、ユーザ１０１Ａに対する日報の出力例である。また、図８Ｂ（ｃ３）は、ユーザ１０１Ａに対する週報の出力例である。各レポートには、レポート名、ユーザ名、集計対象日が記載された表題（例えば、図８Ｂ（ｃ１）であれば、「ユーザＡ 日報 ［１２／０３（月）］」）、テーマ名称、タスク名、工数に関する情報が記載されている。
なお、タスク工数は、図８Ａ（ｂ１）〜（ｂ３）で集計された結果をそのまま出力しても構わないが、図８Ｂ（ｃ１）〜（ｃ３）に示されるように、例えば３０分単位など、ある程度まとまった単位で集計することが望ましい。また、出力するレポートのフォーマットはこれらに限るものではない。例えば、合計のタスク工数ではなく、開始時刻と終了時刻を出力してもよい。また、タスク工数が一定以上となるタスクのみをタスク工数順にソートして出力するなどしてもよい。

＜ワーカのタスク内容変更検知について＞
上述したようなタスク推定処理においては、ワーカのタスク内容に変更があった場合、タスク推定処理に用いる学習モデルを更新しなければ、推定精度が悪化してしまう可能性がある。そこで、本実施形態における業務管理システム１００では、ワーカのタスク内容が変更したこと検知する手段が設けられる。ここで、タスク内容とは、図３（ｂ）に示されるような、タスク一覧ＤＢ２６０に登録されている、ユーザごとに関連付けられている各種のタスクについての内容である。

また、ワーカのタスク内容の変更や学習モデルの更新は、一般的に、システム管理者１０２により行われる。そこで、ユーザ１０１のタスク内容の変更をシステム管理者１０２に把握させるため、ユーザ１０１のタスク内容にあった場合、本実施形態における業務管理システム１００では、システム管理者１０２にその旨が通知される。これにより、業務管理システム１００を管理するシステム管理者１０２の負担を低減させることができる。

図９は、業務管理システム１００において、ユーザのタスク内容に変更がある可能性があると判断された場合に、ユーザ１０１やシステム管理者１０２へ通知や確認を行う際の処理（タスク内容変更検知処理）のフローチャートである。

ステップＳ９１０において、サーバ装置１３０の制御部１３２は、ユーザ１０１が携わるタスクの内容に変更があるか否かを、タスク一覧ＤＢ２６０の情報を用いて判断する。この判断は、タスク一覧ＤＢ２６０で管理されているタスクに関するデータに変更があるか否かにより行われる。
なお、タスク一覧ＤＢ２６０内のデータの変更は、ユーザ１０１が、例えばその他のシステム１４０におけるプロジェクト管理ツール１４３やスケジューラ１４１を介して、自身の携わるタスクの変更を入力することにより、行うことができる。また、あるユーザが携わるタスク内容に変更がある場合、他のユーザが、プロジェクト管理ツール１４３やスケジューラ１４１を介して、タスク内容の変更を入力して、タスク一覧ＤＢ２０６のデータが変更されるようにしてもよい。

ステップＳ９１０でユーザ１０１のタスク内容に変更があると判断した場合、新たな学習データを用いて学習モデルの生成を行う必要がある。そこで、ステップＳ９２０において、制御部１３２は、その旨をマネジメント端末１５０の表示部１５５へ表示させることにより、システム管理者１０２に通知する。

タスクの内容に変更があった場合、そのユーザについては、現在の学習モデルではタスク推定の精度が悪化したり、正しいレポートが生成されなかったりすることにより、利便性が低下することが考えられる。
そこで、ステップＳ９３０において、制御部１３２は、レポートの生成を手動入力モードに切り替える。そして、ユーザ１０１がレポート生成要求（図７のフローチャートにおけるＳ７３０）を行った場合、図６Ａ（２）に示すようなタスク手動入力画面１０３０を表示部１１５に表示させ、手動入力モードであることをユーザ１０１に通知する。
なお、手動入力モードは、新たな学習モデルが生成されると、再び、従来の自動入力モードに切り替えられる。また、手動入力モードへの切り替えを行わないように設定することも可能である。

ステップＳ９１０でユーザ１０１のタスク内容の変更がその他システム１４０において行われていないと判断した場合、ステップＳ９４０において、制御部１３２は、学習モデル処理部２４２から出力された評価値が低下していないかを確認する。

評価値を確認する目的は、その他システム１４０を介してユーザ１０１のタスク内容の変更は入力されていないが、実際にはユーザ１０１のタスク内容に変更があった可能性があるためである。ここで、評価値が低下していないかは、図３（ｄ）に示されるタスク推定結果２４４における評価値３７５の値が所定値よりも低いか否かにより判断することができる。

ステップＳ９４０において評価値が低下していると判断された場合、タスクの内容に変更があったか否かの確認を行うようにユーザ１０１に要求する。そこで、ステップＳ９５０において、制御部１３２は、図６Ｂ（３）に示すような、タスク変更確認画面１０４０を表示部１１５に表示させる。

そして、ステップＳ９６０において、制御部１３２は、タスク変更確認画面１０４０（図６Ｂ（３））においてユーザ１０１によりＮＯボタン１０２０が押下されたか否かを判別する。
ユーザ１０１によりＮＯボタン１０２０が押下された場合、ステップＳ９７０において、制御部１３２は、評価値が低下した原因の解析を行う旨をマネジメント端末１５０の表示部１５５へ表示させる。これは、ユーザのタスク内容の変更がないのにもかかわらず評価値が低下しているため、学習モデルの構成が正しいか否かを管理者１０２が確認する必要があるためである。
そして、ステップＳ９３０へ移行する。

一方、ステップＳ９６０においてユーザによりＹＥＳボタン１０１９が押下された場合、ステップＳ９２０へ移行する。そして、上述のとおり、制御部１３２は、タスク内容に変更があった旨をマネジメント端末１５０の表示部１５５へ表示させることにより、システム管理者１０２に通知する。

また、ステップＳ９４０において評価値が低下していないと判断された場合は、ステップＳ９８０に移行し、制御部１３２は、タスク修正回数が一定以上であるか否かの判断を行う。
タスク修正回数が一定以上であるか否かの判断は、例えば、一定期間内におけるユーザごとのタスク修正回数が所定回数を超えるか否かにより行ってもよい。例えば、タスク修正画面１０１６（図６Ｂ（２））において、一週間以内にタスクの修正が５回以上なされた場合、タスク修正回数が一定以上であると判断する。また、レポート確認画面８１０（図８Ｂ（ｃ１）〜（ｃ３））において修正ボタン８４０が一週間以内に５回以上押下された場合は、タスク修正回数が一定以上であると判断する。
ステップＳ９８０においてタスク修正回数が一定以上であった場合、ステップＳ９５０へ移行する。

以上のように、本実施形態においては、日報や週報などを作成するために、ユーザの作業状況を解析して各タスクに分類する業務管理システムにおいて、タスク内容に変更があったか否かを自動的に判断する。そして、ユーザの業務の内容に変更があった場合には、その旨をシステム管理者に通知する。
これにより、システムの管理者の負担の低減とタスク推定の精度の低下の防止を図ることできる。
また、ユーザの業務の内容の変化に学習モデルの精度が低下してきた場合においても、その旨を管理者に通知して、学習モデルが正しいか否かの確認を促すことができるため、利便性の低下を防ぐことができる。

（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上述の実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形が可能であり、それらを本発明の範囲から除外するものではない。すなわち、上述の実施形態及びその変形例を組み合わせた構成もすべて本発明に含まれるものである。

１１０ クライアント端末
１３０ サーバ装置
１５０ マネジメント端末
２１０ ワークログ
２４０ タスク推定部
２４１ 学習モデル
２６０ タスク一覧ＤＢ
２７０ 学習データ
２８０ 学習モデル生成部
２９０ タスク工数集計部

Claims (18)

1. ユーザの作業状況を示すワークログに対応するタスクを学習モデルに基づいて推定する推定手段と、
   ユーザに関連付けられているタスク内容に変更があったか否かを判断する判断手段と、
   前記タスク内容に変更があったと前記判断手段が判断した場合、第１の通知を行う通知手段と、を有する
   ことを特徴とする業務管理システム。
2. 前記タスク内容の変更が入力された場合、前記判断手段は前記タスク内容に変更があったと判断する
   ことを特徴とする請求項１に記載の業務管理システム。
3. 前記タスク内容を格納する記憶手段を有し、
   前記記憶手段に格納されている前記タスク内容について変更があった場合、前記判断手段は前記タスク内容に変更があったと判断する
   ことを特徴とする請求項１に記載の業務管理システム。
4. 前記ワークログについて、前記推定手段により推定されたタスクに対する評価値を算出する算出手段を有する
   ことを特徴とする請求項１に記載の業務管理システム。
5. 前記評価値が所定の値より低い場合、前記判断手段は前記タスク内容に変更があったと判断する
   ことを特徴とする請求項４に記載の業務管理システム。
6. 前記評価値が所定の値より低い場合、前記タスク内容に変更があったか否かの確認を要求する
   ことを特徴とする請求項４に記載の業務管理システム。
7. 前記タスク内容に変更がないことが確認された場合、前記通知手段は第２の通知を行う
   ことを特徴とする請求項６に記載の業務管理システム。
8. 前記タスク内容に変更があることが確認された場合、前記通知手段は前記第１の通知を行う
   ことを特徴とする請求項６に記載の業務管理システム。
9. 前記推定手段により推定されたタスクを修正する修正手段を有する
   ことを特徴とする請求項１に記載の業務管理システム。
10. 前記修正手段において一定以上の修正がなされた場合、前記判断手段は前記タスク内容に変更があったと判断する
    ことを特徴とする請求項９に記載の業務管理システム。
11. 前記修正手段において一定以上の修正がなされた場合、前記タスク内容に変更があったか否かの確認を要求する
    ことを特徴とする請求項９に記載の業務管理システム。
12. 前記タスク内容に変更がないことが確認された場合、前記通知手段は第２の通知を行う
    ことを特徴とする請求項１１に記載の業務管理システム。
13. 前記タスク内容に変更があることが確認された場合、前記通知手段は前記第１の通知を行う
    ことを特徴とする請求項１１に記載の業務管理システム。
14. 前記推定手段により推定された前記タスクに基づいてレポートを生成する生成手段を有する
    ことを特徴とする請求項１乃至１３のいずれか１項に記載の業務管理システム。
15. 前記生成手段は、前記タスクの実行時間を合計した実行総時間に基づいて前記レポートを生成する
    ことを特徴とする請求項１４に記載の業務管理システム。
16. 前記生成手段は、前記実行時間が指定された時間以上である前記タスクのみを集計して前記実行総時間を集計する
    ことを特徴とする請求項１５に記載の業務管理システム。
17. ユーザの作業状況を示すワークログに対応するタスクを学習モデルに基づいて推定する推定ステップと、
    ユーザに関連付けられているタスク内容に変更があったか否かを判断する判断ステップと、
    前記タスク内容に変更があったと前記判断ステップにおいて判断された場合、第１の通知を行う通知ステップと、を有する
    ことを特徴とする業務管理方法。
18. 請求項１７に記載の業務管理方法をコンピュータにより実行させるためのプログラム。