(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0011】
以下、本発明をその実施の形態を示す図面に基づいて詳述する。
(実施の形態1)
図1は、タスク管理システムの構成例を示す模式図である。本実施の形態では、業務内でユーザが携わるプロジェクトのタスク管理を行うタスク管理システムについて説明する。タスク管理システムは、情報処理装置1、端末2、2、2…、メールサーバ3、スケジュールサーバ4を含む。各装置は、インターネット等のネットワークNを介して通信接続されている。
【0012】
情報処理装置1は、種々の情報処理、情報の送受信を行う情報処理装置であり、例えばサーバ装置、パーソナルコンピュータ等である。本実施の形態において情報処理装置1はサーバ装置であるものとし、以下では簡潔のため、サーバ1と読み替える。サーバ1は、ユーザに関連するタスク情報を記憶し、タスクの実行期限等を管理する。本実施の形態では、サーバ1は、ユーザに割り当てられたタスクだけでなく、例えばユーザが他人に依頼したタスクのように、他人に割り当てられたタスクもユーザに関連するタスクとして管理する。
【0013】
端末2は、各ユーザが使用する端末装置であり、例えばパーソナルコンピュータ、スマートフォン、タブレット端末等である。端末2はサーバ1と通信を行い、タスク情報の表示、入力等の処理を行う。
【0014】
メールサーバ3は、ユーザによるメールの送受信を管理するサーバ装置である。本実施の形態においてサーバ1は、ユーザが送受信した電子メール(メッセージ情報)をメールサーバ3から取得し、メール文面からタスク名、タスクの内容、実施期限等のタスク情報を抽出する。サーバ1は、抽出したタスク情報をデータベースに登録し、タスク管理を行う。
【0015】
スケジュールサーバ4は、ユーザのスケジュールに関する情報を管理するサーバ装置である。後述するように、スケジュールサーバ4は、タスク管理を行うサーバ1と情報の送受信を行い、他人からのスケジュールの調整依頼に対してユーザが対応可能な日程候補を特定し、スケジュールを仮登録する処理を行う。
【0016】
図2は、サーバ1の構成例を示すブロック図である。サーバ1は、制御部11、記憶部12、通信部13、大容量記憶装置14を含む。
制御部11はCPU(Central Processing Unit)、MPU(Micro-Processing Unit)等の演算処理装置を含み、記憶部12に記憶されたプログラムPを読み出して実行することにより、サーバ1に係る種々の情報処理、制御処理等を行う。なお、
図2では制御部11を単一のプロセッサとして図示してあるが、制御部11はマルチプロセッサであってもよい。記憶部12はRAM(Random Access Memory)、ROM(Read Only Memory)等のメモリ素子を含み、制御部11が処理を実行するために必要なプログラムP及びデータを記憶している。また、記憶部12は、制御部11が演算処理を実行するために必要なデータを一時的に記憶する。通信部13は通信に関する処理を行うための処理回路等を含み、ネットワークNを介して端末2等と情報の送受信を行う。
【0017】
大容量記憶装置14は、例えばハードディスク等を含む大容量の記憶装置である。大容量記憶装置14は、プロジェクトDB141、タスクDB142、ユーザDB143等を記憶している。プロジェクトDB141は、ユーザが携わっている各プロジェクトのデータを記憶している。タスクDB142は、各プロジェクトにおいてユーザが実施するタスクに関する情報を記憶している。ユーザDB143は、各ユーザの情報を記憶している。
【0018】
なお、本実施の形態において記憶部12及び大容量記憶装置14は一体の記憶装置として構成されていてもよい。また、大容量記憶装置14は複数の記憶装置により構成されていてもよい。また、大容量記憶装置14はサーバ1に接続された外部記憶装置であってもよい。
また、本実施の形態においてサーバ1は上記の構成に限られず、例えば操作入力を受け付ける入力部、サーバ1に係る情報を表示する表示部、可搬型記憶媒体に記憶された情報を読み取る読取部等を含んでもよい。
【0019】
図3は、プロジェクトDB141のレコードレイアウトの一例を示す説明図である。プロジェクトDB141は、プロジェクトID列、プロジェクト名列、顧客列、プロジェクト属性列を含む。プロジェクトID列は、各プロジェクトを識別するための識別情報を記憶している。プロジェクト名列は、プロジェクトの名称を記憶している。顧客列は、各プロジェクトの取引先である顧客の情報(例えば法人名)を記憶している。プロジェクト属性列は、各プロジェクトの商材である商品名、各プロジェクトで取り扱う案件名など、プロジェクトの属性を表す情報を記憶している。
上記のように、プロジェクトDB141には、業務内の各プロジェクトの情報が記憶されている。例えばサーバ1は、管理者によるプロジェクトの事前登録を受け付け、プロジェクトDB141に記憶しておく。
【0020】
図4は、タスクDB142のレコードレイアウトの一例を示す説明図である。タスクDB142は、タスクID列、タスク名列、プロジェクト列、タスク内容列、進捗列、添付ファイル列、担当者列、関係者列、着手予定日列、着手日列、完了予定日列、完了日列、後続タスク列を含む。タスクID列は、各プロジェクトにおいて実施される個々のタスクを識別するための識別情報を記憶している。タスク名列は、タスクIDと対応付けて、タスクの名称を記憶している。プロジェクト列は、タスクIDと対応付けて、当該タスクに係るプロジェクトのIDを記憶している。タスク内容列は、タスクIDと対応付けて、各タスクの内容を記憶している。進捗列は、タスクIDと対応付けて、各タスクの進捗状況を記憶している。
【0021】
担当者列は、タスクIDと対応付けて、タスクの担当者を識別するための識別情報を記憶している。関係者列は、タスクIDと対応付けて、当該タスクに関係する関係者を識別するための識別情報を記憶している。関係者は、担当者にタスクを依頼した依頼者、その他の関係者である。タスクDB142には、各タスクの担当者だけでなく、各タスクの関係者も併せて登録されている。
【0022】
着手予定日列、着手日列、完了予定日列、完了日列はそれぞれ、タスクIDと対応付けて、タスクの着手予定日、着手日、完了予定日、完了日を記憶している。後続タスク列は、タスクIDと対応付けて、プロジェクトにおいて当該タスクに続く後続タスクのIDを記憶している。
【0023】
図5は、ユーザDB143のレコードレイアウトの一例を示す説明図である。ユーザDB143は、ユーザID列、ユーザ名列、所属列、アドレス列、スケジューラアカウント列を含む。ユーザID列は、各ユーザを識別するための識別情報を記憶している。ユーザ名列は、ユーザIDと対応付けて、各ユーザの名前を記憶している。所属列は、ユーザIDと対応付けて、各ユーザの所属先(例えば勤務先の部署名)を記憶している。アドレス列は、ユーザIDと対応付けて、ユーザが使用しているメールアドレスを記憶している。スケジューラアカウント列は、ユーザIDと対応付けて、各ユーザが使用しているスケジューラのアカウント情報を記憶している。
【0024】
図6は、タスク登録処理の概要に関する説明図である。以下では、タスク管理システムが実行する処理の概要について説明する。
サーバ1は、ユーザが送信又は受信したメッセージ情報からタスク情報を抽出し、データベースに登録する処理を行う。メッセージ情報は、例えば電子メールである。サーバ1は、メールサーバ3と同期し、ユーザのメールアドレス宛に送信されたメール、及びユーザのメールアドレスから送信されたメールを取得する。
【0025】
なお、サーバ1は、本システムの利用者が送受信したメールを取得可能であればよく、メールの相手方は本システムの利用者である必要はない。例えば本システムを社内のタスク管理ツールとして実装する場合、メールの送信元又は送信先は社外の人間であってよい。
【0026】
サーバ1は、取得したメールが、タスク依頼に係るメールであるか否かを判定する。例えばサーバ1は、メールのタイトル及び本文において、「依頼」、「お願いします」など、タスクの依頼時に用いられる所定のキーワードが記述されているか否かを判定する。
【0027】
タスク依頼に係るメールであると判定した場合、サーバ1は、当該メールからタスク情報を抽出する。具体的には、サーバ1はタスク名、タスクの内容、タスクの実施期限等の情報を抽出する。例えばサーバ1は、メールのタイトルをタスク名とし、メールの本文をタスク内容として抽出する。また、サーバ1は、メール本文から、タスクの実施期限のほか、タスクに係るプロジェクト名、顧客名等のように、タスクに関連する属性情報を抽出する。属性情報は、タスクの分類を表す情報であり、タスクIDと紐付けられる関連情報である。サーバ1は、電子メールに対する文字認識を行い、実施期限のほかに、タスクの属性情報を抽出する。サーバ1はさらに、当該メールの添付ファイルを抽出する。このように、サーバ1は電子メールから、タスクに関連する情報を可能な限り抽出していく。
【0028】
サーバ1は、抽出したタスク情報から、タスクの担当者及び関係者を識別する。担当者は、タスクを担当するユーザである。一方で、関係者は、例えばタスクを依頼した依頼者、タスクの結果物を共有するプロジェクトのメンバーなど、タスクに関係するユーザである。例えばサーバ1は、送信元(From)、送信先(To)、同時送信先(Cc、Bcc)等の電子メールのヘッダ情報から、タスクの担当者及び関係者を識別する。また、例えばサーバ1は、メール本文の文字認識を行い、メール本文に含まれる個人名から、担当者及び関係者を識別するようにしてもよい。このように、サーバ1は、電子メールのヘッダ情報又は本文から担当者及び関係者を識別する。
【0029】
サーバ1は、上記の識別結果に基づき、メールから抽出したタスク情報を、当該メールの送受信元であるユーザが担当者である第1タスク情報、又は当該ユーザが関係者である第2タスク情報に分類する。すなわちサーバ1は、メールに記載されているタスクが、ユーザ本人が実施すべきタスクであるか、又は他のユーザが実施すべきタスクであるかを判断する。
【0030】
サーバ1は、第1タスク情報、又は第2タスク情報として分類したタスク情報を、タスクDB142に登録する。例えばサーバ1は、当該タスクについて新規のタスクIDを発行し、タスクIDと対応付けて、タスク名、タスク内容、タスクの実施期限等の情報をタスクDB142に記憶する。また、サーバ1は、タスクIDと対応付けて、担当者のユーザID、及び関係者のユーザID、その他の属性情報をタスクDB142に記憶する。
【0031】
上記の処理により、サーバ1は、ユーザが担当する第1タスク情報と、他のユーザが担当する第2タスク情報とを別々に管理する。すなわち、
図6下に示すように、サーバ1は、ユーザから他人にアウトプットすべきタスクと、他人からユーザにインプットされるタスクとを別々に管理する。以上より、ユーザ本人のタスクと他人のタスクとが自動的に仕分けられ、タスク管理の利便性を高めることができる。
【0032】
図7及び
図8は、タスク管理画面の一例を示す説明図である。タスク管理画面は、タスクDB142に登録されているタスク情報を一覧で示す管理画面である。例えばサーバ1は、端末2からログイン処理を受け付けた場合、
図7等に示すタスク管理画面を生成して端末2に出力する。
図7に示すように、タスク管理画面には、画面左側に第1タスクフォルダ51、第2タスクフォルダ52、及び実績タブ53を含むメニューが表示される。
【0033】
例えば端末2は、第1タスクフォルダ51への操作入力を受け付けた場合、
図7に示す画面を表示する。
図7は、ユーザが担当する第1タスク情報の管理画面である。当該画面では、タスク名54、プロジェクト名55、及び実施期限56を含むタスク情報が一覧表示される。
【0034】
端末2は、タスク名54への操作入力を受け付けた場合、さらにタスクの詳細表示を行う。具体的には
図7に示すように、端末2は、タスク名54の下に、客先名、関係者名、タスクの内容(詳細)、添付ファイル等の表示を行う。これにより、ユーザはタスクの詳細を確認することができる。
【0035】
なお、タスク情報の抽出元であるメールの文面によっては、例えばタスクの実施期限、プロジェクト名等の必要事項が記述されていない可能性もあるため、サーバ1は、
図7に示すタスク管理画面で、各タスクの属性情報の設定入力を受け付ける。例えば端末2は、タスク名54、プロジェクト名55、実施期限56等の設定入力を受け付ける。サーバ1は、端末2を介して受け付けた属性情報をタスクDB142に記憶する。
【0036】
また、サーバ1は、端末2を介して、後続タスクの設定入力を受け付ける。後続タスクは、一連のプロジェクトにおいて、当該タスクに続いて実施すべきタスクである。例えばサーバ1は、同一プロジェクトについてタスクDB142に登録済みのタスクを管理画面の後続タスク欄57にプルダウン表示させ、ユーザによる選択を受け付ける。サーバ1は、後続タスク欄57で選択されたタスクを、タスク名54で示すタスクと対応付けてタスクDB142に登録する。
【0037】
また、サーバ1は、ユーザによる手動で一つひとつ後続タスクを設定するだけでなく、複数の後続タスクを一斉に登録可能としてもよい。具体的には、サーバ1は、複数のタスク情報を関連付けたプロジェクトのテンプレート情報を記憶しておき、テンプレート情報の指定を受け付けることで複数のタスク情報をタスクDB142に一斉登録する。
【0038】
例えばサーバ1は、「テンプレートを参照する」と表示されている参照オブジェクト572への操作入力を受け付けた場合、プロジェクトDB141を参照し、過去に実施済みのプロジェクトの情報を読み出して端末2に出力する。例えばサーバ1は、商品名、案件名などのプロジェクト属性が、プロジェクト名55で示されるプロジェクトと同じプロジェクトを検索し、検索されたプロジェクトを端末2に出力する。サーバ1は、端末2を介して、当該プロジェクトで実施されたタスクをテンプレートとして使用するか否かの指定入力を受け付ける。テンプレートとして使用する旨の指定入力を受け付けた場合、サーバ1は、後続タスクとして過去のプロジェクトのタスクを一斉登録する。
【0039】
なお、上記では過去に実施されたプロジェクトのタスク情報を流用することとしたが、管理者が事前にテンプレートを用意しておき、事前設定されたテンプレートを用いてもよいことは勿論である。
【0040】
上述の如く、サーバ1は、後続タスクの設定入力を受け付けることで、タスク同士の時系列的な紐付けを行い、複数のタスクを一連のプロジェクトとして管理する。これにより、ユーザは効率的にタスク情報を把握することができる。
【0041】
ユーザは、タスク管理画面に表示されている第1タスク情報を確認し、タスクを実施する。ユーザは、タスクの進捗状況に応じて、関係者に対する進捗報告を行う。例えば端末2は、タスク管理画面に報告ボタン58を表示しておく。報告ボタン58への操作入力を受け付けた場合、端末2は新規のメール(不図示)を作成する。ユーザは、新規のメールに、タスクが進行中であること、タスクが完了したことなどの進捗報告をテキスト入力する。なお、当該メールにタスクの結果物を添付ファイルとして添付してもよいことは勿論である。端末2は、関係者宛に進捗報告のメールを送信する。
【0042】
端末2から進捗報告に係るメールが送信された場合、サーバ1は、当該メールをメールサーバ3から取得する。サーバ1は、当該メールの文面に対して文字認識を行い、進捗報告の内容を抽出する。また、サーバ1は、添付ファイルを併せて抽出する。サーバ1は、抽出した進捗報告に係る情報を進捗履歴としてタスクDB142に記録する。
【0043】
上述の如く、サーバ1は、電子メールから進捗報告の内容を抽出し、進捗履歴を記録する。従って、サーバ1は、本システムの利用者ではない外部ユーザから送信されたメールについても、進捗報告の抽出、記録が可能である。例えば本システムを社内のタスク管理ツールとして実装する場合、サーバ1は、業務委託先など、社外の担当者からのメールを取得し、当該メールから進捗報告を抽出して記録してもよい。すなわちサーバ1は、本システムの利用者のメールアドレス宛に送信された電子メールから進捗報告を取得可能であればよく、進捗報告の発信元はシステムの内外を問わない。これにより、タスク管理の汎用性を高めることができる。
【0044】
図8は、ユーザに関係する第2タスク情報の管理画面である。第2タスクフォルダ52への操作入力を受け付けた場合、端末2は、
図8に示すタスク管理画面を表示する。当該画面では、
図7に示した第1タスク情報の管理画面と同じく、第2タスク情報が一覧で表示される。
【0045】
一方で、
図7の管理画面とは異なり、端末2は、各タスクの進捗状況を示すステータス59を併せて表示する。具体的には、画面右端に示すように、「完了」、「未着手」、「進行中」などのステータス59が表示される。サーバ1は、タスクDB142に記録された進捗履歴を参照して、ステータス59を管理画面上に出力する。ユーザ(関係者)はステータス59により、各タスクの進捗状況を確認することができる。
【0046】
端末2は、当該管理画面で第2タスク情報を一覧表示するだけでなく、タスクの完了を承認するか否かの選択入力を受け付ける。例えば
図8に示すように、端末2は、担当者から完了の報告があったタスクについてアイコン60を表示し、タスクが完了した旨をユーザ(関係者)に報知する。さらに端末2は、サーバ1と通信を行い、進捗報告の内容を示す報告画面61をポップアップ表示する。
【0047】
報告画面61は、担当者から送信された進捗報告のメール内容を示すポップアップ画面である。端末2は、報告画面61に、メール文面、添付ファイル等のほかに、承認ボタン62、質問ボタン63、及び差戻しボタン64を表示する。承認ボタン62への操作が行われた場合、当該タスクの完了が承認される。この場合、端末2はタスク完了が承認された旨をサーバ1に通知する。サーバ1は、タスクが完了した旨を進捗履歴としてタスクDB142に記録する。この場合、例えばサーバ1は後続タスクの担当者に対し、後続タスクに着手すべき旨を通知する。
【0048】
一方で、タスクの完了が承認されなかった場合、サーバ1は、承認が得られなかった旨を担当者に返信する。例えば報告画面61の質問ボタン63が操作された場合、端末2は、新規のメールを作成する。ユーザ(関係者)は、報告内容について疑問点をメールに入力し、担当者に返信して質問を行う。また、差戻しボタン64が操作された場合、サーバ1が、タスクの完了が承認されなかった旨の定型メールを自動生成して担当者に返信する。このように、端末2はタスク管理画面上でタスクの完了を承認するか否かの選択を受け付け、非承認である場合に担当者へ通知を行う。なお、サーバ1は、関係者による質問、差戻し等の進捗履歴をタスクDB142に記録しておく。
以上より、サーバ1は電子メールからタスク情報を抽出するだけでなく、進捗報告に係る電子メールの送信など、タスク管理に必要な処理を管理画面内で一括して行うことができる。これにより、ユーザの利便性を高めることができる。
【0049】
図9は、スケジュール調整処理に関する説明図である。本システムでは、タスク管理を行うだけでなく、ユーザのスケジュールの調整支援も行う。
具体的には、サーバ1は、ユーザが送受信した電子メールから、ユーザのスケジュールの調整依頼に係る情報を抽出する。スケジュールの調整依頼は、例えば打ち合わせなどのイベントへの参加をユーザに要求する参加依頼である。サーバ1は、
図9右上に示すように、メール文面から「打合せ」、「ご都合」等のキーワードの有無を判断し、スケジュール調整依頼に係るメールか否かを判定する。調整依頼に係るメールであると判定した場合、サーバ1は、メールに記載されている場所、日時(候補日)、イベント内容等の情報をメール文面から抽出する。
【0050】
サーバ1は、ユーザのスケジュールを管理するスケジュールサーバ4にアクセスし、ユーザが対応可能な日程候補を特定する。すなわちサーバ1は、スケジューラから日程候補を特定する。なお、当該スケジューラは外部(スケジュールサーバ4)で管理してもよいし、サーバ1で管理してもよい。すなわち、サーバ1がユーザのスケジュールを参照可能であればよい。サーバ1はさらに、相手方から提示されている日時、前後のユーザの滞在場所、移動手段等から、日程候補を絞り込む。サーバ1は、最終的に特定した日程候補を相手方に通知する定型メールを作成し、メールサーバ3に返信を依頼する。メールサーバ3は、当該メールを相手方に返信する。
【0051】
また、サーバ1は、上記で特定した日程候補におけるスケジュールを、スケジューラに仮登録をしておく。すなわちサーバ1は、スケジュールの仮押さえを行う。サーバ1は、イベントの場所、イベント内容、相手方の名称などを、日程候補の日時と対応付けてスケジュールサーバ4に記憶させる。
【0052】
例えばサーバ1は、仮登録したスケジュールについて、後に相手方から返信されるメール内容を基に、スケジュールの確定、修正、リマインド等を行う。例えば日程確定のメールをメールサーバ3から取得した場合、サーバ1は当該メールから確定した日時を抽出し、スケジュールサーバ4に転送する。スケジュールサーバ4は、当該日時におけるスケジュールの確定登録、他の日程候補日に仮登録しておいたスケジュールの削除等を行う。このように、サーバ1は電子メールからタスク情報を抽出するだけでなく、ユーザのスケジュールに係る情報を抽出することで、スケジュール管理の支援を併せて行う。
【0053】
図10は、タスク実績画面の一例を示す説明図である。サーバ1は、タスクDB142に記録されたタスクの進捗履歴から、各タスクの実施効率を表す実績情報を生成して端末2に出力する。
実績情報は、例えばタスクの工数、所要時間(いわゆるリードタイム)など、タスクの実績の評価指標となり得る情報である。例えばサーバ1は、タスクDB142を参照し、各プロジェクトにおけるタスク別の所要時間、担当者数などの情報を読み出す。サーバ1は、上記の情報を基に、プロジェクト全体の工数、リードタイムのほか、タスク別の工数などを計算する。
【0054】
例えば端末2は、実績タブ53への操作入力を受け付けた場合、
図10に示すタスク実績画面を表示する。当該画面は、プロジェクトの実績情報を表示する画面である。例えば端末2は、プロジェクトタブ65によりプロジェクトの指定入力を受け付ける。端末2は、プロジェクトタブ65で選択されたプロジェクトについて、実績情報の出力をサーバ1に要求する。サーバ1は、要求されたプロジェクトの実績情報を端末2に出力する。
【0055】
端末2は、サーバ1で計算されたタスクの実施効率をタスク実績画面に表示する。例えば端末2は、プロジェクト全体の工数、リードタイムを画面上部に表示する。また、端末2はタスク別の工数をガントチャート形式で表示する。これにより、ユーザはタスクの実績を確認することができ、業務の効率化を図ることができる。
【0056】
なお、上記ではタスクの工数及びリードタイムを一例に挙げたが、サーバ1はこれだけでなく、例えばタスクの差戻し回数、タスクが完了してから後続タスクが着手されるまでのレスポンス時間など、その他の評価指標を実績情報として計算してもよい。
【0057】
また、サーバ1は、過去に実施されたタスクの実績情報に基づき、未着手のタスクの工数予測、リードタイムの予測等を行ってもよい。これにより、ユーザの業務をより積極的に支援することができる。
【0058】
図11は、タスク登録処理の処理手順の一例を示すフローチャートである。
図11に基づき、サーバ1が実行するタスク登録処理の処理内容について説明する。
例えばサーバ1の制御部11は、バッジ処理により以下の処理を行う。制御部11は、ユーザのメッセージ情報を取得する(ステップS11)。具体的には、サーバ1はメールサーバ3にアクセスし、ユーザから送信された、又はユーザ宛に送信された電子メールを取得する。制御部11は、取得したメッセージ情報が、新規のタスク依頼に係るメッセージ情報であるか否かを判定する(ステップS12)。例えば制御部11は、メールのタイトル及び本文の文字認識を行い、タスクの依頼時に用いられる所定のキーワードが含まれるか否かを判定する。
【0059】
タスク依頼に係るメッセージ情報であると判定した場合(S12:YES)、制御部11は、メッセージ情報からタスク情報を抽出する(ステップS13)。例えば制御部11は、メールのタイトルをタスク名、メール本文をタスク内容として、タスク情報を抽出する。また、制御部11は、メール本文に対する文字認識を行い、タスクの実施期限のほか、例えばプロジェクト名、顧客名等の属性情報を抽出する。
【0060】
制御部11は、抽出したタスク情報から、タスクの担当者及び関係者を識別する(ステップS14)。担当者は、タスクの実施を担当するユーザである。関係者は、タスクを担当者に依頼した依頼者、その他のユーザである。例えば制御部11は、メールの送信元、送信先等のヘッダ情報から、又はメール本文に含まれる個人名から、タスクの担当者及び関係者を識別する。
【0061】
制御部11は、ステップS14の識別結果に基づき、ステップS13で抽出したタスク情報を、ユーザが担当者である第1タスク情報、又はユーザが関係者である第2タスク情報に分類する(ステップS15)。すなわちサーバ1は、ユーザのメールから抽出したタスクを、ユーザが担当するタスクと、他のユーザが担当するタスクとに分類する。制御部11は、分類した第1又は第2タスク情報をタスクDB142に登録する(ステップS16)。例えば制御部11は、タスクIDと対応付けて、タスク名、タスク内容、実施期限のほか、担当者のユーザID、関係者のユーザID、その他の属性情報をタスクDB142に記憶する。制御部11は、一連の処理を終了する。
【0062】
新規のタスク依頼に係るメッセージ情報でないと判定した場合(S12:NO)、制御部11は、メッセージ情報が既存タスクの進捗報告であるか否かを判定する(ステップS17)。進捗報告であると判定した場合(S17:YES)、制御部11は、メッセージ情報から進捗報告の内容を抽出する(ステップS18)。制御部11は、抽出した進捗報告の内容を、進捗履歴としてタスクDB142に記録し(ステップS19)、一連の処理を終了する。
【0063】
進捗報告でないと判定した場合(S17:NO)、制御部11は、メッセージ情報が、ユーザのスケジュールの調整依頼に係るメッセージであるか否かを判定する(ステップS20)。スケジュールの調整依頼でないと判定した場合(S20:NO)、制御部11は一連の処理を終了する。スケジュールの調整依頼であると判定した場合(S20:YES)、制御部11は、メッセージ情報から、スケジュールの調整依頼に係る情報を抽出する(ステップS21)。例えば制御部11は、メールに記述されているイベントの場所、日時、イベント内容等の情報を抽出する。
【0064】
制御部11は、スケジュールサーバ4で管理されているスケジューラを参照し、ユーザが対応可能な日程候補を特定する(ステップS22)。制御部11は、特定した日程候補を相手方に通知する返信メッセージを生成し、メールサーバ3を介して返信する(ステップS23)。さらに制御部11は、スケジュールサーバ4で管理されているスケジューラに対し、ステップS22で特定された日程候補におけるスケジュールを仮登録する(ステップS24)。制御部11は、一連の処理を終了する。
【0065】
図12は、タスク出力処理の処理手順の一例を示すフローチャートである。
図12に基づき、サーバ1が実行するタスク出力処理の処理内容について説明する。
例えばサーバ1の制御部11は、端末2からのログイン処理を受け付けた場合、以下の処理を実行する。制御部11は、端末2からの出力要求に基づき、ログインしたユーザが担当者である第1タスク情報を出力するか否かを判定する(ステップS41)。第1タスク情報を出力すると判定した場合(S41:YES)、制御部11はタスクDB142を参照して、当該ユーザが担当者である第1タスク情報を一覧で示すタスク管理画面を端末2に出力する(ステップS42)。制御部11は、当該タスク管理画面において、既存タスクの属性情報の設定入力、後続タスクの設定入力、及び進捗報告の入力等を受け付ける(ステップS43)。制御部11は、入力内容をタスクDB142に記憶する。
【0066】
制御部11は、ステップS43で進捗報告を受け付けたか否かを判定する(ステップS44)。進捗報告を受け付けていないと判定した場合(S44:NO)、制御部11は処理をステップS56に移行する。進捗報告を受け付けたと判定した場合(S44:YES)、制御部11は、進捗報告に係るメッセージ情報を生成し、関係者宛に出力する(ステップS45)。制御部11は、処理をステップS56に移行する。
【0067】
第1タスク情報を出力しないと判定した場合(S41:NO)、制御部11は、ユーザが関係者である第2タスク情報を出力するか否かを判定する(ステップS46)。第2タスク情報を出力すると判定した場合(S46:YES)、制御部11は、当該ユーザが関係者である第2タスク情報を一覧で示すタスク管理画面を端末2に出力する(ステップS47)。
【0068】
制御部11は、タスクDB142を参照し、担当者から進捗報告がなされた第2タスク情報があるか否かを判定する(ステップS48)。進捗報告がなされた第2タスク情報がないと判定した場合(S48:NO)、制御部11は処理をステップS56に移行する。進捗報告がなされた第2タスク情報があると判定した場合(S48:YES)、制御部11は、担当者から送信された進捗報告に係るメッセージ情報を端末2に出力する(ステップS49)。例えば制御部11は、進捗報告の内容を示す報告画面61を生成し、端末2に出力する。報告画面61は、担当者から送信された進捗報告のメール内容を示すポップアップ画面であり、ユーザ(関係者)がタスクの完了を承認するか否かを選択するための承認ボタン62、差戻しボタン64等を含む。
【0069】
制御部11は、ステップS49で出力した進捗報告に対して、タスクの完了を承認する選択入力を受け付けたか否かを判定する(ステップS50)。承認されたと判定した場合(S50:YES)、制御部11は、当該タスクが完了した旨の進捗履歴をタスクDB142に記録する(ステップS51)。制御部11は、処理をステップS56に移行する。
【0070】
タスクの完了が承認されなかったと判定した場合(S50:NO)、制御部11は、タスクの担当者に対する通知を行う(ステップS52)。当該通知の内容は、例えばタスクの差戻し、報告内容に関する質問などである。サーバ1は、関係者により入力された入力内容に応じて、担当者に対する通知を行う。また、この場合にサーバ1は、タスクの差戻し、質問などの通知内容を進捗履歴としてタスクDB142に記録しておく。制御部11は、処理をステップS56に移行する。
【0071】
第2タスク情報を出力しないと判定した場合(S46:NO)、制御部11は、タスクの実績情報を出力するか否かを判定する(ステップS53)。実績情報は、タスクの実施効率を表す情報であり、例えばタスクの工数、リードタイム等の情報である。実績情報を出力しないと判定した場合(S53:NO)、制御部11は処理をステップS56に移行する。実績情報を出力すると判定した場合(S53:YES)、制御部11は、タスクDB142に記憶されている各タスクの進捗履歴を参照し、タスクの工数、所要時間(リードタイム)等の実施効率を計算する(ステップS54)。制御部11は、計算した工数、リードタイム等の実施効率を表示するタスク実績画面を生成し、端末2に出力する(ステップS55)。制御部11は、処理をステップS56に移行する。
【0072】
制御部11は、端末2からログアウトの要求を受け付けたか否かを判定する(ステップS56)。ログアウトしないと判定した場合(S56:NO)、制御部11は処理をステップS41に戻す。ログアウトすると判定した場合(S56:YES)、制御部11は一連の処理を終了する。
【0073】
なお、上記でサーバ1は、ユーザのメールアドレスにおいて送受信された電子メールからタスク情報を抽出したが、本実施の形態はこれに限定されるものではない。例えばサーバ1は、ユーザが属するチャットグループ内のメッセージを読み取り、タスク情報を抽出するようにしてもよい。このように、サーバ1はユーザが送受信するメッセージ情報からタスク情報を抽出可能であればよく、タスク情報の抽出元は電子メールに限定されない。
【0074】
また、ユーザのメールアドレス宛に送信された電子メールにタスク情報が記述されておらず、スケジュールに関する情報も記述されていない場合、当該メールは、例えば単なる確認、御礼など、形式的な内容である可能性が高い。そこで、例えばサーバ1は、電子メールからタスク及びスケジュールに関する記述が認識されない場合(ステップS20:NO)、定型メッセージを自動返信するようにしてもよい。これにより、ユーザの利便性を高めることができる。
【0075】
また、例えばサーバ1は、担当者に対するリマインド、催促等を行ってもよいことは勿論である。
【0076】
以上より、本実施の形態1によれば、ユーザに関連するタスクを適切に分類して管理することができる。
【0077】
また、本実施の形態1によれば、進捗報告の送受信を仲介することで、効率的なタスク管理を支援することができる。
【0078】
また、本実施の形態1によれば、タスクの工数、リードタイム等、タスク実績の管理を行うことができる。
【0079】
また、本実施の形態1によれば、複数のタスクを関連付けたプロジェクトのテンプレート情報を用いることで、漏れのないタスク管理を行うことができる。
【0080】
また、本実施の形態1によれば、タスク管理の支援だけでなく、スケジュール管理の支援も行うことができる。
【0081】
(実施の形態2)
本実施の形態では、サーバ1が管理しているタスク情報を基に、ユーザが会議で使用する文書を作成する形態について述べる。なお、実施の形態1と重複する内容については同一の符号を付して説明を省略する。
図13は、文書生成処理に関する説明図である。本実施の形態においてサーバ1は、ユーザが会議で使用するアジェンダ、及び会議内容を記録した議事録を作成する。
【0082】
具体的には、サーバ1は端末2より、タスクDB142に登録されている複数のタスクのうち、会議の議題に関連するタスクの選択を受け付ける。例えば
図13右上に示すように、サーバ1は、プロジェクトのタスクを端末2に一覧表示し、一又は複数のタスクの選択をチェックボックス形式で受け付ける。
【0083】
例えばサーバ1は、ユーザにより指定された属性を有するタスクをタスクDB142から検索し、端末2に一覧表示する。上述の如く、タスクの属性は、例えば担当者名、関係者名、プロジェクト名、顧客名、プロジェクトの属性(例えばプロジェクトで取り扱う商品等)などのように、タスクの分類を表す情報であり、タスクIDに紐付く関連情報である。実施の形態1で述べたように、サーバ1は、電子メールの内容を認識することで、又はタスク管理画面を介して設定入力を受け付けることで、上記の各種情報をタスクの属性情報としてタスクDB142に記憶しておく。
【0084】
例えばサーバ1は、端末2を介して属性情報の指定を受け付け、指定された属性のタスクを検索して端末2に一覧表示する。例えば「プロジェクトA」というプロジェクト名の指定を受け付けた場合、サーバ1は、「プロジェクトA」の属性を有するタスク群をタスクDB142から検索する。そしてサーバ1は、
図13に示すように、検索したタスク群を端末2に一覧表示する。
【0085】
サーバ1は、端末2に一覧表示した複数のタスクから、会議の議題に用いるタスクの選択を受け付ける。サーバ1は、選択されたタスクに係るタスク情報を基に、会議の議題項目と、各項目に対応する入力欄とを含む文書ファイルを生成する。例えばサーバ1は、各タスクのタスク名を項目名とし、各項目に対応するテキスト入力欄を挿入した文書ファイルを生成する。これによりサーバ1は、会議のアジェンダに相当する文書を作成する。
【0086】
サーバ1は、生成した文書ファイルを端末2に出力する。会議時にユーザは、端末2を操作して、各入力欄へのテキスト入力を行う。具体的には、ユーザは会議内の発言、決定事項、新たに挙がった課題など、議事内容を入力していく。
【0087】
会議後、サーバ1は端末2からの操作に応じて、議事内容が入力された文書ファイルを議事録として保存する。例えばサーバ1は、当該文書ファイルをタスクに関連する添付ファイルとしてタスクDB142に記憶する。
【0088】
また、サーバ1は、当該文書ファイルへの入力内容に応じて、タスクDB142を更新する。例えばサーバ1は、各議題項目の入力欄に入力されたテキストデータを参照し、対応するタスクの完了が承認されたか否かを判別する。サーバ1は、判別結果に応じてタスクの進捗履歴を更新し、タスクの完了を記録する。また、例えばサーバ1は、文書ファイルに入力された新たな課題を、新規のタスク情報としてタスクDB142に登録する。
上述の如く、サーバ1はタスク情報を基にアジェンダ及び議事録を作成し、議事内容を基にタスクDB142を更新していく。これにより、サーバ1は単にタスク情報を管理するだけでなく、タスク情報に基づく業務支援を行うことができる。
【0089】
図14は、文書生成処理の処理手順の一例を示すフローチャートである。
図14に基づき、サーバ1が実行する文書生成処理の処理内容について説明する。
サーバ1の制御部11は、端末2を介して、タスクの属性情報の指定を受け付ける(ステップS201)。属性情報は、メッセージ情報から抽出された、又はユーザにより設定入力された情報であり、タスクの分類を表す情報である。タスクDB142には、タスクIDと対応付けて、タスクの属性情報が記憶されている。制御部11は、指定された属性情報に基づき、複数のタスク情報をタスクDB142から検索する(ステップS202)。
【0090】
制御部11は、検索した複数のタスク情報を端末2に出力する(ステップS203)。そして制御部11は、出力した複数のタスク情報のうち、一又は複数のタスク情報を選択する選択入力を受け付ける(ステップS204)。制御部11は、選択されたタスク情報に基づき、議題項目と、議題項目に対応する入力欄とを含む文書ファイルを生成し、端末2に出力する(ステップS205)。上述の如く、当該文書ファイルはアジェンダに相当する文書である。例えば制御部11は、タスク名を議題項目とし、各項目に対応するテキスト入力欄を文書ファイルに挿入してアジェンダを生成する。
【0091】
制御部11は、生成した文書ファイルへの情報入力を受け付ける(ステップS206)。例えば制御部11は、端末2を介して、文書ファイルへのテキスト入力を受け付ける。制御部11は、ユーザによりテキスト等が入力された文書ファイルを、議事録として保存する(ステップS207)。
【0092】
制御部11は、文書ファイルへの入力内容に応じて、タスクDB142を更新する(ステップS208)。例えば制御部11は、文書ファイルに入力されたテキストデータから、既存タスクの進捗履歴の更新、新規タスクの登録等を行う。制御部11は、一連の処理を終了する。
【0093】
なお、上記では属性情報に基づくタスクの検索機能をアジェンダ作成時に利用する場合について説明したが、検索機能の利用はアジェンダ作成時に限定されるものではなく、例えばプロジェクトの現状確認時など、その他の利用場面で検索可能としてもよいことは勿論である。すなわちサーバ1は、タスク属性を検索キーとして複数のタスク情報を一斉出力することができればよい。
【0094】
以上より、本実施の形態2によれば、タスク情報を基にした文書作成を行うことで、さらなる業務の効率化を支援することができる。
【0095】
(実施の形態3)
本実施の形態では、担当者が認識するタスクの難易度と、関係者が認識するタスクの難易度との差異を解消し、タスクの難易度の代表値を決定する形態について述べる。
図15は、タスクの難易度決定処理に関する説明図である。
図15では、本実施の形態においてサーバ1が実行する処理内容について、概念的な説明図を図示している。
【0096】
関係者から担当者へタスクが依頼された場合、当該タスクの難易度について、関係者と担当者との間で認識の差異が生じる場合がある。例えば
図15に示すように、タスクを依頼する関係者から見れば難易度が低いが、実際にタスクを行う担当者から見れば難易度が高い場合がある。そこで本実施の形態では、関係者及び担当者の双方から難易度の設定入力を受け付け、設定された難易度の設定値を統計的に処理し、一般的な難易度に変換してユーザに提示する。
【0097】
例えばサーバ1は、
図7、
図8等で図示したタスク管理画面において、1〜5の五段階の数値でタスクの難易度の設定入力を受け付ける。サーバ1は、入力されたタスクの難易度をタスクDB142に記憶する。サーバ1は、各タスクについて担当者及び関係者の双方から難易度の設定入力を受け付け、タスクDB142に記憶していく。
【0098】
サーバ1は、内容が同じタスク(例えばタスク名が類似するタスク)について、担当者及び関係者夫々の難易度の設定値をタスクDB142から読み出す。サーバ1は、読み出した担当者及び関係者夫々の難易度の設定値について、統計処理を行う。例えばサーバ1は、担当者たちが設定した難易度の分布、及び関係者たちが設定した難易度の分布がそれぞれ正規分布に従うと仮定し、全体として2つの正規分布が重ね合わされた二峰分布に従うと仮定して統計処理を行う。サーバ1は、担当者側の難易度の設定値、及び関係者側の難易度の設定値夫々について平均値、分散等を計算し、正規分布に係る近似曲線を導出する。
【0099】
サーバ1は、統計処理による分析結果から、当該タスクの難易度の代表値を決定する。例えばサーバ1は、各正規分布の交点に位置する難易度を、当該タスクの難易度の代表値に決定する。すなわちサーバ1は、
図15に示す分布図において、二峰分布の谷に相当する位置を代表値に決定する。例えばサーバ1は、
図10で例示したタスク実績画面において、決定した難易度の代表値をタスクの一般的難易度としてユーザに提示する。ユーザは、提示された難易度を参考に、タスクの工数予測などを行うことができる。
【0100】
なお、上記の難易度の代表値の決定方法は一例であって、本実施の形態はこれに限定されるものではない。例えばサーバ1は、担当者及び関係者が設定した難易度の中央値、平均値などを代表値としてもよい。
【0101】
図16は、実施の形態3に係るタスク出力処理の処理手順の一例を示すフローチャートである。
図16に基づき、本実施の形態に係るサーバ1の処理内容について説明する。
第1タスク情報を端末2に出力した後(ステップS42)、サーバ1の制御部11は、タスクの担当者による、第1タスク情報の難易度の設定入力を受け付け、タスクDB142に記憶する(ステップS301)。例えば制御部11は、五段階評価で各タスクの難易度の設定入力を受け付ける。制御部11は、担当者が設定した難易度の設定値をタスクDB142に記憶しておく。制御部11は、処理をステップS43に移行する。
【0102】
第2タスク情報を端末2に出力した後(ステップS47)、制御部11は、タスクの関係者による、第2タスク情報の難易度の設定入力を受け付け、タスクDB142に記憶する(ステップS302)。例えば制御部11は、ステップS301と同じく、五段階評価で各タスクの難易度の設定入力を受け付ける。制御部11は、関係者が設定した難易度の設定値をタスクDB142に記憶しておく。制御部11は、処理をステップS48に移行する。
【0103】
ステップS54の処理を実行後、制御部11は、タスクDB142を参照し、担当者及び関係者の双方が設定した難易度の設定値から、タスクの難易度の代表値を決定する(ステップS303)。例えば制御部11は、担当者の設定値、及び関係者の設定値の双方が正規分布に従うと仮定し、全体として二峰分布に従うと仮定して統計処理を行い、難易度の代表値を決定する。制御部11は、決定した難易度の代表値を含むタスク実績画面を生成し、端末2に出力する(ステップS304)。制御部11は、処理をステップS56に移行する。
【0104】
以上より、本実施の形態3によれば、タスクの難易度の代表値を定めることで、担当者と関係者との間の認識の差異の解消、タスクの工数予測等に役立てることができる。
【0105】
今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。