(57)【特許請求の範囲】
【請求項１】
利用者を識別する利用者識別情報と当該利用者のメールアドレスとを含む利用者情報を記憶する利用者情報記憶手段と、
タスクの依頼先である被依頼者に成り得る被依頼者候補の利用者識別情報と当該被依頼者が依頼されることとなるタスクに関する情報とをそれぞれ含む複数のレコードからなる一覧表データを記憶する一覧表記憶手段と、
前記利用者情報記憶手段に記憶されている利用者情報に含まれる利用者識別情報で識別された利用者によって入力された一覧表データを受け付け、当該一覧表データを前記一覧表記憶手段に登録する一覧表登録手段と、
前記利用者情報記憶手段に記憶されている利用者情報に含まれる利用者識別情報で識別された利用者である依頼者によって前記一覧表記憶手段に記憶されている複数の一覧表データの中からタスクの対象として選択された一覧表データである対象一覧表データを、前記被依頼者が依頼されることとなるタスクの対象として決定する一覧表決定手段と、
前記対象一覧表データのレコード毎に当該各レコードを更新する被依頼者を、前記一覧表決定手段によってタスクの対象として決定された前記対象一覧表データに含まれる利用者識別情報によって示される被依頼者候補の中から前記依頼者に選択させることができ、選択された当該被依頼者が前記利用者情報記憶手段に記憶されている利用者情報に含まれる利用者識別情報で識別される利用者である場合に、選択された当該被依頼者を前記対象一覧表データの各レコードについてのタスク依頼先として決定する被依頼者決定手段と、
前記利用者情報記憶手段に記憶されている利用者情報から前記被依頼者決定手段によってタスクの依頼先として決定された被依頼者のメールアドレスを取得し、取得した当該メールアドレスを宛先として前記依頼者によるタスクの依頼が記載された電子メールを送信するタスク依頼手段と、
前記タスク依頼手段によって送信された電子メールを受信した被依頼者に、前記対象一覧表データの中から、前記被依頼者決定手段によって各前記被依頼者が依頼先として決定されたレコードのみを提示し、提示された当該レコードのみを各前記被依頼者が前記電子メールに記載されたタスクの依頼に従って更新することを可能とするタスク実現手段と、
を備えることを特徴とする一覧表管理システム。
【請求項２】
前記一覧表データが、スプレッドシートとして作成されていることを特徴とする請求項１に記載の一覧表管理システム。
【請求項３】
前記一覧表登録手段によって登録された一覧表データを入力した利用者に、前記対象一覧表データについてのタスクの進捗を提示する進捗管理者提示手段と、
前記被依頼者に、前記対象一覧表データについてのタスクの進捗を提示する進捗被依頼者提示手段と、
前記依頼者に、前記対象一覧表データについてのタスクの進捗を提示する進捗依頼者提示手段と、
を含む進捗管理手段を備えることを特徴とする請求項１または２に記載の一覧表管理システム。
【請求項４】
前記進捗管理手段が、前記依頼者によって設定されたタイミングで、前記タスクが未完了の被依頼者に催促の電子メールを送信する催促手段を含むことを特徴とする請求項３に記載の一覧表管理システム。
【請求項５】
前記利用者識別情報が、利用者名と部署名とを含み、
部署名変更および／または人事異動を示すデータに基づいて、前記一覧表記憶手段に記憶されている一覧表データに含まれる利用者識別情報の部署名および／または利用者名を更新し、前記利用者情報記憶手段に記憶されている利用者情報から前記一覧表登録手段によって登録された一覧表データを入力した利用者のメールアドレスを取得し、取得した当該メールアドレスを宛先として、前記更新された部署名および／または利用者名を確認するタスクの依頼が記載された電子メールを送信する部署名・利用者名更新手段を備え、
前記被依頼者決定手段において、前記部署名・利用者名更新手段によって送信された電子メールを受け取った前記依頼者によって前記被依頼者が選択され、
前記タスク実現手段によって実行可能とされるタスクは、前記被依頼者決定手段によって決定された被依頼者が前記対象一覧表データに含まれる利用者識別情報の部署名および／または利用者名を確認および／または更新することである、
ことを特徴とする請求項１ないし４のいずれか１項に記載の一覧表管理システム。
【請求項６】
前記タスク実現手段によって実行可能とされるタスクは、前記被依頼者決定手段によって決定された被依頼者が、当該タスクの対象である前記対象一覧表データに関連する文書ファイルを取得すること、および／または当該対象一覧表データに関連する文書ファイルを提出することであることを特徴とする請求項１ないし５のいずれか１項に記載の一覧表管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、組織において一覧表を管理する一覧表管理システムに関する。
【背景技術】
【０００２】
企業等の組織において、Ｅｘｃｅｌ（登録商標）のようなスプレッドシート等で作成された一覧表を従業員間で分担して維持管理する業務がある。この業務は、主として人手で行われている。例えば、このような一覧表のマスタを管理する管理者が担当者に一覧表の格納されたファイルを電子メールに添付して送信したり、ファイルサーバにファイルを置いて場所（パス名）を電子メールで知らせたりすることにより更新を依頼するといった方法がとられる。
【０００３】
メールソフトによっては、タスクを依頼する電子メールを送信した場合に、そのタスクが完了したという電子メールが返信されているか否かを一覧で表示できるものもある。例えば、Ｍｉｃｒｏｓｏｆｔ  Ｏｕｔｌｏｏｋ（登録商標）はタスクの依頼を作成および管理する機能を有する（例えば、非特許文献１参照。）。
特許文献１と特許文献２は、電子メールから自動的にタスクの依頼と回答を抽出する技術を開示する。
【０００４】
また、データベースでは、データベース管理者がテーブル（表）のレコードごとに利用者のアクセス権を設定することが可能である。従って、一覧表がデータベースのテーブルに格納されている場合、テーブルのレコードごとに利用者のアクセス権を設定することによって、各利用者が担当するレコードだけを更新可能にすることができる。
特許文献３は、更新を確実に行うために、ファイル管理システムにおいて、ファイルごとに見直し時期を設定し、見直しが必要な場合は管理者（全ファイル共通）に連絡する技術を開示する。
【０００５】
また、一覧表には、担当部署と担当者名が含まれる場合が多い。一覧表がデータベースのテーブルの場合には、システムごとにバッチプログラムを実行して、人事異動時にデータベース中の部署名と担当者名を更新することが行われる。
【０００６】
また、企業では、各人のタスクの管理にグループウェアが使われることが多い。グループウェアでは、従業員間でのタスクの依頼に関して、個人ごとに依頼されたタスクを設定し、また、タスクの完了状況を入力したり、表示したりすることが可能である。グループウェアによっては、従業員間でタスクを依頼する場合に、依頼するタスクを入力し、管理できるものもある。そのようなグループウェアでは、各人が、他の従業員に依頼したタスクとその完了状況、および自分に依頼されたタスクとその完了状況を一覧で確認することができる。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００６−１９０１７７号公報
【特許文献２】特開２００２−７４３７号公報
【特許文献３】特開２００７−２１３１７１号公報
【非特許文献】
【０００８】
【非特許文献１】“仕事の依頼を作成および管理する”、[online]、[平成２６年７月３日検索]、インターネット<URL:http://office.microsoft.com/ja-jp/outlook-help/HA001229368.aspx>
【発明の概要】
【発明が解決しようとする課題】
【０００９】
企業は多数の一覧表を保有するが、それらの維持管理には様々な困難がある。
例えば、一覧表がスプレッドシートで作成されている場合、一覧表の部署名や担当者名等を一括して更新することはできない。人事異動時には人事異動データを基にスプレッドシートの文字列置換機能を用いて一覧表を手作業で更新しなければならない。このため、一覧表中の部署名等を人事異動時に変更するには時間とコストがかかる。
【００１０】
また、企業において、各部署の担当者一覧表の更新では、多人数に同時に指示・依頼をする場合がある。そのような場合、依頼のメールが一通なのに対して、更新完了の返信メールは依頼先数分あり、依頼のうち、いくつが完了していないのか、誰が完了していないのかといったタスクの完了状況を把握することは難しい。
依頼メールに対する返信メールの一覧を表示できるメールソフトウェアを使う場合であっても、多種の依頼の返信メールが混じって表示されるので、各依頼の完了状況を把握することや、どの件が完了しているかを把握することは難しい。
また、取りまとめ者は、別途、スプレッドシート等を使って進捗管理表を作成し、返信メールに基づいて依頼先ごとのタスクの完了状況をその進捗管理表に手作業で入力して管理せざるを得ない。
また、企業で業務改善のために、一覧表更新に掛かった日数などを分析しようとした場合、メールではデータを手作業で入力しなくてはならず、多くの作業量を要する。
【００１１】
更に、一覧表に書かれている担当者が退職した場合にその一覧表の管理者が気づかず、担当者が更新されないままになる場合がある。
【００１２】
本発明の目的は、組織において一覧表を効率的に管理することができる一覧表管理システムを提供することである。
【課題を解決するための手段】
【００１３】
上記目的を達成するために、本発明の一覧表管理システムは、
利用者を識別する利用者識別情報と当該利用者のメールアドレスとを含む利用者情報を記憶する利用者情報記憶手段と、
タスクの依頼先である被依頼者に成り得る被依頼者候補の利用者識別情報と当該被依頼者が依頼されることとなるタスクに関する情報とをそれぞれ含む複数のレコードからなる一覧表データを記憶する一覧表記憶手段と、
前記利用者情報記憶手段に記憶されている利用者情報に含まれる利用者識別情報で識別された利用者によって入力された一覧表データを受け付け、当該一覧表データを前記一覧表記憶手段に登録する一覧表登録手段と、
前記利用者情報記憶手段に記憶されている利用者情報に含まれる利用者識別情報で識別された利用者である依頼者によって前記一覧表記憶手段に記憶されている複数の一覧表データの中からタスクの対象として選択された一覧表データである対象一覧表データを、前記被依頼者が依頼されることとなるタスクの対象として決定する一覧表決定手段と、
前記対象一覧表データのレコード毎に当該各レコードを更新する被依頼者を、前記一覧表決定手段によってタスクの対象として決定された前記対象一覧表データに含まれる利用者識別情報によって示される被依頼者候補の中から前記依頼者に選択させることができ、選択された当該被依頼者が前記利用者情報記憶手段に記憶されている利用者情報に含まれる利用者識別情報で識別される利用者である場合に、選択された当該被依頼者を前記対象一覧表データの各レコードについての依頼先として決定する被依頼者決定手段と、
前記利用者情報記憶手段に記憶されている利用者情報から前記被依頼者決定手段によってタスクの依頼先として決定された被依頼者のメールアドレスを取得し、取得した当該メールアドレスを宛先として前記依頼者によるタスクの依頼が記載された電子メールを送信するタスク依頼手段と、
前記タスク依頼手段によって送信された電子メールを受信した被依頼者に、前記対象一覧表データの中から、前記被依頼者決定手段によって各前記被依頼者が依頼先として決定されたレコードのみを提示し、提示された当該レコードのみを各前記被依頼者が前記電子メールに記載されたタスクの依頼に従って更新することを可能とするタスク実現手段と、
を備えることを特徴とする。
【００１４】
好ましくは、本発明の一覧表管理システムは、
前記一覧表データが、スプレッドシートとして作成されていることを特徴とする。
【００１６】
好ましくは、本発明の一覧表管理システムは、
前記一覧表登録手段によって登録された一覧表データを入力した利用者に、前記対象一覧表データについてのタスクの進捗を提示する進捗管理者提示手段と、
前記被依頼者に、前記対象一覧表データについてのタスクの進捗を提示する進捗被依頼者提示手段と、
前記依頼者に、前記対象一覧表データについてのタスクの進捗を提示する進捗依頼者提示手段と、
を含む進捗管理手段を備えることを特徴とする。
【００１７】
好ましくは、本発明の一覧表管理システムは、
前記進捗管理手段が、前記依頼者によって設定されたタイミングで、前記タスクが未完了の被依頼者に催促の電子メールを送信する催促手段を含むことを特徴とする。
【００１８】
好ましくは、本発明の一覧表管理システムは、
前記利用者識別情報が、利用者名と部署名とを含み、
部署名変更および／または人事異動を示すデータに基づいて、前記一覧表記憶手段に記憶されている一覧表データに含まれる利用者識別情報の部署名および／または利用者名を更新し、前記利用者情報記憶手段に記憶されている利用者情報から前記一覧表登録手段によって登録された一覧表データを入力した利用者のメールアドレスを取得し、取得した当該メールアドレスを宛先として、前記更新された部署名および／または利用者名を確認するタスクの依頼が記載された電子メールを送信する部署名・利用者名更新手段を備え、
前記被依頼者決定手段において、前記部署名・利用者名更新手段によって送信された電子メールを受け取った前記依頼者によって前記被依頼者が選択され、
前記タスク実現手段によって実行可能とされるタスクは、前記被依頼者決定手段によって決定された被依頼者が前記対象一覧表データに含まれる利用者識別情報の部署名および／または利用者名を確認および／または更新することである、
ことを特徴とする。
【００１９】
好ましくは、本発明の一覧表管理システムは、
前記タスク実現手段によって実行可能とされるタスクは、前記被依頼者決定手段によって決定された被依頼者が、当該タスクの対象である前記対象一覧表データに関連する文書ファイルを取得すること、および／または当該対象一覧表データに関連する文書ファイルを提出することであることを特徴とする。
【発明の効果】
【００２０】
本発明によれば、組織において一覧表を効率的に管理することができる。
【図面の簡単な説明】
【００２１】
【図１】一覧表管理サーバ利用システムの構成の一例を示す図である。
【図２】利用者テーブルの構成の一例を示す図である。
【図３】一覧表の例を示す図である。図３（Ａ）は製品一覧の例を示す図である。図３（Ｂ）は○○会議参加者一覧の例を示す図である。
【図４】一覧表テーブルの一例を示す図である。
【図５】タスクテーブルの一例を示す図である。
【図６】レコード毎タスクテーブルの一例を示す図である。
【図７】部署名変更テーブルの一例を示す図である。
【図８】異動テーブルの一例を示す図である。
【図９】一覧表を一覧表ストレージに登録する一覧表登録処理の流れの一例を示す図である。
【図１０】利用者画面の一例を示す図である。
【図１１】利用者画面の中の一覧表一覧の一例を示す図である。
【図１２】一覧表についてのタスクを依頼するタスク依頼処理の流れの一例を示す図である。
【図１３】部署名・担当者指定画面の一例を示す図である。
【図１４】依頼画面の一例を示す図である。
【図１５】利用者画面の中の依頼されているタスク一覧の一例を示す図である。
【図１６】利用者画面の中の自分がレコードの担当者になっている一覧表一覧の一例を示す図である。
【図１７】タスク実行画面の一例を示す図である。
【図１８】利用者画面の中の依頼しているタスク一覧の一例を示す図である。
【図１９】被依頼者毎進捗表示画面の一例を示す図である。
【図２０】レコード毎進捗表示画面の一例を示す図である。
【図２１】部署名変更テーブルおよび／または異動テーブルが更新されたときの部署名変更・異動処理の流れの一例を示す図である。
【発明を実施するための形態】
【００２２】
以下、本発明の実施形態に係る一覧表管理システムについて図面を参照しながら説明する。なお、実施形態を説明する全図において、共通の構成要素には同一の符号を付し、繰り返しの説明を省略する。
【００２３】
図1は、一覧表管理サーバ利用システムの構成の一例を示す。
一覧表管理サーバ利用システムは、一覧表管理サーバ１００と、複数の利用者端末１４０と、システム管理者端末１５０と、メールサーバ１６０と、利用者認証システム１７０とで構成される。一覧表管理サーバ１００と、複数の利用者端末１４０と、システム管理者端末１５０と、メールサーバ１６０と、利用者認証システム１７０は、ネットワーク１８０に接続されており、相互に通信することができる。
利用者端末１４０は、メールクライアント１４１と、ブラウザ１４２とを有する。一覧表管理サーバ１００は、Ｗｅｂサーバの機能を有しており、ブラウザ１４２に各種の画面を表示させ、ブラウザ１４２に入力された操作を受け付けることができる。また、メールクライアント１４１と一覧表管理サーバ１００は、メールサーバ１６０を介してメールを送受信することができる。
システム管理者端末１５０はデータベースクライアント１５１を有する。一覧表管理サーバ利用システムにはシステム管理者がいる。システム管理者は各ＤＢをデータベースクライアント１５１を利用して更新する。
一覧表管理サーバ１００と利用者端末１４０は、シングルサインオン技術を導入している。シングルサインオン技術により、利用者は、一覧表管理サーバ１００の利用に先立って利用者端末１４０にログインするとき、利用者認証システム１７０で識別認証を受けることができる。一覧表管理サーバ１００は、利用者認証システム１７０から利用者を識別・認証した結果を入手し、利用者を識別する。
【００２４】
一覧表管理サーバ１００は、本発明の一覧表管理システムの一例である。一覧表管理サーバ１００は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）と、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）等で構成される主メモリと、ハードディスク等で構成される記憶装置と、一覧表ストレージ１１０と、タスクＤＢ（データベース）１２０と、部署名・利用者名ＤＢ１３０とを備えている。一覧表ストレージ１１０と、タスクＤＢ１２０と、部署名・利用者名ＤＢ１３０とは、それぞれ独立した装置であってもよいし、記憶装置に格納されていてもよい。
一覧表管理サーバ１００の記憶装置には、一覧表管理プログラムが格納されており、一覧表管理サーバ１００のＣＰＵが記憶装置から一覧表管理プログラムを主メモリに読み出して実行することにより、認証部１０１と、一覧表登録部１０２と、一覧表決定部１０３と、被依頼者決定部１０４と、タスク依頼部１０５と、タスク実現部１０６と、進捗管理部１０７と、部署名・担当者名更新部１０８との各部の機能が実現される。
【００２５】
一覧表ストレージ１１０には、一覧表データである一覧表３００が格納される。一覧表３００は、それを一覧表ストレージ１１０に登録した利用者が維持・更新の責任を持つ。すなわち、一覧表３００を登録した利用者がその管理者となる。利用者端末１４０を利用する利用者は、一覧表３００を対象とするタスクを依頼する依頼者と、タスクを依頼される被依頼者の両者となることができる。ある一覧表３００を対象とするタスクの依頼者が、別の一覧表３００を対象とするタスクの被依頼者であるという場合もあり得る。なお、タスクには、例えば一覧表の更新、一覧表に関連する文書の配布や提出等がある。
タスクＤＢ１２０には、一覧表テーブル４００と、タスクテーブル５００と、レコード毎タスクテーブル６００とが格納される。一覧表テーブル４００は、一覧表ストレージ１１０に格納されている一覧表３００のリストである。タスクテーブル５００には、一覧表ストレージ１１０に格納されている一覧表３００に対するタスクの依頼が格納されている。タスクテーブル５００には、タスクが完了したものも未完了のものも格納されている。レコード毎タスクテーブル６００には、一覧表３００中のレコード毎のタスクについての情報が格納されている。レコード毎タスクテーブル６００には、タスクが完了したものも未完了のものも格納されている。
部署名・利用者名ＤＢ１３０には、部署名変更テーブル７００と、異動テーブル８００と、利用者テーブル２００とが格納される。部署名変更テーブル７００には、一覧表ストレージ１１０に格納されている一覧表３００中に出てくる全部署名についての部署名変更の履歴が格納されている。部署名変更テーブル７００には過去のものも予定のものも格納されている。異動テーブル８００には、一覧表３００中に出てくる全利用者名についての異動の履歴が格納されている。異動テーブル８００には、過去のものも予定のものも格納されている。利用者テーブル２００は、一覧表管理サーバ１００を利用する全利用者についての情報が格納されている。利用者テーブル２００は利用者認証システム１７０の中に導入することもできる。
【００２６】
図２は、利用者テーブル２００の構成の一例を示す。
利用者テーブル２００は、例えば、利用者ＩＤ（Ｉｄｅｎｔｉｆｉｅｒ）２０１と、部署名２０２と、利用者名２０３と、メールアドレス２０４と、利用者状態２０５とを含む利用者情報を格納する。利用者テーブル２００には、一覧表管理サーバ１００の利用者一人ひとりが登録される。
利用者ＩＤ２０１は、利用者を一意に示す情報である。部署名２０２は、利用者が所属する部署を示す。利用者名２０３は、利用者の氏名を示す。なお、部署名２０２と利用者名２０３とは、本発明の利用者識別情報の一例である。メールアドレス２０４は、利用者に対して電子メールで連絡する際に宛先とするメールアドレスを示す。
利用者状態２０５は、例えば、利用者が責任者、退職者、およびそれら以外の者のいずれであるかを示す。退職者は一覧表管理サーバ１００を利用できず、退職者の認証は失敗とされる。責任者の役割については次の図３を参照して説明する。
【００２７】
図３は、一覧表３００の例を示す。図３（Ａ）は製品一覧３０１の例を示す。図３（Ｂ）は○○会議参加者一覧３１１の例を示す。
列は、一覧表３００毎に異なる。図３（Ａ）の製品一覧３０１の例は、製品ＩＤ３０２と、製品名３０３と、担当部署３０４と、担当者名３０５と、…（他の列）からなるレコード３０６で構成される。また、図３（Ｂ）の○○会議参加者一覧３１１の例は、参加者ＩＤ３１２と、部署３１３と、参加者名３１４と、出欠３１５とからなるレコード３０６で構成される。
ここで、利用者情報に含まれる部署名２０２と利用者名２０３は、どの一覧表３００でも必要である。ただし、異なる一覧表３００において部署名２０２と利用者名２０３とはそれぞれ異なる名称と名前であってもよい。各一覧表３００の列のうち、どの列が部署名２０２と利用者名２０３にそれぞれ該当するかは各一覧表３００の管理者（各一覧表３００を一覧表ストレージ１１０に登録した者）が指定する。
例えば、図３（Ａ）において担当部署３０４が部署名２０２である。担当部署３０４は、レコード３０６を維持する部署を示す。また、担当者名３０５が利用者名２０３である。担当者名３０５は、レコード３０８の更新が依頼される担当者（被依頼者）を示す。担当者は、部署名３０４の部署に所属する。担当者名３０５が未定義の場合は、部署名３０４の部署の責任者にレコード３０６の更新が依頼される。すなわち、図２の利用者状態２０５に責任者と記載されている利用者に、レコード３０６の更新が依頼される。図３（Ａ）の例は、レコード３０６あたりの担当者名３０５が一つの場合を示すが、担当者名３０５を複数設定することも可能である。
製品一覧３０１を対象とするタスクの例としては、製品名３０３、担当部署３０４、または担当者名３０５の変更がある。
【００２８】
また、○○会議参加者一覧３１１を対象とするタスクの例としては、出欠３１５の記入、会議参加者（被依頼者）が○○会議参加者一覧３１１に関連する文書ファイル（会議資料や議事録）を取得すること、会議参加者が文書ファイル（会議資料や議事録のレビュー）を提出することがある。
○○会議参加者一覧３１１の管理者と会議参加者との間の資料のやり取りは、例えば、文書ファイルを添付することにより行われる。文書ファイルを添付するために、一覧表ストレージ１１０に各一覧表３００に対応するフォルダ（以下、保管フォルダという。）が設けられる。そして、ファイルの添付はその保管フォルダを介して行われる。
後述するように、例えば、会議参加者に議事録を配布する場合、○○会議参加者一覧３１１の管理者は、図１４の依頼画面１４００でファイル添付ボタン１４０８を押すことにより、議事録を添付する。このとき、議事録は保管フォルダに保存される。会議参加者は、担当者（被依頼者）として、図１７のタスク実行画面１７００でレコード１７０９を選択して添付ファイルボタン１７１０を押すことにより、議事録を参照することができる。また、例えば、会議参加者が担当者（被依頼者）として議事録のレビュー等を提出する場合、会議参加者は図１７のタスク実行画面１７００でレコード１７０９を選択してファイル添付ボタン１７１１を押すことにより、議事録のレビューを添付する。このとき、議事録のレビューは保管フォルダに保存される。管理者は図２０のレコード毎進捗表示画面２０００でレコード２００８を選択して添付ファイルボタン２００９を押すことにより、議事録のレビューを参照したり、それを取り出して利用者端末１４０の記憶装置に保存したりすることができる。
【００２９】
図４は、一覧表テーブル４００の一例を示す。
一覧表テーブル４００は、一覧表管理サーバ１００を利用する会社等の組織ごとに一つである。
一覧表テーブル４００は、例えば、一覧表ＩＤ４０１と、一覧表名４０２と、管理者名４０３と、登録日時４０４と、部署名範囲４０５と、利用者範囲４０６と、部署との関係４０７とで構成される。
一覧表ＩＤ４０１は、その一覧表を一意に示す情報である。
一覧表名４０２は一覧表ストレージ１１０に格納されている一覧表３００の名称を示す。なお、登録される一覧表３００には、その名前（ファイル名）が同じものが複数ある場合もある。同じファイル名の一覧表が登録できるように、一覧表３００を一覧表ストレージ１１０中のフォルダに格納し、一覧表名の登録時に一覧表名４０２としてそのフォルダ名も含めてフォルダ名＋ファイル名を指定することもできる。
管理者名４０３は、一覧表３００の管理者（すなわち、その一覧表３００を一覧表ストレージ１１０に登録した者）を示す情報である。管理者名４０３は、利用者テーブル２００の利用者ＩＤ２０１、利用者名２０３、またはメールアドレス２０４に対応する。管理者は、一覧表３００の更新を被依頼者に依頼する。
登録日時４０４は、管理者が一覧表３００を一覧表ストレージ１１０に登録した日時である。
部署名範囲４０５は、一覧表３００中の部署名が指定されている列名および行番号を示す。
利用者範囲４０６は、一覧表３００中の利用者が指定されている列名および行番号を示す。
部署との関係４０７は、１対１と１対ｎがあり、部署が分割、合併、または廃止されたときの一覧表３００の更新方法を示す。ここで、１対１は、１部署１レコードの場合である。部署が分割された場合、増えた部署数分だけ、レコードを追加する必要、および、担当者を設定する必要がある。部署が合併または廃止された場合は、減った部署数分だけレコードを削除する必要がある。１対ｎは、部署ごとに、複数レコード（０件以上）がある場合である。部署が分割された場合、既存のレコードをいずれかの部署に振り分ける必要がある。
【００３０】
図５は、タスクテーブル５００の一例を示す。
タスクテーブル５００は、例えば、タスクＮｏ５０１と、一覧表ＩＤ５０２と、一覧表名５０３と、依頼者名５０４と、タスク種別５０５と、開始日時５０６と、期限日時５０７と、催促日時５０８と、件名５０９と、依頼文５１０と、保存フォルダのパス５１１と、状態５１２とで構成される。
タスクテーブル５００に行が追加される場合には、例えば、一覧表名５０３が示す一覧表３００が図３（Ａ）の製品一覧３０１であるときに、管理者から新たな依頼があった場合、製品一覧３０１中の担当者が担当部署３０４または担当者名３０５の変更を申し出る場合、製品一覧３０１中の担当部署３０４について部署名変更テーブル７００に新たな部署名変更が登録された場合、および、製品一覧３０１中の担当者名３０５について異動テーブル８００に新たな異動が登録された場合などがある。
タスクＮｏ５０１は、タスク毎に一意に付与される番号である。一覧表ＩＤ５０２は、一覧表３００を一意に示す情報である。一覧表名５０３は、一覧表３００の名前である。
依頼者名５０４は、タスク種別５０５によって異なる。タスク種別５０５には、依頼、申し出、部署名変更、異動がある。一覧表３００の管理者が依頼をする場合は、依頼となり、レコード３０６の担当者が申し出る場合は、申し出となり、部署名変更があった場合は、部署名変更となり、担当者の異動が合った場合は、異動となる。
開始日時５０６は、依頼があった日時を示す。期限日時５０７は、被依頼者が更新を完了すべき日時を示す。催促日時５０８は、進捗管理部１０７が催促する予定の日時を示す。
件名５０９と依頼文５１０は、後述するように、依頼者が入力した件名と依頼文である。
保存フォルダのパス５１１は、依頼者によって被依頼者に配布される文書、被依頼者によって提出される文書等が保存されるフォルダへのパスを示す。図１４と図１７を参照して後述するように、依頼画面１４００のファイル添付ボタン１４０８が依頼者によって押されるとき、およびタスク実行画面１７００のファイル添付ボタン１７１１が被依頼者によって押されるとき、タスク依頼部１０５は保存フォルダを一覧表ストレージ１１０内に確保し、保存フォルダのパス５１１にその保存フォルダへのパスを設定する。
状態５１２は、依頼した各タスクでの総レコード件数とそのうち更新が完了したレコード件数を示す。例えば、タスクＮｏ５０１＝１の総依頼レコード件数が１００件であり、そのうち５０件のレコードの更新が完了しているとき、「１００件中５０件完了」となる。
【００３１】
図６は、レコード毎タスクテーブル６００の一例を示す。
レコード毎タスクテーブル６００は、タスクＮｏ６０１と、利用者ＩＤ６０２と、レコード番号６０３と、タスク状態６０４と、レコード中の更新箇所６０５と、最終更新日時６０６と、更新前レコード６０７と、更新後レコード６０８とで構成される。
タスクテーブル５００に行が追加されると、タスクテーブル５００の一覧表名５０３が示す一覧表３００のレコード３０６のうち該当するものに対してレコード毎タスクテーブル６００に行が1行ずつ追加される。
タスクＮｏ６０１は、タスク毎に一意に付与される番号である。タスクＮｏ６０１は、対応するタスクテーブル５００のタスクＮｏ５０１を示す。
利用者ＩＤ６０２は、タスクの依頼が送られる被依頼者の利用者ＩＤを示す。利用者ＩＤ６０２は、利用者テーブル２００の利用者ＩＤ２０１に対応する。
レコード番号６０３は、タスクが依頼されているレコード３０６を示す。
タスク状態６０４は、レコード３０６に対する依頼の進捗状況を示す。例えば、被依頼者がタスクを実行する前は未、タスクを完了すれば完となる。更に細かな区分もできる。
レコード中の更新箇所６０５と、最終更新日時６０６と、更新前レコード６０７と、更新後レコード６０８はレコード３０６を更新するタスクである場合に有効となる。また、タスクの内容が被依頼者による文書の取得や提出である場合には、レコード中の更新箇所６０５は、参照または添付された添付ファイルへのパス、最終更新日時６０６は参照または添付の日時、更新前レコード６０７は参照された添付ファイル、更新後レコード６０８は添付された添付ファイルになる。
レコード中の更新箇所６０５は、レコード３０６中で、更新された箇所を示す。更新箇所は複数の場合もある。最終更新日時６０６は、レコード３０６に対する当該タスクＮｏ６０１のタスクに対する更新による最終更新の日時である。当該タスクＮｏ６０１に対しての更新がまだされていない場合は未定義である。更新前レコード６０７は、被依頼者によって更新される前のレコード３０６のデータである。更新後レコード６０８は、被依頼者によって更新された後のレコード３０６のデータである。被依頼者がレコード３０６を更新する前は未定義である。
【００３２】
例えば、製品一覧３０１（一覧表３００）の複数のレコード３０６の担当者名３０５が同じ場合はその担当者が複数のレコード３０６の更新を依頼される場合がある。その場合、利用者ＩＤ６０２が同じでも更新すべきレコード３０６ごとにレコード番号６０３が異なる行が追加される。
また、同じレコード３０６に対して複数の更新依頼がある場合がある。そのような場合は被依頼者決定部１０４が検知して、依頼者および被依頼者にその旨を伝える。しかし、更新が可能な被依頼者は、レコード毎タスクテーブル６００の構造によって一人に限られるので、２人が同時に更新をして片方の更新が失われるといった不都合を防ぐことができる。複数の更新依頼があるレコード３０６を被依頼者が更新をした場合は、そのレコード３０６に対する最終更新日時６０６は当該更新依頼タスクで同じ日時になる。
【００３３】
図７は、部署名変更テーブル７００の一例を示す。
部署名変更テーブル７００は、部署名変更Ｎｏ７０１と、変更日時７０２と、旧部署名７０３と、新部署名７０４と、部署名変更区分７０５とで構成される。
部署名変更Ｎｏ７０１は、行毎に一意に付与される番号である。変更日時７０２は、部署名を変更する日時を示す。旧部署名７０３は、変更前の部署名を示す。新部署名７０４は、変更後の部署名を示す。
部署名変更区分７０５は、部署名の変更の種類を示し、変更、新設、廃止、分割、統合などがある。変更は、１部署の名称が変更される場合を示し、部署名変更テーブル７００には１行追加される。追加は、１部署が追加される場合を示し、旧部署名７０３は未定義である。廃止は、１部署が廃止される場合を示し、部署名変更テーブル７００には1行追加され、新部署名７０４は未定義である。分割は、１部署が複数部署に分割される場合を示し、部署名変更テーブル７００には分割後の部署数分の行数追加される。統合は、複数部署が１部署に統合される場合を示し、部署名変更テーブル７００には分割前の部署数分の行数が追加される。一覧表管理サーバ１００の利用開始時点では、部署名変更区分７０５は、追加で登録されている。
部署名・担当者名更新部１０８は、部署名変更テーブル７００に行が追加された場合、それに合わせて利用者テーブル２００を更新する。さらに、タスク依頼部１０５は、部署名の変更に関係する一覧表３００についてタスクテーブル５００に一行追加する。
【００３４】
図８は、異動テーブル８００の一例を示す。
異動テーブル８００は、異動Ｎｏ８０１と、異動日時８０２と、異動者名８０３と、異動前部署名８０４と、異動後部署名８０５と、異動区分８０６とで構成される。異動テーブル８００には、利用者一人の一回の異動ごとに1行追加される。
異動Ｎｏ８０１は、行毎に一意に付与される番号である。異動日時８０２は、異動の日時を示す。異動者名８０３は、異動する利用者を示す。異動前部署名８０４は、異動前の部署名を示す。異動後部署名８０５は、異動後の部署名を示す。
異動区分８０６は、異動の種類を示し、登録、異動、退職などがある。登録は、利用者が新たに一覧表管理サーバ１００を使い始めることを示す。異動は、利用者の所属部署名が変更されることを示す。退職は、異動者名８０３が担当者名３０５や参加者名３１４として一覧表３００中に指定されている場合に更新が必要であるということ、異動日時８０２までに別の者に更新する必要があること、およびその異動者が異動日時８０２以降に一覧表管理サーバ１００を使用できないようにすることを示す。
部署名・担当者名更新部１０８は、異動テーブル８００に行が追加された場合、それに合わせて利用者テーブル２００を更新する。さらに、異動区分８０６が異動または退職である行が追加された場合、タスク依頼部１０５は、異動者に関係する一覧表３００についてタスクテーブル５００に一行追加する。
【００３５】
以下、一覧表管理サーバ１００の各部の機能について説明する。
一覧表管理サーバ１００の全ての利用者は、予め利用者テーブル２００に登録されている。また、予め、各一覧表３００の管理者は、利用者端末１４０でＥｘｃｅｌ（登録商標）等のスプレッドシートを使って一覧表３００を作成し、または作成済みの一覧表３００を取得し、利用者端末１４０の記憶装置に保存する。一覧表３００の作成または取得、および保存は、一覧表管理サーバ１００の外での処理である。一覧表３００は、例えば利用者端末１４０の記憶装置に確保されたフォルダに保存される。一覧表３００中にはレコード３０６の維持をすべき利用者の部署名と利用者名が書かれている。
【００３６】
図９は、一覧表３００を一覧表ストレージ１１０に登録する一覧表登録処理の流れの一例を示す。
［認証部１０１の処理、利用者識別・認証ステップ（Ｓ９０１）]
利用者は、一覧表管理サーバ１００にアクセスする前に利用者認証システム１７０で識別・認証を受ける。利用者が一覧表管理サーバ１００にアクセスするときには、利用者ＩＤ２０１と利用者名２０３は識別・認証済みである。
利用者端末１４０から一覧表管理サーバ１００へのアクセスがあると、認証部１０１は、利用者認証システム１７０に利用者の識別・認証状況を問い合わせ、応答を得ることで、利用者が利用者テーブル２００中のどの利用者かを識別する。そのとき、利用者状態２０５が退職者であった場合、利用者識別・認証処理は失敗として、認証部１０１は利用者端末１４０にエラーメッセージを返す。
【００３７】
［一覧表登録部１０２の処理、一覧表登録ステップ（Ｓ９０２）]
一覧表登録部１０２は、利用者テーブル２００に記憶されている利用者情報に含まれる部署名２０２と利用者名２０３（利用者識別情報）で識別された利用者によって入力された一覧表３００を受け付け、その一覧表３００を一覧表ストレージ１１０に登録する。
具体的には、認証部１０１によって利用者が識別・認証されると、一覧表登録部１０２は、利用者端末１４０のブラウザ１４２に図１０の利用者画面１０００を表示する。
利用者画面１０００は、一覧表一覧１００１と、依頼しているタスク一覧１００２と、依頼されているタスク一覧１００３と、自分がレコードの担当者になっている一覧表一覧１００４とを含む。
図１１に示すように、一覧表一覧１００１は、一覧表ＩＤ１２０１と、一覧表名１２０２と、管理者名１２０３と、未完了タスク１２０４と、完了タスク１２０５と、一覧表出力ボタン１２０６とで構成される。
一覧表登録部１０２は、利用者端末１４０の記憶装置内のフォルダに保存されている一覧表３００をブラウザ１４２内のフォルダ画面１２０７に表示する。利用者は、ブラウザ１４２においてフォルダ画面１２０７中の一覧表３００のアイコンを利用者画面１０００中の一覧表一覧１００１のエリアにドラッグアンドドロップすることによって、一覧表３００を一覧表管理サーバ１００に入力（送信）することができる。
一覧表登録部１０２は、入力された一覧表３００を受け付け、その一覧表３００を一覧表ストレージ１１０に登録する。そして、一覧表登録部１０２は、一覧表テーブル４００に新たな行を追加し、一覧表ＩＤ４０１を付与して一覧表名４０２を登録する。ここで、一覧表登録部１０２は、管理者名４０３には先に識別・認証されている利用者の利用者名２０３を登録する。さらに、一覧表一覧１００１に一覧表ＩＤ１２０１と一覧表名１２０２と管理者名１２０３を追加で表示する。ここで、一覧表登録部１０２は一覧表３００の列名またはデータを基に部署範囲４０５と利用者範囲４０６を自動的に判断する。一覧表登録部１０２は、この判断のために、部署名変更テーブル７００および異動テーブル８００の登録内容を利用することもできる。
未完了タスク１２０４と完了タスク１２０５は、一覧表３００について管理者が依頼したタスクのうちそれぞれ完了していないものと完了しているものの数を示す。進捗管理部１０７は、所定のタイミングで未完了タスク１２０４と完了タスク１２０５を計算し、一覧表一覧１００１に表示する。
なお、一覧表一覧１００１は本発明の進捗管理者提示手段の一例である。
【００３８】
図１２は、一覧表３００についてのタスクを依頼するタスク依頼処理の流れの一例を示す。
タスクの依頼に先だって、依頼者（利用者）は、認証部１０１によって利用者テーブル２００中のどの利用者かの識別を受ける（Ｓ１２０１）。ステップＳ１２０１における認証部１０１の処理は、上述したステップＳ９０１と同様である。
【００３９】
［一覧表決定部１０３の処理、一覧表決定ステップ（Ｓ１２０２）］
一覧表決定部１０３は、利用者テーブル２００に記憶されている利用者情報に含まれる部署名２０２と利用者名２０３（利用者識別情報）で識別された利用者（以下、依頼者という。）によって一覧表ストレージ１１０に記憶されている一覧表３００の中から選択された一覧表３００をタスクの対象として決定する。
例えば、タスク種別５０５が依頼の場合、依頼者はブラウザ１４２内に表示されている一覧表一覧１００１の行をマウス等で選択することによってタスクの対象である一覧表３００を選択する。一覧表決定部１０３は、依頼者によって選択された一覧表３００をタスクの対象として決定する。
また、ブラウザ１４２内に表示される自分がレコードの担当者になっている一覧表一覧１００４については後で図１６を参照して詳細に説明するが、自分がレコードの担当者になっている一覧表一覧１００４には利用者がレコードの担当者になっている一覧表３００が表示される。例えば、タスク種別５０５が申し出の場合、依頼者は自分がレコードの担当者になっている一覧表一覧１００４の中からタスクの対象である一覧表３００を選択する。一覧表決定部１０３は、依頼者によって選択された一覧表３００をタスクの対象として決定する。
【００４０】
［被依頼者決定部１０４の処理、被依頼者決定ステップ（Ｓ１２０３）]
被依頼者決定部１０４は、一覧表決定部１０３によってタスクの対象として決定された一覧表３００に含まれる部署名２０２と利用者名２０３（利用者識別情報）によって示される被依頼者候補の中から依頼者によって選択された被依頼者が、利用者テーブル２００に記憶されている利用者情報に含まれる部署名２０２と利用者名２０３（利用者識別情報）で識別される利用者である場合に、その被依頼者を一覧表３００についてのタスクの依頼先として決定する。
【００４１】
具体的には、被依頼者決定部１０４は、一覧表決定部１０３によってタスクの対象である一覧表３００が決定されると、その一覧表３００を基にブラウザ１４２内に図１３に示す部署名・担当者指定画面１３００を表示する。部署名・担当者指定画面１３００は、少なくとも一覧表名１３０１と、部署名１３０２と、部署名範囲枠１３０３と、利用者名１３０４と、利用者名範囲枠１３０５と、確認メッセージ１３０６と、完了ボタン１３０７と、キャンセルボタン１３０８とを含む。
被依頼者決定部１０４は、一覧表テーブル４００の部署範囲４０５と利用者範囲４０６を基に部署名範囲枠１３０３と利用者範囲枠１３０４を表示し、更新を促す確認メッセージ１３０６を表示する。被依頼者決定部１０４は、さらに、一覧表３００中の各レコード３０６の担当部署３０４と担当者名３０５の組合せが利用者テーブル２００中の部署名２０２と利用者名２０３にあるかを確認する。もし、マッチしない組合せがあれば、被依頼者決定部１０４はエラーメッセージを表示する。なお、被依頼者決定部１０４は、部署名１３０２または利用者名１３０４が未定義の場合もマッチしないものとして処理する。ここで、依頼者が一覧表３００の管理者（すなわち、一覧表３００を一覧表ストレージ１１０に登録した利用者）である場合には、一覧表３００の部署名または利用者名を修正し、修正した一覧表３００の結果を用いて再度マッチを確認することもできる。管理者が修正する際には利用者テーブル２００にある部署名２０２および利用者名２０３から選択させることもできる。
【００４２】
依頼者によって完了ボタン１３０７が押されると、被依頼者決定部１０４は、部署名範囲枠１３０３の中の部署名１３０２と利用者名範囲枠１３０５の中の利用者名１３０４とに基づいて、一覧表３００についてのタスクの依頼先である被依頼者を決定する。
なお、例えば、図３（Ａ）の製品一覧３０１の担当者名３０５や図３（Ｂ）の○○会議参加者一覧３１１の参加者名３１４のように、利用者名は一覧表３００のレコード３０６毎に指定されている。このため、被依頼者決定部１０４は、部署名・担当者指定画面１３００上で一覧表３００のレコード３０６毎にそのレコードを更新する被依頼者を依頼者に選択させることができ、選択された被依頼者を一覧表３００の各レコード３０６についての依頼先として決定する。そして、後述するように、タスク実現部１０６は、図１７のタスク実行画面１７００において、被依頼者決定部１０４によって各被依頼者が依頼先として決定されたレコードのみを提示し、提示されたレコードのみを各被依頼者が更新することを可能とする。
【００４３】
［タスク依頼部１０５の処理、タスク依頼ステップ（Ｓ１２０４）］
タスク依頼部１０５は、利用者テーブル２００に登録されている利用者情報から被依頼者決定部１０４によって決定された被依頼者のメールアドレス２０４を取得し、取得したメールアドレスを宛先として依頼者によるタスクの依頼が記載された電子メールを送信する。
具体的には、被依頼者決定部１０４によって被依頼者が決定されると、タスク依頼部１０５は、依頼者の利用者端末１４０のブラウザ１４２に、図１４に示す依頼画面１４００を表示する。依頼者は依頼画面１４００上で一覧表３００についてのタスクの内容を入力する。
依頼画面１４００は、一覧表ＩＤ１４０１と、一覧表名１４０２と、被依頼者名１４０３と、期限日時１４０４と、催促日時１４０５と、件名１４０６、依頼文１４０７と、ファイル添付ボタン１４０８と、依頼ボタン１４０９と、後で依頼ボタン１４１０と、キャンセルボタン１４１１とで構成される。
期限日時１４０４は、タスクが完了されるべき期限を示す。催促日時１４０５は、進捗管理部１０７が催促メールを送信する日時を示す。期限日時１４０４と催促日時１４０５は、依頼者が入力する。
件名１４０６と依頼文１４０７は、タスクについて依頼先に伝えるべき件名と依頼文である。件名１４０６と依頼文１４０７は、依頼者が入力する。
ファイル添付ボタン１４０８が依頼者によって押されると、タスク依頼部１０５は保存フォルダを一覧表ストレージ１１０内に確保し、その保存フォルダに文書ファイルを保存するための画面をブラウザ１４２に開く。依頼者は、その画面に文書ファイルをドラッグアンドドロップすることによって文書ファイルを保存フォルダに保存することができる。
【００４４】
依頼者が依頼画面１４００で各項目を設定し、依頼ボタン１４０９を押すと、タスク依頼部１０５は、タスクテーブル５００に新しい行を追加し、上記各項目の内容を登録する。同時に、タスク依頼部１０５は、レコード毎タスクテーブル６００に、一覧表３００の各レコード３０６に対応する行を追加する。このとき、タスク依頼部１０５は、催促日時５０８をオペレーティングシステムのイベント管理機能に登録する。これにより、催促日時になったら、一覧表管理サーバ１００にイベントが通知され、それによってタスクを実行していない被依頼者への催促が可能になる。
次に、タスク依頼部１０５は、利用者テーブル２００を検索して各被依頼者に対応するメールアドレス２０４を取得する。そして、タスク依頼部１０５は、タスクテーブル５００に登録された内容に基づいて取得したメールアドレス２０４を宛先とする電子メールを作成し、メールサーバ１６０経由で被依頼者に送信する。
なお、上述した図１３では部署名・担当者名指定画面１３００に部署名範囲枠１３０３と利用者範囲枠１３０４とがそれぞれ１つずつ表示されている例を示したが、１つの一覧表３００について部署名範囲枠１３０３と利用者範囲枠１３０４をそれぞれ複数設定することもできる。これにより、一覧表３００中の一部のレコード３０６または、多数の担当者うち、一部だけを指定してタスクを依頼することも可能である。また、本実施形態では、レコード３０６ごとの担当者名３０５や参加者３１４が一人の場合を説明しているが、担当者名３０５や参加者３１４が複数設定されている場合は、レコード３０６の代表の担当者や参加者だけに送る、または全担当者や全参加者に送るといった選択を可能にすることもできる。
【００４５】
［タスク実現部１０６の処理］
タスク実現部１０６は、タスク依頼部１０５によって送信された電子メールを受信した被依頼者が、一覧表決定部１０３によってタスクの対象として決定された一覧表３００を対象として、その電子メールに記載されたタスクの依頼に従ってタスクを実行することを可能とする。
タスク実現部１０６は、タスク確認処理とタスク実行処理を実行する。ただし、タスク確認処理とタスク実行処理の実行に先だって、被依頼者（利用者）は、認証部１０１によって利用者テーブル２００中のどの利用者かの識別を受ける（Ｓ１２０５）。ステップＳ１２０５における認証部１０１の処理は、上述したステップＳ９０１と同様である。
【００４６】
［タスク確認ステップ（Ｓ１２０６）］
被依頼者が使用している利用者端末１４０のブラウザ１４２に利用者画面１０００が表示されるとき、タスク実現部１０６は、被依頼者の利用者名２０３に対応した利用者ＩＤ２０１をレコード毎タスクテーブル６００中で検索し、利用者画面１０００中に、図１５の依頼されているタスク一覧１００３と図１６の自分がレコードの担当者になっている一覧表一覧１００４とを表示する。
タスク実現部１０６は、依頼されているタスク一覧１００３に被依頼者に依頼されているタスクを表示する。また、タスク実現部１０６は、自分がレコードの担当者になっている一覧表一覧１００４に被依頼者が担当者になっているレコードを含む一覧表を表示する。依頼されているタスク一覧１００３または自分がレコードの担当者になっている一覧表一覧１００４を見ることにより、被依頼者は自分に依頼されているタスクを知ることができる。
【００４７】
図１５に示すように、依頼されているタスク一覧１００３は、タスクＮｏ１５０１と、依頼者名１５０２と、一覧表名１５０３と、開始日時１５０４と、期限日時１５０５と、件名１５０６と、依頼文１５０７と、依頼があったレコード数１５０８と、更新していないレコード数１５０９と、他の依頼先も含めた完了状況１５１０とで構成される。
依頼があったレコード数１５０８と更新していないレコード数１５０９は、一覧表名１５０３の一覧表３００を対象とするタスクＮｏ１５０１のタスクにおいて、被依頼者の担当になっているレコード数とそのうち未完了のレコード数である。
依頼されているタスク一覧１００３において、被依頼者がタスクを実行したい一覧表名１５０３を含む行を選択すると、タスク実現部１０６は、一覧表ストレージ１１０中の一覧表３００から被依頼者の担当するタスクが未完了のレコード３０６を選択し、ブラウザ１４２に図１７のタスク実行画面１７００を表示する。なお、表示するレコード３０６を選択する条件を指定することによって、タスク実行画面１７００にタスクが完了のものだけを表示したり、タスクが未完了と完了のものの両方を表示したりすることもできる。
【００４８】
また、図１６に示すように、自分がレコードの担当者になっている一覧表一覧１００４は、一覧表ＩＤ１６０１と、一覧表名１６０２と、管理者名１６０３と、担当レコード数１６０４、未完了タスク１６０５と、完了タスク１６０６とで構成される。
一覧表３００についてタスクの依頼がないときでも、利用者としては、例えば、作業計画を立てるに当たって、自分がどのような担当になっているのか、今後、どのような依頼に対応する必要があるのかを確認したい場合がある。そのような場合に、利用者は、自分がレコードの担当者になっている一覧表一覧１００４を参照する。自分がレコードの担当者になっている一覧表一覧１００４には、利用者に対して依頼されているタスク（利用者が被依頼者になっているタスク）がない一覧表３００も含めて、一覧表テーブル４００中の一覧表３００のうち、利用者がレコードの担当者になっている一覧表３００が表示される。
ここで、担当レコード数１６０４は、各行に表示されている一覧表３００について自分が担当者になっているレコードの件数を示す。
未完了タスク１６０５は、各行に表示されている一覧表３００について自分に依頼されているタスクのうち、完了していないタスクの件数を示す。完了タスク１６０６は、各行に表示されている一覧表３００について自分に依頼されているタスクのうち、既に完了したタスクの件数を示す。未完了タスク１６０５と完了タスク１６０６の両方とも０件であることはその一覧表３００についてタスクが依頼されていない（自分が被依頼者になっていない）ことを意味する。
このため、自分がレコードの担当者になっている一覧表一覧１００４の一覧表名１６０２を参照することによって各被依頼者は自分が何の担当者になっているのかを把握することができる。自分がレコードの担当者になっている一覧表一覧１００４において、被依頼者がタスクを実行したい一覧表名１６０２を含む行を選択し、例えばその時表示されるプルダウンメニューからタスク実行を選択すると、上記と同様に、タスク実現部１０６は、一覧表ストレージ１１０中の一覧表３００から被依頼者の担当するタスクが未完了のレコード３０６を選択し、ブラウザ１４２に図１７のタスク実行画面１７００を表示する。なお、表示するレコード３０６を選択する条件を指定することによって、タスク実行画面１７００にタスクが完了のものだけを表示したり、タスクが未完了と完了のものの両方を表示したりすることもできる。
また、タスク種別５０５が申し出であるタスクを依頼する場合、利用者（依頼者）がタスクを依頼したい一覧表名１６０２を含む行を選択し、例えばその時表示されるプルダウンメニューからタスク申し出を選択すると、一覧表決定部１０３は、その利用者によって選択された一覧表３００をタスクの対象として決定する。
なお、依頼されているタスク一覧１００３と自分がレコードの担当者になっている一覧表一覧１００４とは、本発明の進捗被依頼者提示手段の例である。
【００４９】
［タスク実行ステップ（Ｓ１２０７）］
タスク実行画面１７００は、タスクＮｏ１７０１と、依頼者名１７０２と、期限日時１７０３と、担当レコード数１７０４と、依頼文１７０５と、一覧表名１７０６と、部署名１７０７および担当者名（利用者名）１７０８を含む一つ以上のレコード１７０９と、添付ファイルボタン１７１０と、ファイル添付ボタン１７１１と、完了ボタン１７１２と、後で続けるボタン１７１３と、キャンセルボタン１７１４とで構成される。
タスク実現部１０６は、タスク実行画面１７００に、被依頼者決定部１０４によって各被依頼者が更新すると決定されたレコードのみを表示する。被依頼者はタスク実行画面１７００でタスクの対象である一覧表３００の一覧表名１７０６とレコード１７０９を確認し、レコード１７０９を編集する。タスク実現部１０６は、被依頼者の編集に従って、一覧表ストレージ１１０に格納されている一覧表３００のレコード３０６を更新する。例えば、担当者が「佐藤○○」から「渡辺△△」に変わっている場合、被依頼者は担当者名１７０８を「渡辺△△」に変更する。これに従って、タスク実現部１０６は一覧表３００のレコード３０６の担当者名３０５を「渡辺△△」に更新する。
タスク実現部１０６はスプレッドシートで作成された一覧表３００の編集機能を有しており、被依頼者の利用者端末１４０がスプレッドシートソフトウェアを持っていない場合でも、タスク実現部１０６はタスク実行画面１７００における入力に従ってスプレッドシートで作成された一覧表３００を更新することができる。
添付ファイルボタン１７１０は、上述した図１４の依頼画面１４００でファイル添付ボタン１４０８が依頼者によって押され、保存フォルダが一覧表ストレージ１１０内に確保されているときに表示される。添付ファイルボタン１７１０が被依頼者によって押されると、タスク実現部１０６は、依頼者によって保存フォルダに保存されたファイルをブラウザ１４２に表示する。
レコード１７０９（すなわち、一覧表３００のレコード３０６）が選択され、ファイル添付ボタン１７１１が被依頼者によって押されると、タスク実現部１０６は保存フォルダに文書ファイルを保存するための画面をブラウザ１４２に開く。なお、ファイル添付ボタン１７１１が被依頼者によって押された時に保存フォルダが一覧表ストレージ１１０内にない場合、タスク実現部１０６は保存フォルダを一覧表ストレージ１１０内に確保して、その保存フォルダに文書ファイルを保存するための画面をブラウザ１４２に開く。被依頼者は、その画面に文書ファイルをドラッグアンドドロップすることによって文書ファイルを保存フォルダに保存することができる。
利用者端末１４０でレコード１７０９（すなわち、一覧表３００のレコード３０６）が更新され、完了ボタン１７１２が押されるとレコード毎タスクテーブル６００の対応する行が更新され、タスクは完了となる。
なお、タスク実行画面１７００中に一部のレコード１７０９だけを選択するチェックマークを設け、一部のレコード１７０９だけを更新できるようにしてもよい。
【００５０】
［進捗管理部１０７の処理］
進捗管理部１０７は、進捗確認処理と催促処理とタスク完了処理を実行する。
【００５１】
［進捗確認ステップ（Ｓ１２０８）］
図１８は、利用者画面１０００の中の依頼しているタスク一覧１００２の一例を示す。
依頼しているタスク一覧１００２は、タスクＮｏ１８０１と、一覧表ＩＤ１８０２と、一覧表名１８０３と、被依頼者名１８０４と、タスク種別１８０５と、開始日時１８０６と、期限日時１８０７と、催促日時１８０８と、件名１８０９と、依頼文１８１０と、被依頼者毎進捗１８１１と、レコード毎進捗１８１２と、締切りボタン１８１３とで構成される。依頼しているタスク一覧１００２を見ることによって、利用者は他の利用者に依頼しているタスクの進捗を確認することができる。
ここで、被依頼者毎進捗１８１１は、一覧表３００についてのタスクを依頼された被依頼者の総人数の中で何人がタスクを完了しているかを示す。レコード毎進捗１８１２は、一覧表３００に含まれる総レコード数の中で何件のレコードについてのタスクが完了しているかを示す。
依頼しているタスク一覧１００２において、利用者があるタスクＮｏ１８０１の行で一覧表名１８０３を選択すると、進捗管理部１０７はその時点の一覧表３００を表示する。
【００５２】
また、依頼しているタスク一覧１００２において、利用者があるタスクＮｏ１８０１の行で被依頼者毎進捗１８１１を選択すると、進捗管理部１０７は図１９の被依頼者毎進捗表示画面１９００を表示する。
被依頼者毎進捗表示画面１９００は、一覧表名１９０１と、タスクＮｏ１９０２と、担当者名１９０３と、レコード数１９０４と、完了状況１９０５と、締切りボタン１９０６とで構成される。被依頼者毎進捗画面１９００を参照すれば、依頼者は依頼したタスクの進捗状況を担当者毎（被依頼者毎）に把握することができる。
【００５３】
また、依頼しているタスク一覧１００２において、利用者があるタスクＮｏ１８０１の行でレコード毎進捗１８１２を選択すると、進捗管理部１０７は図２０のレコード毎進捗表示画面２０００を表示する。
レコード毎進捗表示画面２０００は、一覧表名２００１と、タスクＮｏ２００２と、製品ＩＤ２００３と、製品名２００４と、担当部署２００５と、担当者名２００６と、完了状況２００７と、添付ファイルボタン２００９と、締切りボタン２０１０とで構成される。レコード毎進捗表示画面２０００を参照すれば、依頼者は依頼したタスクの進捗状況をレコード２００８（すなわち、一覧表３００のレコード３０６）毎に把握することができる。
添付ファイルボタン２００９は、上述した図１７のタスク実行画面１７００でファイル添付ボタン１７１１が被依頼者によって押され、保存フォルダが一覧表ストレージ１１０内に確保されているときに表示される。依頼者がレコード２００８を選択して添付ファイルボタン２００９を押すと、タスク実現部１０６は、被依頼者によって保存フォルダに保存されたファイルをブラウザ１４２に表示する。
なお、図２０には、レコード３０６あたりの担当者名２００６が一つの場合を示すが、担当者名２００６を複数設定可能とすることもできる。
また、依頼しているタスク一覧１００２と被依頼者毎進捗表示画面１９００とレコード毎進捗表示画面２０００とは、本発明の進捗依頼者提示手段の例である。
【００５４】
［催促ステップ（Ｓ１２０９）］
未完了のタスクの催促日時になると、オペレーティングシステムのイベント管理機能は進捗管理部１０７にイベントを通知する。進捗管理部１０７は、通知されたイベントとタスクテーブル５００とレコード毎タスクテーブル６００に基づいてタスクが未完了の被依頼者を特定する。そして、進捗管理部１０７は、特定した被依頼者に催促の電子メールをメールサーバ１６０を経由して送信する。
なお、ステップＳ１２０９の催促ステップは、本発明の催促手段によって実行されるステップの一例である。
【００５５】
［タスク完了ステップ（Ｓ１２１０）］
被依頼者全員がタスクを完了した、または、被依頼者の一部がタスクを実行していないが期限を過ぎてしまったときに、依頼者は、依頼しているタスク一覧１００２でタスクを選択して締切りボタン１８０３を押すこと、若しくは被依頼者毎進捗表示画面１９００またはレコード毎進捗表示画面２０００で締切りボタン１９０６または締切りボタン２０１０を押すことにより、そのタスクについて以降の被依頼者によるレコードの更新を禁止することができる。
締切りボタン１８０３、１９０６、２０１０が押されると、進捗管理部１０７は、それ以降被依頼者がそのタスクを実行することができないようにする。
締切りボタン１８０３、１９０６、２０１０を押すことによって、管理者は、一覧表３００についてのタスクを完了することができる。
【００５６】
また、一覧表３００の管理者は、図１１の一覧表一覧１００１において、一覧表名１２０２をいくつか選び、一覧表出力ボタン１２０６を押すことができる。一覧表出力ボタン１２０６が押されると、進捗管理部１０７は、更新後の一覧表３００を一覧表ストレージ１１０から取り出し、管理者の利用者端末１４０に出力（送信）する。
【００５７】
図２１は、部署名変更テーブル７００および／または異動テーブル８００が更新されたときの部署名変更・異動処理の流れの一例を示す。
部署名変更・異動処理では、組織で部署名変更や人事異動があった場合、部署名・担当者名更新部１０８は一覧表ストレージ１１０に記憶されている一覧表３００に含まれる利用者名（担当者名３０５や参加者名３１４）や部署名（担当部署３０４や部署３１３）を更新する。そして、部署名・担当者名更新部１０８はその結果の確認を依頼する電子メールを各一覧表３００の管理者（一覧表ストレージ１１０に一覧表３００を登録した利用者）に送信する（Ｓ２１０１）。その後の処理は図１２のタスク依頼処理におけるステップＳ１２０１からＳ１２１０と同様である。
【００５８】
［部署名・担当者名更新部１０８の処理、部署名・担当者名更新ステップ（Ｓ２１０１）］
部署名・利用者名更新部１０８は、部署名変更および／または人事異動を示すデータに基づいて、一覧表記憶ストレージ１１０に記憶されている一覧表３００に含まれる部署名および／または利用者名を更新し、利用者テーブル２００に記憶されている利用者情報から各一覧表３００を登録した管理者のメールアドレスを取得し、取得したメールアドレスを宛先として、更新された部署名および／または利用者名を確認するタスクの依頼が記載された電子メールを送信する。
具体的には、組織で部署名変更や利用者（担当者や参加者）の異動があった場合、人事部門などが新旧の部署名の対応の一覧や異動の一覧を作成し、それを受け取ったシステム管理者がデータベースクライアント１５１を利用してその新旧の部署名の対応の一覧や異動の一覧を部署名変更テーブル７００と異動テーブル８００に追加行として登録する。
部署名変更テーブル７００と異動テーブル８００に行が追加されると、部署名・利用者名更新部１０８は、一覧表ストレージ１１０中の各一覧表３００の数だけタスクテーブル５００に新たな行を追加する。そして、部署名・利用者名更新部１０８は、一覧表３００の部署範囲４０５で指定されている範囲中の各部署名について、一覧表テーブル４００の部署名との関係４０７および部署名変更テーブル７００の部署名変更区分７０５に応じて、旧部署名７０３を新部署名７０４に更新する、レコード３０６を２行に分割する、レコード３０６を削除する、部署名（担当部署３０４や部署３１３）を未定義にする、といった処理を行う。続いて、部署名・利用者名更新部１０８は、一覧表テーブル４００の利用者範囲４０６で指定されている範囲中の利用者名（担当者名３０５や参加者名３１４）について、異動テーブル８００の異動区分８０６に応じて、異動者の部署名を異動前部署名８０４から異動後部署名８０５に更新する、または、未定義にする、といった処理を行う。部署名・利用者名更新部１０８は、利用者名を更新するとき、部署名が既に更新されていることも、レコード毎タスクテーブル６００を使って確認しながら利用者名を更新する。
部署名・利用者名更新部１０８は、部署名変更または異動による一覧表３００の更新が完了すると、各管理者に一覧表３００の更新結果の確認を依頼する旨の電子メールを送信する。
【００５９】
ステップＳ２１０１の後のステップは、図１２のタスク依頼処理におけるステップＳ１２０１からＳ１２１０と同様である。
部署名・担当者名更新ステップ（Ｓ２１０１）において部署名や利用者名が未定義に更新されたレコード３０６について、被依頼者決定ステップ（Ｓ１２０３）で、管理者は部署名や利用者名を設定し、レコード３０６の更新の被依頼者を決めることができる。
なお、本実施形態はレコード３０６ごとの利用者名が一つの場合を示しているが、利用者名を複数設定し、利用者のうちの一部だけが退職した場合には残りの利用者に退職した利用者に対する新利用者の設定を依頼することとしてもよい。
また、部署名と利用者名がすべて定義されている場合には、部署名・利用者名更新部１０８が直接利用者（担当者や参加者）に依頼することとしてもよい。また、一覧表３００ごとに、管理者が依頼するか、部署名・利用者名更新部１０８が直接依頼するかを指定可能にすることとしてもよい。
【００６０】
なお、上述した実施形態では一覧表３００がスプレッドシートで作成されている例について説明したが、それに限らず他のシステムで作成された一覧表であっても本発明が適用できることはもちろんである。
【００６１】
上述したように、本発明によれば、組織において一覧表を効率的に管理することができる。
また、本発明によれば、会議資料の送付やレビュー、プロジェクト状況報告、作業実施状況報告、アンケートの依頼といった作業の依頼とその管理を効果的に行うことができる。さらに、例えば、担当者ごとの案件一覧の配布といった作業も効果的に行うことができる。
【００６２】
以上、本発明の実施形態について説明したが、設計上の都合やその他の要因によって必要となる様々な修正や組み合わせは、請求項に記載されている発明や発明の実施形態に記載されている具体例に対応する発明の範囲に含まれると理解されるべきである。
【符号の説明】
【００６３】
１００…一覧表管理サーバ、１０１…認証部、１０２…一覧表登録部、１０３…一覧表決定部、１０４…被依頼者決定部、１０５…タスク依頼部、１０６…タスク実現部、１０７…進捗管理部、１０８…部署名・担当者名更新部、１１０…一覧表ストレージ、１２０…タスクＤＢ、１３０…部署名・利用者名ＤＢ、１４０…利用者端末、１４１…メールクライアント、１４２…ブラウザ、１５０…システム管理者端末、１５１…データベースクライアント、１６０…メールサーバ、１７０…利用者認証システム、１８０…ネットワーク、２００…利用者テーブル、３００…一覧表、４００…一覧表テーブル、５００…タスクテーブル、６００…レコード毎タスクテーブル、７００…部署名変更テーブル、８００…異動テーブル、１０００…利用者画面、１００１…一覧表一覧、１００２…依頼しているタスク一覧、１００３…依頼されているタスク一覧、１００４…自分がレコードの担当者になっている一覧表一覧、１３００…部署名・担当者名指定画面、１４００…依頼画面、１７００…タスク実行画面、１９００…被依頼者毎進捗表示画面、２０００…レコード毎進捗表示画面
【図１】
0006420597.tif 000002
【図２】
0006420597.tif 000003
【図３】
0006420597.tif 000004
【図４】
0006420597.tif 000005
【図５】
0006420597.tif 000006
【図６】
0006420597.tif 000007
【図７】
0006420597.tif 000008
【図８】
0006420597.tif 000009
【図９】
0006420597.tif 000010
【図１０】
0006420597.tif 000011
【図１１】
0006420597.tif 000012
【図１２】
0006420597.tif 000013
【図１３】
0006420597.tif 000014
【図１４】
0006420597.tif 000015
【図１５】
0006420597.tif 000016
【図１６】
0006420597.tif 000017
【図１７】
0006420597.tif 000018
【図１８】
0006420597.tif 000019
【図１９】
0006420597.tif 000020
【図２０】
0006420597.tif 000021
【図２１】
0006420597.tif 000022