JP2020052802A - 作業管理装置、その制御方法およびプログラム - Google Patents

Abstract

【課題】ユーザがした作業についての作業実績時間や作業実績工数だけに基づいては判断することができない作業の停滞を判断して、作業の停滞をより確からしく判断する作業管理装置、その制御方法及びプログラムを提供する。【解決手段】作業管理フローは、ユーザの作業についての作業単位での作業実績時間または作業実績工数とともにユーザの作業の状況または内容についての情報を取得し、取得した情報を記憶する記憶し、記憶している作業単位での作業実績時間または作業実績工数に基づいて、作業の停滞を判断し、記憶しているユーザの作業の状況または内容についての取得情報に基づいて、作業の停滞を判断し、上記判断の少なくとも一方において作業の停滞が判断される場合にメッセージを通知先へ通知する。【選択図】図１０

Description

本発明は、ユーザによる作業を管理する作業管理装置に関する。

業務におけるプロジェクトの作業者などのユーザは、そのプロジェクトを進めるために、プロジェクトに関するタスクといった作業を行う。この場合、プロジェクトの管理者は、ユーザによる作業の進捗度合いや内容を管理し、計画通りにプロジェクトが進行するように管理することが求められる。プロジェクトの管理者は、たとえば、予め与えられたスケジュール情報（作業日程）やプロジェクトの情報（作業時間、作業工数）と、ユーザの作業実績とを突き合わせて、ユーザの作業の進捗度合いを判断している。また、プロジェクトの管理者は、作業が停滞しているような場合には、必要に応じてプロジェクト全体での作業負荷のバランスを調整している。このようなプロジェクトの管理者を管理するために、ユーザによる作業を管理する作業管理装置を用いることが考えられる。たとえば、特許文献１は、作業者毎の作業内容に「計画遅れ」や「計画通り」などの囲み線を付与した表示画面をプロジェクトマネージャに対して表示する。これにより、プロジェクトの管理者は、作業者毎の作業負荷を容易に把握することができる。

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

ところで、特許文献１では、プロジェクトを管理するために、作業の実績時間に基づく判断により「計画遅れ」や「計画通り」などの判断をしている。しかしながら、プロジェクトの停滞の一部は時間管理により判断できるものの、プロジェクトにおいて実際に発生するすべての停滞の状態および内容を時間により判断することはできない。たとえば、実際の作業では、時間を計測するタイミングでは遅れが生じないこととなるとしても、ユーザの作業の状態、作業の内容などによっては一時的に遅れが生じることもある。プロジェクトの管理者にとっては、このような実際に大きな停滞が生じる前に、停滞の原因を直接的に把握できることが望ましい。特許文献１の技術では、このような要望に応えることが難しい。特許文献１は、作業の実績工数に基づいた作業の遅延状況を判断しているが、ユーザの作業の質や作業状況を加味した停滞リスクの判断ができない。ユーザの作業状況に応じた停滞判断が十分に行えない。また、特許文献２は、組織内のコミュニティを抽出し、そのコミュニティの質を可視化している。しかしながら、特許文献２では、コミュニティの質とユーザ毎の作業状況との間を関連づけていない。したがって、このようなコミュニティの質の情報が提供されたとしても、プロジェクトの管理者は、ユーザの個別の作業について改善策を講じることは難しい。このように、ユーザによる作業を管理する作業管理装置では、ユーザがした作業についての作業実績時間や作業実績工数だけに基づいては判断することができない作業の停滞を判断して、作業の停滞をより確からしく判断できることが求められている。

本発明の作業管理装置は、ユーザの作業を管理する作業管理装置であって、ユーザの作業についての作業単位での作業実績時間または作業実績工数とともにユーザの作業の状況または内容についての情報を取得する取得手段と、前記取得手段による取得情報を記憶する記憶手段と、前記記憶手段に記憶されている作業単位での作業実績時間または作業実績工数に基づいて、作業の停滞を判断する第一停滞判断手段と、前記記憶手段に記憶されているユーザの作業の状況または内容についての取得情報に基づいて、作業の停滞を判断する第二停滞判断手段と、前記第一停滞判断手段および前記第二停滞判断手段の中の少なくとも一方において作業の停滞が判断される場合にメッセージを通知先へ通知する通知手段と、を有する。

本発明では、ユーザがした作業についての作業実績時間や作業実績工数だけに基づいては判断することができない作業の停滞を判断して、作業の停滞をより確からしく判断することができる。

本発明の第一実施形態に係る作業管理装置を有する作業管理システムの構成図である。 図１のスケジュールＤＢのデータ構造の説明図である。 図１のプロジェクトＤＢのデータ構造の説明図である。 図１のタスク進捗ＤＢのデータ構造の説明図である。 図１の成果物ＤＢのデータ構造の説明図である。 図１の感情ＤＢのデータ構造の説明図である。 図１のコミュニケーションＤＢのデータ構造の説明図である。 図１のプロセスＤＢのデータ構造の説明図である。 図１の停滞ＤＢのデータ構造の説明図である。 ユーザの作業についての停滞判断からメッセージの通知までの処理の流れを示すメインフローチャートである。 作業単位での作業実績工数に基づく停滞判断の流れを示すフローチャートである。 作業単位の成果物に基づく停滞判断の流れを示すフローチャートである。 作業中のユーザの感情に基づく停滞判断の流れを示すフローチャートである。 作業開始後のコミュニケーション状態に基づく停滞判断の流れを示すフローチャートである。 作業単位についての作業状態に基づく停滞判断の流れを示すフローチャートである。 本発明の第二実施形態のプロジェクトＤＢのデータ構造の説明図である。 第二実施形態の停滞ＤＢのデータ構造の説明図である。

以下、本発明の実施形態について図面を参照しながら詳細に説明する。しかしながら、以下の実施形態に記載されている構成はあくまで例示に過ぎず、本発明の範囲は実施形態に記載されている構成によって限定されることはない。

［第１実施形態］
図１は、本発明の第一実施形態に係る作業管理装置を有する作業管理システム１００の構成図である。図１の作業管理システム１００は、クライアント端末１０、作業管理装置としてのサーバ装置３０、モニタリング装置４０、管理者端末５０、およびこれらが接続されるネットワーク２０、を有する。作業管理システム１００は、複数のクライアント端末１０、複数のサーバ装置３０、複数のモニタリング装置４０、複数の管理者端末５０、を有してよい。作業管理システム１００において、クライアント端末１０は、作業者としてのユーザが作業をする端末である。ユーザは、クライアント端末１０を用いてタスクなどの作業単位の作業をし、成果物を作成する。クライアント端末１０は、ユーザの作業中においてユーザの作業情報を生成し、ネットワーク２０を通じてサーバ装置３０へ送信する。モニタリング装置４０は、作業中のユーザまたは作業エリアをモニタする。モニタリング装置４０は、撮像した画像などを含むユーザの作業情報を生成し、ネットワーク２０を通じてサーバ装置３０へ送信する。サーバ装置３０は、クライアント端末１０やモニタリング装置４０から作業情報を受信する。サーバ装置３０は、取得した作業情報を、作業ログとして蓄積し、蓄積した作業ログに基づいてユーザの作業の停滞を判断する。サーバ装置３０は、作業の停滞判断結果に応じて、メッセージをネットワーク２０を通じてクライアント端末１０または管理者端末５０へ送信する。管理者端末５０は、ユーザの管理者、作業単位が属するプロジェクトの管理者、またはそれらの上位の管理者が使用する端末である。管理者端末５０およびクライアント端末１０は、サーバ装置３０からメッセージを受信して表示する。これにより、メッセージは、ユーザまたは管理者へ通知され得る。ネットワーク２０は、装置間において上述した各種のデータを送受信するために用いられるＬＡＮ等である。

クライアント端末１０は、ユーザが作業に使用するものである。クライアント端末１０は、たとえば通信部１１、制御部１２、記憶部１３、操作部１４、表示部１５、検出部１６、およびこれらを接続するシステムバス、を有するパーソナルコンピュータ装置である。通信部１１は、ネットワーク２０に接続される。通信部１１は、ネットワーク２０に接続される他の装置との間でデータを送受する。通信部１１は、受信した通信データをシステムバスへ出力し、システムバスの通信データを送信する。表示部１５は、たとえばディスプレイで構成される。表示部１５は、システムバスから表示データを取得して表示する。表示部１５は、たとえばユーザが作業に使用する画面、ユーザの作業を管理する画面を表示する。表示部１５は、たとえば、タスクの成果物を生成するための文書作成の画面、表計算の画面、スケジュール管理の画面、プロジェクト管理の画面を表示する。操作部１４は、たとえばキーボード、マウスデバイスで構成される。操作部１４は、ユーザの操作による入力データを、システムバスへ出力する。検出部１６は、たとえばカメラ、マイクロホンで構成される。検出部１６は、作業中のユーザについての画像または音声による検出データを、システムバスへ出力する。検出部１６は、たとえば作業中のユーザの操作行動、表示部１５に対する注視行動、ユーザの表情や音声から得られる感情状態、他のユーザとの会話行動、などについて検出した行動データを、システムバスへ出力する。記憶部１３は、たとえばＲＯＭ、ＲＡＭ、ＨＤＤで構成される。記憶部１３は、制御部１２により実行されるプログラム、各種のデータを保持する。制御部１２は、たとえばＣＰＵで構成される。制御部１２としてのＣＰＵは、記憶部１３のプログラムを読み込んで実行する。これにより、制御部１２が実現される。制御部１２は、クライアント端末１０の動作を制御する。制御部１２は、クライアント端末１０の内部で扱うデータを処理する。たとえば、制御部１２は、システムバスから通信データ、入力データ、検出データを取得し、データに対する処理を実行し、表示データや通信データを生成してシステムバスへ出力する。これにより、たとえば、制御部１２は、操作部１４の入力データや、検出部１６の検出データを含む行動ログを、作業情報として収集して記憶部１３に保持させる。制御部１２は、記憶部１３が保持している作業情報を通信部１１に送信させる。クライアント端末１０は、ユーザの作業状況を示すデータを収集してユーザの作業情報を生成してサーバ装置３０へ送信したり、サーバ装置３０からメッセージを受信して表示したりする。

モニタリング装置４０は、ユーザが作業に使用するエリアをモニタする。モニタリング装置４０は、たとえば作業エリアとしてのオフィスの天井や壁などに設置される。モニタリング装置４０は、たとえば、通信部４１、制御部４２、記憶部４３、検出部４４、およびこれらを接続するシステムバス、を有する。通信部４１、制御部４２、記憶部４３および、システムバスは、クライアント端末１０の同名のものと同様であり、説明を省略する。検出部４４は、たとえば作業エリアとしてのオフィスに存在するユーザを撮像するカメラである。制御部４２としてのＣＰＵは、記憶部４３のプログラムを読み込んで実行する。これにより、制御部４２が実現される。制御部４２は、モニタリング装置４０の動作を制御し、モニタリング装置４０の内部で扱うデータを処理する。たとえば、制御部４２は、勤務時間中において随時に、たとえば検出部４４により作業エリアを撮像した画像データを含むコミュニケーションログを、作業情報として収集して記憶部４３に保持させる。制御部４２は、画像解析によりユーザ毎のコミュニケーション状態を検出し、各ユーザの作業に伴う他ユーザとの会話行動の有無などを、コミュニケーションログに記録する。制御部４２は、記憶部４３が保持している作業情報を通信部４１に送信させる。なお、ここでは、モニタリング装置４０は、ネットワーク２０カメラの例で説明している。この他にもたとえば、モニタリング装置４０は、公知の屋内測位手段によって各ユーザの位置情報を計測することによりユーザ毎のコミュニケーション状態を検出する装置でもよい。また、モニタリング装置４０は、ユーザが装着するデバイスによって各ユーザの発話状態を計測することによりユーザ毎のコミュニケーション状態を検出する装置でもよい。また、モニタリング装置４０は、これら各種の方式を組み合わせてコミュニケーション状態を検出する装置でもよい。モニタリング装置４０は、ネットワーク２０カメラに限定されない。

管理者端末５０は、ユーザの管理者、作業単位が属するプロジェクトの管理者、またはそれらの上位の管理者が使用する端末である。管理者端末５０は、作業管理対象であるユーザの停滞リスクを示すメッセージをサーバ装置３０から受信し、管理者に向けて表示する。管理者端末５０は、管理者の要求に応じて、作業管理対象であるユーザの作業状況や停滞リスクを表示する。管理者端末５０は、通信部５１、制御部５２、記憶部５３、操作部５４、表示部５５、およびこれらを接続するシステムバス、を有する。通信部５１、制御部５２、記憶部５３、操作部５４、表示部５５、およびシステムバスは、クライアント端末１０の同名のものと同様であり、説明を省略する。制御部５２としてのＣＰＵは、記憶部５３のプログラムを読み込んで実行する。これにより、制御部５２が実現される。制御部５２は、管理者端末５０の動作を制御し、管理者端末５０の内部で扱うデータを処理する。たとえば、制御部５２は、サーバ装置３０が送信したメッセージを通信部５１で受信し、そのメッセージを表示部５５に表示する。メッセージは、たとえば電子メールシステムのメッセージでもよい。また、制御部５２は、管理者からの操作入力に応じて作業管理アプリケーションプログラムまたはＷＥＢブラウザプログラムを起動し、通信部５１によりサーバ装置３０からユーザの作業状況や停滞リスクの情報を受信し、表示部５５に表示する。

サーバ装置３０は、作業者であるユーザによるタスクなどの作業単位についての作業を管理する。サーバ装置３０は、通信部３００１、制御部３００２、記憶部３００３、およびこれらを接続するシステムバス、を有する。通信部３００１、制御部３００２、システムバスは、クライアント端末１０の同名のものと同様であり、説明を省略する。なお、サーバ装置３０は、たとえば、大容量データを解析するためのＣＰＵ、ＲＡＭ、ＲＯＭ等の専用デバイスを搭載したサーバ装置３０本体と、大容量データを記憶するためのＨＤＤ等の専用デバイスを搭載した記憶装置とが独立した構成でもよい。制御部３００２としてのＣＰＵは、記憶部３００３のプログラムを読み込んで実行する。これにより、制御部３００２が実現される。制御部３００２は、サーバ装置３０の動作を制御し、サーバ装置３０の内部で扱うデータを処理する。記憶部３００３は、制御プログラムとしてのＤＢ（データベース）管理部３１を記憶する。記憶部３００３は、データベースとして、スケジュールＤＢ３２、プロジェクトＤＢ３３、タスク進捗ＤＢ３４、成果物ＤＢ３５、感情ＤＢ３６、コミュニケーションＤＢ３７、プロセスＤＢ３８、停滞ＤＢ３９、を記憶する。ＤＢ管理部３１は、制御部３００２におけるデータベースを管理するための機能である。制御部３００２は、ＤＢ管理部３１を用いてデータベースを管理し、データベースの情報を用いて、ユーザおよび作業としてのタスクのスケジュールやプロジェクト、タスク進捗などを管理する。たとえば、制御部３００２は、クライアント端末１０およびモニタリング装置４０から送信されたユーザの作業状況を示すデータを分析することでプロジェクトの進行状態を特定する。プロジェクトの進行状態には、タスク進捗、成果物登録状況、感情状態、コミュニケーション状態、プロセス状態、などでよい。そして、制御部３００２は、特定した進行状態を、作業の停滞リスクとして記録する。ここで、プロジェクトとは、たとえば企業組織活動において、ある目標を達成するために複数の組織から集められた特定の集団で実行する業務のことを指し、計画や課題、目標、人員などをいうことが一般的である。

次に、記憶部３００３に記憶される各データベースについて説明する。制御部３００２は、通信部３００１を用いてユーザの作業情報を取得し、ＤＢ管理部３１として記憶部３００３に記憶される各データベースに保存させる。これにより、記憶部３００３は、取得した作業情報を蓄積して記憶する。取得するユーザの作業情報には、たとえば作業実績時間、作業実績工程、ユーザの作業の状況または内容についての情報、がある。ユーザの作業の状況または内容についての情報には、たとえば、ユーザ（によるクライアント端末１０）の操作に関する作業ログ、がある。この他にもたとえば、この情報には、作業中のユーザを撮像した画像の解析に基づいて得られる作業ログ、および、ユーザが作業するスペースを撮像した画像の解析に基づいて得られる作業ログ、が含まれる。

図２は、図１のスケジュールＤＢのデータ構造の説明図である。スケジュールＤＢは、作業管理対象であるユーザに関するスケジュール情報を記憶するデータベースである。図２のスケジュールＤＢ３２は、図２（ａ）のカレンダ２００の情報、図２（ｂ）のユーザの勤務情報、図２（ｃ）のユーザの予定情報、を有する。図２（ａ）のカレンダ２００の情報には、ユーザが所属する組織の通常出勤日、が登録される。図２（ｂ）の勤務情報には、ユーザ毎に、通常出勤日における始業時刻２０１、終業時刻２０２、休憩時間が定義された勤務形態２０３、といった就業時間帯、が登録される。図２（ｃ）の予定情報には、ユーザ毎に、作業時間として使用できない打合せなどの予定時間帯、が登録される。図２（ｃ）の例では、たとえば図２（ａ）のカレンダ２００における実働５日間２１０での、一人のユーザの予定時間帯の情報についての日付２２０、開始時刻２２１、終了時刻２２２、要件２２３、が登録されている。制御部３００２は、ユーザの予定に関する取得情報を取得すると、それを用いてスケジュールＤＢ３２を更新する。制御部３００２は、スケジュールＤＢ３２の情報に基づいて、たとえば作業管理対象であるユーザが確保できる正味の作業可能時間を算出することができる。

図３は、図１のプロジェクトＤＢのデータ構造の説明図である。プロジェクトＤＢ３３は、作業管理対象であるユーザに関するプロジェクト情報を記憶するためのデータベースである。図３のプロジェクトＤＢ３３は、図３（ａ）のプロジェクトの作業単位であるタスクの情報、図３（ｂ）のサブタスクの管理テーブル、図３（ｃ）のプロジェクトの管理者の情報、を有する。図３（ａ）のプロジェクトのタスクの情報は、タスク毎のレコード３１０〜３１５を有する。図３（ａ）のタスク毎のレコードには、プロジェクトの各作業単位（タスク）に関する情報として、タスクＩＤ３００、タスク名３０１、関連プロジェクト名３０２、期限３０３、が登録される。図３（ａ）の例のプロジェクトＤＢ３３は、タスクＩＤとしてＴ１、Ｔ２、Ｔ３、Ｔ４、Ｔ５、Ｔ６を有する６つのタスク毎のレコード３１０〜３１５が登録されている。図３（ｂ）のサブタスクの管理テーブルは、図３（ａ）のＴ１からＴ６のそれぞれのタスクを構成するサブタスクを管理する管理テーブルである。サブタスクの管理テーブルには、サブタスクのレコード毎に、タスクＩＤ３００、サブタスクＩＤ３２０、サブタスク名３２１、予定工数３２２、サブタスクを担当する担当者名３２３、が登録される。サブタスクの各レコードに、図３（ａ）と共通するタスクＩＤ３００を登録することにより、タスクとサブタスクとの親子関係が管理できる。また、サブタスク毎に、開発部門のサブタスク情報と、サブタスクを担当する作業者であるユーザと、を管理できる。各サブタスクは、たとえば、ソフトウェア開発工程における機能モジュールの１個当たりのコーディングおよびデバッグ作業時間のような作業単位でよい。サブタスクの管理テーブルには、作業の予定工数３２２が設定されている。予定工数３２２は、たとえば、組織内で蓄積された過去の類似タスクにおける過去の実績工数のデータに基づいた統計的な期待値を設定したものでも、担当者の経験年数などの諸条件を入力して学習したモデルの出力値を設定したものでもよい。図３（ｃ）のプロジェクトの管理者の情報には、プロジェクトのレコード毎に、プロジェクト名３４０、管理者名３４１、相談役名３４２、が登録される。これにより、各プロジェクトについての管理者と相談役とを登録して管理できる。管理者名３４１には、たとえば、プロジェクトの責任者にあたる人物を設定してよい。相談役名３４２には、たとえば、図３（ｂ）の担当者名３２３の指導役の人物、または、チームリーダを設定してよい。管理者名３５１または相談役名３５２には、複数人を設定してよい。制御部３００２は、取得情報に基づいて、プロジェクトＤＢを適宜更新する。制御部３００２は、プロジェクトＤＢに基づいて、たとえば各担当者が担当するタスク、そのタスクのプロジェクト、そのプロジェクトの管理者などについて、情報を得ることができる。たとえば、図３（ｃ）と図３（ａ）の３１０〜３１５の関連プロジェクト名３０２とを参照することにより、制御部３００２は、各タスクがどのプロジェクトに関連付けられいるか、そのプロジェクトの管理者と相談役が誰であるかの情報を得ることができる。

図４は、図１のタスク進捗ＤＢのデータ構造の説明図である。タスク進捗ＤＢ３４は、作業管理対象であるユーザに関するタスク進捗情報を記憶するためのデータベースである。図４のタスク進捗ＤＢは、図４（ａ）および図４（ｂ）の各タスクについてのこれまでの過去の実績情報、図４（ｃ）のユーザの作業予定の情報、図４（ｄ）のユーザの当日の実績情報、を有する。図４（ａ）または図４（ｂ）の過去の実績情報は、図３（ａ）に登録されているタスク毎の過去の実績情報のレコードである。タスク毎の過去の実績情報のレコードには、タスクＩＤ４００、タスク名４０１、総予定工数４０２、実績工数４０３、進捗率４０４、予定進捗率４０５、が登録される。進捗率４０４は、たとえば、クライアント端末１０の操作部１４を用いてユーザから手動で入力されたデータに基づいて更新される。たとえば、図４（ａ）の進捗率４０４は、タスクＩＤがＴ１であるタスクについてのものであり、制御部３００２が自動で算出した進捗率が０％である例である。図４（ｂ）の進捗率４０４は、タスクＩＤがＴ２であるタスクについてのものであり、制御部３００２が自動で算出した進捗率が２５％である例である。制御部３００２は、進捗率の算出を、たとえば、「実績工数／総予定工数×１００」という計算式で計算してよい。図４（ａ）および図４（ｂ）の予定進捗率４０５は、後述する図４（ｃ）の予定進捗率４２５での、ある時点での予定進捗率である。たとえば、図４（ａ）の予定進捗率４０５は、２０１７年１１月０６日（月）の終業時刻時点でのものであり、制御部３００２が自動で算出した予定進捗率が２０％である例である。また、図４（ｂ）の予定進捗率４０５は、２０１７年１１月０７日（火）の終業時刻時点でのものであり、制御部３００２が自動で算出した予定進捗率が６２．５％ある例である。なお、説明の便宜上、以降の説明では、図４（ａ）を２０１７年１１月０６日（月）の終業時刻時点でのタスク進捗ＤＢ３４の状態とし、図４（ｂ）を２０１７年１１月０７日（火）の終業時刻時点でのタスク進捗ＤＢ３４の状態とする。図４（ｃ）の作業予定の情報には、日付４２０、開始時刻４２１、終了時刻４２２、予定工数４２３、タスク名４２４、予定進捗率４２５、が登録される。作業予定におけるタスク名４２４は、作業を実施するユーザによって予め設定されたものでよい。予定工数４２３は、図４（ａ）の総予定工数４０２に対応したものでよい。すなわち、図４（ａ）のタスク４１０に登録されているタスクＡの総予定工数である１５時間は、図４（ｃ）の各タスクのレコード４３０、４３４、４３６、４３７、４３８に割り付けた予定工数の合計である。また、図４（ｂ）のタスク４１１に登録されているタスクＢの総予定工数である８時間は、図４（ｃ）の各タスクのレコード４３１、４３２、４３３、４３５、４３９に割り付けた予定工数の合計である。予定進捗率４２５は、予定工数４２３が予定通りに行われた場合の進捗率を示している。制御部３００２は、予定進捗率４２５を、「あるタスクにおけるその時点までの予定工数の合計／総予定工数×１００」で演算してよい。たとえば、図４（ａ）のタスクＡの総予定工数は１５時間である。この場合、２０１７年１１月０８日（水）の終業時刻時点での予定進捗率４２５は、図４（ｃ）に示すように「（３時間＋４時間）／１５時間×１００≒４６．６％」と演算される。図４（ｄ）の当日の実績情報には、日付４４０、開始時刻４４１、終了時刻４４２、実績工数４４３、タスク名４４４、が登録される。制御部３００２は、作業実績におけるタスク名４４４を、たとえば、クライアント端末１０から収集した操作ログや行動ログのデータを入力した学習モデルからの出力値に基づいて登録してよい。タスク名４４４は、日付４４０、開始時刻４４１、終了時刻４４２などの時間情報と共に分類して予め登録されていてよい。図４（ｄ）の作業実績４５０、４５１はいずれも、タスク名４４４がタスクＢに分類された例である。制御部３００２は、図４（ｄ）の作業実績を集計し、図４（ａ）、図４（ｂ）の過去の実績情報を当日の実績により更新する。この場合、図４（ａ）の実績工数４０３には０時間が加算され、図４（ｂ）の実績工数４０３には２時間が加算される。制御部３００２は、図４（ａ）、図４（ｂ）の情報に基づいて、後述する図１１のフローチャートにより、図４（ａ）のタスクＡの停滞リスクとして未着手を判断し、図４（ｂ）のタスクＢの停滞リスクとして遅延を判断することができる。

図５は、図１の成果物ＤＢのデータ構造の説明図である。成果物ＤＢ３５は、作業管理対象であるユーザが担当するタスクに関する成果物の情報を記憶するためのデータベースである。予定成果物は、たとえば、テキストデータ、ＰＤＦデータなどの任意の電子データでよい。成果物は、クライアント端末１０、または、管理者端末５０から任意のタイミングで登録してよい。図５の成果物ＤＢ３５は、登録されているタスク毎の成果物のレコードである。タスク毎の成果物のレコードには、タスクＩＤ５００、タスク名５０１、日付５０２、期限５０３、進捗率５０４、予定成果物名５０５、成果物有無５０６、が登録される。図５のレコード５１０のタスクＩＤ５００、タスク名５０１、期限５０３は、それぞれ図３（ａ）のタスクＴ３のレコード３２１に対応している。図５のレコード５１０の日付５０２と進捗率５０４は、その時点での日付と進捗率である。予定成果物名５０５は、ユーザがタスクに予め設定している成果物データの名前である。たとえば、図５のレコード５１０の予定成果物名５０５は「成果物Ａ．ｐｄｆ」として、ユーザがタスクＣに設定したものである。予定成果物名５０５は、クライアント端末１０、または、管理者端末５０から設定することができ、タスクを担当するユーザではなく、管理者が設定してもよい。予定成果物名５０５は、タスクが終了するまでの任意の時点（すなわち進捗率５０４が１００％になるまでの任意の時点）で設定してよい。成果物有無５０６は、予定成果物名５０５と同一名称の成果物データが該当するタスクに登録されているか否かを示している。制御部３００２は、予定成果物が登録されると、成果物有無５０６を無しから有りに更新する。たとえば、図５のレコード５１０の成果物有無５０６は、タスクＣに成果物が登録されていない状態でのものであり、「無し」となってる。この場合、制御部３００２は、成果物有無５０６の値に基づいて、図５のタスクＣについての停滞リスクとして、成果物無しに対応するリスクを判断する。

図６は、図１の感情ＤＢのデータ構造の説明図である。感情ＤＢ３６は、作業管理対象であるユーザが担当するタスクに関する感情情報を記憶するためのデータベースである。図６の感情ＤＢ３６は、図６（ａ）のタスク毎の感情データベースと、図６（ｂ）のユーザ毎の感情データベースと、を有する。図６（ａ）のタスク毎の感情データベースには、図３（ａ）に登録されているタスク毎の感情のレコードを有する。タスク毎の感情のレコードには、タスクＩＤ６００、タスク名６０１、感情６０２、が登録される。図６（ａ）のレコード６１０、６１１のタスクＩＤ６００およびタスク名６０１は、それぞれ、図３（ａ）のレコード３１１、３１３のタスクＴ２、タスクＴ４のものに対応している。図６（ｂ）のユーザ毎の感情データベースには、日付６２０、開始時刻６２１、終了時刻６２２、実績工数６２３、タスク名６２４、感情６２５、が登録される。図６（ｂ）のレコード６３０は、タスクＢの作業をしていた１時間ではポジティブな感情の割合が所定値より高かったことを示している。所定値は、たとえば実績工数の内の６０％としても、その以外の任意の値としてもよい。制御部３００２は、作業を実施しているユーザのクライアント端末１０の検出部１６で取得され、検出部１６のカメラやマイクロホンからユーザの表情または音声を解析することにより、タスク毎の感情、ユーザ毎の感情を判断すればよい。たとえば、検出部１６としてのカメラから取得されるユーザの撮像画像では、「怒り」、「軽蔑」、「嫌悪」、「恐怖」、「喜び」、「悲しみ」、「驚き」、「はっきりしない」などの感情を判断できる。本実施形態では、「怒り」、「軽蔑」、「嫌悪」、「恐怖」、「悲しみ」をネガティブ感情、「喜び」、「驚き」、「はっきりしない」をポジティブ感情と分類する。なお、画像からの表情認識技術、および、音声からの感情認識技術については、公知の技術であるため、それらの説明を省略する。図６（ａ）のレコード６１０、６１１に登録される感情６０２は、２０１７年１１月０７日（火）の終業時刻の時点で、タスクＢとタスクＤがそれぞれポジティブとネガティブに分類された場合を示したものである。制御部３００２は、作業をしている最後の時点の感情を、レコード６１０、６１１に登録される感情６０２としてよい。制御部３００２は、図６（ａ）、（ｂ）の情報に基づいて、たとえばタスクＤの停滞リスクの感情としてネガティブ感情を判断する。

図７は、図１のコミュニケーションＤＢのデータ構造の説明図である。コミュニケーションＤＢ３７は、作業管理対象であるユーザが担当するタスクのコミュニケーション状態を記憶するためのデータベースである。図７のコミュニケーションＤＢ３７は、タスク毎のコミュニケーションに関するレコードを有する。タスク毎のコミュニケーションに関するレコードには、図３（ａ）に登録されているタスク毎のタスクＩＤ７００、タスク名７０１、進捗率７０２、コミュニケーション回数７０３、が登録される。図７のコミュニケーション回数７０３は、そのタスクを担当しているユーザの、ある時点での相談役への会話行動の回数を示している。たとえば、図７のレコード７１０では、タスクＥを担当しているユーザＥの相談役への会話行動の回数となる。制御部３００２は、図３（ａ）のプロジェクトＤＢ３３から、タスクＥの関連プロジェクト名３０２がプロジェクトＺと判断し、図３（ｃ）によりユーザＥの相談役が相談役Ｆと判断し、その会話行動の回数をコミュニケーション回数７０３として記録する。会話行動の検出は、クライアント端末１０の検出部１６、および、モニタリング装置４０の検出部４４で行えばよい。制御部３００２は、図７の情報に基づいて、後述する図１４のフローチャートにおいて、図７のタスクＥについての停滞リスクを、コミュニケーション回数の多少により判断する。

図８は、図１のプロセスＤＢのデータ構造の説明図である。プロセスＤＢ３８は、作業管理対象であるユーザが担当しているタスクのプロセス情報を記憶するためのデータベースである。図８のプロセスＤＢ３８は、タスク毎のプロセス情報のレコードを有する。タスク毎のプロセス情報のレコードには、タスクＩＤ８００、タスク名８０１、進捗率８０２、プロセス８０３、が登録される。図８のレコード８１０のタスクＩＤ８００およびタスク名８０１は、それぞれ、図３（ａ）のレコード３１５のタスクＴ６のものに対応している。図８のプロセス８０３は、タスクを実施している作業の進め方の状態を示している。制御部３００２は、クライアント端末１０の操作部１４による操作行動、および、表示部１５に対する注視行動などに基づいて、プロセス８０３の情報を取得することができる。プロセス８０３の情報は、たとえば操作部１４の操作行動として、ＷＥＢブラウザなどによる“検索”、テキストデータなどの“編集”、“電子メール”、何らかの“アプリケーション操作”、でよい。また、プロセス８０３の情報は、エクスプローラの“ファイル操作”、一定時間（たとえば１５分など任意の値を設定できる）のキー操作の“休止”、表示画面の“スクロール操作”などでよい。プロセス８０３の情報は、この他にもたとえば、表示部１５に対する注視行動としての“画面注視”、“画面見ず”、“不在”などでよい。ここで、「“」と「”」とに囲まれた行動は、イベントと呼ぶ。制御部３００２は、上記イベントの組み合わせにより、プロセス状態を判断してよい。たとえば、“画面注視”と“休止”とのイベントの組み合わせが一定時間（たとえば１５分などの任意の値の時間）以上になると、作業が停滞している可能性があるため、制御部３００２は、作業中のタスクを膠着状態と判断する。“検索”と“スクロール操作”とのイベントの組み合わせが一定時間（たとえば１時間などの任意の値の時間）以上になると、制御部３００２は、作業中のタスクを膠着状態と判断する。これらの膠着状態がタスクの作業工数の内の所定の割合（たとえば８０％など任意の割合）を超えている場合、制御部３００２は、プロセスＤＢ３８のプロセス８０３を、膠着状態に更新する。制御部３００２は、図８の情報に基づいて、後述する図１５のフローチャートにおいて、図８のタスクＥについての停滞リスクが膠着状態であると判断する。

図９は、図１の停滞ＤＢのデータ構造の説明図である。停滞ＤＢ３９は、作業管理対象であるユーザが担当しているタスクの停滞リスク、および、各タスクのメッセージ内容を記憶するためのデータベースである。図９の停滞ＤＢ３９は、図９（ａ）のタスク毎の停滞判断結果、図９（ｂ）のメッセージデータ、図９（ｃ）の通知先の設定、を有する。図９（ａ）のタスク毎の停滞判断結果は、タスク毎の判断結果のレコードを有する。タスク毎の判断結果のレコードには、日付９００、タスクＩＤ９０１、タスク名９０２、未着手９０３、作業遅延９０４、成果物無し９０５、感情９０６、相談・確認９０７、膠着９０８、が登録される。図９（ａ）のレコード９１０〜９１５のタスクＩＤ９０１およびタスク名９０２は、図３（ａ）のレコード３１０〜３１５のタスクＴ１〜タスクＴ６のものに対応している。図９（ａ）の未着手９０３から膠着９０８までの項目の値は、それぞれ、制御部３００２による停滞リスクの判断結果に応じて、更新される。制御部３００２は、図４〜図８に記載のタスク進捗ＤＢ３４、成果物ＤＢ３５、感情ＤＢ３６、コミュニケーションＤＢ３７、プロセスＤＢ３８に基づいて、停滞リスクを判断する。未着手９０３〜膠着９０８の更新処理については、後述の図１０で述べる。図９（ａ）において、丸印は、その項目での停滞リスクがあるとの判断結果を示す。ハイフンは、その項目での停滞リスクがないとの判断結果を示す。図９（ｂ）のメッセージデータは、通知するメッセージおよび通知先の組み合わせ毎のレコードを有する。組み合わせ毎のレコードには、日付９００、タスクＩＤ９０１、タスク名９０２、担当者名９２０、通知先９２１、メッセージ内容９２２、が登録される。これにより、通知毎の、停滞リスクの通知先と、メッセージの内容とが登録される。制御部３００２は、図９（ａ）のデータを更新した後、図９（ｂ）のデータを更新する。担当者名９２０は、図３（ｂ）の担当者名３２３に対応している。通知先９２１には、タスクを担当する作業者であるユーザ本人、またはその管理者が登録される。管理者は、たとえば、タスクＩＤ９０１から図３（ａ）の関連プロジェクト名３０２を特定し、さらに関連プロジェクト名３０２から図３（ｃ）の管理者名３４１を特定することにより、特定し得る。図９（ｃ）の通知先の設定は、停滞リスクの種類毎の値を有する複数のレコード９４０〜９４５を有する。レコード９４０〜９４５には、停滞リスクの種類毎の値とともに、通知先の属性が登録される。通知先の属性には、タスクを担当する作業者、管理者、などの情報が登録される。なお、図９（ｃ）の通知先の属性には、プロジェクトの管理者に加え、相談役を加えてもよい。また、通知先の属性では、属性ではなく、プロジェクト外の任意の人物の指名情報を、ダイレクトに登録してもよい。図９（ｂ）のレコード９３１の場合、そのタスクＩＤ９０１がＴ２である。この場合、制御部３００２は、図９（ａ）から停滞リスクが作業遅延９０４と判断し、図９（ｃ）から通知先９２１としてプロジェクトの管理者を特定する。タスクＩＤ９０１がＴ２の場合、図３（ａ）より関連プロジェクト名３０２がプロジェクトＸとなり、図３（ｃ）よりプロジェクトＸの管理者名３４１はマネージャＡとなる。この場合、制御部３００２は、図９（ｂ）のレコード９３１に対応する通知先９２１として、マネージャＡを特定して登録する。図９（ｂ）のレコード９３０のタスクＡでは、図９（ａ）より停滞リスクが未着手であるため、図９（ｃ）より通知先９２１はタスクの担当者、すなわちユーザＡとなる。図９（ｂ）のメッセージ内容は、担当者名９２０、および、図９（ａ）の未着手９０３から膠着９０８までの停滞項目に対応する停滞リスク項目にもとづいて生成される。たとえば、図９（ｂ）のレコード９３４では、担当者名９２０がユーザＦ、タスクＩＤ９０１のタスクＴ６の図９（ａ）での停滞リスクが膠着である。この場合、制御部３００２は、「ユーザＦの”タスクＦ”の作業が膠着状態にある可能性があります。」というメッセージ内容を登録する。

次に、各停滞判断から通知までの処理について説明する。図１０〜図１５は、サーバ装置３０のＤＢ管理部３１としての制御部３００２により実行される処理の流れを説明するフローチャートである。ＤＢ管理部３１は、クライアント端末１０または管理者端末５０からユーザの作業状況を示す操作ログや行動ログのデータを受信した場合、ユーザの停滞リスク情報の表示を指示するための操作入力を受信した場合、図１０〜図１５の処理を実行する。フローチャートで示す各手順は、ＤＢ管理部３１のＲＡＭ、ＲＯＭ等にプログラム等として記憶され、ＤＢ管理部３１としてのＣＰＵにより実行される。

図１０は、ユーザの作業についての停滞判断からメッセージの通知までの処理の流れを示すメインフローチャートである。ＤＢ管理部３１としてのＣＰＵは、記憶部３００３からプログラムを読み込んで実行することにより、図１０の処理を実行する。図１０の処理を開始すると、ステップＳ１００１において、ＤＢ管理部３１は、図２〜図９で説明した各種のデータベースのデータを全て更新する。ＤＢ管理部３１は、スケジュールＤＢ３２、プロジェクトＤＢ３３、タスク進捗ＤＢ３４、成果物ＤＢ３５、感情ＤＢ３６、コミュニケーションＤＢ３７、プロセスＤＢ３８、停滞ＤＢ３９のデータを全て更新する。ステップＳ１００２において、ＤＢ管理部３１は、処理を開始した現時刻が終業時刻であるか否かを判断する。ＤＢ管理部３１は、たとえば図２（ｂ）のスケジュールＤＢ３２を参照して終業時刻を取得することができる。なお、ＤＢ管理部３１は、終業時刻以外の他の時刻と現時刻とを比較して同様の判断処理を実行してよい。現時刻が終業時刻である場合、ＤＢ管理部３１は、処理をステップＳ１００４へ進める。それ以外の場合には、ＤＢ管理部３１は、処理をステップＳ１００３へ進める。ステップＳ１００３において、ＤＢ管理部３１は、クライアント端末１０の操作部１４または管理者端末５０の操作部５４の操作入力として、停滞リスク情報の表示を要求されたか否かを判断する。停滞リスク情報の表示要求があった場合、ＤＢ管理部３１は、処理をステップＳ１００４へ進める。それ以外の場合には、ＤＢ管理部３１は、図１０の処理を終了する。ステップＳ１００４において、ＤＢ管理部３１は、図４のタスク進捗ＤＢ３４から、ユーザのタスクが未着手、または、遅延であるかの判断処理を行う。詳細な処理は、後述する図１１で説明する。ステップＳ１００５において、ＤＢ管理部３１は、図５の成果物ＤＢ３４から、ユーザのタスクに成果物が登録されているかの判断処理を行う。詳細な処理は、後述する図１２で説明する。ステップＳ１００６において、ＤＢ管理部３１は、図６の感情ＤＢ３６から、ユーザのタスクに対する感情がポジティブであるかの判断処理を行う。詳細な処理は、後述する図１３で説明する。ステップＳ１００７において、ＤＢ管理部３１は、図７のコミュニケーションＤＢ３７から、ユーザがタスクに関わる相談役とコミュニケーションがとれているかの判断処理を行う。詳細な処理は、後述する図１４で説明する。ステップＳ１００８において、ＤＢ管理部３１は、図８のプロセスＤＢ３８から、ユーザのタスクのプロセス状態の判断処理を行う。詳細な処理は、後述する図１５で説明する。以上の各種の停滞リスクの判断処理が終了すると、ステップＳ１００９において、ＤＢ管理部３１は、図９の停滞ＤＢ３９から、その時点においてユーザまたは管理者へ通知する項目があるか否かを判断する。図９の停滞ＤＢ３９は、図９（ａ）の説明で述べたように、タスク進捗ＤＢ３４からプロセスＤＢ３８までの停滞リスクの判断に応じて、ステップＳ１００４〜ステップＳ１００８の処理により未着手９０３から膠着９０８までの項目が自動的に更新される。ＤＢ管理部３１は、更新された停滞ＤＢ３９に基づいて、ユーザまたは管理者へ通知する項目があるか否かを判断する。そして、たとえば現在の時点の日付が２０１７年１１月１３日（月）である場合、ＤＢ管理部３１は、図９（ｂ）のレコード９３３，９３４を、通知する項目として判断する。ユーザまたは管理者へ通知する項目がない場合、ＤＢ管理部３１は、メッセージの通知をすることなく図１０の処理を終了する。ユーザまたは管理者へ通知する項目がある場合、ＤＢ管理部３１は、処理をステップＳ１０１０へ進める。ステップＳ１０１０において、ＤＢ管理部３１は、通知する項目として判断したメッセージを送信する。ＤＢ管理部３１は、通知する項目として判断したメッセージの中の、要求があった通知先に対して通知するメッセージを送信してよい。たとえば現在の時点の日付が２０１７年１１月１３日（月）である場合、ＤＢ管理部３１は、図９（ｂ）のレコード９３３，９３４のメッセージ９２２を通知先９２１へ送信する。この場合、マネージャＢとマネージャＣの所持する各管理者端末５０へ、それぞれのメッセージ９２２が送信される。これにより、管理者端末５０には、メッセージ９２２が表示される。メッセージは、たとえばブラウザ画面に表示されてよい。これに対し、作業者であるユーザのクライアント端末１０から停滞リスク情報の表示要求を受信している場合、ＤＢ管理部３１は、要求したユーザへ通知する項目に含まれるメッセージを、クライアント端末１０へ送信する。これにより、クライアント端末１０には、メッセージが表示される。メッセージは、たとえばブラウザ画面に表示されてよい。たとえば図９（ｂ）のユーザＡについては、レコード９３０のメッセージ内容９２２が表示される。このユーザに対するメッセージには、管理者に対するメッセージと異なり、メッセージにユーザ名が含まれない。ところで、ＤＢ管理部３１は、ステップＳ１００４〜ステップＳ１００８の処理を、後述する図１１から図１５の処理の後に全てのタスクに関して実行する。図１１から図１５の処理によりデータベースが更新される。停滞ＤＢ３９には、新たな図９（ａ）および図９（ｂ）のレコードが生成して追加される。ステップＳ１００９では、ＤＢ管理部３１は、その判断時点で更新されている停滞ＤＢ３９の図９（ｂ）に基づいて、新たにメッセージを送信する。なお、後述する第二実施形態においても、ＤＢ管理部３１は、同様の処理を経て、図１７（ａ）および図１７（ｂ）の停滞ＤＢ３９が更新される。

図１１は、作業単位での作業実績工数に基づく停滞判断の流れを示すフローチャートである。ＤＢ管理部３１としてのＣＰＵは、記憶部３００３からプログラムを読み込んで実行することにより、図１０のステップＳ１００４において図１１の処理を実行する。図１１の作業実績工数にもとづく停滞リスクの判断処理のステップＳ１１０１において、ＤＢ管理部３１は、タスク進捗ＤＢ３４より現時点までのタスク毎の総予定工数を取得する。ＤＢ管理部３１は、たとえば図４（ａ）より２０１７年１１月０６日（月）終業時刻時点では、タスクＡの総予定工数４０２として１５時間を取得する。ステップＳ１１０２において、ＤＢ管理部３１は、タスク進捗ＤＢ３４より現時点までのタスク毎の実績工数を取得する。ＤＢ管理部３１は、たとえば図４（ａ）より２０１７年１１月０６日（月）終業時刻時点では、タスクＡの実績工数４０３として０時間を取得する。ステップＳ１１０３において、ＤＢ管理部３１は、タスク進捗ＤＢ３４より現時点までのタスク毎の予定進捗率を取得する。ＤＢ管理部３１は、たとえば図４（ａ）より２０１７年１１月０６日（月）終業時刻時点では、タスクＡの予定進捗率４０５として２０％を取得する。ステップＳ１１０４において、ＤＢ管理部３１は、タスク進捗ＤＢ３４より現時点までのタスク毎の進捗率を取得する。ＤＢ管理部３１は、たとえば図４（ａ）より２０１７年１１月０６日（月）終業時刻時点では、タスクＡの進捗率４０４として０％を取得する。ステップＳ１１０５において、ＤＢ管理部３１は、各タスクの予定進捗率が０より大きいか否かを判断する。予定進捗率が０より大きい場合、ＤＢ管理部３１は、処理をステップＳ１１０６へ進める。それ以外の場合は、ＤＢ管理部３１は、図１１の処理を終了する。たとえば図４（ａ）のレコード４１０では予定進捗率４０５が２０％なので、０より大きいと判断され、ステップＳ１１０６へ進む。ステップＳ１１０６において、ＤＢ管理部３１は、各タスクの進捗率が０より大きいか否かを判断する。進捗率が０より大きい場合、ＤＢ管理部３１は、処理をステップＳ１１０８へ進める。それ以外の場合は、ＤＢ管理部３１は、処理をステップＳ１１０７へ進める。たとえば図４（ａ）のレコード４１０では進捗率４０４が０％である。この場合、ＤＢ管理部３１は、０より大きく無いと判断して、処理をステップＳ１１０７へ進める。図４（ｂ）のレコード４１１では進捗率４０４が２５％である。この場合、ＤＢ管理部３１は、０より大きいと判断して、処理をステップＳ１１０８へ進める。ステップＳ１１０７において、ＤＢ管理部３１は、ステップＳ１１０５およびステップＳ１１０６の判断からタスクを未着手と判断し、停滞ＤＢ３９の該当するタスクの項目を更新し、図１１の処理を終了する。たとえば図４（ａ）のレコード４１０の場合、ＤＢ管理部３１は、未着手と判断し、停滞ＤＢ３９の未着手９０３の項目の値を、図９（ａ）のレコード９１０に示すようにハイフンから丸印へ更新する。ステップＳ１１０８において、ＤＢ管理部３１は、タスクの「予定進捗率−進捗率」が閾値より大きいか否かを判断する。この場合の閾値は、０から９９までの任意の値でよく、たとえば２０でよい。タスクの「予定進捗率−進捗率」が閾値より大きい場合、ＤＢ管理部３１は、処理をステップＳ１１０９へ進める。それ以外の場合は、ＤＢ管理部３１は、図１１の処理を終了する。たとえば図４（ｂ）のレコード４１１の場合、「予定進捗率−進捗率」が３７．５である。この場合、ＤＢ管理部３１は、閾値２０より大きいと判断し、処理をステップＳ１１０９へ進める。この閾値は、予定に対して実績がどこまで遅れていたら遅延とみなすかの基準となる。ステップＳ１１０９において、ＤＢ管理部３１は、ステップＳ１１０５からステップＳ１１０８の判断からタスクの遅延と判断し、停滞ＤＢ３９の該当するタスクの項目を更新して、図１１の処理を終了する。たとえば図４（ｂ）のレコード４１１の場合、ＤＢ管理部３１は、遅延と判断する。そして、ＤＢ管理部３１は、停滞ＤＢ３９の作業遅延９０４の項目を、図９（ａ）のレコード９１１に示すようにハイフンから丸印へ更新する。なお、ＤＢ管理部３１は、作業工程の比較ではなく、作業時間の比較により、図１１の処理を実行してもよい。

図１２は、作業単位の成果物に基づく停滞判断の流れを示すフローチャートである。ＤＢ管理部３１としてのＣＰＵは、記憶部３００３からプログラムを読み込んで実行することにより、図１０のステップＳ１００５において図１２の処理を実行する。図１２の成果物に基づく停滞リスクの判断処理のステップＳ１２０１において、ＤＢ管理部３１は、成果物ＤＢ３５より現時点までのタスク毎の予定成果物名を取得する。ＤＢ管理部３１は、たとえば図５のレコード５１０よりタスクＣの予定成果物名５０５として「成果物Ａ．ｐｄｆ」を取得する。ステップＳ１２０２において、ＤＢ管理部３１は、ステップＳ１２０１で取得した予定成果物名があったか否かを判断する。予定成果物名があった場合、ＤＢ管理部３１は、処理をステップＳ１２０３へ進め、そうでなければ図１２の処理を終了する。たとえば図５のレコード５１０では、予定成果物名として「成果物Ａ．ｐｄｆ」がある。この場合、ＤＢ管理部３１は、予定成果物名があると判断し、処理をステップＳ１２０３へ進める。ステップＳ１２０３において、ＤＢ管理部３１は、成果物ＤＢ３５より現時点までのタスク毎の成果物有無を取得する。ＤＢ管理部３１は、たとえば図５のレコード５１０より２０１７年１１月１３日（月）の時点では、タスクＣの成果物有無５０６が無しを取得する。ステップＳ１２０４において、ＤＢ管理部３１は、成果物ＤＢ３５より現時点までのタスク毎の進捗率を取得する。ＤＢ管理部３１は、たとえば図５のレコード５１０より２０１７年１１月１３日（月）の時点では、タスクＣの進捗率５０４として１００％を取得する。ステップＳ１２０５において、ＤＢ管理部３１は、ステップＳ１２０４で取得した進捗率が１００％であるか否かを判断する。進捗率が１００％であれば、ＤＢ管理部３１は、処理をステップＳ１２０６へ進め、そうでなければ図１２の処理を終了する。たとえば図５のレコード５１０では、進捗率５０４が１００％である。この場合、ＤＢ管理部３１は、処理をステップＳ１２０６へ進める。ここで進捗率が１００％であるか否かを判断するのは、１００％未満のときに成果物が登録されていたとしても、その成果物がタスクの最終成果物とみなすことができないためである。ステップＳ１２０６において、ＤＢ管理部３１は、タスクに登録されている成果物があるか否かを判断する。ＤＢ管理部３１は、成果物があれば図１２の処理を終了し、そうでなければ処理をステップＳ１２０７へ進める。たとえば図５のレコード５０１では、成果物有無５０６が「無し」である。この場合、ＤＢ管理部３１は、処理をステップＳ１２０７へ進める。ステップＳ１２０７において、ＤＢ管理部３１は、ステップＳ１２０６の判断からタスクの成果物無しと判断し、停滞ＤＢ３９の該当するタスクの項目を更新し、図１２の処理を終了する。たとえば図５のレコード５１０の場合、ＤＢ管理部３１は、成果物無しと判断し、停滞ＤＢ３９のレコード９１３についての成果物無し９０５の項目を、図９（ａ）に示すようにハイフンから丸印へ更新する。

図１３は、作業中のユーザの感情に基づく停滞判断の流れを示すフローチャートである。ＤＢ管理部３１としてのＣＰＵは、記憶部３００３からプログラムを読み込んで実行することにより、図１０のステップＳ１００６において図１３の処理を実行する。図１３のユーザの感情に基づく停滞判断処理のステップＳ１３０１において、ＤＢ管理部３１は、感情ＤＢ３６より現時点までのタスク毎の感情６０２を取得する。ＤＢ管理部３１は、たとえば図６のレコード６１０よりタスクＢの感情６０２として「ポジティブ」を取得する。ＤＢ管理部３１は、図６のレコード６１１よりタスクＢの感情６０２として「ネガティブ」を取得する。ステップＳ１３０２において、ＤＢ管理部３１は、ステップＳ１３０１で取得した感情６０２が「ポジティブ」であるか否かを判断する。感情６０２がポジティブである場合、ＤＢ管理部３１は、図１３の処理を終了し、そうでなければ処理をステップＳ１３０３へ進める。ＤＢ管理部３１は、たとえば図６のレコード６１１の場合には感情６０２がネガティブであるので、処理をステップＳ１３０３へ進める。ステップＳ１３０３において、ＤＢ管理部３１は、ステップＳ１３０２の判断からタスクをネガティブ感情と判断し、停滞ＤＢ３９の該当するタスクの項目を更新して、図１３の処理を終了する。ＤＢ管理部３１は、たとえば図６のレコード６１１の場合にはネガティブ感情と判断し、停滞ＤＢ３９のレコード９１２についての感情９０６の項目を、図９（ａ）のレコード９１２に示すようにハイフンから丸印へ更新する。

図１４は、作業開始後のコミュニケーション状態に基づく停滞判断の流れを示すフローチャートである。ＤＢ管理部３１としてのＣＰＵは、記憶部３００３からプログラムを読み込んで実行することにより、図１０のステップＳ１００７において図１４の処理を実行する。図１４のコミュニケーション状態に基づく停滞判断処理のステップＳ１４０１において、ＤＢ管理部３１は、コミュニケーションＤＢ３７より現時点までのタスク毎の進捗率７０２を取得する。ＤＢ管理部３１は、たとえば図７のレコード７１０よりタスクＥの進捗率７０２として７０％を取得する。ステップＳ１４０２において、ＤＢ管理部３１は、ステップＳ１４０１で取得した進捗率７０２が閾値以上であるか否かを判断する。閾値は、５０％などのように任意の値を設定できる。進捗率が閾値以上である場合、ＤＢ管理部３１は、処理をステップＳ１４０３へ進め、そうでなければ図１４の処理を終了する。たとえば図７のレコード７１０では進捗率７０２が７０％である。この場合、ＤＢ管理部３１は、閾値５０％以上であると判断し、処理をステップＳ１４０３へ進める。ここで、閾値以上か否かを判断する理由は、進捗率が低い時点（たとえば１０％）のときに相談役とのコミュニケーションが無かったとしても、タスク進行の初期段階を停滞リスクとみなすのが時期なお早なためである。ステップＳ１４０３において、ＤＢ管理部３１は、コミュニケーションＤＢ３７より現時点までのタスク毎のコミュニケーション回数７０３を取得する。ＤＢ管理部３１は、たとえば図７のレコード７１０よりタスクＥのコミュニケーション回数７０３として０回を取得する。なお、コミュニケーション回数７０３の取得方法については、図７の説明で既にしているため、ここでの説明は省略する。ステップＳ１４０４において、ＤＢ管理部３１は、ステップＳ１４０３で取得したコミュニケーション回数７０３が所定回数以上であるか否かを判断する。所定回数には、３回などのように任意の値を設定できる。コミュニケーション回数が所定回数以上である場合、ＤＢ管理部３１は、図１４の処理を終了し、そうでなければ処理をステップＳ１４０５へ進める。たとえば図７のレコード７１０ではコミュニケーション回数が０回である。この場合、ＤＢ管理部３１は、所定回数以上無いと判断し、処理をステップＳ１４０５へ進める。ステップＳ１４０５において、ＤＢ管理部３１は、ステップＳ１４０４の判断におけるタスクのコミュニケーション回数が少ないとの判断に基づいて、停滞ＤＢ３９の該当するタスクの項目を更新し、図１４の処理を終了する。ＤＢ管理部３１は、たとえば図７のレコード７１０の場合にはコミュニケーション回数が少ないと判断し、停滞ＤＢ３９のレコード９１５についての相談・確認９０７の項目を、図９（ａ）のようにハイフンから丸へ更新する。

図１５は、作業単位についての作業状態に基づく停滞判断の流れを示すフローチャートである。ＤＢ管理部３１としてのＣＰＵは、記憶部３００３からプログラムを読み込んで実行することにより、図１０のステップＳ１００８において図１５の処理を実行する。図１５の作業状態に基づく停滞判断処理のステップＳ１５０１において、ＤＢ管理部３１は、プロセスＤＢ３８より現時点までのタスク毎の進捗率８０２を取得する。ＤＢ管理部３１は、たとえば図８のレコード８１０よりタスクＦの進捗率８０２として５０％を取得する。

ステップＳ１５０２において、ＤＢ管理部３１は、ステップＳ１５０１で取得した進捗率８０２が閾値以上であるか否かを判断する。閾値には、３０％などのように任意の値を設定できる。進捗率が閾値以上である場合、ＤＢ管理部３１は、処理をステップＳ１５０３へ進め、そうでなければ図１５の処理を終了する。たとえば図８のレコード８１０では進捗率８０２が５０％である。この場合、ＤＢ管理部３１は、閾値３０％以上と判断し、処理をステップＳ１５０３へ進める。ここで、閾値以上か否かを判断する理由は、進捗率が低い時点（たとえば１０％）のときにプロセス状態が膠着状態だと判断したとしても、タスク進行の初期段階を膠着しているとみなすのが時期なお早なためである。ステップＳ１５０３において、ＤＢ管理部３１は、プロセスＤＢ３８より現時点までのタスク毎のプロセス８０３を取得する。ＤＢ管理部３１は、たとえば図８のレコード８１０よりタスクＦのプロセス８０３として膠着状態を取得する。なお、プロセス８０３の取得方法については、図８の説明で既にしているため、ここでの説明は省略する。ステップＳ１５０４において、ＤＢ管理部３１は、ステップＳ１５０３で取得したプロセス８０３が膠着状態であるか否かを判断する。ＤＢ管理部３１は、たとえば作業単位についてのユーザの作業が閾値以上の回数で繰り返されることにより取得した進捗率が低くなっている場合、作業が膠着していると判断して、作業単位の作業が停滞していると判断する、プロセスが膠着状態である場合、ＤＢ管理部３１は、処理をステップＳ１５０５へ進め、そうでなければ図１５の処理を終了する。ＤＢ管理部３１は、たとえば図８のレコード８１０ではプロセス８０３が膠着状態と判断し、処理をステップＳ１５０５へ進める。ステップＳ１５０５において、ＤＢ管理部３１は、ステップＳ１５０４でのタスクのプロセス状態が膠着状態であるとの判断に基づいて、停滞ＤＢ３９の該当するタスクの項目を更新し、図１５の処理を終了する。ＤＢ管理部３１は、たとえば図８のレコード８１０の場合には膠着状態と判断し、停滞ＤＢ３９のレコード９１４についての膠着９０８の項目を、図９（ａ）に示すようにハイフンから丸へ更新する。

以上の図１１から図１５の判断により、ＤＢ管理部３１は、停滞ＤＢ３９の各レコード９１４についての、未着手９０３から膠着９０８までの項目を自動的に更新される。そして、ＤＢ管理部３１は、たとえば、作業単位の成果物が判断時点で無い場合、そのタスクの作業が停滞していると判断し、メッセージを通知する。また、ＤＢ管理部３１は、作業中のユーザの感情がネガティブであると判断できる場合、作業開始後の判断時点までのコミュニケーション回数が少ないと判断できる場合、そのタスクの作業が停滞していると判断し、メッセージを通知する。また、ＤＢ管理部３１は、作業が膠着していると判断できる場合、そのタスクの作業が停滞していると判断し、メッセージを通知する。ＤＢ管理部３１は、タスクの種類や重要度、タスクの作業を担当するユーザ、および、タスクの作業の停滞を判断した内容および個数に応じて、異なる内容のメッセージを異なる通知先へ通知する。この場合において、ＤＢ管理部３１は、タスクについての作業実績時間または作業実績工数が無い状態である未着手の場合には、タスクを担当するユーザを通知先とする。ＤＢ管理部３１は、作業実績時間または作業実績校数が不足する場合には、タスクの作業を担当するユーザの管理者を通知先とする。ＤＢ管理部３１は、タスクの成果物が無い場合には、タスクの作業を担当するユーザの管理者を通知先とする。ＤＢ管理部３１は、作業中のユーザの感情情報がネガティブであると判断できる場合には、タスクの作業を担当するユーザの管理者を通知先とする。ＤＢ管理部３１は、作業開始後のコミュニケーション回数が少ないと判断できる場合には、タスクの作業を担当するユーザの管理者を通知先とする。ＤＢ管理部３１は、タスクの作業が膠着していると判断できる場合には、タスクの作業を担当するユーザの管理者を通知先とする。また、ＤＢ管理部３１は、メッセージの通知を以下のように実施してもよい。ＤＢ管理部３１は、ユーザによるタスク毎の設定に基づいて通知先または通知の有無を選択し、メッセージを通知する。ＤＢ管理部３１は、停滞ＤＢ３９のメッセージ内容９２５として同じ内容のメッセージ内容９２５が連日続く場合は、経過日数をカウントし、経過日数が多くなった場合はよりリスクが高まっている旨を示すメッセージ内容９２５へ変更してもよい。

以上のように、本実施形態では、ユーザがした作業についての作業実績時間や作業実績工数に基づいて作業の停滞を判断するとともに、その以外の情報に基づいて作業の停滞を判断する。これにより、本実施形態では、ユーザがした作業についての作業実績時間や作業実績工数に基づいては判断することができない作業の停滞を判断して、作業の停滞をより確からしく判断することができる。そして、本実施形態では、それらの少なくとも一方の判断において停滞が判断された場合、その判断に基づいて通知をする。これにより、ユーザや管理者などは、タスクが停滞している場合または停滞しそうにある場合にその通知を受けて、タスクを停滞させる要因を早急にかつ効果的に解消するように対策を講じることができる。

［第二実施形態］
次に、本発明の第二実施形態に係る作業管理装置を有する作業管理システム１００について説明する。第一実施形態では、プロジェクトＤＢ３３の管理者名３４１にもとづいて、あるユーザが担当するタスクに停滞リスクがあると判断される場合に、そのタスクを含むプロジェクトの管理者が所持する管理者端末５０へ停滞リスクのメッセージを送信している。本実施形態では、組織内においてプロジェクトに属する複数のユーザがグループとして活動する場合、管理者の上位に更に管理者としてのオーナが存在する場合において好適な例を説明する。以下の説明では、主に第一実施形態との相違点について説明する。

図１６は、本発明の第二実施形態のプロジェクトＤＢのデータ構造の説明図である。プロジェクトＤＢ３３は、作業管理対象であるユーザに関するプロジェクト情報を記憶するためのデータベースである。図１６には、図３のプロジェクトＤＢ３３に追加されるもののみを図示している。すなわち、第二実施形態におけるプロジェクトＤＢ３３は、図３のデータ構造に加えて、図１６（ａ）のグループに属するユーザと管理者との関係の情報、図１６（ｂ）の管理者とその上位に位置するオーナの関係の情報、を有する。図１６（ａ）のユーザと管理者との関係の情報は、プロジェクト毎のレコードを有する。プロジェクト毎のレコードには、プロジェクト名３４０、管理者名３４１、グループ名１６００、担当者名１６０１、が登録される。グループ名１６００には、複数のグループ名が登録されてよい。担当者名１６０１には、複数の担当者名が登録されてよい。図１６（ａ）のタスクＩＤ３４０および管理者名３４１は、それぞれ、図３（ｃ）のタスクＩＤ３４０および管理者名３４１に対応する。図１６（ａ）のレコード１６１０〜１６１５は、各ユーザがグループに所属していることを示す。図１６（ａ）の例では、ユーザＡとユーザＢがグループＡに、ユーザＣとユーザＤとユーザＧがグループＢに、ユーザＨとユーザＩがグループＣに、ユーザＥとユーザＦがグループＤに、所属している。また、ユーザＪとユーザＫがグループＥ、ユーザＣとユーザＤがグループＬに所属している。グループは、あるプロジェクトの下でチームとして活動している組織的な単位である。図１６（ａ）のレコード１６１０のユーザＡとユーザＢとは、マネージャＡが管理するプロジェクトＸの下のグループＡとして活動している。図１６（ａ）のレコード１６１１のユーザＣ、ユーザＤおよびユーザＧは、マネージャＢが管理するプロジェクトＹの下のグループＢとして活動している。図１６（ａ）のレコード１６１１とレコード１６１５とより、ユーザＣとユーザＤは、グループＢとグループＬの両方に所属していることが分かる。これは、ユーザＣとユーザＤは、プロジェクトＹというプロジェクトに参加しつつ、プロジェクトＬに参加していることを示している。同じユーザが複数のプロジェクトそれぞれに所属するよう設定されることにより、各プロジェクトの管理職へ適切に通知することが可能になる。図１６（ｂ）の管理者とその上位に位置するオーナの関係の情報、オーナ毎のレコードを有する。オーナ毎のレコードには、オーナ名１６２０、管理者名１６２１、が登録される。１つのレコードには、複数の管理者名１６２１が登録されてよい。これにより、管理者とオーナとに関する組織の上位下位関係が登録される。図１６（ｂ）のレコード１６３０〜１６３１は、各管理者が各オーナの下位に所属していることを示す。各オーナは、複数のプロジェクトを束ねているたとえば重役である。図１６（ｂ）の例では、マネージャＡとマネージャＢがオーナＡに、マネージャＣとマネージャＤとマネージャＥがオーナＢの下位に所属している。この場合、マネージャＡとマネージャＢとは、それぞれが管理するプロジェクトＸとプロジェクトＹに関して、プロジェクトの成果をオーナＡへ報告する義務を負っている。

図１７は、第二実施形態の停滞ＤＢのデータ構造の説明図である。図１７の停滞ＤＢは、図９の停滞ＤＢと同様に、図１０〜図１５のフローを経て更新されるタスク毎の停滞リスクを示すテーブルである。図１７の停滞ＤＢは、図１７（ａ）のタスク毎の停滞判断結果、図１７（ｂ）のメッセージデータ、を有する。図１７（ａ）のタスク毎の停滞判断結果は、タスク毎の判断結果のレコードを有する。タスク毎の判断結果のレコードには、図９（ａ）と同様に、日付９００、タスクＩＤ９０１、タスク名９０２、未着手９０３、作業遅延９０４、成果物無し９０５、感情９０６、相談・確認９０７、膠着９０８、が登録される。図１７（ｂ）のメッセージデータは、通知するメッセージおよび通知先の組み合わせ毎のレコードを有する。組み合わせ毎のレコードには、図９（ｂ）と同様に、日付９００、タスクＩＤ９０１、タスク名９０２、担当者名９２０、通知先９２１、メッセージ内容９２２、が登録される。次に、図１７（ａ）と図１７（ｂ）について、図９との差分を中心に説明する。図１７（ａ）のレコード１７００〜１７０２、および、図１７（ｂ）のレコード１７１０〜１７１３について、図１６（ａ）を用いて説明する。図１７（ａ）のレコード１７００〜１７０２は、２０１７年１１月０７日（火）の終業時刻時点のものであり、タスクＩＤ９０１がＴ３、Ｔ４、Ｔ７のタスクについて感情９０６の停滞リスク項目に丸印がついている。Ｔ３のタスクの担当者９２０は、図３よりユーザＣである。Ｔ４のタスクの担当者９２０は、図３よりユーザＤである。Ｔ７のタスクの担当者９２０は、ユーザＧである。ＤＢ管理部３１は、Ｔ３、Ｔ４、Ｔ７のタスクの担当者名９２０がそれぞれユーザＣ、ユーザＤ、ユーザＧと判断し、図１６（ａ）のレコード１６１１よりユーザＣ、ユーザＤ、ユーザＧがグループＢに所属していると判断する。ＤＢ管理部３１は、図１７（ｂ）のレコード１７１０〜１７１１を、第一実施形態と同様の処理で生成する。ＤＢ管理部３１は、図１７（ｂ）のレコード１７１３を、図１６（ａ）のグループにもとづいて生成する。つまり、前述したように、図１７（ａ）のユーザＣ、ユーザＤ、ユーザＧはグループＢに所属しており、同じグループに所属する３ユーザが同じ時点で感情９０６がネガティブである。この場合、ＤＢ管理部３１は、グループに対して停滞リスクを通知するメッセージを生成する。具体的には、ＤＢ管理部３１は、図１７（ｂ）のメッセージ内容９２２として「グループＢは、”タスクＣ”、”タスクＤ”、”タスクＧ”について困っている可能性があります。」というメッセージを生成する。その後、ＤＢ管理部３１は、図１７（ｂ）のレコード１７１３から、図１０のステップＳ１０１０の処理により、通知先９２１であるマネージャＢの所持する管理者端末５０へメッセージを送信する。

次に、図１７（ａ）のレコード１７０３、１７０４、および、図１７（ｂ）のレコード１７１４、１７１５について、図１６（ｂ）を用いて説明する。図１７（ａ）は、２０１７年１１月１５日（水）の終業時刻時点のものである。レコード１７０３は、作業遅延９０４、相談・確認９０７、膠着９０８の停滞リスク項目に、停滞を示す丸印がついている。レコード１７０４では、作業遅延９０４、感情９０６の停滞リスク項目に、停滞を示す丸印がついている。Ｔ８のタスクは、タスク名９０２がタスクＨであり、担当者名９２０がユーザＨである。Ｔ９のタスクは、タスク名９０２がタスクＪであり、担当者名９２０がユーザＪである。ＤＢ管理部３１は、図１６（ｂ）にもとづいて、図１７（ｂ）のレコード１７１４、１７１５を生成する。ＤＢ管理部３１は、前述したように、図１７（ａ）のレコード１７０３、１７０４より、それぞれのタスクは複数の停滞リスク項目に丸がついているため、一つだけ丸がついている場合より停滞リスクが高いと判断する。このように複数の停滞リスク項目に丸がついている場合、ＤＢ管理部３１は、停滞リスクの重要度が高いと判断し、タスクの管理者とともに、オーナを通知先に加える。ＤＢ管理部３１は、具体的には、図１７（ｂ）のタスクＨの管理者であるマネージャＢとともに、図１６（ｂ）よりそのオーナであるオーナＡを通知先に加える。また、 ＤＢ管理部３１は、図１７（ｂ）のタスクＪの管理者はマネージャＣとともに、図１６（ｂ）よりそのオーナであるオーナＢを通知先に加える。ＤＢ管理部３１は、メッセージ内容９２２については、図１７（ｂ）のレコード１７１４、１７１５と同様に、複数の停滞リスク項目を含めた内容を生成する。その後、ＤＢ管理部３１は、図１７（ｂ）のレコード１７１４、１７１５から、図１０のステップＳ１０１０の処理により、タスクＨの停滞リスクについてのメッセージを、「マネージャＢ、オーナＡ」の各自が使用する２つの管理者端末５０へ送信する。また、ＤＢ管理部３１は、タスクＪの停滞リスクについてのメッセージを、通知先９２１である「マネージャＢ、オーナＡ」の各自が使用する２つの管理者端末５０へ送信する。

以上のように、本実施形態では、ユーザがした作業についての作業実績時間や作業実績工数だけに基づいては判断することができない作業の停滞を判断して、作業の停滞をより確からしく判断することができる。また、その判断に基づいて通知をすることにより、ユーザや管理者などは、タスクが停滞している場合または停滞しそうにある場合にその通知を受けて、タスクを停滞させる要因を早急にかつ効果的に解消するように対策を講じることができる。特に、本実施形態では、ＤＢ管理部３１は、同一グループまたは同一プロジェクトに属する複数のユーザが同時期にネガティブな感情にあると判断できる場合、その複数のユーザについて同一グループまたは同一プロジェクトの作業が停滞していると判断する。この場合、本実施形態では、グループまたはプロジェクトの管理者へ通知する。ＤＢ管理部３１は、タスクが重要であると判断できる場合、そのタスクを担当するユーザの上司だけでなく、その上位の管理者へメッセージを通知する。ＤＢ管理部３１は、ユーザが属するグループ、タスクが属するプロジェクトを担当しているグループのメンバに対して、メッセージを通知する。ＤＢ管理部３１は、作業が停滞しているとの複数の判断がある場合には、ユーザの管理者またはタスクが属するプロジェクトの管理者とともに、それらの上位の管理者へメッセージを通知する。また、ＤＢ管理部３１は、メッセージの通知を以下のように実施してもよい。ＤＢ管理部３１は、ユーザによるタスク毎の設定に基づいて通知先または通知の有無を選択し、メッセージを通知する。ＤＢ管理部３１は、停滞ＤＢ３９のメッセージ内容９２５として同じ内容のメッセージ内容９２５が連日続く場合は、経過日数をカウントし、経過日数が多くなった場合はよりリスクが高まっている旨を示すメッセージ内容９２５へ変更してもよい。

以上、本発明をその好適な実施形態に基づいて詳述してきたが、本発明はこれら特定の実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の様々な形態も本発明に含まれる。

本発明は、上述の実施の形態の１以上の機能を実現するプログラムを、ネットワーク２０や記憶媒体を介してシステムや装置に供給し、そのシステム又は装置のコンピュータの１つ以上のプロセッサーがプログラムを読み出して実行する処理でも実現可能である。また、本発明は、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

また、上述した実施形態では、コンピュータがプログラムを実行することにより、各処理部として機能するものとしたが、処理の一部または全部を専用の電子回路（ハードウェア）で構成するようにしても構わない。

また、本発明には、プログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。

１０ クライアント端末
２０ ネットワーク
３０ サーバ装置
３１ ＤＢ管理部
３２ スケジュールＤＢ
３３ プロジェクトＤＢ
３４ タスク進捗ＤＢ
３５ 成果物ＤＢ
３６ 感情ＤＢ
３７ コミュニケーションＤＢ
３８ プロセスＤＢ
３９ 停滞ＤＢ
４０ モニタリング装置
５０ 管理者端末
１００ 作業管理システム
３００１ 通信部
３００２ 制御部
３００３ 記憶部

Claims (16)

1. ユーザの作業を管理する作業管理装置であって、
   ユーザの作業についての作業単位での作業実績時間または作業実績工数とともにユーザの作業の状況または内容についての情報を取得する取得手段と、
   前記取得手段による取得情報を記憶する記憶手段と、
   前記記憶手段に記憶されている作業単位での作業実績時間または作業実績工数に基づいて、作業の停滞を判断する第一停滞判断手段と、
   前記記憶手段に記憶されているユーザの作業の状況または内容についての取得情報に基づいて、作業の停滞を判断する第二停滞判断手段と、
   前記第一停滞判断手段および前記第二停滞判断手段の中の少なくとも一方において作業の停滞が判断される場合にメッセージを通知先へ通知する通知手段と、
   を有する、作業管理装置。
2. 前記取得手段は、
   ユーザの作業の状況または内容についての情報として、ユーザの操作に関する作業ログ、作業中のユーザを撮像した画像の解析に基づいて得られる作業ログ、および、ユーザが作業するスペースを撮像した画像の解析に基づいて得られる作業ログ、の中の少なくとも１つの作業ログを取得する、
   請求項１記載の、作業管理装置。
3. 前記取得手段は、
   ユーザの作業の状況または内容についての情報として、ユーザの操作に関する作業ログ、作業中のユーザを撮像した画像の解析に基づいて得られる作業ログ、および、ユーザが作業するスペースを撮像した画像の解析に基づいて得られる作業ログ、のすべてを取得する、
   請求項１記載の、作業管理装置。
4. 前記第一停滞判断手段は、
   作業実績時間または作業実績工数に基づく作業単位の実績が、予定に対して不足している場合、作業単位の作業が停滞していると判断する、
   請求項１から３のいずれか一項記載の、作業管理装置。
5. 前記第二停滞判断手段は、
   作業単位の成果物が無い場合、作業中のユーザの感情がネガティブであると判断できる場合、作業開始後のコミュニケーション回数が少ないと判断できる場合、および作業が膠着していると判断できる場合、の中の少なくとも１つの場合に、作業単位の作業が停滞していると判断する、
   請求項１から４のいずれか一項記載の、作業管理装置。
6. 前記第二停滞判断手段は、
   作業単位についてのユーザの作業が繰り返されている場合、作業が膠着していると判断して、前記作業単位の作業が停滞していると判断する、
   請求項５記載の、作業管理装置。
7. 前記第二停滞判断手段は、
   複数のユーザが同時期にネガティブな感情にあると判断できる場合、複数のユーザによる作業が停滞していると判断する、
   請求項１から６のいずれか一項記載の、作業管理装置。
8. 前記通知手段は、
   ユーザ、ユーザの管理者、作業単位が属するプロジェクトの管理者、および、それらの上位の管理者、の中から選択した通知先へメッセージを通知する、
   請求項１から７のいずれか一項記載の、作業管理装置。
9. 前記通知手段は、
   前記作業単位、前記作業単位を担当するユーザ、および、作業の停滞を判断した内容および個数に応じて、異なる内容のメッセージをまたは異なる通知先へ通知する、
   請求項１から８のいずれか一項記載の、作業管理装置。
10. 前記通知手段は、
    作業単位についての作業実績時間または作業実績工数が無い状態である未着手の場合には、作業単位を担当するユーザを通知先とすること、
    作業実績時間または作業実績校数が不足する場合には、作業単位を担当するユーザの管理者を通知先とすること、
    作業単位の成果物が無い場合には、作業単位を担当するユーザの管理者を通知先とすること、
    作業中のユーザの感情情報がネガティブであると判断できる場合には、作業単位を担当するユーザの管理者を通知先とすること、
    作業開始後のコミュニケーション回数が少ないと判断できる場合には、作業単位を担当するユーザの管理者を通知先とすること、および、
    作業が膠着していると判断できる場合には、作業単位を担当するユーザの管理者を通知先とすること、の中の少なくとも１つの通知を実行する、
    請求項１から９のいずれか一項記載の、作業管理装置。
11. 前記通知手段は、
    作業単位の重要度が高いほど、より上位の管理者へメッセージを通知する、
    請求項１から１０のいずれか一項記載の、作業管理装置。
12. 前記通知手段は、
    作業単位ごとの設定に基づいて、通知先または通知の有無を選択する、
    請求項１から１１のいずれか一項記載の、作業管理装置。
13. 前記通知手段は、
    ユーザが属するグループ、作業単位が属するプロジェクトを担当するグループに対して、メッセージを通知する、
    請求項１から１２のいずれか一項記載の、作業管理装置。
14. 前記通知手段は、
    作業が停滞しているとの複数の判断がある場合、ユーザの管理者または作業単位が属するプロジェクトの管理者、および、それらの上位の管理者へメッセージを通知する、
    請求項１から１３のいずれか一項記載の、作業管理装置。
15. ユーザの作業を管理する作業管理装置の制御方法であって、
    ユーザの作業についての作業単位での作業実績時間または作業実績工数とともにユーザの作業の状況または内容についての情報を取得する取得工程と、
    前記取得工程による取得情報を記憶手段に記憶する記憶工程と、
    前記記憶手段に記憶されている作業単位での作業実績時間または作業実績工数に基づいて、作業の停滞を判断する第一停滞判断工程と、
    前記記憶手段に記憶されているユーザの作業の状況または内容についての取得情報に基づいて、作業の停滞を判断する第二停滞判断工程と、
    前記第一停滞判断工程および前記第二停滞判断工程の中の少なくとも一方において作業の停滞が判断される場合にメッセージを通知先へ通知する通知工程と、
    を有する、作業管理装置の制御方法。
16. ユーザの作業を管理する作業管理装置の制御方法をコンピュータに実行させるプログラムであって、
    前記作業管理装置の制御方法は、
    ユーザの作業についての作業単位での作業実績時間または作業実績工数とともにユーザの作業の状況または内容についての情報を取得する取得工程と、
    前記取得工程による取得情報を記憶手段に記憶する記憶工程と、
    前記記憶手段に記憶されている作業単位での作業実績時間または作業実績工数に基づいて、作業の停滞を判断する第一停滞判断工程と、
    前記記憶手段に記憶されているユーザの作業の状況または内容についての取得情報に基づいて、作業の停滞を判断する第二停滞判断工程と、
    前記第一停滞判断工程および前記第二停滞判断工程の中の少なくとも一方において作業の停滞が判断される場合にメッセージを通知先へ通知する通知工程と、
    を有する、プログラム。

Images