JP6535863B2 - 情報処理装置及びプログラム - Google Patents

Description

本発明は、情報処理装置及びプログラムに関する。

従来、ユーザのタスクを管理するタスク管理ツールとして、種々の管理システムが提案されている。例えば特許文献１では、企業等の組織内のワークフローシステムであって、業務内の各タスクと、各タスクを担当する従業員とを紐付けた一覧表データを基に、従業員に対してタスクを依頼する電子メールの送信、タスクの催促、期限管理等を行う管理システムが開示されている。

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

しかしながら、特許文献１に係る発明は、個々のユーザに割り当てたタスクの管理を行うのみで、ユーザが他人に依頼したタスクの管理を行っていない。

例えばタスクの内容によっては、ユーザがあるタスクを行うためには、他人に依頼したタスクの完了を待たなくてはならない場合がある。従って、ユーザが担当するタスクを管理するだけでなく、他人が担当するタスクの管理も重要となる。

一つの側面では、ユーザに関連するタスクを適切に分類して管理することができる情報処理装置等を提供することを目的とする。

一つの案では、情報処理装置は、ユーザのメッセージ情報を取得する取得部と、取得した前記メッセージ情報から、前記ユーザに関連するタスク情報を抽出する抽出部と、抽出した前記タスク情報から、タスクを依頼された担当者、及び前記タスクを依頼した依頼者を識別する識別部と、前記タスク情報を、前記ユーザが前記担当者である第１タスク情報、又は前記ユーザが前記依頼者である第２タスク情報に分類する分類部と、分類した前記第１又は第２タスク情報をデータベースに登録する登録部と、該データベースを参照して、前記ユーザに対し、該ユーザが前記担当者である前記第１タスク情報の一覧と、該ユーザが前記依頼者である前記第２タスク情報の一覧とを別々に出力する出力部と、前記担当者及び依頼者の双方から、前記タスクの難易度の設定入力を受け付ける難易度受付部と、受け付けた前記難易度の設定値を記憶する難易度記憶部と、該難易度記憶部を参照し、複数の前記担当者が設定した前記難易度の設定値の分布に係る近似曲線、及び複数の前記依頼者が設定した前記難易度の設定値の分布に係る近似曲線を導出する導出部と、前記担当者及び依頼者それぞれについて導出した前記近似曲線の交点を、前記タスクの難易度の代表値に決定する決定部とを備えることを特徴とする。

一つの案では、プログラムは、ユーザのメッセージ情報を取得し、取得した前記メッセージ情報から、前記ユーザに関連するタスク情報を抽出し、抽出した前記タスク情報から、タスクを依頼された担当者、及び前記タスクを依頼した依頼者を識別し、前記タスク情報を、前記ユーザが前記担当者である第１タスク情報、又は前記ユーザが前記依頼者である第２タスク情報に分類し、分類した前記第１又は第２タスク情報をデータベースに登録し、該データベースを参照して、前記ユーザに対し、該ユーザが前記担当者である前記第１タスク情報の一覧と、該ユーザが前記依頼者である前記第２タスク情報の一覧とを別々に出力し、前記担当者及び依頼者の双方から、前記タスクの難易度の設定入力を受け付け、受け付けた前記難易度の設定値を難易度記憶部に記憶し、該難易度記憶部を参照し、複数の前記担当者が設定した前記難易度の設定値の分布に係る近似曲線、及び複数の前記依頼者が設定した前記難易度の設定値の分布に係る近似曲線を導出し、前記担当者及び依頼者それぞれについて導出した前記近似曲線の交点を、前記タスクの難易度の代表値に決定する処理をコンピュータに実行させることを特徴とする。

一つの側面では、ユーザに関連するタスクを適切に分類して管理することができる。

タスク管理システムの構成例を示す模式図である。 サーバの構成例を示すブロック図である。 プロジェクトＤＢのレコードレイアウトの一例を示す説明図である。 タスクＤＢのレコードレイアウトの一例を示す説明図である。 ユーザＤＢのレコードレイアウトの一例を示す説明図である。 タスク登録処理の概要に関する説明図である。 タスク管理画面の一例を示す説明図である。 タスク管理画面の一例を示す説明図である。 スケジュール調整処理に関する説明図である。 タスク実績画面の一例を示す説明図である。 タスク登録処理の処理手順の一例を示すフローチャートである。 タスク出力処理の処理手順の一例を示すフローチャートである。 文書生成処理に関する説明図である。 文書生成処理の処理手順の一例を示すフローチャートである。 タスクの難易度決定処理に関する説明図である。 実施の形態３に係るタスク出力処理の処理手順の一例を示すフローチャートである。

以下、本発明をその実施の形態を示す図面に基づいて詳述する。
（実施の形態１）
図１は、タスク管理システムの構成例を示す模式図である。本実施の形態では、業務内でユーザが携わるプロジェクトのタスク管理を行うタスク管理システムについて説明する。タスク管理システムは、情報処理装置１、端末２、２、２…、メールサーバ３、スケジュールサーバ４を含む。各装置は、インターネット等のネットワークＮを介して通信接続されている。

情報処理装置１は、種々の情報処理、情報の送受信を行う情報処理装置であり、例えばサーバ装置、パーソナルコンピュータ等である。本実施の形態において情報処理装置１はサーバ装置であるものとし、以下では簡潔のため、サーバ１と読み替える。サーバ１は、ユーザに関連するタスク情報を記憶し、タスクの実行期限等を管理する。本実施の形態では、サーバ１は、ユーザに割り当てられたタスクだけでなく、例えばユーザが他人に依頼したタスクのように、他人に割り当てられたタスクもユーザに関連するタスクとして管理する。

端末２は、各ユーザが使用する端末装置であり、例えばパーソナルコンピュータ、スマートフォン、タブレット端末等である。端末２はサーバ１と通信を行い、タスク情報の表示、入力等の処理を行う。

メールサーバ３は、ユーザによるメールの送受信を管理するサーバ装置である。本実施の形態においてサーバ１は、ユーザが送受信した電子メール（メッセージ情報）をメールサーバ３から取得し、メール文面からタスク名、タスクの内容、実施期限等のタスク情報を抽出する。サーバ１は、抽出したタスク情報をデータベースに登録し、タスク管理を行う。

スケジュールサーバ４は、ユーザのスケジュールに関する情報を管理するサーバ装置である。後述するように、スケジュールサーバ４は、タスク管理を行うサーバ１と情報の送受信を行い、他人からのスケジュールの調整依頼に対してユーザが対応可能な日程候補を特定し、スケジュールを仮登録する処理を行う。

図２は、サーバ１の構成例を示すブロック図である。サーバ１は、制御部１１、記憶部１２、通信部１３、大容量記憶装置１４を含む。
制御部１１はＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro-Processing Unit）等の演算処理装置を含み、記憶部１２に記憶されたプログラムＰを読み出して実行することにより、サーバ１に係る種々の情報処理、制御処理等を行う。なお、図２では制御部１１を単一のプロセッサとして図示してあるが、制御部１１はマルチプロセッサであってもよい。記憶部１２はＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等のメモリ素子を含み、制御部１１が処理を実行するために必要なプログラムＰ及びデータを記憶している。また、記憶部１２は、制御部１１が演算処理を実行するために必要なデータを一時的に記憶する。通信部１３は通信に関する処理を行うための処理回路等を含み、ネットワークＮを介して端末２等と情報の送受信を行う。

大容量記憶装置１４は、例えばハードディスク等を含む大容量の記憶装置である。大容量記憶装置１４は、プロジェクトＤＢ１４１、タスクＤＢ１４２、ユーザＤＢ１４３等を記憶している。プロジェクトＤＢ１４１は、ユーザが携わっている各プロジェクトのデータを記憶している。タスクＤＢ１４２は、各プロジェクトにおいてユーザが実施するタスクに関する情報を記憶している。ユーザＤＢ１４３は、各ユーザの情報を記憶している。

なお、本実施の形態において記憶部１２及び大容量記憶装置１４は一体の記憶装置として構成されていてもよい。また、大容量記憶装置１４は複数の記憶装置により構成されていてもよい。また、大容量記憶装置１４はサーバ１に接続された外部記憶装置であってもよい。
また、本実施の形態においてサーバ１は上記の構成に限られず、例えば操作入力を受け付ける入力部、サーバ１に係る情報を表示する表示部、可搬型記憶媒体に記憶された情報を読み取る読取部等を含んでもよい。

図３は、プロジェクトＤＢ１４１のレコードレイアウトの一例を示す説明図である。プロジェクトＤＢ１４１は、プロジェクトＩＤ列、プロジェクト名列、顧客列、プロジェクト属性列を含む。プロジェクトＩＤ列は、各プロジェクトを識別するための識別情報を記憶している。プロジェクト名列は、プロジェクトの名称を記憶している。顧客列は、各プロジェクトの取引先である顧客の情報（例えば法人名）を記憶している。プロジェクト属性列は、各プロジェクトの商材である商品名、各プロジェクトで取り扱う案件名など、プロジェクトの属性を表す情報を記憶している。
上記のように、プロジェクトＤＢ１４１には、業務内の各プロジェクトの情報が記憶されている。例えばサーバ１は、管理者によるプロジェクトの事前登録を受け付け、プロジェクトＤＢ１４１に記憶しておく。

図４は、タスクＤＢ１４２のレコードレイアウトの一例を示す説明図である。タスクＤＢ１４２は、タスクＩＤ列、タスク名列、プロジェクト列、タスク内容列、進捗列、添付ファイル列、担当者列、関係者列、着手予定日列、着手日列、完了予定日列、完了日列、後続タスク列を含む。タスクＩＤ列は、各プロジェクトにおいて実施される個々のタスクを識別するための識別情報を記憶している。タスク名列は、タスクＩＤと対応付けて、タスクの名称を記憶している。プロジェクト列は、タスクＩＤと対応付けて、当該タスクに係るプロジェクトのＩＤを記憶している。タスク内容列は、タスクＩＤと対応付けて、各タスクの内容を記憶している。進捗列は、タスクＩＤと対応付けて、各タスクの進捗状況を記憶している。

担当者列は、タスクＩＤと対応付けて、タスクの担当者を識別するための識別情報を記憶している。関係者列は、タスクＩＤと対応付けて、当該タスクに関係する関係者を識別するための識別情報を記憶している。関係者は、担当者にタスクを依頼した依頼者、その他の関係者である。タスクＤＢ１４２には、各タスクの担当者だけでなく、各タスクの関係者も併せて登録されている。

着手予定日列、着手日列、完了予定日列、完了日列はそれぞれ、タスクＩＤと対応付けて、タスクの着手予定日、着手日、完了予定日、完了日を記憶している。後続タスク列は、タスクＩＤと対応付けて、プロジェクトにおいて当該タスクに続く後続タスクのＩＤを記憶している。

図５は、ユーザＤＢ１４３のレコードレイアウトの一例を示す説明図である。ユーザＤＢ１４３は、ユーザＩＤ列、ユーザ名列、所属列、アドレス列、スケジューラアカウント列を含む。ユーザＩＤ列は、各ユーザを識別するための識別情報を記憶している。ユーザ名列は、ユーザＩＤと対応付けて、各ユーザの名前を記憶している。所属列は、ユーザＩＤと対応付けて、各ユーザの所属先（例えば勤務先の部署名）を記憶している。アドレス列は、ユーザＩＤと対応付けて、ユーザが使用しているメールアドレスを記憶している。スケジューラアカウント列は、ユーザＩＤと対応付けて、各ユーザが使用しているスケジューラのアカウント情報を記憶している。

図６は、タスク登録処理の概要に関する説明図である。以下では、タスク管理システムが実行する処理の概要について説明する。
サーバ１は、ユーザが送信又は受信したメッセージ情報からタスク情報を抽出し、データベースに登録する処理を行う。メッセージ情報は、例えば電子メールである。サーバ１は、メールサーバ３と同期し、ユーザのメールアドレス宛に送信されたメール、及びユーザのメールアドレスから送信されたメールを取得する。

なお、サーバ１は、本システムの利用者が送受信したメールを取得可能であればよく、メールの相手方は本システムの利用者である必要はない。例えば本システムを社内のタスク管理ツールとして実装する場合、メールの送信元又は送信先は社外の人間であってよい。

サーバ１は、取得したメールが、タスク依頼に係るメールであるか否かを判定する。例えばサーバ１は、メールのタイトル及び本文において、「依頼」、「お願いします」など、タスクの依頼時に用いられる所定のキーワードが記述されているか否かを判定する。

タスク依頼に係るメールであると判定した場合、サーバ１は、当該メールからタスク情報を抽出する。具体的には、サーバ１はタスク名、タスクの内容、タスクの実施期限等の情報を抽出する。例えばサーバ１は、メールのタイトルをタスク名とし、メールの本文をタスク内容として抽出する。また、サーバ１は、メール本文から、タスクの実施期限のほか、タスクに係るプロジェクト名、顧客名等のように、タスクに関連する属性情報を抽出する。属性情報は、タスクの分類を表す情報であり、タスクＩＤと紐付けられる関連情報である。サーバ１は、電子メールに対する文字認識を行い、実施期限のほかに、タスクの属性情報を抽出する。サーバ１はさらに、当該メールの添付ファイルを抽出する。このように、サーバ１は電子メールから、タスクに関連する情報を可能な限り抽出していく。

サーバ１は、抽出したタスク情報から、タスクの担当者及び関係者を識別する。担当者は、タスクを担当するユーザである。一方で、関係者は、例えばタスクを依頼した依頼者、タスクの結果物を共有するプロジェクトのメンバーなど、タスクに関係するユーザである。例えばサーバ１は、送信元（Ｆｒｏｍ）、送信先（Ｔｏ）、同時送信先（Ｃｃ、Ｂｃｃ）等の電子メールのヘッダ情報から、タスクの担当者及び関係者を識別する。また、例えばサーバ１は、メール本文の文字認識を行い、メール本文に含まれる個人名から、担当者及び関係者を識別するようにしてもよい。このように、サーバ１は、電子メールのヘッダ情報又は本文から担当者及び関係者を識別する。

サーバ１は、上記の識別結果に基づき、メールから抽出したタスク情報を、当該メールの送受信元であるユーザが担当者である第１タスク情報、又は当該ユーザが関係者である第２タスク情報に分類する。すなわちサーバ１は、メールに記載されているタスクが、ユーザ本人が実施すべきタスクであるか、又は他のユーザが実施すべきタスクであるかを判断する。

サーバ１は、第１タスク情報、又は第２タスク情報として分類したタスク情報を、タスクＤＢ１４２に登録する。例えばサーバ１は、当該タスクについて新規のタスクＩＤを発行し、タスクＩＤと対応付けて、タスク名、タスク内容、タスクの実施期限等の情報をタスクＤＢ１４２に記憶する。また、サーバ１は、タスクＩＤと対応付けて、担当者のユーザＩＤ、及び関係者のユーザＩＤ、その他の属性情報をタスクＤＢ１４２に記憶する。

上記の処理により、サーバ１は、ユーザが担当する第１タスク情報と、他のユーザが担当する第２タスク情報とを別々に管理する。すなわち、図６下に示すように、サーバ１は、ユーザから他人にアウトプットすべきタスクと、他人からユーザにインプットされるタスクとを別々に管理する。以上より、ユーザ本人のタスクと他人のタスクとが自動的に仕分けられ、タスク管理の利便性を高めることができる。

図７及び図８は、タスク管理画面の一例を示す説明図である。タスク管理画面は、タスクＤＢ１４２に登録されているタスク情報を一覧で示す管理画面である。例えばサーバ１は、端末２からログイン処理を受け付けた場合、図７等に示すタスク管理画面を生成して端末２に出力する。図７に示すように、タスク管理画面には、画面左側に第１タスクフォルダ５１、第２タスクフォルダ５２、及び実績タブ５３を含むメニューが表示される。

例えば端末２は、第１タスクフォルダ５１への操作入力を受け付けた場合、図７に示す画面を表示する。図７は、ユーザが担当する第１タスク情報の管理画面である。当該画面では、タスク名５４、プロジェクト名５５、及び実施期限５６を含むタスク情報が一覧表示される。

端末２は、タスク名５４への操作入力を受け付けた場合、さらにタスクの詳細表示を行う。具体的には図７に示すように、端末２は、タスク名５４の下に、客先名、関係者名、タスクの内容（詳細）、添付ファイル等の表示を行う。これにより、ユーザはタスクの詳細を確認することができる。

なお、タスク情報の抽出元であるメールの文面によっては、例えばタスクの実施期限、プロジェクト名等の必要事項が記述されていない可能性もあるため、サーバ１は、図７に示すタスク管理画面で、各タスクの属性情報の設定入力を受け付ける。例えば端末２は、タスク名５４、プロジェクト名５５、実施期限５６等の設定入力を受け付ける。サーバ１は、端末２を介して受け付けた属性情報をタスクＤＢ１４２に記憶する。

また、サーバ１は、端末２を介して、後続タスクの設定入力を受け付ける。後続タスクは、一連のプロジェクトにおいて、当該タスクに続いて実施すべきタスクである。例えばサーバ１は、同一プロジェクトについてタスクＤＢ１４２に登録済みのタスクを管理画面の後続タスク欄５７にプルダウン表示させ、ユーザによる選択を受け付ける。サーバ１は、後続タスク欄５７で選択されたタスクを、タスク名５４で示すタスクと対応付けてタスクＤＢ１４２に登録する。

また、サーバ１は、ユーザによる手動で一つひとつ後続タスクを設定するだけでなく、複数の後続タスクを一斉に登録可能としてもよい。具体的には、サーバ１は、複数のタスク情報を関連付けたプロジェクトのテンプレート情報を記憶しておき、テンプレート情報の指定を受け付けることで複数のタスク情報をタスクＤＢ１４２に一斉登録する。

例えばサーバ１は、「テンプレートを参照する」と表示されている参照オブジェクト５７２への操作入力を受け付けた場合、プロジェクトＤＢ１４１を参照し、過去に実施済みのプロジェクトの情報を読み出して端末２に出力する。例えばサーバ１は、商品名、案件名などのプロジェクト属性が、プロジェクト名５５で示されるプロジェクトと同じプロジェクトを検索し、検索されたプロジェクトを端末２に出力する。サーバ１は、端末２を介して、当該プロジェクトで実施されたタスクをテンプレートとして使用するか否かの指定入力を受け付ける。テンプレートとして使用する旨の指定入力を受け付けた場合、サーバ１は、後続タスクとして過去のプロジェクトのタスクを一斉登録する。

なお、上記では過去に実施されたプロジェクトのタスク情報を流用することとしたが、管理者が事前にテンプレートを用意しておき、事前設定されたテンプレートを用いてもよいことは勿論である。

上述の如く、サーバ１は、後続タスクの設定入力を受け付けることで、タスク同士の時系列的な紐付けを行い、複数のタスクを一連のプロジェクトとして管理する。これにより、ユーザは効率的にタスク情報を把握することができる。

ユーザは、タスク管理画面に表示されている第１タスク情報を確認し、タスクを実施する。ユーザは、タスクの進捗状況に応じて、関係者に対する進捗報告を行う。例えば端末２は、タスク管理画面に報告ボタン５８を表示しておく。報告ボタン５８への操作入力を受け付けた場合、端末２は新規のメール（不図示）を作成する。ユーザは、新規のメールに、タスクが進行中であること、タスクが完了したことなどの進捗報告をテキスト入力する。なお、当該メールにタスクの結果物を添付ファイルとして添付してもよいことは勿論である。端末２は、関係者宛に進捗報告のメールを送信する。

端末２から進捗報告に係るメールが送信された場合、サーバ１は、当該メールをメールサーバ３から取得する。サーバ１は、当該メールの文面に対して文字認識を行い、進捗報告の内容を抽出する。また、サーバ１は、添付ファイルを併せて抽出する。サーバ１は、抽出した進捗報告に係る情報を進捗履歴としてタスクＤＢ１４２に記録する。

上述の如く、サーバ１は、電子メールから進捗報告の内容を抽出し、進捗履歴を記録する。従って、サーバ１は、本システムの利用者ではない外部ユーザから送信されたメールについても、進捗報告の抽出、記録が可能である。例えば本システムを社内のタスク管理ツールとして実装する場合、サーバ１は、業務委託先など、社外の担当者からのメールを取得し、当該メールから進捗報告を抽出して記録してもよい。すなわちサーバ１は、本システムの利用者のメールアドレス宛に送信された電子メールから進捗報告を取得可能であればよく、進捗報告の発信元はシステムの内外を問わない。これにより、タスク管理の汎用性を高めることができる。

図８は、ユーザに関係する第２タスク情報の管理画面である。第２タスクフォルダ５２への操作入力を受け付けた場合、端末２は、図８に示すタスク管理画面を表示する。当該画面では、図７に示した第１タスク情報の管理画面と同じく、第２タスク情報が一覧で表示される。

一方で、図７の管理画面とは異なり、端末２は、各タスクの進捗状況を示すステータス５９を併せて表示する。具体的には、画面右端に示すように、「完了」、「未着手」、「進行中」などのステータス５９が表示される。サーバ１は、タスクＤＢ１４２に記録された進捗履歴を参照して、ステータス５９を管理画面上に出力する。ユーザ（関係者）はステータス５９により、各タスクの進捗状況を確認することができる。

端末２は、当該管理画面で第２タスク情報を一覧表示するだけでなく、タスクの完了を承認するか否かの選択入力を受け付ける。例えば図８に示すように、端末２は、担当者から完了の報告があったタスクについてアイコン６０を表示し、タスクが完了した旨をユーザ（関係者）に報知する。さらに端末２は、サーバ１と通信を行い、進捗報告の内容を示す報告画面６１をポップアップ表示する。

報告画面６１は、担当者から送信された進捗報告のメール内容を示すポップアップ画面である。端末２は、報告画面６１に、メール文面、添付ファイル等のほかに、承認ボタン６２、質問ボタン６３、及び差戻しボタン６４を表示する。承認ボタン６２への操作が行われた場合、当該タスクの完了が承認される。この場合、端末２はタスク完了が承認された旨をサーバ１に通知する。サーバ１は、タスクが完了した旨を進捗履歴としてタスクＤＢ１４２に記録する。この場合、例えばサーバ１は後続タスクの担当者に対し、後続タスクに着手すべき旨を通知する。

一方で、タスクの完了が承認されなかった場合、サーバ１は、承認が得られなかった旨を担当者に返信する。例えば報告画面６１の質問ボタン６３が操作された場合、端末２は、新規のメールを作成する。ユーザ（関係者）は、報告内容について疑問点をメールに入力し、担当者に返信して質問を行う。また、差戻しボタン６４が操作された場合、サーバ１が、タスクの完了が承認されなかった旨の定型メールを自動生成して担当者に返信する。このように、端末２はタスク管理画面上でタスクの完了を承認するか否かの選択を受け付け、非承認である場合に担当者へ通知を行う。なお、サーバ１は、関係者による質問、差戻し等の進捗履歴をタスクＤＢ１４２に記録しておく。
以上より、サーバ１は電子メールからタスク情報を抽出するだけでなく、進捗報告に係る電子メールの送信など、タスク管理に必要な処理を管理画面内で一括して行うことができる。これにより、ユーザの利便性を高めることができる。

図９は、スケジュール調整処理に関する説明図である。本システムでは、タスク管理を行うだけでなく、ユーザのスケジュールの調整支援も行う。
具体的には、サーバ１は、ユーザが送受信した電子メールから、ユーザのスケジュールの調整依頼に係る情報を抽出する。スケジュールの調整依頼は、例えば打ち合わせなどのイベントへの参加をユーザに要求する参加依頼である。サーバ１は、図９右上に示すように、メール文面から「打合せ」、「ご都合」等のキーワードの有無を判断し、スケジュール調整依頼に係るメールか否かを判定する。調整依頼に係るメールであると判定した場合、サーバ１は、メールに記載されている場所、日時（候補日）、イベント内容等の情報をメール文面から抽出する。

サーバ１は、ユーザのスケジュールを管理するスケジュールサーバ４にアクセスし、ユーザが対応可能な日程候補を特定する。すなわちサーバ１は、スケジューラから日程候補を特定する。なお、当該スケジューラは外部（スケジュールサーバ４）で管理してもよいし、サーバ１で管理してもよい。すなわち、サーバ１がユーザのスケジュールを参照可能であればよい。サーバ１はさらに、相手方から提示されている日時、前後のユーザの滞在場所、移動手段等から、日程候補を絞り込む。サーバ１は、最終的に特定した日程候補を相手方に通知する定型メールを作成し、メールサーバ３に返信を依頼する。メールサーバ３は、当該メールを相手方に返信する。

また、サーバ１は、上記で特定した日程候補におけるスケジュールを、スケジューラに仮登録をしておく。すなわちサーバ１は、スケジュールの仮押さえを行う。サーバ１は、イベントの場所、イベント内容、相手方の名称などを、日程候補の日時と対応付けてスケジュールサーバ４に記憶させる。

例えばサーバ１は、仮登録したスケジュールについて、後に相手方から返信されるメール内容を基に、スケジュールの確定、修正、リマインド等を行う。例えば日程確定のメールをメールサーバ３から取得した場合、サーバ１は当該メールから確定した日時を抽出し、スケジュールサーバ４に転送する。スケジュールサーバ４は、当該日時におけるスケジュールの確定登録、他の日程候補日に仮登録しておいたスケジュールの削除等を行う。このように、サーバ１は電子メールからタスク情報を抽出するだけでなく、ユーザのスケジュールに係る情報を抽出することで、スケジュール管理の支援を併せて行う。

図１０は、タスク実績画面の一例を示す説明図である。サーバ１は、タスクＤＢ１４２に記録されたタスクの進捗履歴から、各タスクの実施効率を表す実績情報を生成して端末２に出力する。
実績情報は、例えばタスクの工数、所要時間（いわゆるリードタイム）など、タスクの実績の評価指標となり得る情報である。例えばサーバ１は、タスクＤＢ１４２を参照し、各プロジェクトにおけるタスク別の所要時間、担当者数などの情報を読み出す。サーバ１は、上記の情報を基に、プロジェクト全体の工数、リードタイムのほか、タスク別の工数などを計算する。

例えば端末２は、実績タブ５３への操作入力を受け付けた場合、図１０に示すタスク実績画面を表示する。当該画面は、プロジェクトの実績情報を表示する画面である。例えば端末２は、プロジェクトタブ６５によりプロジェクトの指定入力を受け付ける。端末２は、プロジェクトタブ６５で選択されたプロジェクトについて、実績情報の出力をサーバ１に要求する。サーバ１は、要求されたプロジェクトの実績情報を端末２に出力する。

端末２は、サーバ１で計算されたタスクの実施効率をタスク実績画面に表示する。例えば端末２は、プロジェクト全体の工数、リードタイムを画面上部に表示する。また、端末２はタスク別の工数をガントチャート形式で表示する。これにより、ユーザはタスクの実績を確認することができ、業務の効率化を図ることができる。

なお、上記ではタスクの工数及びリードタイムを一例に挙げたが、サーバ１はこれだけでなく、例えばタスクの差戻し回数、タスクが完了してから後続タスクが着手されるまでのレスポンス時間など、その他の評価指標を実績情報として計算してもよい。

また、サーバ１は、過去に実施されたタスクの実績情報に基づき、未着手のタスクの工数予測、リードタイムの予測等を行ってもよい。これにより、ユーザの業務をより積極的に支援することができる。

図１１は、タスク登録処理の処理手順の一例を示すフローチャートである。図１１に基づき、サーバ１が実行するタスク登録処理の処理内容について説明する。
例えばサーバ１の制御部１１は、バッジ処理により以下の処理を行う。制御部１１は、ユーザのメッセージ情報を取得する（ステップＳ１１）。具体的には、サーバ１はメールサーバ３にアクセスし、ユーザから送信された、又はユーザ宛に送信された電子メールを取得する。制御部１１は、取得したメッセージ情報が、新規のタスク依頼に係るメッセージ情報であるか否かを判定する（ステップＳ１２）。例えば制御部１１は、メールのタイトル及び本文の文字認識を行い、タスクの依頼時に用いられる所定のキーワードが含まれるか否かを判定する。

タスク依頼に係るメッセージ情報であると判定した場合（Ｓ１２：ＹＥＳ）、制御部１１は、メッセージ情報からタスク情報を抽出する（ステップＳ１３）。例えば制御部１１は、メールのタイトルをタスク名、メール本文をタスク内容として、タスク情報を抽出する。また、制御部１１は、メール本文に対する文字認識を行い、タスクの実施期限のほか、例えばプロジェクト名、顧客名等の属性情報を抽出する。

制御部１１は、抽出したタスク情報から、タスクの担当者及び関係者を識別する（ステップＳ１４）。担当者は、タスクの実施を担当するユーザである。関係者は、タスクを担当者に依頼した依頼者、その他のユーザである。例えば制御部１１は、メールの送信元、送信先等のヘッダ情報から、又はメール本文に含まれる個人名から、タスクの担当者及び関係者を識別する。

制御部１１は、ステップＳ１４の識別結果に基づき、ステップＳ１３で抽出したタスク情報を、ユーザが担当者である第１タスク情報、又はユーザが関係者である第２タスク情報に分類する（ステップＳ１５）。すなわちサーバ１は、ユーザのメールから抽出したタスクを、ユーザが担当するタスクと、他のユーザが担当するタスクとに分類する。制御部１１は、分類した第１又は第２タスク情報をタスクＤＢ１４２に登録する（ステップＳ１６）。例えば制御部１１は、タスクＩＤと対応付けて、タスク名、タスク内容、実施期限のほか、担当者のユーザＩＤ、関係者のユーザＩＤ、その他の属性情報をタスクＤＢ１４２に記憶する。制御部１１は、一連の処理を終了する。

新規のタスク依頼に係るメッセージ情報でないと判定した場合（Ｓ１２：ＮＯ）、制御部１１は、メッセージ情報が既存タスクの進捗報告であるか否かを判定する（ステップＳ１７）。進捗報告であると判定した場合（Ｓ１７：ＹＥＳ）、制御部１１は、メッセージ情報から進捗報告の内容を抽出する（ステップＳ１８）。制御部１１は、抽出した進捗報告の内容を、進捗履歴としてタスクＤＢ１４２に記録し（ステップＳ１９）、一連の処理を終了する。

進捗報告でないと判定した場合（Ｓ１７：ＮＯ）、制御部１１は、メッセージ情報が、ユーザのスケジュールの調整依頼に係るメッセージであるか否かを判定する（ステップＳ２０）。スケジュールの調整依頼でないと判定した場合（Ｓ２０：ＮＯ）、制御部１１は一連の処理を終了する。スケジュールの調整依頼であると判定した場合（Ｓ２０：ＹＥＳ）、制御部１１は、メッセージ情報から、スケジュールの調整依頼に係る情報を抽出する（ステップＳ２１）。例えば制御部１１は、メールに記述されているイベントの場所、日時、イベント内容等の情報を抽出する。

制御部１１は、スケジュールサーバ４で管理されているスケジューラを参照し、ユーザが対応可能な日程候補を特定する（ステップＳ２２）。制御部１１は、特定した日程候補を相手方に通知する返信メッセージを生成し、メールサーバ３を介して返信する（ステップＳ２３）。さらに制御部１１は、スケジュールサーバ４で管理されているスケジューラに対し、ステップＳ２２で特定された日程候補におけるスケジュールを仮登録する（ステップＳ２４）。制御部１１は、一連の処理を終了する。

図１２は、タスク出力処理の処理手順の一例を示すフローチャートである。図１２に基づき、サーバ１が実行するタスク出力処理の処理内容について説明する。
例えばサーバ１の制御部１１は、端末２からのログイン処理を受け付けた場合、以下の処理を実行する。制御部１１は、端末２からの出力要求に基づき、ログインしたユーザが担当者である第１タスク情報を出力するか否かを判定する（ステップＳ４１）。第１タスク情報を出力すると判定した場合（Ｓ４１：ＹＥＳ）、制御部１１はタスクＤＢ１４２を参照して、当該ユーザが担当者である第１タスク情報を一覧で示すタスク管理画面を端末２に出力する（ステップＳ４２）。制御部１１は、当該タスク管理画面において、既存タスクの属性情報の設定入力、後続タスクの設定入力、及び進捗報告の入力等を受け付ける（ステップＳ４３）。制御部１１は、入力内容をタスクＤＢ１４２に記憶する。

制御部１１は、ステップＳ４３で進捗報告を受け付けたか否かを判定する（ステップＳ４４）。進捗報告を受け付けていないと判定した場合（Ｓ４４：ＮＯ）、制御部１１は処理をステップＳ５６に移行する。進捗報告を受け付けたと判定した場合（Ｓ４４：ＹＥＳ）、制御部１１は、進捗報告に係るメッセージ情報を生成し、関係者宛に出力する（ステップＳ４５）。制御部１１は、処理をステップＳ５６に移行する。

第１タスク情報を出力しないと判定した場合（Ｓ４１：ＮＯ）、制御部１１は、ユーザが関係者である第２タスク情報を出力するか否かを判定する（ステップＳ４６）。第２タスク情報を出力すると判定した場合（Ｓ４６：ＹＥＳ）、制御部１１は、当該ユーザが関係者である第２タスク情報を一覧で示すタスク管理画面を端末２に出力する（ステップＳ４７）。

制御部１１は、タスクＤＢ１４２を参照し、担当者から進捗報告がなされた第２タスク情報があるか否かを判定する（ステップＳ４８）。進捗報告がなされた第２タスク情報がないと判定した場合（Ｓ４８：ＮＯ）、制御部１１は処理をステップＳ５６に移行する。進捗報告がなされた第２タスク情報があると判定した場合（Ｓ４８：ＹＥＳ）、制御部１１は、担当者から送信された進捗報告に係るメッセージ情報を端末２に出力する（ステップＳ４９）。例えば制御部１１は、進捗報告の内容を示す報告画面６１を生成し、端末２に出力する。報告画面６１は、担当者から送信された進捗報告のメール内容を示すポップアップ画面であり、ユーザ（関係者）がタスクの完了を承認するか否かを選択するための承認ボタン６２、差戻しボタン６４等を含む。

制御部１１は、ステップＳ４９で出力した進捗報告に対して、タスクの完了を承認する選択入力を受け付けたか否かを判定する（ステップＳ５０）。承認されたと判定した場合（Ｓ５０：ＹＥＳ）、制御部１１は、当該タスクが完了した旨の進捗履歴をタスクＤＢ１４２に記録する（ステップＳ５１）。制御部１１は、処理をステップＳ５６に移行する。

タスクの完了が承認されなかったと判定した場合（Ｓ５０：ＮＯ）、制御部１１は、タスクの担当者に対する通知を行う（ステップＳ５２）。当該通知の内容は、例えばタスクの差戻し、報告内容に関する質問などである。サーバ１は、関係者により入力された入力内容に応じて、担当者に対する通知を行う。また、この場合にサーバ１は、タスクの差戻し、質問などの通知内容を進捗履歴としてタスクＤＢ１４２に記録しておく。制御部１１は、処理をステップＳ５６に移行する。

第２タスク情報を出力しないと判定した場合（Ｓ４６：ＮＯ）、制御部１１は、タスクの実績情報を出力するか否かを判定する（ステップＳ５３）。実績情報は、タスクの実施効率を表す情報であり、例えばタスクの工数、リードタイム等の情報である。実績情報を出力しないと判定した場合（Ｓ５３：ＮＯ）、制御部１１は処理をステップＳ５６に移行する。実績情報を出力すると判定した場合（Ｓ５３：ＹＥＳ）、制御部１１は、タスクＤＢ１４２に記憶されている各タスクの進捗履歴を参照し、タスクの工数、所要時間（リードタイム）等の実施効率を計算する（ステップＳ５４）。制御部１１は、計算した工数、リードタイム等の実施効率を表示するタスク実績画面を生成し、端末２に出力する（ステップＳ５５）。制御部１１は、処理をステップＳ５６に移行する。

制御部１１は、端末２からログアウトの要求を受け付けたか否かを判定する（ステップＳ５６）。ログアウトしないと判定した場合（Ｓ５６：ＮＯ）、制御部１１は処理をステップＳ４１に戻す。ログアウトすると判定した場合（Ｓ５６：ＹＥＳ）、制御部１１は一連の処理を終了する。

なお、上記でサーバ１は、ユーザのメールアドレスにおいて送受信された電子メールからタスク情報を抽出したが、本実施の形態はこれに限定されるものではない。例えばサーバ１は、ユーザが属するチャットグループ内のメッセージを読み取り、タスク情報を抽出するようにしてもよい。このように、サーバ１はユーザが送受信するメッセージ情報からタスク情報を抽出可能であればよく、タスク情報の抽出元は電子メールに限定されない。

また、ユーザのメールアドレス宛に送信された電子メールにタスク情報が記述されておらず、スケジュールに関する情報も記述されていない場合、当該メールは、例えば単なる確認、御礼など、形式的な内容である可能性が高い。そこで、例えばサーバ１は、電子メールからタスク及びスケジュールに関する記述が認識されない場合（ステップＳ２０：ＮＯ）、定型メッセージを自動返信するようにしてもよい。これにより、ユーザの利便性を高めることができる。

また、例えばサーバ１は、担当者に対するリマインド、催促等を行ってもよいことは勿論である。

以上より、本実施の形態１によれば、ユーザに関連するタスクを適切に分類して管理することができる。

また、本実施の形態１によれば、進捗報告の送受信を仲介することで、効率的なタスク管理を支援することができる。

また、本実施の形態１によれば、タスクの工数、リードタイム等、タスク実績の管理を行うことができる。

また、本実施の形態１によれば、複数のタスクを関連付けたプロジェクトのテンプレート情報を用いることで、漏れのないタスク管理を行うことができる。

また、本実施の形態１によれば、タスク管理の支援だけでなく、スケジュール管理の支援も行うことができる。

（実施の形態２）
本実施の形態では、サーバ１が管理しているタスク情報を基に、ユーザが会議で使用する文書を作成する形態について述べる。なお、実施の形態１と重複する内容については同一の符号を付して説明を省略する。
図１３は、文書生成処理に関する説明図である。本実施の形態においてサーバ１は、ユーザが会議で使用するアジェンダ、及び会議内容を記録した議事録を作成する。

具体的には、サーバ１は端末２より、タスクＤＢ１４２に登録されている複数のタスクのうち、会議の議題に関連するタスクの選択を受け付ける。例えば図１３右上に示すように、サーバ１は、プロジェクトのタスクを端末２に一覧表示し、一又は複数のタスクの選択をチェックボックス形式で受け付ける。

例えばサーバ１は、ユーザにより指定された属性を有するタスクをタスクＤＢ１４２から検索し、端末２に一覧表示する。上述の如く、タスクの属性は、例えば担当者名、関係者名、プロジェクト名、顧客名、プロジェクトの属性（例えばプロジェクトで取り扱う商品等）などのように、タスクの分類を表す情報であり、タスクＩＤに紐付く関連情報である。実施の形態１で述べたように、サーバ１は、電子メールの内容を認識することで、又はタスク管理画面を介して設定入力を受け付けることで、上記の各種情報をタスクの属性情報としてタスクＤＢ１４２に記憶しておく。

例えばサーバ１は、端末２を介して属性情報の指定を受け付け、指定された属性のタスクを検索して端末２に一覧表示する。例えば「プロジェクトＡ」というプロジェクト名の指定を受け付けた場合、サーバ１は、「プロジェクトＡ」の属性を有するタスク群をタスクＤＢ１４２から検索する。そしてサーバ１は、図１３に示すように、検索したタスク群を端末２に一覧表示する。

サーバ１は、端末２に一覧表示した複数のタスクから、会議の議題に用いるタスクの選択を受け付ける。サーバ１は、選択されたタスクに係るタスク情報を基に、会議の議題項目と、各項目に対応する入力欄とを含む文書ファイルを生成する。例えばサーバ１は、各タスクのタスク名を項目名とし、各項目に対応するテキスト入力欄を挿入した文書ファイルを生成する。これによりサーバ１は、会議のアジェンダに相当する文書を作成する。

サーバ１は、生成した文書ファイルを端末２に出力する。会議時にユーザは、端末２を操作して、各入力欄へのテキスト入力を行う。具体的には、ユーザは会議内の発言、決定事項、新たに挙がった課題など、議事内容を入力していく。

会議後、サーバ１は端末２からの操作に応じて、議事内容が入力された文書ファイルを議事録として保存する。例えばサーバ１は、当該文書ファイルをタスクに関連する添付ファイルとしてタスクＤＢ１４２に記憶する。

また、サーバ１は、当該文書ファイルへの入力内容に応じて、タスクＤＢ１４２を更新する。例えばサーバ１は、各議題項目の入力欄に入力されたテキストデータを参照し、対応するタスクの完了が承認されたか否かを判別する。サーバ１は、判別結果に応じてタスクの進捗履歴を更新し、タスクの完了を記録する。また、例えばサーバ１は、文書ファイルに入力された新たな課題を、新規のタスク情報としてタスクＤＢ１４２に登録する。
上述の如く、サーバ１はタスク情報を基にアジェンダ及び議事録を作成し、議事内容を基にタスクＤＢ１４２を更新していく。これにより、サーバ１は単にタスク情報を管理するだけでなく、タスク情報に基づく業務支援を行うことができる。

図１４は、文書生成処理の処理手順の一例を示すフローチャートである。図１４に基づき、サーバ１が実行する文書生成処理の処理内容について説明する。
サーバ１の制御部１１は、端末２を介して、タスクの属性情報の指定を受け付ける（ステップＳ２０１）。属性情報は、メッセージ情報から抽出された、又はユーザにより設定入力された情報であり、タスクの分類を表す情報である。タスクＤＢ１４２には、タスクＩＤと対応付けて、タスクの属性情報が記憶されている。制御部１１は、指定された属性情報に基づき、複数のタスク情報をタスクＤＢ１４２から検索する（ステップＳ２０２）。

制御部１１は、検索した複数のタスク情報を端末２に出力する（ステップＳ２０３）。そして制御部１１は、出力した複数のタスク情報のうち、一又は複数のタスク情報を選択する選択入力を受け付ける（ステップＳ２０４）。制御部１１は、選択されたタスク情報に基づき、議題項目と、議題項目に対応する入力欄とを含む文書ファイルを生成し、端末２に出力する（ステップＳ２０５）。上述の如く、当該文書ファイルはアジェンダに相当する文書である。例えば制御部１１は、タスク名を議題項目とし、各項目に対応するテキスト入力欄を文書ファイルに挿入してアジェンダを生成する。

制御部１１は、生成した文書ファイルへの情報入力を受け付ける（ステップＳ２０６）。例えば制御部１１は、端末２を介して、文書ファイルへのテキスト入力を受け付ける。制御部１１は、ユーザによりテキスト等が入力された文書ファイルを、議事録として保存する（ステップＳ２０７）。

制御部１１は、文書ファイルへの入力内容に応じて、タスクＤＢ１４２を更新する（ステップＳ２０８）。例えば制御部１１は、文書ファイルに入力されたテキストデータから、既存タスクの進捗履歴の更新、新規タスクの登録等を行う。制御部１１は、一連の処理を終了する。

なお、上記では属性情報に基づくタスクの検索機能をアジェンダ作成時に利用する場合について説明したが、検索機能の利用はアジェンダ作成時に限定されるものではなく、例えばプロジェクトの現状確認時など、その他の利用場面で検索可能としてもよいことは勿論である。すなわちサーバ１は、タスク属性を検索キーとして複数のタスク情報を一斉出力することができればよい。

以上より、本実施の形態２によれば、タスク情報を基にした文書作成を行うことで、さらなる業務の効率化を支援することができる。

（実施の形態３）
本実施の形態では、担当者が認識するタスクの難易度と、関係者が認識するタスクの難易度との差異を解消し、タスクの難易度の代表値を決定する形態について述べる。
図１５は、タスクの難易度決定処理に関する説明図である。図１５では、本実施の形態においてサーバ１が実行する処理内容について、概念的な説明図を図示している。

関係者から担当者へタスクが依頼された場合、当該タスクの難易度について、関係者と担当者との間で認識の差異が生じる場合がある。例えば図１５に示すように、タスクを依頼する関係者から見れば難易度が低いが、実際にタスクを行う担当者から見れば難易度が高い場合がある。そこで本実施の形態では、関係者及び担当者の双方から難易度の設定入力を受け付け、設定された難易度の設定値を統計的に処理し、一般的な難易度に変換してユーザに提示する。

例えばサーバ１は、図７、図８等で図示したタスク管理画面において、１〜５の五段階の数値でタスクの難易度の設定入力を受け付ける。サーバ１は、入力されたタスクの難易度をタスクＤＢ１４２に記憶する。サーバ１は、各タスクについて担当者及び関係者の双方から難易度の設定入力を受け付け、タスクＤＢ１４２に記憶していく。

サーバ１は、内容が同じタスク（例えばタスク名が類似するタスク）について、担当者及び関係者夫々の難易度の設定値をタスクＤＢ１４２から読み出す。サーバ１は、読み出した担当者及び関係者夫々の難易度の設定値について、統計処理を行う。例えばサーバ１は、担当者たちが設定した難易度の分布、及び関係者たちが設定した難易度の分布がそれぞれ正規分布に従うと仮定し、全体として２つの正規分布が重ね合わされた二峰分布に従うと仮定して統計処理を行う。サーバ１は、担当者側の難易度の設定値、及び関係者側の難易度の設定値夫々について平均値、分散等を計算し、正規分布に係る近似曲線を導出する。

サーバ１は、統計処理による分析結果から、当該タスクの難易度の代表値を決定する。例えばサーバ１は、各正規分布の交点に位置する難易度を、当該タスクの難易度の代表値に決定する。すなわちサーバ１は、図１５に示す分布図において、二峰分布の谷に相当する位置を代表値に決定する。例えばサーバ１は、図１０で例示したタスク実績画面において、決定した難易度の代表値をタスクの一般的難易度としてユーザに提示する。ユーザは、提示された難易度を参考に、タスクの工数予測などを行うことができる。

なお、上記の難易度の代表値の決定方法は一例であって、本実施の形態はこれに限定されるものではない。例えばサーバ１は、担当者及び関係者が設定した難易度の中央値、平均値などを代表値としてもよい。

図１６は、実施の形態３に係るタスク出力処理の処理手順の一例を示すフローチャートである。図１６に基づき、本実施の形態に係るサーバ１の処理内容について説明する。
第１タスク情報を端末２に出力した後（ステップＳ４２）、サーバ１の制御部１１は、タスクの担当者による、第１タスク情報の難易度の設定入力を受け付け、タスクＤＢ１４２に記憶する（ステップＳ３０１）。例えば制御部１１は、五段階評価で各タスクの難易度の設定入力を受け付ける。制御部１１は、担当者が設定した難易度の設定値をタスクＤＢ１４２に記憶しておく。制御部１１は、処理をステップＳ４３に移行する。

第２タスク情報を端末２に出力した後（ステップＳ４７）、制御部１１は、タスクの関係者による、第２タスク情報の難易度の設定入力を受け付け、タスクＤＢ１４２に記憶する（ステップＳ３０２）。例えば制御部１１は、ステップＳ３０１と同じく、五段階評価で各タスクの難易度の設定入力を受け付ける。制御部１１は、関係者が設定した難易度の設定値をタスクＤＢ１４２に記憶しておく。制御部１１は、処理をステップＳ４８に移行する。

ステップＳ５４の処理を実行後、制御部１１は、タスクＤＢ１４２を参照し、担当者及び関係者の双方が設定した難易度の設定値から、タスクの難易度の代表値を決定する（ステップＳ３０３）。例えば制御部１１は、担当者の設定値、及び関係者の設定値の双方が正規分布に従うと仮定し、全体として二峰分布に従うと仮定して統計処理を行い、難易度の代表値を決定する。制御部１１は、決定した難易度の代表値を含むタスク実績画面を生成し、端末２に出力する（ステップＳ３０４）。制御部１１は、処理をステップＳ５６に移行する。

以上より、本実施の形態３によれば、タスクの難易度の代表値を定めることで、担当者と関係者との間の認識の差異の解消、タスクの工数予測等に役立てることができる。

今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。

１ サーバ（情報処理装置）
１１ 制御部
１２ 記憶部
Ｐ プログラム
１３ 通信部
１４ 大容量記憶装置
１４１ プロジェクトＤＢ
１４２ タスクＤＢ
１４３ ユーザＤＢ
２ 端末
３ メールサーバ
４ スケジュールサーバ

Claims (9)

1. ユーザのメッセージ情報を取得する取得部と、
   取得した前記メッセージ情報から、前記ユーザに関連するタスク情報を抽出する抽出部と、
   抽出した前記タスク情報から、タスクを依頼された担当者、及び前記タスクを依頼した依頼者を識別する識別部と、
   前記タスク情報を、前記ユーザが前記担当者である第１タスク情報、又は前記ユーザが前記依頼者である第２タスク情報に分類する分類部と、
   分類した前記第１又は第２タスク情報をデータベースに登録する登録部と、
   該データベースを参照して、前記ユーザに対し、該ユーザが前記担当者である前記第１タスク情報の一覧と、該ユーザが前記依頼者である前記第２タスク情報の一覧とを別々に出力する出力部と、
   前記担当者及び依頼者の双方から、前記タスクの難易度の設定入力を受け付ける難易度受付部と、
   受け付けた前記難易度の設定値を記憶する難易度記憶部と、
   該難易度記憶部を参照し、複数の前記担当者が設定した前記難易度の設定値の分布に係る近似曲線、及び複数の前記依頼者が設定した前記難易度の設定値の分布に係る近似曲線を導出する導出部と、
   前記担当者及び依頼者それぞれについて導出した前記近似曲線の交点を、前記タスクの難易度の代表値に決定する決定部と
   を備えることを特徴とする情報処理装置。
2. 前記タスクの進捗報告を取得する第２取得部を備え、
   前記進捗報告を取得した場合、前記出力部は、該進捗報告を前記依頼者に対して出力し、
   出力した前記進捗報告に対して、前記タスクの完了を承認するか否かの選択を受け付ける承認受付部と、
   前記タスクの完了が承認されなかった場合、前記担当者に対する通知を行う通知部と
   を備えることを特徴とする請求項１に記載の情報処理装置。
3. 前記進捗報告を基に、前記タスクの進捗履歴を記録する記録部と、
   該進捗履歴を参照して、前記タスクの実施効率を計算する計算部と
   を備えることを特徴とする請求項２に記載の情報処理装置。
4. 複数の前記タスク情報を関連付けたテンプレート情報を記憶する記憶部を備え、
   前記登録部は、前記テンプレート情報の指定を受け付けることで、前記複数のタスク情報を登録する
   ことを特徴とする請求項１〜３のいずれか１項に記載の情報処理装置。
5. 前記抽出部はさらに、前記メッセージ情報から、前記ユーザのスケジュールの調整依頼に係る情報を抽出し、
   前記ユーザのスケジュールを管理するスケジューラを参照して、前記ユーザが対応可能な日程候補を特定する特定部と、
   特定した前記日程候補におけるスケジュールを前記スケジューラに仮登録する第２登録部と
   を備えることを特徴とする請求項１〜４のいずれか１項に記載の情報処理装置。
6. 前記タスクの属性情報に基づき、複数の前記タスク情報を前記データベースから検索する検索部を備え、
   前記出力部は、検索された前記複数のタスク情報を出力する
   ことを特徴とする請求項１〜５のいずれか１項に記載の情報処理装置。
7. 前記データベースに登録されている前記タスク情報の選択を受け付けるタスク選択部と、
   選択された前記タスク情報を基に、議題項目と、該議題項目に対応する入力欄とを含む文書ファイルを生成する文書生成部とを備え、
   前記出力部は、前記文書ファイルを出力し、
   出力した前記文書ファイルへの入力内容に応じて、前記データベースを更新する更新部を備える
   ことを特徴とする請求項１〜６のいずれか１項に記載の情報処理装置。
8. 前記メッセージ情報は、前記ユーザから送信された、又は前記ユーザ宛に送信された電子メールであり、
   前記識別部は、前記電子メールのヘッダ情報又は本文から前記担当者及び依頼者を識別する
   ことを特徴とする請求項１〜７のいずれか１項に記載の情報処理装置。
9. ユーザのメッセージ情報を取得し、
   取得した前記メッセージ情報から、前記ユーザに関連するタスク情報を抽出し、
   抽出した前記タスク情報から、タスクを依頼された担当者、及び前記タスクを依頼した依頼者を識別し、
   前記タスク情報を、前記ユーザが前記担当者である第１タスク情報、又は前記ユーザが前記依頼者である第２タスク情報に分類し、
   分類した前記第１又は第２タスク情報をデータベースに登録し、
   該データベースを参照して、前記ユーザに対し、該ユーザが前記担当者である前記第１タスク情報の一覧と、該ユーザが前記依頼者である前記第２タスク情報の一覧とを別々に出力し、
   前記担当者及び依頼者の双方から、前記タスクの難易度の設定入力を受け付け、
   受け付けた前記難易度の設定値を難易度記憶部に記憶し、
   該難易度記憶部を参照し、複数の前記担当者が設定した前記難易度の設定値の分布に係る近似曲線、及び複数の前記依頼者が設定した前記難易度の設定値の分布に係る近似曲線を導出し、
   前記担当者及び依頼者それぞれについて導出した前記近似曲線の交点を、前記タスクの難易度の代表値に決定する
   処理をコンピュータに実行させることを特徴とするプログラム。

Images