JP6420597B2 - 一覧表管理システム - Google Patents

一覧表管理システム Download PDF

Info

Publication number
JP6420597B2
JP6420597B2 JP2014173768A JP2014173768A JP6420597B2 JP 6420597 B2 JP6420597 B2 JP 6420597B2 JP 2014173768 A JP2014173768 A JP 2014173768A JP 2014173768 A JP2014173768 A JP 2014173768A JP 6420597 B2 JP6420597 B2 JP 6420597B2
Authority
JP
Japan
Prior art keywords
list
task
user
name
requestee
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2014173768A
Other languages
English (en)
Other versions
JP2016048513A (ja
Inventor
孝則 塚田
孝則 塚田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Solutions Ltd
Original Assignee
Hitachi Solutions Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Solutions Ltd filed Critical Hitachi Solutions Ltd
Priority to JP2014173768A priority Critical patent/JP6420597B2/ja
Publication of JP2016048513A publication Critical patent/JP2016048513A/ja
Application granted granted Critical
Publication of JP6420597B2 publication Critical patent/JP6420597B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Description

本発明は、組織において一覧表を管理する一覧表管理システムに関する。
企業等の組織において、Excel(登録商標)のようなスプレッドシート等で作成された一覧表を従業員間で分担して維持管理する業務がある。この業務は、主として人手で行われている。例えば、このような一覧表のマスタを管理する管理者が担当者に一覧表の格納されたファイルを電子メールに添付して送信したり、ファイルサーバにファイルを置いて場所(パス名)を電子メールで知らせたりすることにより更新を依頼するといった方法がとられる。
メールソフトによっては、タスクを依頼する電子メールを送信した場合に、そのタスクが完了したという電子メールが返信されているか否かを一覧で表示できるものもある。例えば、Microsoft Outlook(登録商標)はタスクの依頼を作成および管理する機能を有する(例えば、非特許文献1参照。)。
特許文献1と特許文献2は、電子メールから自動的にタスクの依頼と回答を抽出する技術を開示する。
また、データベースでは、データベース管理者がテーブル(表)のレコードごとに利用者のアクセス権を設定することが可能である。従って、一覧表がデータベースのテーブルに格納されている場合、テーブルのレコードごとに利用者のアクセス権を設定することによって、各利用者が担当するレコードだけを更新可能にすることができる。
特許文献3は、更新を確実に行うために、ファイル管理システムにおいて、ファイルごとに見直し時期を設定し、見直しが必要な場合は管理者(全ファイル共通)に連絡する技術を開示する。
また、一覧表には、担当部署と担当者名が含まれる場合が多い。一覧表がデータベースのテーブルの場合には、システムごとにバッチプログラムを実行して、人事異動時にデータベース中の部署名と担当者名を更新することが行われる。
また、企業では、各人のタスクの管理にグループウェアが使われることが多い。グループウェアでは、従業員間でのタスクの依頼に関して、個人ごとに依頼されたタスクを設定し、また、タスクの完了状況を入力したり、表示したりすることが可能である。グループウェアによっては、従業員間でタスクを依頼する場合に、依頼するタスクを入力し、管理できるものもある。そのようなグループウェアでは、各人が、他の従業員に依頼したタスクとその完了状況、および自分に依頼されたタスクとその完了状況を一覧で確認することができる。
特開2006−190177号公報 特開2002−7437号公報 特開2007−213171号公報
"仕事の依頼を作成および管理する"、[online]、[平成26年7月3日検索]、インターネット<URL:http://office.microsoft.com/ja-jp/outlook-help/HA001229368.aspx>
企業は多数の一覧表を保有するが、それらの維持管理には様々な困難がある。
例えば、一覧表がスプレッドシートで作成されている場合、一覧表の部署名や担当者名等を一括して更新することはできない。人事異動時には人事異動データを基にスプレッドシートの文字列置換機能を用いて一覧表を手作業で更新しなければならない。このため、一覧表中の部署名等を人事異動時に変更するには時間とコストがかかる。
また、企業において、各部署の担当者一覧表の更新では、多人数に同時に指示・依頼をする場合がある。そのような場合、依頼のメールが一通なのに対して、更新完了の返信メールは依頼先数分あり、依頼のうち、いくつが完了していないのか、誰が完了していないのかといったタスクの完了状況を把握することは難しい。
依頼メールに対する返信メールの一覧を表示できるメールソフトウェアを使う場合であっても、多種の依頼の返信メールが混じって表示されるので、各依頼の完了状況を把握することや、どの件が完了しているかを把握することは難しい。
また、取りまとめ者は、別途、スプレッドシート等を使って進捗管理表を作成し、返信メールに基づいて依頼先ごとのタスクの完了状況をその進捗管理表に手作業で入力して管理せざるを得ない。
また、企業で業務改善のために、一覧表更新に掛かった日数などを分析しようとした場合、メールではデータを手作業で入力しなくてはならず、多くの作業量を要する。
更に、一覧表に書かれている担当者が退職した場合にその一覧表の管理者が気づかず、担当者が更新されないままになる場合がある。
本発明の目的は、組織において一覧表を効率的に管理することができる一覧表管理システムを提供することである。
上記目的を達成するために、本発明の一覧表管理システムは、
利用者を識別する利用者識別情報と当該利用者のメールアドレスとを含む利用者情報を記憶する利用者情報記憶手段と、
タスクの依頼先である被依頼者に成り得る被依頼者候補の利用者識別情報と当該被依頼者が依頼されることとなるタスクに関する情報とをそれぞれ含む複数のレコードからなる一覧表データを記憶する一覧表記憶手段と、
前記利用者情報記憶手段に記憶されている利用者情報に含まれる利用者識別情報で識別された利用者によって入力された一覧表データを受け付け、当該一覧表データを前記一覧表記憶手段に登録する一覧表登録手段と、
前記利用者情報記憶手段に記憶されている利用者情報に含まれる利用者識別情報で識別された利用者である依頼者によって前記一覧表記憶手段に記憶されている複数の一覧表データの中からタスクの対象として選択された一覧表データである対象一覧表データを、前記被依頼者が依頼されることとなるタスクの対象として決定する一覧表決定手段と、
前記対象一覧表データのレコード毎に当該各レコードを更新する被依頼者を、前記一覧表決定手段によってタスクの対象として決定された前記対象一覧表データに含まれる利用者識別情報によって示される被依頼者候補の中から前記依頼者に選択させることができ、選択された当該被依頼者が前記利用者情報記憶手段に記憶されている利用者情報に含まれる利用者識別情報で識別される利用者である場合に、選択された当該被依頼者を前記対象一覧表データの各レコードについての依頼先として決定する被依頼者決定手段と、
前記利用者情報記憶手段に記憶されている利用者情報から前記被依頼者決定手段によってタスクの依頼先として決定された被依頼者のメールアドレスを取得し、取得した当該メールアドレスを宛先として前記依頼者によるタスクの依頼が記載された電子メールを送信するタスク依頼手段と、
前記タスク依頼手段によって送信された電子メールを受信した被依頼者に、前記対象一覧表データの中から、前記被依頼者決定手段によって各前記被依頼者が依頼先として決定されたレコードのみを提示し、提示された当該レコードのみを各前記被依頼者が前記電子メールに記載されたタスクの依頼に従って更新することを可能とするタスク実現手段と、
を備えることを特徴とする。
好ましくは、本発明の一覧表管理システムは、
前記一覧表データが、スプレッドシートとして作成されていることを特徴とする。
好ましくは、本発明の一覧表管理システムは、
前記一覧表登録手段によって登録された一覧表データを入力した利用者に、前記対象一覧表データについてのタスクの進捗を提示する進捗管理者提示手段と、
前記被依頼者に、前記対象一覧表データについてのタスクの進捗を提示する進捗被依頼者提示手段と、
前記依頼者に、前記対象一覧表データについてのタスクの進捗を提示する進捗依頼者提示手段と、
を含む進捗管理手段を備えることを特徴とする。
好ましくは、本発明の一覧表管理システムは、
前記進捗管理手段が、前記依頼者によって設定されたタイミングで、前記タスクが未完了の被依頼者に催促の電子メールを送信する催促手段を含むことを特徴とする。
好ましくは、本発明の一覧表管理システムは、
前記利用者識別情報が、利用者名と部署名とを含み、
部署名変更および/または人事異動を示すデータに基づいて、前記一覧表記憶手段に記憶されている一覧表データに含まれる利用者識別情報の部署名および/または利用者名を更新し、前記利用者情報記憶手段に記憶されている利用者情報から前記一覧表登録手段によって登録された一覧表データを入力した利用者のメールアドレスを取得し、取得した当該メールアドレスを宛先として、前記更新された部署名および/または利用者名を確認するタスクの依頼が記載された電子メールを送信する部署名・利用者名更新手段を備え、
前記被依頼者決定手段において、前記部署名・利用者名更新手段によって送信された電子メールを受け取った前記依頼者によって前記被依頼者が選択され、
前記タスク実現手段によって実行可能とされるタスクは、前記被依頼者決定手段によって決定された被依頼者が前記対象一覧表データに含まれる利用者識別情報の部署名および/または利用者名を確認および/または更新することである、
ことを特徴とする。
好ましくは、本発明の一覧表管理システムは、
前記タスク実現手段によって実行可能とされるタスクは、前記被依頼者決定手段によって決定された被依頼者が、当該タスクの対象である前記対象一覧表データに関連する文書ファイルを取得すること、および/または当該対象一覧表データに関連する文書ファイルを提出することであることを特徴とする。
本発明によれば、組織において一覧表を効率的に管理することができる。
一覧表管理サーバ利用システムの構成の一例を示す図である。 利用者テーブルの構成の一例を示す図である。 一覧表の例を示す図である。図3(A)は製品一覧の例を示す図である。図3(B)は○○会議参加者一覧の例を示す図である。 一覧表テーブルの一例を示す図である。 タスクテーブルの一例を示す図である。 レコード毎タスクテーブルの一例を示す図である。 部署名変更テーブルの一例を示す図である。 異動テーブルの一例を示す図である。 一覧表を一覧表ストレージに登録する一覧表登録処理の流れの一例を示す図である。 利用者画面の一例を示す図である。 利用者画面の中の一覧表一覧の一例を示す図である。 一覧表についてのタスクを依頼するタスク依頼処理の流れの一例を示す図である。 部署名・担当者指定画面の一例を示す図である。 依頼画面の一例を示す図である。 利用者画面の中の依頼されているタスク一覧の一例を示す図である。 利用者画面の中の自分がレコードの担当者になっている一覧表一覧の一例を示す図である。 タスク実行画面の一例を示す図である。 利用者画面の中の依頼しているタスク一覧の一例を示す図である。 被依頼者毎進捗表示画面の一例を示す図である。 レコード毎進捗表示画面の一例を示す図である。 部署名変更テーブルおよび/または異動テーブルが更新されたときの部署名変更・異動処理の流れの一例を示す図である。
以下、本発明の実施形態に係る一覧表管理システムについて図面を参照しながら説明する。なお、実施形態を説明する全図において、共通の構成要素には同一の符号を付し、繰り返しの説明を省略する。
図1は、一覧表管理サーバ利用システムの構成の一例を示す。
一覧表管理サーバ利用システムは、一覧表管理サーバ100と、複数の利用者端末140と、システム管理者端末150と、メールサーバ160と、利用者認証システム170とで構成される。一覧表管理サーバ100と、複数の利用者端末140と、システム管理者端末150と、メールサーバ160と、利用者認証システム170は、ネットワーク180に接続されており、相互に通信することができる。
利用者端末140は、メールクライアント141と、ブラウザ142とを有する。一覧表管理サーバ100は、Webサーバの機能を有しており、ブラウザ142に各種の画面を表示させ、ブラウザ142に入力された操作を受け付けることができる。また、メールクライアント141と一覧表管理サーバ100は、メールサーバ160を介してメールを送受信することができる。
システム管理者端末150はデータベースクライアント151を有する。一覧表管理サーバ利用システムにはシステム管理者がいる。システム管理者は各DBをデータベースクライアント151を利用して更新する。
一覧表管理サーバ100と利用者端末140は、シングルサインオン技術を導入している。シングルサインオン技術により、利用者は、一覧表管理サーバ100の利用に先立って利用者端末140にログインするとき、利用者認証システム170で識別認証を受けることができる。一覧表管理サーバ100は、利用者認証システム170から利用者を識別・認証した結果を入手し、利用者を識別する。
一覧表管理サーバ100は、本発明の一覧表管理システムの一例である。一覧表管理サーバ100は、CPU(Central Processing Unit)と、RAM(Random Access Memory)等で構成される主メモリと、ハードディスク等で構成される記憶装置と、一覧表ストレージ110と、タスクDB(データベース)120と、部署名・利用者名DB130とを備えている。一覧表ストレージ110と、タスクDB120と、部署名・利用者名DB130とは、それぞれ独立した装置であってもよいし、記憶装置に格納されていてもよい。
一覧表管理サーバ100の記憶装置には、一覧表管理プログラムが格納されており、一覧表管理サーバ100のCPUが記憶装置から一覧表管理プログラムを主メモリに読み出して実行することにより、認証部101と、一覧表登録部102と、一覧表決定部103と、被依頼者決定部104と、タスク依頼部105と、タスク実現部106と、進捗管理部107と、部署名・担当者名更新部108との各部の機能が実現される。
一覧表ストレージ110には、一覧表データである一覧表300が格納される。一覧表300は、それを一覧表ストレージ110に登録した利用者が維持・更新の責任を持つ。すなわち、一覧表300を登録した利用者がその管理者となる。利用者端末140を利用する利用者は、一覧表300を対象とするタスクを依頼する依頼者と、タスクを依頼される被依頼者の両者となることができる。ある一覧表300を対象とするタスクの依頼者が、別の一覧表300を対象とするタスクの被依頼者であるという場合もあり得る。なお、タスクには、例えば一覧表の更新、一覧表に関連する文書の配布や提出等がある。
タスクDB120には、一覧表テーブル400と、タスクテーブル500と、レコード毎タスクテーブル600とが格納される。一覧表テーブル400は、一覧表ストレージ110に格納されている一覧表300のリストである。タスクテーブル500には、一覧表ストレージ110に格納されている一覧表300に対するタスクの依頼が格納されている。タスクテーブル500には、タスクが完了したものも未完了のものも格納されている。レコード毎タスクテーブル600には、一覧表300中のレコード毎のタスクについての情報が格納されている。レコード毎タスクテーブル600には、タスクが完了したものも未完了のものも格納されている。
部署名・利用者名DB130には、部署名変更テーブル700と、異動テーブル800と、利用者テーブル200とが格納される。部署名変更テーブル700には、一覧表ストレージ110に格納されている一覧表300中に出てくる全部署名についての部署名変更の履歴が格納されている。部署名変更テーブル700には過去のものも予定のものも格納されている。異動テーブル800には、一覧表300中に出てくる全利用者名についての異動の履歴が格納されている。異動テーブル800には、過去のものも予定のものも格納されている。利用者テーブル200は、一覧表管理サーバ100を利用する全利用者についての情報が格納されている。利用者テーブル200は利用者認証システム170の中に導入することもできる。
図2は、利用者テーブル200の構成の一例を示す。
利用者テーブル200は、例えば、利用者ID(Identifier)201と、部署名202と、利用者名203と、メールアドレス204と、利用者状態205とを含む利用者情報を格納する。利用者テーブル200には、一覧表管理サーバ100の利用者一人ひとりが登録される。
利用者ID201は、利用者を一意に示す情報である。部署名202は、利用者が所属する部署を示す。利用者名203は、利用者の氏名を示す。なお、部署名202と利用者名203とは、本発明の利用者識別情報の一例である。メールアドレス204は、利用者に対して電子メールで連絡する際に宛先とするメールアドレスを示す。
利用者状態205は、例えば、利用者が責任者、退職者、およびそれら以外の者のいずれであるかを示す。退職者は一覧表管理サーバ100を利用できず、退職者の認証は失敗とされる。責任者の役割については次の図3を参照して説明する。
図3は、一覧表300の例を示す。図3(A)は製品一覧301の例を示す。図3(B)は○○会議参加者一覧311の例を示す。
列は、一覧表300毎に異なる。図3(A)の製品一覧301の例は、製品ID302と、製品名303と、担当部署304と、担当者名305と、…(他の列)からなるレコード306で構成される。また、図3(B)の○○会議参加者一覧311の例は、参加者ID312と、部署313と、参加者名314と、出欠315とからなるレコード306で構成される。
ここで、利用者情報に含まれる部署名202と利用者名203は、どの一覧表300でも必要である。ただし、異なる一覧表300において部署名202と利用者名203とはそれぞれ異なる名称と名前であってもよい。各一覧表300の列のうち、どの列が部署名202と利用者名203にそれぞれ該当するかは各一覧表300の管理者(各一覧表300を一覧表ストレージ110に登録した者)が指定する。
例えば、図3(A)において担当部署304が部署名202である。担当部署304は、レコード306を維持する部署を示す。また、担当者名305が利用者名203である。担当者名305は、レコード308の更新が依頼される担当者(被依頼者)を示す。担当者は、部署名304の部署に所属する。担当者名305が未定義の場合は、部署名304の部署の責任者にレコード306の更新が依頼される。すなわち、図2の利用者状態205に責任者と記載されている利用者に、レコード306の更新が依頼される。図3(A)の例は、レコード306あたりの担当者名305が一つの場合を示すが、担当者名305を複数設定することも可能である。
製品一覧301を対象とするタスクの例としては、製品名303、担当部署304、または担当者名305の変更がある。
また、○○会議参加者一覧311を対象とするタスクの例としては、出欠315の記入、会議参加者(被依頼者)が○○会議参加者一覧311に関連する文書ファイル(会議資料や議事録)を取得すること、会議参加者が文書ファイル(会議資料や議事録のレビュー)を提出することがある。
○○会議参加者一覧311の管理者と会議参加者との間の資料のやり取りは、例えば、文書ファイルを添付することにより行われる。文書ファイルを添付するために、一覧表ストレージ110に各一覧表300に対応するフォルダ(以下、保管フォルダという。)が設けられる。そして、ファイルの添付はその保管フォルダを介して行われる。
後述するように、例えば、会議参加者に議事録を配布する場合、○○会議参加者一覧311の管理者は、図14の依頼画面1400でファイル添付ボタン1408を押すことにより、議事録を添付する。このとき、議事録は保管フォルダに保存される。会議参加者は、担当者(被依頼者)として、図17のタスク実行画面1700でレコード1709を選択して添付ファイルボタン1710を押すことにより、議事録を参照することができる。また、例えば、会議参加者が担当者(被依頼者)として議事録のレビュー等を提出する場合、会議参加者は図17のタスク実行画面1700でレコード1709を選択してファイル添付ボタン1711を押すことにより、議事録のレビューを添付する。このとき、議事録のレビューは保管フォルダに保存される。管理者は図20のレコード毎進捗表示画面2000でレコード2008を選択して添付ファイルボタン2009を押すことにより、議事録のレビューを参照したり、それを取り出して利用者端末140の記憶装置に保存したりすることができる。
図4は、一覧表テーブル400の一例を示す。
一覧表テーブル400は、一覧表管理サーバ100を利用する会社等の組織ごとに一つである。
一覧表テーブル400は、例えば、一覧表ID401と、一覧表名402と、管理者名403と、登録日時404と、部署名範囲405と、利用者範囲406と、部署との関係407とで構成される。
一覧表ID401は、その一覧表を一意に示す情報である。
一覧表名402は一覧表ストレージ110に格納されている一覧表300の名称を示す。なお、登録される一覧表300には、その名前(ファイル名)が同じものが複数ある場合もある。同じファイル名の一覧表が登録できるように、一覧表300を一覧表ストレージ110中のフォルダに格納し、一覧表名の登録時に一覧表名402としてそのフォルダ名も含めてフォルダ名+ファイル名を指定することもできる。
管理者名403は、一覧表300の管理者(すなわち、その一覧表300を一覧表ストレージ110に登録した者)を示す情報である。管理者名403は、利用者テーブル200の利用者ID201、利用者名203、またはメールアドレス204に対応する。管理者は、一覧表300の更新を被依頼者に依頼する。
登録日時404は、管理者が一覧表300を一覧表ストレージ110に登録した日時である。
部署名範囲405は、一覧表300中の部署名が指定されている列名および行番号を示す。
利用者範囲406は、一覧表300中の利用者が指定されている列名および行番号を示す。
部署との関係407は、1対1と1対nがあり、部署が分割、合併、または廃止されたときの一覧表300の更新方法を示す。ここで、1対1は、1部署1レコードの場合である。部署が分割された場合、増えた部署数分だけ、レコードを追加する必要、および、担当者を設定する必要がある。部署が合併または廃止された場合は、減った部署数分だけレコードを削除する必要がある。1対nは、部署ごとに、複数レコード(0件以上)がある場合である。部署が分割された場合、既存のレコードをいずれかの部署に振り分ける必要がある。
図5は、タスクテーブル500の一例を示す。
タスクテーブル500は、例えば、タスクNo501と、一覧表ID502と、一覧表名503と、依頼者名504と、タスク種別505と、開始日時506と、期限日時507と、催促日時508と、件名509と、依頼文510と、保存フォルダのパス511と、状態512とで構成される。
タスクテーブル500に行が追加される場合には、例えば、一覧表名503が示す一覧表300が図3(A)の製品一覧301であるときに、管理者から新たな依頼があった場合、製品一覧301中の担当者が担当部署304または担当者名305の変更を申し出る場合、製品一覧301中の担当部署304について部署名変更テーブル700に新たな部署名変更が登録された場合、および、製品一覧301中の担当者名305について異動テーブル800に新たな異動が登録された場合などがある。
タスクNo501は、タスク毎に一意に付与される番号である。一覧表ID502は、一覧表300を一意に示す情報である。一覧表名503は、一覧表300の名前である。
依頼者名504は、タスク種別505によって異なる。タスク種別505には、依頼、申し出、部署名変更、異動がある。一覧表300の管理者が依頼をする場合は、依頼となり、レコード306の担当者が申し出る場合は、申し出となり、部署名変更があった場合は、部署名変更となり、担当者の異動が合った場合は、異動となる。
開始日時506は、依頼があった日時を示す。期限日時507は、被依頼者が更新を完了すべき日時を示す。催促日時508は、進捗管理部107が催促する予定の日時を示す。
件名509と依頼文510は、後述するように、依頼者が入力した件名と依頼文である。
保存フォルダのパス511は、依頼者によって被依頼者に配布される文書、被依頼者によって提出される文書等が保存されるフォルダへのパスを示す。図14と図17を参照して後述するように、依頼画面1400のファイル添付ボタン1408が依頼者によって押されるとき、およびタスク実行画面1700のファイル添付ボタン1711が被依頼者によって押されるとき、タスク依頼部105は保存フォルダを一覧表ストレージ110内に確保し、保存フォルダのパス511にその保存フォルダへのパスを設定する。
状態512は、依頼した各タスクでの総レコード件数とそのうち更新が完了したレコード件数を示す。例えば、タスクNo501=1の総依頼レコード件数が100件であり、そのうち50件のレコードの更新が完了しているとき、「100件中50件完了」となる。
図6は、レコード毎タスクテーブル600の一例を示す。
レコード毎タスクテーブル600は、タスクNo601と、利用者ID602と、レコード番号603と、タスク状態604と、レコード中の更新箇所605と、最終更新日時606と、更新前レコード607と、更新後レコード608とで構成される。
タスクテーブル500に行が追加されると、タスクテーブル500の一覧表名503が示す一覧表300のレコード306のうち該当するものに対してレコード毎タスクテーブル600に行が1行ずつ追加される。
タスクNo601は、タスク毎に一意に付与される番号である。タスクNo601は、対応するタスクテーブル500のタスクNo501を示す。
利用者ID602は、タスクの依頼が送られる被依頼者の利用者IDを示す。利用者ID602は、利用者テーブル200の利用者ID201に対応する。
レコード番号603は、タスクが依頼されているレコード306を示す。
タスク状態604は、レコード306に対する依頼の進捗状況を示す。例えば、被依頼者がタスクを実行する前は未、タスクを完了すれば完となる。更に細かな区分もできる。
レコード中の更新箇所605と、最終更新日時606と、更新前レコード607と、更新後レコード608はレコード306を更新するタスクである場合に有効となる。また、タスクの内容が被依頼者による文書の取得や提出である場合には、レコード中の更新箇所605は、参照または添付された添付ファイルへのパス、最終更新日時606は参照または添付の日時、更新前レコード607は参照された添付ファイル、更新後レコード608は添付された添付ファイルになる。
レコード中の更新箇所605は、レコード306中で、更新された箇所を示す。更新箇所は複数の場合もある。最終更新日時606は、レコード306に対する当該タスクNo601のタスクに対する更新による最終更新の日時である。当該タスクNo601に対しての更新がまだされていない場合は未定義である。更新前レコード607は、被依頼者によって更新される前のレコード306のデータである。更新後レコード608は、被依頼者によって更新された後のレコード306のデータである。被依頼者がレコード306を更新する前は未定義である。
例えば、製品一覧301(一覧表300)の複数のレコード306の担当者名305が同じ場合はその担当者が複数のレコード306の更新を依頼される場合がある。その場合、利用者ID602が同じでも更新すべきレコード306ごとにレコード番号603が異なる行が追加される。
また、同じレコード306に対して複数の更新依頼がある場合がある。そのような場合は被依頼者決定部104が検知して、依頼者および被依頼者にその旨を伝える。しかし、更新が可能な被依頼者は、レコード毎タスクテーブル600の構造によって一人に限られるので、2人が同時に更新をして片方の更新が失われるといった不都合を防ぐことができる。複数の更新依頼があるレコード306を被依頼者が更新をした場合は、そのレコード306に対する最終更新日時606は当該更新依頼タスクで同じ日時になる。
図7は、部署名変更テーブル700の一例を示す。
部署名変更テーブル700は、部署名変更No701と、変更日時702と、旧部署名703と、新部署名704と、部署名変更区分705とで構成される。
部署名変更No701は、行毎に一意に付与される番号である。変更日時702は、部署名を変更する日時を示す。旧部署名703は、変更前の部署名を示す。新部署名704は、変更後の部署名を示す。
部署名変更区分705は、部署名の変更の種類を示し、変更、新設、廃止、分割、統合などがある。変更は、1部署の名称が変更される場合を示し、部署名変更テーブル700には1行追加される。追加は、1部署が追加される場合を示し、旧部署名703は未定義である。廃止は、1部署が廃止される場合を示し、部署名変更テーブル700には1行追加され、新部署名704は未定義である。分割は、1部署が複数部署に分割される場合を示し、部署名変更テーブル700には分割後の部署数分の行数追加される。統合は、複数部署が1部署に統合される場合を示し、部署名変更テーブル700には分割前の部署数分の行数が追加される。一覧表管理サーバ100の利用開始時点では、部署名変更区分705は、追加で登録されている。
部署名・担当者名更新部108は、部署名変更テーブル700に行が追加された場合、それに合わせて利用者テーブル200を更新する。さらに、タスク依頼部105は、部署名の変更に関係する一覧表300についてタスクテーブル500に一行追加する。
図8は、異動テーブル800の一例を示す。
異動テーブル800は、異動No801と、異動日時802と、異動者名803と、異動前部署名804と、異動後部署名805と、異動区分806とで構成される。異動テーブル800には、利用者一人の一回の異動ごとに1行追加される。
異動No801は、行毎に一意に付与される番号である。異動日時802は、異動の日時を示す。異動者名803は、異動する利用者を示す。異動前部署名804は、異動前の部署名を示す。異動後部署名805は、異動後の部署名を示す。
異動区分806は、異動の種類を示し、登録、異動、退職などがある。登録は、利用者が新たに一覧表管理サーバ100を使い始めることを示す。異動は、利用者の所属部署名が変更されることを示す。退職は、異動者名803が担当者名305や参加者名314として一覧表300中に指定されている場合に更新が必要であるということ、異動日時802までに別の者に更新する必要があること、およびその異動者が異動日時802以降に一覧表管理サーバ100を使用できないようにすることを示す。
部署名・担当者名更新部108は、異動テーブル800に行が追加された場合、それに合わせて利用者テーブル200を更新する。さらに、異動区分806が異動または退職である行が追加された場合、タスク依頼部105は、異動者に関係する一覧表300についてタスクテーブル500に一行追加する。
以下、一覧表管理サーバ100の各部の機能について説明する。
一覧表管理サーバ100の全ての利用者は、予め利用者テーブル200に登録されている。また、予め、各一覧表300の管理者は、利用者端末140でExcel(登録商標)等のスプレッドシートを使って一覧表300を作成し、または作成済みの一覧表300を取得し、利用者端末140の記憶装置に保存する。一覧表300の作成または取得、および保存は、一覧表管理サーバ100の外での処理である。一覧表300は、例えば利用者端末140の記憶装置に確保されたフォルダに保存される。一覧表300中にはレコード306の維持をすべき利用者の部署名と利用者名が書かれている。
図9は、一覧表300を一覧表ストレージ110に登録する一覧表登録処理の流れの一例を示す。
[認証部101の処理、利用者識別・認証ステップ(S901)]
利用者は、一覧表管理サーバ100にアクセスする前に利用者認証システム170で識別・認証を受ける。利用者が一覧表管理サーバ100にアクセスするときには、利用者ID201と利用者名203は識別・認証済みである。
利用者端末140から一覧表管理サーバ100へのアクセスがあると、認証部101は、利用者認証システム170に利用者の識別・認証状況を問い合わせ、応答を得ることで、利用者が利用者テーブル200中のどの利用者かを識別する。そのとき、利用者状態205が退職者であった場合、利用者識別・認証処理は失敗として、認証部101は利用者端末140にエラーメッセージを返す。
[一覧表登録部102の処理、一覧表登録ステップ(S902)]
一覧表登録部102は、利用者テーブル200に記憶されている利用者情報に含まれる部署名202と利用者名203(利用者識別情報)で識別された利用者によって入力された一覧表300を受け付け、その一覧表300を一覧表ストレージ110に登録する。
具体的には、認証部101によって利用者が識別・認証されると、一覧表登録部102は、利用者端末140のブラウザ142に図10の利用者画面1000を表示する。
利用者画面1000は、一覧表一覧1001と、依頼しているタスク一覧1002と、依頼されているタスク一覧1003と、自分がレコードの担当者になっている一覧表一覧1004とを含む。
図11に示すように、一覧表一覧1001は、一覧表ID1201と、一覧表名1202と、管理者名1203と、未完了タスク1204と、完了タスク1205と、一覧表出力ボタン1206とで構成される。
一覧表登録部102は、利用者端末140の記憶装置内のフォルダに保存されている一覧表300をブラウザ142内のフォルダ画面1207に表示する。利用者は、ブラウザ142においてフォルダ画面1207中の一覧表300のアイコンを利用者画面1000中の一覧表一覧1001のエリアにドラッグアンドドロップすることによって、一覧表300を一覧表管理サーバ100に入力(送信)することができる。
一覧表登録部102は、入力された一覧表300を受け付け、その一覧表300を一覧表ストレージ110に登録する。そして、一覧表登録部102は、一覧表テーブル400に新たな行を追加し、一覧表ID401を付与して一覧表名402を登録する。ここで、一覧表登録部102は、管理者名403には先に識別・認証されている利用者の利用者名203を登録する。さらに、一覧表一覧1001に一覧表ID1201と一覧表名1202と管理者名1203を追加で表示する。ここで、一覧表登録部102は一覧表300の列名またはデータを基に部署範囲405と利用者範囲406を自動的に判断する。一覧表登録部102は、この判断のために、部署名変更テーブル700および異動テーブル800の登録内容を利用することもできる。
未完了タスク1204と完了タスク1205は、一覧表300について管理者が依頼したタスクのうちそれぞれ完了していないものと完了しているものの数を示す。進捗管理部107は、所定のタイミングで未完了タスク1204と完了タスク1205を計算し、一覧表一覧1001に表示する。
なお、一覧表一覧1001は本発明の進捗管理者提示手段の一例である。
図12は、一覧表300についてのタスクを依頼するタスク依頼処理の流れの一例を示す。
タスクの依頼に先だって、依頼者(利用者)は、認証部101によって利用者テーブル200中のどの利用者かの識別を受ける(S1201)。ステップS1201における認証部101の処理は、上述したステップS901と同様である。
[一覧表決定部103の処理、一覧表決定ステップ(S1202)]
一覧表決定部103は、利用者テーブル200に記憶されている利用者情報に含まれる部署名202と利用者名203(利用者識別情報)で識別された利用者(以下、依頼者という。)によって一覧表ストレージ110に記憶されている一覧表300の中から選択された一覧表300をタスクの対象として決定する。
例えば、タスク種別505が依頼の場合、依頼者はブラウザ142内に表示されている一覧表一覧1001の行をマウス等で選択することによってタスクの対象である一覧表300を選択する。一覧表決定部103は、依頼者によって選択された一覧表300をタスクの対象として決定する。
また、ブラウザ142内に表示される自分がレコードの担当者になっている一覧表一覧1004については後で図16を参照して詳細に説明するが、自分がレコードの担当者になっている一覧表一覧1004には利用者がレコードの担当者になっている一覧表300が表示される。例えば、タスク種別505が申し出の場合、依頼者は自分がレコードの担当者になっている一覧表一覧1004の中からタスクの対象である一覧表300を選択する。一覧表決定部103は、依頼者によって選択された一覧表300をタスクの対象として決定する。
[被依頼者決定部104の処理、被依頼者決定ステップ(S1203)]
被依頼者決定部104は、一覧表決定部103によってタスクの対象として決定された一覧表300に含まれる部署名202と利用者名203(利用者識別情報)によって示される被依頼者候補の中から依頼者によって選択された被依頼者が、利用者テーブル200に記憶されている利用者情報に含まれる部署名202と利用者名203(利用者識別情報)で識別される利用者である場合に、その被依頼者を一覧表300についてのタスクの依頼先として決定する。
具体的には、被依頼者決定部104は、一覧表決定部103によってタスクの対象である一覧表300が決定されると、その一覧表300を基にブラウザ142内に図13に示す部署名・担当者指定画面1300を表示する。部署名・担当者指定画面1300は、少なくとも一覧表名1301と、部署名1302と、部署名範囲枠1303と、利用者名1304と、利用者名範囲枠1305と、確認メッセージ1306と、完了ボタン1307と、キャンセルボタン1308とを含む。
被依頼者決定部104は、一覧表テーブル400の部署範囲405と利用者範囲406を基に部署名範囲枠1303と利用者範囲枠1304を表示し、更新を促す確認メッセージ1306を表示する。被依頼者決定部104は、さらに、一覧表300中の各レコード306の担当部署304と担当者名305の組合せが利用者テーブル200中の部署名202と利用者名203にあるかを確認する。もし、マッチしない組合せがあれば、被依頼者決定部104はエラーメッセージを表示する。なお、被依頼者決定部104は、部署名1302または利用者名1304が未定義の場合もマッチしないものとして処理する。ここで、依頼者が一覧表300の管理者(すなわち、一覧表300を一覧表ストレージ110に登録した利用者)である場合には、一覧表300の部署名または利用者名を修正し、修正した一覧表300の結果を用いて再度マッチを確認することもできる。管理者が修正する際には利用者テーブル200にある部署名202および利用者名203から選択させることもできる。
依頼者によって完了ボタン1307が押されると、被依頼者決定部104は、部署名範囲枠1303の中の部署名1302と利用者名範囲枠1305の中の利用者名1304とに基づいて、一覧表300についてのタスクの依頼先である被依頼者を決定する。
なお、例えば、図3(A)の製品一覧301の担当者名305や図3(B)の○○会議参加者一覧311の参加者名314のように、利用者名は一覧表300のレコード306毎に指定されている。このため、被依頼者決定部104は、部署名・担当者指定画面1300上で一覧表300のレコード306毎にそのレコードを更新する被依頼者を依頼者に選択させることができ、選択された被依頼者を一覧表300の各レコード306についての依頼先として決定する。そして、後述するように、タスク実現部106は、図17のタスク実行画面1700において、被依頼者決定部104によって各被依頼者が依頼先として決定されたレコードのみを提示し、提示されたレコードのみを各被依頼者が更新することを可能とする。
[タスク依頼部105の処理、タスク依頼ステップ(S1204)]
タスク依頼部105は、利用者テーブル200に登録されている利用者情報から被依頼者決定部104によって決定された被依頼者のメールアドレス204を取得し、取得したメールアドレスを宛先として依頼者によるタスクの依頼が記載された電子メールを送信する。
具体的には、被依頼者決定部104によって被依頼者が決定されると、タスク依頼部105は、依頼者の利用者端末140のブラウザ142に、図14に示す依頼画面1400を表示する。依頼者は依頼画面1400上で一覧表300についてのタスクの内容を入力する。
依頼画面1400は、一覧表ID1401と、一覧表名1402と、被依頼者名1403と、期限日時1404と、催促日時1405と、件名1406、依頼文1407と、ファイル添付ボタン1408と、依頼ボタン1409と、後で依頼ボタン1410と、キャンセルボタン1411とで構成される。
期限日時1404は、タスクが完了されるべき期限を示す。催促日時1405は、進捗管理部107が催促メールを送信する日時を示す。期限日時1404と催促日時1405は、依頼者が入力する。
件名1406と依頼文1407は、タスクについて依頼先に伝えるべき件名と依頼文である。件名1406と依頼文1407は、依頼者が入力する。
ファイル添付ボタン1408が依頼者によって押されると、タスク依頼部105は保存フォルダを一覧表ストレージ110内に確保し、その保存フォルダに文書ファイルを保存するための画面をブラウザ142に開く。依頼者は、その画面に文書ファイルをドラッグアンドドロップすることによって文書ファイルを保存フォルダに保存することができる。
依頼者が依頼画面1400で各項目を設定し、依頼ボタン1409を押すと、タスク依頼部105は、タスクテーブル500に新しい行を追加し、上記各項目の内容を登録する。同時に、タスク依頼部105は、レコード毎タスクテーブル600に、一覧表300の各レコード306に対応する行を追加する。このとき、タスク依頼部105は、催促日時508をオペレーティングシステムのイベント管理機能に登録する。これにより、催促日時になったら、一覧表管理サーバ100にイベントが通知され、それによってタスクを実行していない被依頼者への催促が可能になる。
次に、タスク依頼部105は、利用者テーブル200を検索して各被依頼者に対応するメールアドレス204を取得する。そして、タスク依頼部105は、タスクテーブル500に登録された内容に基づいて取得したメールアドレス204を宛先とする電子メールを作成し、メールサーバ160経由で被依頼者に送信する。
なお、上述した図13では部署名・担当者名指定画面1300に部署名範囲枠1303と利用者範囲枠1304とがそれぞれ1つずつ表示されている例を示したが、1つの一覧表300について部署名範囲枠1303と利用者範囲枠1304をそれぞれ複数設定することもできる。これにより、一覧表300中の一部のレコード306または、多数の担当者うち、一部だけを指定してタスクを依頼することも可能である。また、本実施形態では、レコード306ごとの担当者名305や参加者314が一人の場合を説明しているが、担当者名305や参加者314が複数設定されている場合は、レコード306の代表の担当者や参加者だけに送る、または全担当者や全参加者に送るといった選択を可能にすることもできる。
[タスク実現部106の処理]
タスク実現部106は、タスク依頼部105によって送信された電子メールを受信した被依頼者が、一覧表決定部103によってタスクの対象として決定された一覧表300を対象として、その電子メールに記載されたタスクの依頼に従ってタスクを実行することを可能とする。
タスク実現部106は、タスク確認処理とタスク実行処理を実行する。ただし、タスク確認処理とタスク実行処理の実行に先だって、被依頼者(利用者)は、認証部101によって利用者テーブル200中のどの利用者かの識別を受ける(S1205)。ステップS1205における認証部101の処理は、上述したステップS901と同様である。
[タスク確認ステップ(S1206)]
被依頼者が使用している利用者端末140のブラウザ142に利用者画面1000が表示されるとき、タスク実現部106は、被依頼者の利用者名203に対応した利用者ID201をレコード毎タスクテーブル600中で検索し、利用者画面1000中に、図15の依頼されているタスク一覧1003と図16の自分がレコードの担当者になっている一覧表一覧1004とを表示する。
タスク実現部106は、依頼されているタスク一覧1003に被依頼者に依頼されているタスクを表示する。また、タスク実現部106は、自分がレコードの担当者になっている一覧表一覧1004に被依頼者が担当者になっているレコードを含む一覧表を表示する。依頼されているタスク一覧1003または自分がレコードの担当者になっている一覧表一覧1004を見ることにより、被依頼者は自分に依頼されているタスクを知ることができる。
図15に示すように、依頼されているタスク一覧1003は、タスクNo1501と、依頼者名1502と、一覧表名1503と、開始日時1504と、期限日時1505と、件名1506と、依頼文1507と、依頼があったレコード数1508と、更新していないレコード数1509と、他の依頼先も含めた完了状況1510とで構成される。
依頼があったレコード数1508と更新していないレコード数1509は、一覧表名1503の一覧表300を対象とするタスクNo1501のタスクにおいて、被依頼者の担当になっているレコード数とそのうち未完了のレコード数である。
依頼されているタスク一覧1003において、被依頼者がタスクを実行したい一覧表名1503を含む行を選択すると、タスク実現部106は、一覧表ストレージ110中の一覧表300から被依頼者の担当するタスクが未完了のレコード306を選択し、ブラウザ142に図17のタスク実行画面1700を表示する。なお、表示するレコード306を選択する条件を指定することによって、タスク実行画面1700にタスクが完了のものだけを表示したり、タスクが未完了と完了のものの両方を表示したりすることもできる。
また、図16に示すように、自分がレコードの担当者になっている一覧表一覧1004は、一覧表ID1601と、一覧表名1602と、管理者名1603と、担当レコード数1604、未完了タスク1605と、完了タスク1606とで構成される。
一覧表300についてタスクの依頼がないときでも、利用者としては、例えば、作業計画を立てるに当たって、自分がどのような担当になっているのか、今後、どのような依頼に対応する必要があるのかを確認したい場合がある。そのような場合に、利用者は、自分がレコードの担当者になっている一覧表一覧1004を参照する。自分がレコードの担当者になっている一覧表一覧1004には、利用者に対して依頼されているタスク(利用者が被依頼者になっているタスク)がない一覧表300も含めて、一覧表テーブル400中の一覧表300のうち、利用者がレコードの担当者になっている一覧表300が表示される。
ここで、担当レコード数1604は、各行に表示されている一覧表300について自分が担当者になっているレコードの件数を示す。
未完了タスク1605は、各行に表示されている一覧表300について自分に依頼されているタスクのうち、完了していないタスクの件数を示す。完了タスク1606は、各行に表示されている一覧表300について自分に依頼されているタスクのうち、既に完了したタスクの件数を示す。未完了タスク1605と完了タスク1606の両方とも0件であることはその一覧表300についてタスクが依頼されていない(自分が被依頼者になっていない)ことを意味する。
このため、自分がレコードの担当者になっている一覧表一覧1004の一覧表名1602を参照することによって各被依頼者は自分が何の担当者になっているのかを把握することができる。自分がレコードの担当者になっている一覧表一覧1004において、被依頼者がタスクを実行したい一覧表名1602を含む行を選択し、例えばその時表示されるプルダウンメニューからタスク実行を選択すると、上記と同様に、タスク実現部106は、一覧表ストレージ110中の一覧表300から被依頼者の担当するタスクが未完了のレコード306を選択し、ブラウザ142に図17のタスク実行画面1700を表示する。なお、表示するレコード306を選択する条件を指定することによって、タスク実行画面1700にタスクが完了のものだけを表示したり、タスクが未完了と完了のものの両方を表示したりすることもできる。
また、タスク種別505が申し出であるタスクを依頼する場合、利用者(依頼者)がタスクを依頼したい一覧表名1602を含む行を選択し、例えばその時表示されるプルダウンメニューからタスク申し出を選択すると、一覧表決定部103は、その利用者によって選択された一覧表300をタスクの対象として決定する。
なお、依頼されているタスク一覧1003と自分がレコードの担当者になっている一覧表一覧1004とは、本発明の進捗被依頼者提示手段の例である。
[タスク実行ステップ(S1207)]
タスク実行画面1700は、タスクNo1701と、依頼者名1702と、期限日時1703と、担当レコード数1704と、依頼文1705と、一覧表名1706と、部署名1707および担当者名(利用者名)1708を含む一つ以上のレコード1709と、添付ファイルボタン1710と、ファイル添付ボタン1711と、完了ボタン1712と、後で続けるボタン1713と、キャンセルボタン1714とで構成される。
タスク実現部106は、タスク実行画面1700に、被依頼者決定部104によって各被依頼者が更新すると決定されたレコードのみを表示する。被依頼者はタスク実行画面1700でタスクの対象である一覧表300の一覧表名1706とレコード1709を確認し、レコード1709を編集する。タスク実現部106は、被依頼者の編集に従って、一覧表ストレージ110に格納されている一覧表300のレコード306を更新する。例えば、担当者が「佐藤○○」から「渡辺△△」に変わっている場合、被依頼者は担当者名1708を「渡辺△△」に変更する。これに従って、タスク実現部106は一覧表300のレコード306の担当者名305を「渡辺△△」に更新する。
タスク実現部106はスプレッドシートで作成された一覧表300の編集機能を有しており、被依頼者の利用者端末140がスプレッドシートソフトウェアを持っていない場合でも、タスク実現部106はタスク実行画面1700における入力に従ってスプレッドシートで作成された一覧表300を更新することができる。
添付ファイルボタン1710は、上述した図14の依頼画面1400でファイル添付ボタン1408が依頼者によって押され、保存フォルダが一覧表ストレージ110内に確保されているときに表示される。添付ファイルボタン1710が被依頼者によって押されると、タスク実現部106は、依頼者によって保存フォルダに保存されたファイルをブラウザ142に表示する。
レコード1709(すなわち、一覧表300のレコード306)が選択され、ファイル添付ボタン1711が被依頼者によって押されると、タスク実現部106は保存フォルダに文書ファイルを保存するための画面をブラウザ142に開く。なお、ファイル添付ボタン1711が被依頼者によって押された時に保存フォルダが一覧表ストレージ110内にない場合、タスク実現部106は保存フォルダを一覧表ストレージ110内に確保して、その保存フォルダに文書ファイルを保存するための画面をブラウザ142に開く。被依頼者は、その画面に文書ファイルをドラッグアンドドロップすることによって文書ファイルを保存フォルダに保存することができる。
利用者端末140でレコード1709(すなわち、一覧表300のレコード306)が更新され、完了ボタン1712が押されるとレコード毎タスクテーブル600の対応する行が更新され、タスクは完了となる。
なお、タスク実行画面1700中に一部のレコード1709だけを選択するチェックマークを設け、一部のレコード1709だけを更新できるようにしてもよい。
[進捗管理部107の処理]
進捗管理部107は、進捗確認処理と催促処理とタスク完了処理を実行する。
[進捗確認ステップ(S1208)]
図18は、利用者画面1000の中の依頼しているタスク一覧1002の一例を示す。
依頼しているタスク一覧1002は、タスクNo1801と、一覧表ID1802と、一覧表名1803と、被依頼者名1804と、タスク種別1805と、開始日時1806と、期限日時1807と、催促日時1808と、件名1809と、依頼文1810と、被依頼者毎進捗1811と、レコード毎進捗1812と、締切りボタン1813とで構成される。依頼しているタスク一覧1002を見ることによって、利用者は他の利用者に依頼しているタスクの進捗を確認することができる。
ここで、被依頼者毎進捗1811は、一覧表300についてのタスクを依頼された被依頼者の総人数の中で何人がタスクを完了しているかを示す。レコード毎進捗1812は、一覧表300に含まれる総レコード数の中で何件のレコードについてのタスクが完了しているかを示す。
依頼しているタスク一覧1002において、利用者があるタスクNo1801の行で一覧表名1803を選択すると、進捗管理部107はその時点の一覧表300を表示する。
また、依頼しているタスク一覧1002において、利用者があるタスクNo1801の行で被依頼者毎進捗1811を選択すると、進捗管理部107は図19の被依頼者毎進捗表示画面1900を表示する。
被依頼者毎進捗表示画面1900は、一覧表名1901と、タスクNo1902と、担当者名1903と、レコード数1904と、完了状況1905と、締切りボタン1906とで構成される。被依頼者毎進捗画面1900を参照すれば、依頼者は依頼したタスクの進捗状況を担当者毎(被依頼者毎)に把握することができる。
また、依頼しているタスク一覧1002において、利用者があるタスクNo1801の行でレコード毎進捗1812を選択すると、進捗管理部107は図20のレコード毎進捗表示画面2000を表示する。
レコード毎進捗表示画面2000は、一覧表名2001と、タスクNo2002と、製品ID2003と、製品名2004と、担当部署2005と、担当者名2006と、完了状況2007と、添付ファイルボタン2009と、締切りボタン2010とで構成される。レコード毎進捗表示画面2000を参照すれば、依頼者は依頼したタスクの進捗状況をレコード2008(すなわち、一覧表300のレコード306)毎に把握することができる。
添付ファイルボタン2009は、上述した図17のタスク実行画面1700でファイル添付ボタン1711が被依頼者によって押され、保存フォルダが一覧表ストレージ110内に確保されているときに表示される。依頼者がレコード2008を選択して添付ファイルボタン2009を押すと、タスク実現部106は、被依頼者によって保存フォルダに保存されたファイルをブラウザ142に表示する。
なお、図20には、レコード306あたりの担当者名2006が一つの場合を示すが、担当者名2006を複数設定可能とすることもできる。
また、依頼しているタスク一覧1002と被依頼者毎進捗表示画面1900とレコード毎進捗表示画面2000とは、本発明の進捗依頼者提示手段の例である。
[催促ステップ(S1209)]
未完了のタスクの催促日時になると、オペレーティングシステムのイベント管理機能は進捗管理部107にイベントを通知する。進捗管理部107は、通知されたイベントとタスクテーブル500とレコード毎タスクテーブル600に基づいてタスクが未完了の被依頼者を特定する。そして、進捗管理部107は、特定した被依頼者に催促の電子メールをメールサーバ160を経由して送信する。
なお、ステップS1209の催促ステップは、本発明の催促手段によって実行されるステップの一例である。
[タスク完了ステップ(S1210)]
被依頼者全員がタスクを完了した、または、被依頼者の一部がタスクを実行していないが期限を過ぎてしまったときに、依頼者は、依頼しているタスク一覧1002でタスクを選択して締切りボタン1803を押すこと、若しくは被依頼者毎進捗表示画面1900またはレコード毎進捗表示画面2000で締切りボタン1906または締切りボタン2010を押すことにより、そのタスクについて以降の被依頼者によるレコードの更新を禁止することができる。
締切りボタン1803、1906、2010が押されると、進捗管理部107は、それ以降被依頼者がそのタスクを実行することができないようにする。
締切りボタン1803、1906、2010を押すことによって、管理者は、一覧表300についてのタスクを完了することができる。
また、一覧表300の管理者は、図11の一覧表一覧1001において、一覧表名1202をいくつか選び、一覧表出力ボタン1206を押すことができる。一覧表出力ボタン1206が押されると、進捗管理部107は、更新後の一覧表300を一覧表ストレージ110から取り出し、管理者の利用者端末140に出力(送信)する。
図21は、部署名変更テーブル700および/または異動テーブル800が更新されたときの部署名変更・異動処理の流れの一例を示す。
部署名変更・異動処理では、組織で部署名変更や人事異動があった場合、部署名・担当者名更新部108は一覧表ストレージ110に記憶されている一覧表300に含まれる利用者名(担当者名305や参加者名314)や部署名(担当部署304や部署313)を更新する。そして、部署名・担当者名更新部108はその結果の確認を依頼する電子メールを各一覧表300の管理者(一覧表ストレージ110に一覧表300を登録した利用者)に送信する(S2101)。その後の処理は図12のタスク依頼処理におけるステップS1201からS1210と同様である。
[部署名・担当者名更新部108の処理、部署名・担当者名更新ステップ(S2101)]
部署名・利用者名更新部108は、部署名変更および/または人事異動を示すデータに基づいて、一覧表記憶ストレージ110に記憶されている一覧表300に含まれる部署名および/または利用者名を更新し、利用者テーブル200に記憶されている利用者情報から各一覧表300を登録した管理者のメールアドレスを取得し、取得したメールアドレスを宛先として、更新された部署名および/または利用者名を確認するタスクの依頼が記載された電子メールを送信する。
具体的には、組織で部署名変更や利用者(担当者や参加者)の異動があった場合、人事部門などが新旧の部署名の対応の一覧や異動の一覧を作成し、それを受け取ったシステム管理者がデータベースクライアント151を利用してその新旧の部署名の対応の一覧や異動の一覧を部署名変更テーブル700と異動テーブル800に追加行として登録する。
部署名変更テーブル700と異動テーブル800に行が追加されると、部署名・利用者名更新部108は、一覧表ストレージ110中の各一覧表300の数だけタスクテーブル500に新たな行を追加する。そして、部署名・利用者名更新部108は、一覧表300の部署範囲405で指定されている範囲中の各部署名について、一覧表テーブル400の部署名との関係407および部署名変更テーブル700の部署名変更区分705に応じて、旧部署名703を新部署名704に更新する、レコード306を2行に分割する、レコード306を削除する、部署名(担当部署304や部署313)を未定義にする、といった処理を行う。続いて、部署名・利用者名更新部108は、一覧表テーブル400の利用者範囲406で指定されている範囲中の利用者名(担当者名305や参加者名314)について、異動テーブル800の異動区分806に応じて、異動者の部署名を異動前部署名804から異動後部署名805に更新する、または、未定義にする、といった処理を行う。部署名・利用者名更新部108は、利用者名を更新するとき、部署名が既に更新されていることも、レコード毎タスクテーブル600を使って確認しながら利用者名を更新する。
部署名・利用者名更新部108は、部署名変更または異動による一覧表300の更新が完了すると、各管理者に一覧表300の更新結果の確認を依頼する旨の電子メールを送信する。
ステップS2101の後のステップは、図12のタスク依頼処理におけるステップS1201からS1210と同様である。
部署名・担当者名更新ステップ(S2101)において部署名や利用者名が未定義に更新されたレコード306について、被依頼者決定ステップ(S1203)で、管理者は部署名や利用者名を設定し、レコード306の更新の被依頼者を決めることができる。
なお、本実施形態はレコード306ごとの利用者名が一つの場合を示しているが、利用者名を複数設定し、利用者のうちの一部だけが退職した場合には残りの利用者に退職した利用者に対する新利用者の設定を依頼することとしてもよい。
また、部署名と利用者名がすべて定義されている場合には、部署名・利用者名更新部108が直接利用者(担当者や参加者)に依頼することとしてもよい。また、一覧表300ごとに、管理者が依頼するか、部署名・利用者名更新部108が直接依頼するかを指定可能にすることとしてもよい。
なお、上述した実施形態では一覧表300がスプレッドシートで作成されている例について説明したが、それに限らず他のシステムで作成された一覧表であっても本発明が適用できることはもちろんである。
上述したように、本発明によれば、組織において一覧表を効率的に管理することができる。
また、本発明によれば、会議資料の送付やレビュー、プロジェクト状況報告、作業実施状況報告、アンケートの依頼といった作業の依頼とその管理を効果的に行うことができる。さらに、例えば、担当者ごとの案件一覧の配布といった作業も効果的に行うことができる。
以上、本発明の実施形態について説明したが、設計上の都合やその他の要因によって必要となる様々な修正や組み合わせは、請求項に記載されている発明や発明の実施形態に記載されている具体例に対応する発明の範囲に含まれると理解されるべきである。
100…一覧表管理サーバ、101…認証部、102…一覧表登録部、103…一覧表決定部、104…被依頼者決定部、105…タスク依頼部、106…タスク実現部、107…進捗管理部、108…部署名・担当者名更新部、110…一覧表ストレージ、120…タスクDB、130…部署名・利用者名DB、140…利用者端末、141…メールクライアント、142…ブラウザ、150…システム管理者端末、151…データベースクライアント、160…メールサーバ、170…利用者認証システム、180…ネットワーク、200…利用者テーブル、300…一覧表、400…一覧表テーブル、500…タスクテーブル、600…レコード毎タスクテーブル、700…部署名変更テーブル、800…異動テーブル、1000…利用者画面、1001…一覧表一覧、1002…依頼しているタスク一覧、1003…依頼されているタスク一覧、1004…自分がレコードの担当者になっている一覧表一覧、1300…部署名・担当者名指定画面、1400…依頼画面、1700…タスク実行画面、1900…被依頼者毎進捗表示画面、2000…レコード毎進捗表示画面

Claims (6)

  1. 利用者を識別する利用者識別情報と当該利用者のメールアドレスとを含む利用者情報を記憶する利用者情報記憶手段と、
    タスクの依頼先である被依頼者に成り得る被依頼者候補の利用者識別情報と当該被依頼者が依頼されることとなるタスクに関する情報とをそれぞれ含む複数のレコードからなる一覧表データを記憶する一覧表記憶手段と、
    前記利用者情報記憶手段に記憶されている利用者情報に含まれる利用者識別情報で識別された利用者によって入力された一覧表データを受け付け、当該一覧表データを前記一覧表記憶手段に登録する一覧表登録手段と、
    前記利用者情報記憶手段に記憶されている利用者情報に含まれる利用者識別情報で識別された利用者である依頼者によって前記一覧表記憶手段に記憶されている複数の一覧表データの中からタスクの対象として選択された一覧表データである対象一覧表データを、前記被依頼者が依頼されることとなるタスクの対象として決定する一覧表決定手段と、
    前記対象一覧表データのレコード毎に当該各レコードを更新する被依頼者を、前記一覧表決定手段によってタスクの対象として決定された前記対象一覧表データに含まれる利用者識別情報によって示される被依頼者候補の中から前記依頼者に選択させることができ、選択された当該被依頼者が前記利用者情報記憶手段に記憶されている利用者情報に含まれる利用者識別情報で識別される利用者である場合に、選択された当該被依頼者を前記対象一覧表データの各レコードについてのタスク依頼先として決定する被依頼者決定手段と、
    前記利用者情報記憶手段に記憶されている利用者情報から前記被依頼者決定手段によってタスクの依頼先として決定された被依頼者のメールアドレスを取得し、取得した当該メールアドレスを宛先として前記依頼者によるタスクの依頼が記載された電子メールを送信するタスク依頼手段と、
    前記タスク依頼手段によって送信された電子メールを受信した被依頼者に、前記対象一覧表データの中から、前記被依頼者決定手段によって各前記被依頼者が依頼先として決定されたレコードのみを提示し、提示された当該レコードのみを各前記被依頼者が前記電子メールに記載されたタスクの依頼に従って更新することを可能とするタスク実現手段と、
    を備えることを特徴とする一覧表管理システム。
  2. 前記一覧表データが、スプレッドシートとして作成されていることを特徴とする請求項1に記載の一覧表管理システム。
  3. 前記一覧表登録手段によって登録された一覧表データを入力した利用者に、前記対象一覧表データについてのタスクの進捗を提示する進捗管理者提示手段と、
    前記被依頼者に、前記対象一覧表データについてのタスクの進捗を提示する進捗被依頼者提示手段と、
    前記依頼者に、前記対象一覧表データについてのタスクの進捗を提示する進捗依頼者提示手段と、
    を含む進捗管理手段を備えることを特徴とする請求項1または2に記載の一覧表管理システム。
  4. 前記進捗管理手段が、前記依頼者によって設定されたタイミングで、前記タスクが未完了の被依頼者に催促の電子メールを送信する催促手段を含むことを特徴とする請求項3に記載の一覧表管理システム。
  5. 前記利用者識別情報が、利用者名と部署名とを含み、
    部署名変更および/または人事異動を示すデータに基づいて、前記一覧表記憶手段に記憶されている一覧表データに含まれる利用者識別情報の部署名および/または利用者名を更新し、前記利用者情報記憶手段に記憶されている利用者情報から前記一覧表登録手段によって登録された一覧表データを入力した利用者のメールアドレスを取得し、取得した当該メールアドレスを宛先として、前記更新された部署名および/または利用者名を確認するタスクの依頼が記載された電子メールを送信する部署名・利用者名更新手段を備え、
    前記被依頼者決定手段において、前記部署名・利用者名更新手段によって送信された電子メールを受け取った前記依頼者によって前記被依頼者が選択され、
    前記タスク実現手段によって実行可能とされるタスクは、前記被依頼者決定手段によって決定された被依頼者が前記対象一覧表データに含まれる利用者識別情報の部署名および/または利用者名を確認および/または更新することである、
    ことを特徴とする請求項1ないし4のいずれか1項に記載の一覧表管理システム。
  6. 前記タスク実現手段によって実行可能とされるタスクは、前記被依頼者決定手段によって決定された被依頼者が、当該タスクの対象である前記対象一覧表データに関連する文書ファイルを取得すること、および/または当該対象一覧表データに関連する文書ファイルを提出することであることを特徴とする請求項1ないし5のいずれか1項に記載の一覧表管理システム。
JP2014173768A 2014-08-28 2014-08-28 一覧表管理システム Expired - Fee Related JP6420597B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2014173768A JP6420597B2 (ja) 2014-08-28 2014-08-28 一覧表管理システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014173768A JP6420597B2 (ja) 2014-08-28 2014-08-28 一覧表管理システム

Publications (2)

Publication Number Publication Date
JP2016048513A JP2016048513A (ja) 2016-04-07
JP6420597B2 true JP6420597B2 (ja) 2018-11-07

Family

ID=55649361

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014173768A Expired - Fee Related JP6420597B2 (ja) 2014-08-28 2014-08-28 一覧表管理システム

Country Status (1)

Country Link
JP (1) JP6420597B2 (ja)

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11184774A (ja) * 1997-12-25 1999-07-09 Casio Comput Co Ltd メールアドレス管理装置及び記憶媒体
JP2006039828A (ja) * 2004-07-26 2006-02-09 Nec Fielding Ltd 文書管理システム、その方法、文書管理装置およびプログラム
JP2007094904A (ja) * 2005-09-29 2007-04-12 Murata Mach Ltd 文書管理装置
JP2008027339A (ja) * 2006-07-25 2008-02-07 Technoa:Kk 業務管理支援システム
JP5742582B2 (ja) * 2011-08-17 2015-07-01 株式会社リコー 情報処理装置、人事情報管理システム
JP2014143576A (ja) * 2013-01-24 2014-08-07 Oki Electric Ind Co Ltd 連絡先管理システム及び連絡先管理方法
JP5651792B2 (ja) * 2014-02-05 2015-01-14 株式会社クレオネットワークス ワークフロー管理装置及びワークフロー管理方法

Also Published As

Publication number Publication date
JP2016048513A (ja) 2016-04-07

Similar Documents

Publication Publication Date Title
US7672853B2 (en) User interface for processing requests for approval
US6684212B1 (en) System and method for data sharing between members of diverse organizations
US7072940B1 (en) System and method for managing communications and collaboration among team members
US7155435B1 (en) Method for resolving issues within a team environment
US20040002885A1 (en) System, methods and software implemented program product for managing an organization&#39;s resources
JP5651795B1 (ja) 知的財産情報管理システム
JP6277703B2 (ja) 業務管理プログラム、業務管理方法、及び情報処理装置
US20050209904A1 (en) Program for managing workflow and workflow support system
EP2538349A2 (en) Server, inter-business enterprise information control method and computer program
US8751590B2 (en) Method and system for managing a virtual actionable conversation
JP2024012586A (ja) 知財情報管理システム、及び知財情報管理システムの知財情報提供方法
JP2018120366A (ja) タイムスタンプ管理システム、タイムスタンプ管理方法、およびタイムスタンプ管理プログラム
JP2008203909A (ja) アカウント管理システム
JP4944060B2 (ja) グループウェアサーバ装置、グループウェアサーバプログラム及びグループウェアサーバ装置の動作方法
US20190114591A1 (en) Pipeline data structure for generating custom display views on client devices
JP2006107282A (ja) コミュニティ管理システム、コミュニティサーバ、コミュニティ管理方法、及びコミュニティ管理プログラム
JP2020004142A (ja) 面接システム
JP6420597B2 (ja) 一覧表管理システム
JP2005141423A (ja) 電子的フォーム提供システム
JP6097428B1 (ja) 報告書作成支援システム
JP7470469B1 (ja) 情報処理方法、プログラム、及び情報処理装置
JP2001306766A (ja) 名刺管理・名刺交換システム
JP7412526B1 (ja) 株主総会支援システム及び株主総会支援方法
US20240112233A1 (en) Multi-tenant system, service provision method, and information storage medium
JP2017102694A (ja) ガントチャート生成プログラム、ガントチャート生成装置、および、ガントチャート生成方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170215

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180307

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180403

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180508

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20181009

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20181012

R150 Certificate of patent or registration of utility model

Ref document number: 6420597

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees