特許 5687989 アクセス権限管理装置、アクセス権限管理方法及びアクセス権限管理プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5687989

(24)【登録日】2015年1月30日

(45)【発行日】2015年3月25日

(54)【発明の名称】アクセス権限管理装置、アクセス権限管理方法及びアクセス権限管理プログラム

(51)【国際特許分類】

   G06F 21/62 20130101AFI20150305BHJP

   G06Q 10/00 20120101ALI20150305BHJP

【ＦＩ】

   G06F21/62 318

   G06Q10/00 140

【請求項の数】5

【全頁数】22

(21)【出願番号】特願2011-213634(P2011-213634)

(22)【出願日】2011年9月29日

(65)【公開番号】特開2013-73535(P2013-73535A)

(43)【公開日】2013年4月22日

【審査請求日】2014年3月26日

(73)【特許権者】

【識別番号】306020151

【氏名又は名称】株式会社 日立マネジメントパートナー

(74)【代理人】

【識別番号】100064414

【弁理士】

【氏名又は名称】磯野 道造

(74)【代理人】

【識別番号】100111545

【弁理士】

【氏名又は名称】多田 悦夫

(72)【発明者】

【氏名】江端 淳

(72)【発明者】

【氏名】矢吹 忠男

【審査官】 平井 誠

(56)【参考文献】

【文献】 特開２００６−３３０８４６（ＪＰ，Ａ）

【文献】 特開２００９−１２９２８９（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ２１／６２

Ｇ０６Ｑ １０／００

(57)【特許請求の範囲】

【請求項1】

従業員が業務にアクセスするために必要な認証情報の有効及び無効を管理するアクセス権限管理装置であって、
前記従業員に関連付けて、前記アクセス権限管理装置を使用する上での役割であるロールと、前記従業員が前記認証情報を使用できなくなる期限とを記憶した第１の対応情報と、
前記ロール及び異動理由の組合せに関連付けて、人事異動する前記従業員の前記認証情報を無効にするか否かを示す削除条件を記憶した第２の対応情報と、
前記ロール及び異動理由の組合せに関連付けて、人事発令日を起点とし、人事異動する前記従業員の前記認証情報を無効にする日を終点とする期間を示す削除時期を記憶した第３の対応情報と、
が格納される記憶部と、
前記従業員が人事異動する際に、
前記異動理由を受け付け、
前記人事異動する従業員に基づいて、前記第１の対応情報を検索し、前記ロールを取得し、
前記受け付けた異動理由及び前記取得したロールに基づいて、前記第２の対応情報を検索し、前記削除条件を取得し、
前記取得した削除条件が、前記認証情報を無効にすることを示す場合は、
前記受け付けた異動理由及び前記取得したロールに基づいて、前記第３の対応情報を検索し、前記削除時期を取得する制御部と、
を有することを特徴とするアクセス権限管理装置。

【請求項2】

前記削除条件は、
前記ロールが属する階層が上位であるほど、かつ、前記異動理由が部署の階層のうちより上位の階層を跨る異動を示すものであるほど、前記認証情報を無効にする必要が大きいことを示し、
前記削除時期は、
前記ロールが属する階層が上位であるほど、かつ、前記異動理由が前記部署の階層のうちより上位の階層を跨る異動を示すものであるほど、より短い期間であること、
を特徴とする請求項１に記載のアクセス権限管理装置。

【請求項3】

前記制御部は、
前記ロールのうち上位の階層に属するロールを割り当てられた前記従業員からの入力に基づいて、前記ロールのうち下位の階層に属するロールを他の従業員に割り当てることによって、前記第１の対応情報を作成すること、
を特徴とする請求項２に記載のアクセス権限管理装置。

【請求項4】

従業員が業務にアクセスするために必要な認証情報の有効及び無効を管理するアクセス権限管理装置のアクセス権限管理方法であって、
前記アクセス権限管理装置の記憶部は、
前記従業員に関連付けて、前記アクセス権限管理装置を使用する上での役割であるロールと、前記従業員が前記認証情報を使用できなくなる期限とを記憶した第１の対応情報と、
前記ロール及び異動理由の組合せに関連付けて、人事異動する前記従業員の前記認証情報を無効にするか否かを示す削除条件を記憶した第２の対応情報と、
前記ロール及び異動理由の組合せに関連付けて、人事発令日を起点とし、人事異動する前記従業員の前記認証情報を無効にする日を終点とする期間を示す削除時期を記憶した第３の対応情報と、
を格納しており、
前記アクセス権限管理装置の制御部は、
前記従業員が人事異動する際に、
前記異動理由を受け付け、
前記人事異動する従業員に基づいて、前記第１の対応情報を検索し、前記ロールを取得し、
前記受け付けた異動理由及び前記取得したロールに基づいて、前記第２の対応情報を検索し、前記削除条件を取得し、
前記取得した削除条件が、前記認証情報を無効にすることを示す場合は、
前記受け付けた異動理由及び前記取得したロールに基づいて、前記第３の対応情報を検索し、前記削除時期を取得すること、
を特徴とするアクセス権限管理方法。

【請求項5】

従業員が業務にアクセスするために必要な認証情報の有効及び無効を管理するアクセス権限管理装置を機能させるアクセス権限管理プログラムであって、
前記アクセス権限管理プログラムは、
前記アクセス権限管理装置の記憶部に対して、
前記従業員に関連付けて、前記アクセス権限管理装置を使用する上での役割であるロールと、前記従業員が前記認証情報を使用できなくなる期限とを記憶した第１の対応情報と、
前記ロール及び異動理由の組合せに関連付けて、人事異動する前記従業員の前記認証情報を無効にするか否かを示す削除条件を記憶した第２の対応情報と、
前記ロール及び異動理由の組合せに関連付けて、人事発令日を起点とし、人事異動する前記従業員の前記認証情報を無効にする日を終点とする期間を示す削除時期を記憶した第３の対応情報と、
を格納させ、
前記アクセス権限管理装置の制御部に対して、
前記従業員が人事異動する際に、
前記異動理由を受け付け、
前記人事異動する従業員に基づいて、前記第１の対応情報を検索し、前記ロールを取得し、
前記受け付けた異動理由及び前記取得したロールに基づいて、前記第２の対応情報を検索し、前記削除条件を取得し、
前記取得した削除条件が、前記認証情報を無効にすることを示す場合は、
前記受け付けた異動理由及び前記取得したロールに基づいて、前記第３の対応情報を検索し、前記削除時期を取得する処理を実行させること、
を特徴とするアクセス権限管理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、アクセス権限管理装置、アクセス権限管理方法及びアクセス権限管理プログラムに関する。

【背景技術】

【0002】

企業内で、人事異動、給与、勤務成績等の人事情報に対するアクセスを管理する場合、人事情報に対してアクセスしようとする従業員の所属部署及び職位に応じて、アクセス可能な人事情報の範囲を限定することが一般的である。そして、一旦アクセス権限を付与した従業員が企業内で又は企業を跨って異動した場合は、前任者のアクセス権限を抹消し、後任者について、どのようなアクセス権限を付与するかを改めて設定し直す。そして、例えば、前任者の離任日に後任者のアクセス権限が発効するような事前設定が行われることが多い。特許文献１には、前任者の登録管理情報の適用終了日と、後任者の登録管理情報の適用開始日との整合性を確認する技術が記載されている。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０１０−２０５１８３号公報（段落０００９）

【発明の概要】

【発明が解決しようとする課題】

【0004】

特許文献１の技術によれば、アクセス期間の重複及び空白を回避することができる。しかしながら、前任者の適用終了日すなわち後任者の適用開始日を、個々の異動ごとに指定する必要がある。実際の運用においては、業務引継ぎの期間等が様々であることに起因して、手間をかけずにその指定を行うことは困難である。
そこで、本発明は、前任者のアクセス権限が消滅する日を簡便に決定するアクセス権限管理装置等を提供することを目的とする。

【課題を解決するための手段】

【0005】

本発明に係るアクセス権限管理装置は、従業員が業務にアクセスするために必要な認証情報の有効及び無効を管理するアクセス権限管理装置であって、従業員に関連付けて、アクセス権限管理装置を使用する上での役割であるロールと、従業員が認証情報を使用できなくなる期限とを記憶した第１の対応情報と、ロール及び異動理由の組合せに関連付けて、人事異動する従業員の認証情報を無効にするか否かを示す削除条件を記憶した第２の対応情報と、ロール及び異動理由の組合せに関連付けて、人事発令日を起点とし、人事異動する従業員の認証情報を無効にする日を終点とする期間を示す削除時期を記憶した第３の対応情報と、が格納される記憶部と、従業員が人事異動する際に、異動理由を受け付け、人事異動する従業員に基づいて、第１の対応情報を検索し、ロールを取得し、受け付けた異動理由及び取得したロールに基づいて、第２の対応情報を検索し、削除条件を取得し、取得した削除条件が、認証情報を無効にすることを示す場合は、受け付けた異動理由及び取得したロールに基づいて、第３の対応情報を検索し、削除時期を取得する制御部と、を有することを特徴とする。
その他の手段については、発明を実施するための形態において詳述する。

【発明の効果】

【0006】

本発明によれば、前任者のアクセス権限が消滅する日を簡便に決定するアクセス権限管理装置等を提供することができる。

【図面の簡単な説明】

【0007】

【図1】本実施形態に係るアクセス権限管理システムの構成を示す図である。

【図2】本実施形態に係る従業員情報の一例を示す図である。

【図3】本実施形態に係る異動情報の一例を示す図である。

【図4】本実施形態に係るアクセス権限情報の一例を示す図である。

【図5】本実施形態に係るＩＤ削除条件情報の一例を示す図である。

【図6】本実施形態に係るＩＤ削除時期情報の一例を示す図である。

【図7】本実施形態に係る判定対象従業員一覧の一例を示す図である。

【図8】本実施形態に係るアクセス権限初期登録処理手順のフローチャートである。

【図9】本実施形態に係るアクセス権限変更処理手順のフローチャートである。

【図10】本実施形態に係るアクセス権限変更処理手順の他のフローチャートである。

【図11】本実施形態に係る継続・削除判定処理手順のフローチャートである。

【発明を実施するための形態】

【0008】

以降、本発明を実施するための形態（「本実施形態」という）を、図等を参照しながら詳細に説明する。

【0009】

図１に沿って、アクセス権限管理システムの構成を説明する。アクセス権限管理システムは、アクセス権限管理装置１、人事管理サーバ２、人事業務サーバ３及びユーザ端末装置４を有する。これらは、ネットワーク５を介して相互に通信可能である。
アクセス権限管理装置１は、一般的なコンピュータであり、中央制御装置１１、主記憶装置１２、補助記憶装置１３、入力装置１４、出力装置１５及び通信インタフェース１６を有する。これらは、相互にバスで接続されている。補助記憶装置１３は、アクセス権限情報３１、ＩＤ削除条件情報３２、ＩＤ削除時期情報３３及び判定対象従業員一覧３６を有する（詳細後記）。なお、「ＩＤ」は、「Identifier」の略であり、識別子を意味する。アクセス権限初期登録部２１及びアクセス権限変更部２２は、プログラムである。以降において、「○○○部は、」と動作の主体を記した場合は、中央制御装置１１が、プログラムとしての○○○部を補助記憶装置１３から読み出し、主記憶装置１２にロードしたうえで、当該プログラムの機能（詳細後記）を実行するものとする。
なお、「第１の対応情報」、「第２の対応情報」及び「第３の対応情報」には、それぞれ、アクセス権限情報３１、ＩＤ削除条件情報３２及びＩＤ削除時期情報３３が相当する。

【0010】

人事管理サーバ２、人事業務サーバ３及びユーザ端末装置４もまた、一般的なコンピュータであり、アクセス権限管理装置１を使用することを許可された会員企業に管理されている。これらのそれぞれは、中央制御装置、主記憶装置、補助記憶装置、入力装置、出力装置及び通信インタフェースを有する。これらは、相互にバスで接続されている（図示せず）。
人事管理サーバ２は、補助記憶装置に、従業員情報３４及び異動情報３５を格納している（詳細後記）。さらに、人事管理サーバ２は、プログラムとしての異動情報送信部２３を格納している（詳細後記）。図１においては、人事管理サーバ２が、会員企業ごとに独立している構成としたが、アクセス権限管理装置１と一体になっていてもよい。

【0011】

人事業務サーバ３は、当該企業の人事管理に必要な一切のデータ（既述の符号３１〜３６を除く）を記憶及び管理するサーバである。これらのデータの内容は特に限定されず、例えば、異動履歴、職務成績、給与・賞与水準等の人事に関するデータである。
ユーザ端末装置４は、従業員が人事業務サーバ３にアクセスする際に使用する端末装置であり、従業員に対して割り当てられたパーソナルコンピュータであってもよい。

【0012】

（従業員情報）
図２に沿って、従業員情報３４を説明する。従業員情報３４においては、企業ＩＤ欄１０１に記憶された企業ＩＤに関連付けて、従業員ＩＤ欄１０２には従業員ＩＤが、氏名欄１０３には氏名が、メールアドレス欄１０４にはメールアドレスが記憶されている。
企業ＩＤ欄１０１の企業ＩＤは、アクセス権限管理装置１を使用することを許可された会員企業を一意に特定する識別子である。
従業員ＩＤ欄１０２の従業員ＩＤは、会員企業の従業員を一意に特定する識別子である。
氏名欄１０３の氏名は、従業員の氏名である。
メールアドレス欄１０４のメールアドレスは、従業員が使用するユーザ端末装置４のメールアドレスである。

【0013】

（異動情報）
図３に沿って、異動情報３５を説明する。異動情報３５においては、企業ＩＤ欄１１１に記憶された企業ＩＤに関連付けて、従業員ＩＤ欄１１２には従業員ＩＤが、氏名欄１１３には氏名が、所属欄１１４には所属が、職位欄１１５には職位が、異動理由欄１１６には異動理由が、異動基準日欄１１７には異動基準日が記憶されている。

【0014】

企業ＩＤ欄１１１の企業ＩＤは、図２の企業ＩＤと同じである。
従業員ＩＤ欄１１２の従業員ＩＤは、図２の従業員ＩＤと同じである。
氏名欄１１３の氏名は、図２の氏名と同じである。
所属欄１１４の所属は、従業員が属する、当該企業内の組織の名称である。所属の値は、「人事部」のようにある階層の組織の名称、「人事部第一課」のように複数の階層の組織の名称の組合せ、「（株）○○」のように当該会員企業とは別の企業の名称等のバリエーションが有り得る。さらに、空白（役員等）であることもある。
職位欄１１５の職位は、従業員（役員）の業務上の地位である。職位には、企業ごとにその企業独自の上下の序列があるものとする。例えば、図３の例では、取締役＝監査役＞部長＞課長＞主任＞一般、という上下関係があるものとする。なお「ａ＞ｂ」と表記するとき、ａはｂの上位の職位である。
異動理由欄１１６の異動理由は、従業員の異動を発生せしめた理由を示すコードである（詳細後記）。
異動基準日欄１１７の異動基準日は、人事発令が発せられる年月日である。

【0015】

異動情報３５のレコードは、ある会員企業の従業員について行われた人事発令（異動）の数だけ存在する。人事管理サーバ２は、人事発令（異動）がある都度、異動情報３５のレコードを作成するものとする。したがって、通常、異動情報３５のレコードは、異動基準日の順（日が若い順）に並ぶことになる。もちろん、人事管理サーバ２は、これらのレコードを任意の欄の値をキーとして並べ替えること、また、任意のレコードだけを表示することも可能である。図３では、専ら説明を容易にするために、「人事部」に関連するレコードのみを表示した状態が例として示されている。

【0016】

例えば、図３のレコード１１８ａ〜１１８ｇに注目すると、企業ＩＤが「Ｅ００１」である企業において、以下の異動があったことがわかる。
（１）「鈴木正」が２００８年１２月１日の人事発令によって、人事部の部長になった。この際の異動理由は「Ａ３」であった（レコード１１８ａ）。詳細は後記するが、このコードは「事業所内異動」を示す。
（２）「鈴木正」が２０１１年８月１日の人事発令によって、（株）○○の取締役として出向した。この際の異動理由は「Ａ１」であった（レコード１１８ｅ）。詳細は後記するが、このコードは「退職、企業間異動」を示す。
（３）「松本次郎」が２０１１年８月１日の人事発令によって、人事部の部長になった。この際の異動理由もまた「Ａ１」であった（レコード１１８ｆ）。この異動は、「鈴木正」の後任者を決める異動である。

【0017】

（４）「橘友子」が２００６年７月１日の人事発令によって、人事部第二課の課長になった。この際の異動理由は「Ａ３」であった（レコード１１８ｂ）。
（５）「橘友子」が２０１１年７月１日の人事発令によって、営業部第一課の課長になった。この際の異動理由は「Ａ２」であった（レコード１１８ｃ）。詳細は後記するが、このコードは「企業内異動」を示す。
（６）「沢田仁志」が２０１１年７月１日の人事発令によって、人事部第二課の課長になった。この際の異動理由は「Ａ３」であった（レコード１１８ｄ）。この異動は、「橘友子」の後任者を決める異動である。

【0018】

（７）「佐々木清」が２０１１年９月１日の人事発令によって、「主任」に昇格した。この際の異動理由は「Ｂ２」であった（レコード１１８ｇ）。詳細は後記するが、このコードは「職位変更」を示す。

【0019】

（アクセス権限情報）
図４に沿って、アクセス権限情報３１を説明する。アクセス権限情報３１においては、企業ＩＤ欄１２１に記憶された企業ＩＤに関連付けて、ロール欄１２２にはロールが、ユーザＩＤ欄１２３にはユーザＩＤが、従業員ＩＤ欄１２４には従業員ＩＤが、アクセス可能業務欄１２５にはアクセス可能業務が、パスワード欄１２６にはパスワードが、ＩＤ適用開始日欄１２７にはＩＤ適用開始日が、ＩＤ削除日欄１２８にはＩＤ削除日が記憶されている。

【0020】

企業ＩＤ欄１２１の企業ＩＤは、図２の企業ＩＤと同じである。
ロール欄１２２のロールは、会員企業の従業員に対して割り当てられる、アクセス権限管理装置１の使用上の役割であり、ここでは「統括責任者」、「責任者」、「管理者」及び「担当者」のうちの何れかである。統括責任者＞責任者＞管理者＞担当者という責任の重さに応じた上下関係（階層）があるものとする。そして、下位の者は、その直ぐ上位の者から、指定を受ける（詳細後記）。
ユーザＩＤ欄１２３のユーザＩＤは、アクセス権限管理装置１を使用することを許された会員企業の従業員を一意に（すべての会員企業の従業員にわたって重複がないように）特定する識別子である。従業員ＩＤは、一般的に会員企業が独自に採番する一方、ユーザＩＤは、アクセス権限管理装置１が採番する。
従業員ＩＤ欄１２４の従業員ＩＤは、図２の従業員ＩＤと同じである。

【0021】

アクセス可能業務欄１２５のアクセス可能業務は、会員企業の従業員がアクセスすることが可能な人事業務サーバ３の名称である。それぞれの個々の人事業務サーバ３（図１）に対して、個々の業務が割り当てられており、個々の人事業務サーバ３は、当該割り当てられた業務を名称として有するものとする。割り当てられた業務の名称は、例えば、「給与−報酬」、「給与−税金」というように上位項目と下位項目の組合せであってもよい。なお、例えば、「給与−報酬」及び「給与−税金」という業務の名称がある場合、「給与−ａｌｌ」は、「給与−報酬」及び「給与−税金」の両者をまとめて示すものとする。つまり「ａｌｌ」は、すべての下位項目を示している。

【0022】

パスワード欄１２６のパスワードは、会員企業の従業員が人事業務サーバ３に対してアクセスする際のパスワードである。
ＩＤ適用開始日欄１２７のＩＤ適用開始日は、当該レコードが有効になる年月日、すなわち、会員企業の従業員が当該ユーザＩＤ及び当該パスワードを使用して、アクセス可能業務に対してアクセスできるようになる年月日である。ＩＤ適用開始日は、当該従業員の異動基準日を基準にして決定される（詳細後記）。なお、図４において「・・・・・・・・」と記載した部分には、他のレコードと同様に、ＩＤ適用開始日が記憶されているが、ここでは省略的に表記した。
ＩＤ削除日欄１２８のＩＤ削除日は、当該レコードが無効になる年月日、すなわち、会員企業の従業員が当該ユーザＩＤ及び当該パスワードを使用して、アクセス可能業務に対してアクセスすることができなくなる年月日である。ＩＤ削除日は、当該従業員の異動基準日を基準にして決定される（詳細後記）。
なお、「認証情報」には、ユーザＩＤ及びパスワードのうち少なくとも１つが相当する。

【0023】

ロールを与えられた従業員は、自らのユーザ端末装置４を使用して、アクセス可能業務を行う人事管理サーバ３にアクセスする。このとき、アクセス権限管理装置１は、ロールを与えられた従業員ごとに、ユーザＩＤ、パスワード及びアクセス可能業務の組合せを記憶した、アクセス権限情報３１（図４）を参照し、当該従業員がアクセスできる人事管理サーバ３を制限する。例えば、図４のレコード１２９ａ〜１２９ｅに注目すると、企業ＩＤが「Ｅ００１」である企業において、ユーザＩＤ及びパスワードが、以下のように管理されることがわかる。なお、下記の例は、図３の説明における例に対応している。

【0024】

（１）従業員ＩＤが「Ｐ００２」である従業員（鈴木正）は、２００８年１２月２日以降、ロール「責任者」として、「給与−ａｌｌ」及び「人事異動−ａｌｌ」というアクセス可能業務にアクセス可能である。鈴木正は、当該業務を行うためにユーザＩＤ「Ｙ００２」及びパスワード「ｗｒｙｉｐｓ」を与えられている（レコード１２９ａ）。
（２）従業員ＩＤが「Ｐ１０２」である従業員（松本次郎）は、２０１１年８月２日以降、ロール「責任者」として、「給与−ａｌｌ」及び「人事異動−ａｌｌ」というアクセス可能業務にアクセス可能である。松本次郎は、当該業務を行うためにユーザＩＤ「Ｙ０１０」及びパスワード「ｄｇｊｌｘｖ」を与えられている（レコード１２９ｅ）。
（３）松本次郎は、鈴木正の後任者であり、鈴木正が行っていたアクセス可能業務をそのまま引き継いでいる。そして、２０１１年８月２日以降、鈴木正は、ロール「責任者」として、「給与−ａｌｌ」及び「人事異動−ａｌｌ」というアクセス可能業務にアクセスできなくなる（レコード１２９ａのＩＤ削除日欄１２８）。

【0025】

（４）従業員ＩＤが「Ｐ００４」である従業員（橘友子）は、２００６年８月１日以降、ロール「管理者」として、「人事異動−ａｌｌ」というアクセス可能業務にアクセス可能である。橘友子は、当該業務を行うためにユーザＩＤ「Ｙ００４」及びパスワード「ｅｔｕｏａｄ」を与えられている（レコード１２９ｂ）。
（５）従業員ＩＤが「Ｐ１０１」である従業員（沢田仁志）は、２０１１年８月１日以降、ロール「管理者」として、「人事異動−ａｌｌ」というアクセス可能業務にアクセス可能である。沢田仁志は、当該業務を行うためにユーザＩＤ「Ｙ００９」及びパスワード「ｓｆｈｋｚｃ」を与えられている（レコード１２９ｄ）。
（６）沢田仁志は、橘友子の後任者であり、橘友子が行っていたアクセス可能業務をそのまま引き継いでいる。そして、２０１１年８月１日以降、橘友子は、ロール「管理者」として、「人事異動−ａｌｌ」というアクセス可能業務にアクセスできなくなる（レコード１２９ｂのＩＤ削除日欄１２８）。

【0026】

（７）従業員ＩＤが「Ｐ００８」である佐々木清は、２００８年５月１日以降、ロール「担当者」として、「人事異動−転任旅費」というアクセス可能業務にアクセス可能である。佐々木清は、当該業務を行うためにユーザＩＤ「Ｙ００８」及びパスワード「ｚａｑｘｓｗ」を与えられている（レコード１２９ｃ）。なお、前記のように、佐々木清は、２０１１年９月１日の人事発令によって、「主任」に昇格した。そして、佐々木清は、当該昇格についての人事発令後も継続して、ロール「担当者」として、「人事異動−転任旅費」というアクセス可能業務にアクセス可能である。そして、「人事異動−転任旅費」というアクセス可能業務にアクセスできなくなる日は、今のところ予定されていない（レコード１２９ｃのＩＤ削除日欄１２８は空欄である。）。

【0027】

（ＩＤ削除条件情報）
図５に沿って、ＩＤ削除条件情報３２を説明する。ＩＤ削除条件情報３２は、縦軸に異動理由、横軸にロールを有するマトリクスである。そして、縦軸と横軸とが交差する位置のセルに、削除条件が記憶されている。
縦軸の異動理由は、前記したように、従業員の異動を発生せしめた理由を示すコードである。ここでは、コードに関連付けてコードが示す理由が記憶されている。例えば、コード「Ａ１」、「Ａ２」、「Ａ３」、「Ａ４」及び「Ａ５」は、それぞれ、「退職、企業間異動」、「企業内異動」、「事業部内異動」、「部内異動」及び「課内異動」を示す。「Ａ１」〜「Ａ５」を比較すると、コードの数字が小さいほど、部署の階層のうちより上位の階層を跨る異動を示しているといえる。すなわち、異動前後で従業員が行う業務が変化する度合いがより大きく、前任者に対して与えたユーザＩＤ及びパスワードをより早く無効にする必要がある。

【0028】

コード「Ｂ１」は「勤労指定変更」を示す。「勤労指定変更」は、従業員の所属を変えずに、従業員と会員企業との契約上の地位を変更することであり、例えば「本採用従業員」→「派遣従業員」のような変更が該当する。コード「Ｂ２」は「職位変更」を示す。「職位変更」は、従業員の所属を変えずに、従業員の職位を変更することであり、例えば「一般」→「主任」のようないわゆる昇格が該当する。「Ｂ１」及び「Ｂ２」を比較すると、コードの数字が小さいほど、従業員が行う業務が異動（地位又は職位の変更）前後で変化する度合いがより大きく、異動前の従業員に対して与えたユーザＩＤ及びパスワードをより早く無効にする必要がある。

【0029】

横軸のロールは、前記したように、会員企業の従業員に対して割り当てられる、アクセス権限管理装置１の使用上の役割である。ここでは、責任の重さに応じた上下関係（階層）の順に、左から、統括責任者、責任者、管理者、担当者のように記憶されている。
削除条件は、異動基準日を基準にして、どのように前任者のユーザＩＤ及びパスワードを無効にするかを示す情報であり、その値として「削除」、「継続」及び「選択」が存在するものとする。「削除」は、異動基準日の後所定の日数が経過した時点において、前任者のユーザＩＤ及びパスワードを無効にすることを示す。「継続」は、異動基準日後も前任者のユーザＩＤ及びパスワードを引続き有効にしておくことを示す。「選択」は、「削除」及び「継続」のうちの何れかを選択できることを示す。

【0030】

ＩＤ削除条件情報３２（図５）のうち、縦軸の異動理由が「Ａ１」〜「Ａ５」であり、横軸のロールが「統括責任者」〜「担当者」である部分の削除条件に注目する。一般的に、削除条件は、同じ行では左に行くほど厳しく、同じ列では上に行くほど厳しくなる。ここで「厳しい」とは、前任者に対して与えたユーザＩＤ及びパスワードをより早く無効にする必要性があるということである。図５のロール「責任者」の列に注目すると、削除条件が、上から順に「削除」＞「選択」＝「選択」＝「選択」＞「継続」の順に記憶されている。ａ＞ｂは、ｂの削除条件よりａの削除条件の方が厳しいことを示す。図５の異動理由「Ａ２、企業内異動」の行に注目すると、削除条件が、左から順に「選択」＝「選択」＝「選択」＝「選択」の順に記憶されている。この場合では、４つの削除条件がすべて「選択」である。会員企業の自由な設定により、「＜」とならない限りこのような設定も原則的に許容されるものとする。
ＩＤ削除条件情報３２（図５）のうち、縦軸の異動理由が「Ｂ１」及び「Ｂ２」であり、横軸のロールが「統括責任者」〜「担当者」である部分についても、同様のことがあてはまる。
ＩＤ削除条件情報３２は、会員企業独自の設定により様々にカスタマイズできる。

【0031】

（ＩＤ削除時期情報）
図６（ａ）及び図６（ｂ）に沿って、ＩＤ削除時期情報３３を説明する。
ＩＤ削除時期情報３３は、縦軸に異動理由、横軸にロールを有するマトリクスである。そして、縦軸と横軸とが交差する位置のセルに、削除時期が記憶されている。
削除時期は、異動基準日後、何日経過した時点において前任者のユーザＩＤ及びパスワードを無効にするかを示す日数である。
図６（ａ）及び図６（ｂ）の異動理由及びロールは、その順序も含めて図５と同じである。すなわち、図６（ａ）及び図６（ｂ）のＩＤ削除時期情報３３は、図５のＩＤ削除条件情報３２に対応している。

【0032】

さらに詳しく言えば、図５において、削除条件「削除」が記憶されているセルに対応する削除時期が図６（ａ）に記憶され、図５において、削除条件「選択」が記憶されているセルに対応する削除時期が図６（ｂ）に記憶されている。図５において、削除条件「継続」が記憶されているセルに対応する削除時期は存在しない。なお、ここでは、説明のわかりやすさのために、図６（ａ）及び図６（ｂ）を別々にしているが、これらを１つにまとめてもよい。
一般的に、削除時期は、同じ行では左に行くほど、すなわち、ロールが上位であるほど短く、同じ列では上に行くほど、すなわち、部署の階層のうちより上位の階層を跨る異動であるほど短くなる。しかしながら、会員企業の特性に応じて、どのような設定も可能である。

【0033】

（判定対象従業員一覧）
図７に沿って、判定対象従業員一覧３６を説明する。
判定対象従業員一覧３６においては、企業ＩＤ欄１３１に記憶された企業ＩＤに関連付けて、従業員ＩＤ欄１３２には従業員ＩＤが、指定者ＩＤ欄１３３には指定者ＩＤが、ＩＤ削除日欄１３４には、ＩＤ削除日が記憶されている。

【0034】

企業ＩＤ欄１３１の企業ＩＤは、図２の企業ＩＤと同じである。
従業員ＩＤ欄１３２の従業員ＩＤは、図２の従業員ＩＤと同じである。ただし、ここでの従業員ＩＤは、対応する削除条件が「継続」であるのか又は「削除」であるのかが最終的に決定していない状態にある従業員を特定する。
指定者ＩＤ欄１３３の指定者ＩＤは、アクセス権限初期登録処理手順（詳細後記）において、従業員の指定を行った従業員を特定する従業員ＩＤである。例えば、下位の管理者の指定を上位の責任者が行う場合、責任者の従業員ＩＤである。
ＩＤ削除日欄１３４のＩＤ削除日は、図４のＩＤ削除日と同じである。

【0035】

（処理手順）
以降、本実施形態の処理手順を説明する。処理手順には、（１）アクセス権限初期登録処理手順及び（２）アクセス権限変更処理手順の２つがある。（２）の実行は、（１）が終了していることが前提となる。そして、（１）が実行される時点では、従業員情報３４（図２）、異動情報３５（図３）、ＩＤ削除条件情報３２（図５）及びＩＤ削除時期情報３３（図６）が既に完成しているものとする。さらに、人事管理サーバ２は、ユーザ端末装置４を介して、人事異動がある都度、異動情報３５についてのデータを受け付け、異動情報３５のレコードを最新の状態に維持しているものとする。
なお、（２）のアクセス権限変更処理手順には、「第１の実施形態」及び「第２の実施形態」の２つのバリエーションが存在する。アクセス権限変更処理手順の「第２の実施形態」は、「継続・削除判定処理手順」を含む。

【0036】

（アクセス権限初期登録処理手順）
図８に沿って、アクセス権限初期登録処理手順を説明する。
ステップＳ２０１において、アクセス権限管理装置１のアクセス権限初期登録部２１は、統括責任者の指定を受け付ける。具体的には、アクセス権限初期登録部２１は、第１に、会員企業の従業員の内の統括責任者となるべき者のユーザ端末装置４から、初期登録要求を受け付ける。初期登録要求には、企業ＩＤ、従業員ＩＤ及びアクセス可能業務が含まれているものとする。

【0037】

このとき、アクセス権限初期登録部２１は、悪意を以って又は錯誤によって初期登録要求を送信してくる者を排除するために、例えば、補助記憶装置１３に、契約時点等において、会員企業の企業ＩＤ及び統括責任者となるべき者の従業員ＩＤを予め登録しておく。そして、初期登録要求が送信されて来たとき、初期登録要求に含まれる企業ＩＤ及び従業員ＩＤを、登録されている企業ＩＤ及び従業員ＩＤと比較して、一致しない場合は、ユーザ端末装置４に対してエラーメッセージを返信してもよい。

【0038】

アクセス権限初期登録部２１は、第２に、受け付けた初期登録要求に含まれる企業ＩＤ及び従業員ＩＤを検索キーとして、人事管理サーバ２の従業員情報３４（図２）を検索し、該当するレコードの氏名及びメールアドレスを取得する。このとき、アクセス権限初期登録部２１は、企業ＩＤによってアクセスすべき人事管理サーバ２を特定できるものとする。

【0039】

アクセス権限初期登録部２１は、第３に、アクセス権限情報３１（図４）の新たなレコードを作成し、企業ＩＤ欄１２１、従業員ＩＤ欄１２４及びアクセス可能業務欄１２５に、それぞれ、初期登録要求に含まれている、企業ＩＤ、従業員ＩＤ及びアクセス可能業務を記憶する。
アクセス権限初期登録部２１は、第４に、ロール欄１２２に「統括責任者」を記憶し、ユーザＩＤ欄１２３に、新たなユーザＩＤを採番したうえで記憶し、パスワード欄１２６に、他と重複しない文字列をランダムに発生させたうえで記憶し、ＩＤ適用開始日欄１２７に現在の年月日を記憶する。この時点で統括責任者となるべき者は、「統括責任者」として登録されたことになる。

【0040】

ステップＳ２０２において、アクセス権限初期登録部２１は、責任者の指定を受け付ける。具体的には、アクセス権限初期登録部２１は、第１に、従業員情報３４（図２）を統括責任者が使用するユーザ端末装置４の出力装置に表示する。
アクセス権限初期登録部２１は、第２に、統括責任者が、表示されている従業員情報３４から、責任者となるべき者についてのレコードを選択し、当該レコードに対応付けて、アクセス可能業務を、キーボード等の入力装置を介して入力するのを受け付ける。

【0041】

アクセス権限初期登録部２１は、第３に、アクセス権限情報３１（図４）の新たなレコードを作成し、企業ＩＤ欄１２１、従業員ＩＤ欄１２４及びアクセス可能業務欄１２５に、それぞれ、ステップＳ２０２の「第２」において選択されたレコードの企業ＩＤ、従業員ＩＤ、及びステップＳ２０２の「第２」において入力されたアクセス可能業務を記憶する。
アクセス権限初期登録部２１は、第４に、ロール欄１２２に「責任者」を記憶し、ユーザＩＤ欄１２３に、新たなユーザＩＤ採番したうえで記憶し、パスワード欄１２６に、他と重複しない文字列をランダムに発生させたうえで記憶し、ＩＤ適用開始日欄１２７に現在の年月日を記憶する。この時点で責任者となるべき者は、「責任者」として登録されたことになる。

【0042】

ステップＳ２０３において、アクセス権限初期登録部２１は、管理者の指定を受け付ける。具体的には、アクセス権限初期登録部２１は、第１に、ステップＳ２０２において登録された責任者が使用するユーザ端末装置４に対して、ステップＳ２０２の「第２」において選択されたレコードのメールアドレスを使用して通知を送信する。当該通知には、ステップＳ２０２の「第３」及び「第４」において作成されたレコードに記憶されている情報が含まれるものとする。
アクセス権限初期登録部２１は、第２に、通知を送信した後その通知に対する反応があった後（又は反応がなくても所定の時間が経過した後）、従業員情報３４（図２）を責任者が使用するユーザ端末装置４の出力装置に表示する。

【0043】

アクセス権限初期登録部２１は、第３に、責任者が、表示されている従業員情報３４から、管理者となるべき者についてのレコードを選択し、当該レコードに対応付けて、アクセス可能業務を、キーボード等の入力装置を介して入力するのを受け付ける。
アクセス権限初期登録部２１は、第４に、アクセス権限情報３１（図４）の新たなレコードを作成し、企業ＩＤ欄１２１、従業員ＩＤ欄１２４及びアクセス可能業務欄１２５に、それぞれ、ステップＳ２０３の「第３」において選択されたレコードの企業ＩＤ、従業員ＩＤ、及びステップＳ２０３の「第３」において入力されたアクセス可能業務を記憶する。

【0044】

アクセス権限初期登録部２１は、第５に、ロール欄１２２に「管理者」を記憶し、ユーザＩＤ欄１２３に、新たなユーザＩＤ採番したうえで記憶し、パスワード欄１２６に、他と重複しない文字列をランダムに発生させたうえで記憶し、ＩＤ適用開始日欄１２７に現在の年月日を記憶する。この時点で管理者となるべき者は、「管理者」として登録されたことになる。

【0045】

ステップＳ２０４において、アクセス権限初期登録部２１は、担当者の指定を受け付ける。具体的には、アクセス権限初期登録部２１は、第１に、ステップＳ２０３において登録された管理者が使用するユーザ端末装置４に対して、ステップＳ２０３の「第３」において選択されたレコードのメールアドレスを使用して通知を送信する。当該通知には、ステップＳ２０３の「第４」及び「第５」において作成されたレコードに記憶されている情報が含まれるものとする。
アクセス権限初期登録部２１は、第２に、通知を送信した後その通知に対する反応があった後（又は反応がなくても所定の時間が経過した後）、従業員情報３４（図２）を管理者が使用するユーザ端末装置４の出力装置に表示する。

【0046】

アクセス権限初期登録部２１は、第３に、管理者が、表示されている従業員情報３４から、担当者となるべき者についてのレコードを選択し、当該レコードに対応付けて、アクセス可能業務を、キーボード等の入力装置を介して入力するのを受け付ける。
アクセス権限初期登録部２１は、第４に、アクセス権限情報３１（図４）の新たなレコードを作成し、企業ＩＤ欄１２１、従業員ＩＤ欄１２４及びアクセス可能業務欄１２５に、それぞれ、ステップＳ２０４の「第３」において選択されたレコードの企業ＩＤ、従業員ＩＤ、及びステップＳ２０４の「第３」において入力されたアクセス可能業務を記憶する。

【0047】

アクセス権限初期登録部２１は、第５に、ロール欄１２２に「担当者」を記憶し、ユーザＩＤ欄１２３に、新たなユーザＩＤ採番したうえで記憶し、パスワード欄１２６に、他と重複しない文字列をランダムに発生させたうえで記憶し、ＩＤ適用開始日欄１２７に現在の年月日を記憶する。この時点で担当者となるべき者は、「担当者」として登録されたことになる。
アクセス権限初期登録部２１は、第６に、ステップＳ２０４の「第５」において登録された担当者が使用するユーザ端末装置４に対して、ステップＳ２０４の「第３」において選択されたレコードのメールアドレスを使用して通知を送信する。当該通知には、ステップＳ２０４の「第４」及び「第５」において作成されたレコードに記憶されている情報が含まれるものとする。
その後、アクセス権限初期登録処理手順を終了する。

【0048】

（統括責任者等の人数、エラー表示等）
統括責任者は原則１名である。統括責任者が指定する責任者も原則１名である。責任者が指定する管理者の数は、原則複数である。１人の管理者が指定する担当者の数は、原則複数である。したがって、管理者（又は担当者）を複数指定する場合は、アクセス権限初期登録部２１は、ステップＳ２０３及びＳ２０４の処理を人数分繰り返すことになる。

【0049】

責任者（又は管理者）が複数の管理者（又は担当者）を指定する際、複数の管理者（又は担当者）の間で、アクセス可能業務が重複する場合は、アクセス権限初期登録部２１は、責任者（又は管理者）が使用するユーザ端末装置４の出力装置に対してエラーメッセージを表示し、責任者（又は管理者）がアクセス可能業務を再入力するのを促してもよい。

【0050】

さらに、上位の者が、自らのアクセス可能業務の範囲外の業務を、下位の者のアクセス可能業務として指定しようとした場合、アクセス権限初期登録部２１は、上位の者が使用するユーザ端末装置４の出力装置に対してエラーメッセージを表示し、上位の者がアクセス可能業務を再入力するのを促してもよい。

【0051】

なお、アクセス権限初期登録部２１は、アクセス権限情報３１（図４）のいわゆる「棚卸」をすることも可能である。具体的には、アクセス権限初期登録部２１は、月末日、年度末日のように予め決定された時点において、特定のロールを与えられた従業員（例えばロール「統括責任者」を与えられた従業員）のユーザ端末装置４に対して、アクセス権限情報３１を送信し、承認した旨の返信を受信するようにしてもよい。このとき、例えばパスワードを非表示にしてアクセス権限情報３１を送信してもよい。

【0052】

（アクセス権限変更処理手順の第１の実施形態）
図９に沿って、アクセス権限変更処理手順の第１の実施形態を説明する。
ステップＳ３０１において、人事管理サーバ２の異動情報送信部２３は、人事異動をアクセス権限管理装置１に送信する。
前提として、異動情報送信部２３は、異動情報３５（図３）を常時監視しており、レコードが追加されると、それを検知する。今、例えば、図３のレコード１１８ｃ及び１１８ｄが同時に追加されるのを検知し、これらの追加されたレコード（以降「対象異動レコード」と呼ぶことがある）をアクセス権限管理装置１に送信したとする。

【0053】

ステップＳ３０２において、アクセス権限管理装置１のアクセス権限変更部２２は、削除条件を取得する。具体的には、アクセス権限変更部２２は、第１に、対象異動レコードをアクセス権限管理装置１から受信する。
アクセス権限変更部２２は、第２に、対象異動レコードのうちの１つ（例えばレコード１１８ｃ）の異動理由を取得する。この例では、「Ａ２」が取得される。

【0054】

アクセス権限変更部２２は、第３に、対象異動レコード１１８ｃの企業ＩＤ及び従業員ＩＤを検索キーとして、アクセス権限情報３１（図４）を検索し、該当したレコードのうちＩＤ適用開始日が最も新しいレコードのロールを取得する。この例では、「管理者」（図４のレコード１２９ｂのロール欄１２２）が取得される。
アクセス権限変更部２２は、第４に、ステップＳ３０２の「第２」において取得した異動理由及びステップＳ３０２「第３」において取得したロールを検索キーとして、ＩＤ削除条件情報３２（図５）を検索し、該当したセルの削除条件を取得する。この例では、「選択」（図５の２行目３列目のセル）が取得される。

【0055】

ステップＳ３０３において、アクセス権限変更部２２は、削除条件は「継続」であるか否かを判断する。具体的には、アクセス権限変更部２２は、ステップＳ３０２の「第４」において取得した削除条件が「継続」である場合（ステップＳ３０３“ＹＥＳ”）は、ステップＳ３０９に進み、それ以外である場合（ステップＳ３０３“ＮＯ”）は、ステップＳ３０４に進む。

【0056】

ステップＳ３０４において、アクセス権限変更部２２は、削除条件は「選択」であるか否かを判断する。具体的には、アクセス権限変更部２２は、ステップＳ３０２の「第４」において取得した削除条件が「選択」である場合（ステップＳ３０４“ＹＥＳ”）は、ステップＳ３０５に進み、それ以外である場合（ステップＳ３０４“ＮＯ”）は、ステップＳ３０７に進む。

【0057】

ステップＳ３０５において、アクセス権限変更部２２は、「削除」又は「継続」の選択を受け付ける。具体的には、アクセス権限変更部２２は、第１に、対象異動レコード１１８ｃの企業ＩＤ及び従業員ＩＤを検索キーとして従業員情報３４（図２）を検索し、該当したレコードのメールアドレスを取得する。
アクセス権限変更部２２は、第２に、取得したメールアドレスを利用して、当該会員企業の当該従業員が使用するユーザ端末装置４に対して、通知を行う。当該通知は、『引継ぎ等が早期に終了する見込みであれば「削除」を選択して下さい。引継ぎ等が早期に終了する見込みが立たないのであれば「継続」を選択して下さい。』のような内容を含むものとする。
アクセス権限変更部２２は、第３に、当該従業員が使用するユーザ端末装置４から「削除」又は「継続」のうちの何れか一方を選択結果として受信する。

【0058】

ステップＳ３０６において、アクセス権限変更部２２は、削除条件は「継続」であるか否かを判断する。具体的には、アクセス権限変更部２２は、受信した選択結果が「継続」である場合（ステップＳ３０６“ＹＥＳ”）は、ステップＳ３０９に進み、それ以外である場合（ステップＳ３０６“ＮＯ”）は、ステップＳ３０７に進む。

【0059】

ステップＳ３０７において、アクセス権限変更部２２は、削除時期を取得する。具体的には、アクセス権限変更部２２は、ステップＳ３０２の「第２」において取得した異動理由及びステップＳ３０２の「第３」において取得したロールを検索キーとして、ＩＤ削除時期情報３３（図６（ａ）及び図６（ｂ））を検索し、該当したセルの削除時期を取得する。この例では、「１月後」（図６（ｂ）の２行目３列目のセル）が取得される。

【0060】

ステップＳ３０８において、アクセス権限変更部２２は、ＩＤ削除日を記憶する。具体的には、アクセス権限変更部２２は、第１に、対象異動レコード１１８ｃの異動基準日を取得する。そして、取得した異動基準日に対して、ステップＳ３０７において取得した削除時期を加算した年月日を、ＩＤ削除日とする。
アクセス権限変更部２２は、第２に、ステップＳ３０２の「第３」においてロールを取得したアクセス権限情報３１（図４）のレコードのＩＤ削除日欄１２８に、ＩＤ削除日を記憶する。

【0061】

ステップＳ３０９において、アクセス権限変更部２２は、アクセス権限情報３１（図４）のレコードを追加する。具体的には、アクセス権限変更部２２は、第１に、アクセス権限情報３１の新たなレコードを作成する。
アクセス権限変更部２２は、第２に、新たなレコードの企業ＩＤ欄１２１及び従業員ＩＤ欄１２４に、対象異動レコードのうちの他方（レコード１１８ｄ）のそれぞれ、企業ＩＤ及び従業員ＩＤを記憶する。

【0062】

アクセス権限変更部２２は、第３に、新たなレコードのロール欄１２２及びアクセス可能業務欄１２５に、ステップＳ３０８においてＩＤ削除日を記憶したレコードの、それぞれロール（この例では「管理者」）及びアクセス可能業務（この例では「人事異動−ａｌｌ」）を記憶し、新たなレコードのユーザＩＤ欄１２３に、ユーザＩＤを採番したうえで記憶（当該従業員のユーザＩＤを採番済みの場合はそのまま記憶）する。
アクセス権限変更部２２は、第４に、新たなレコードのパスワード欄１２６に、他と重複しない文字列をランダムに発生させたうえで記憶（当該従業員のパスワードを既に付与済みの場合はそのまま記憶）し、新たなレコードのＩＤ適用開始日欄１２７に、ステップＳ３０８においてＩＤ削除日を記憶したレコードのＩＤ削除日を記憶する。
その後、アクセス権限変更処理手順を終了する。

【0063】

（変形例１）
アクセス権限変更部２２は、ステップＳ３０８においてＩＤ削除日を記憶したレコードのＩＤ削除日、及び、ステップＳ３０９において新たに作成したレコードのＩＤ開始適用日を、それぞれ、前任者及び後任者のメールアドレスに関連付けて記憶しておく。そして、アクセス権限変更部２２は、ＩＤ削除日及びＩＤ開始適用日（または、それらの日より所定の期間だけ遡った時点）において、これらのメールアドレスを使用して、それぞれ、前任者及び後任者の使用するユーザ端末装置４に通知を送信してもよい。当該通知は、例えば「○年○月○日以降、○○という業務について、あなたのユーザＩＤ及びパスワードが使用可能（不能）になります」のようなメッセージを含むものとする。

【0064】

（変形例２）
アクセス権限変更部２２は、ステップＳ３０９において、後任者のアクセス可能業務を記憶する際、前任者のアクセス可能業務をそのまま記憶した。しかしながら、アクセス権限変更部２２は、その時点で前任者のロールの直ぐ上位のロールを付与された従業員を、アクセス権限情報３１（図４）を参照することにより特定し、その上位の従業員が使用するユーザ端末装置４に対してメールを送信し、その上位の従業員が、後任者の新たなアクセス可能業務を指定するのを受け付けてもよい。

【0065】

（変形例３）
前記では、前任者の交代要員として後任者が着任する例、すなわち、対象異動レコードが２つ存在する例を説明した。しかしながら、ある従業員の昇格があった場合などは、異動対象レコードが１つしか存在しない。
例えば、対象異動レコードが図３のレコード１１８ｇである場合、アクセス権限変更部２２が実行する処理は、概ね前記した処理と同じである。しかしながら、アクセス権限変更部２２は、ステップＳ３０９の処理は行わず終了する。

【0066】

（アクセス権限変更処理手順の第２の実施形態）
図１０に沿って、アクセス権限変更処理手順の第２の実施形態を説明する。
第１の実施形態においては、削除条件が「選択」である場合、当該異動の対象となる従業員が自ら「継続」及び「削除」のうちから最終的な削除条件を選択した。第２の実施形態においては、当該最終的な削除条件の選択を、異動の対象となる従業員を指定した上位の従業員が行う。さらに、削除時期が到来するまでの期間に、当該最終的な削除条件の選択がなされない場合は、自動的に「削除」が選択される。

【0067】

図１０のステップＳ３０１〜Ｓ３０４の処理は、それぞれ、図９のステップＳ３０１〜Ｓ３０４の処理と同じである。さらに、図１０のステップＳ３０７〜Ｓ３０９の処理は、それぞれ、図９のステップＳ３０７〜Ｓ３０９の処理と同じである。したがって、図１０における、ステップＳ３０１〜Ｓ３０４及びＳ３０７〜Ｓ３０９の処理については詳細説明を省略する。なお、説明のわかりやすさのために、図１０においてはステップＳ３０６を欠番としている。

【0068】

ステップＳ３０５において、アクセス権限変更部２２は、継続・削除判定処理手順を実行する。継続・削除判定処理手順の詳細は直ちに後記する。

【0069】

（継続・削除判定処理手順）
図１１に沿って、継続・削除判定処理手順を説明する。
なお、ステップＳ４０１の処理が実行される前提として、アクセス権限管理装置１のアクセス権限初期登録部２１は、アクセス権限初期登録手順（図８）の各ステップにおいて、指定を行った従業員の企業ＩＤ及び従業員ＩＤと、指定された従業員の企業ＩＤ及び従業員ＩＤと、指定が行われた年月日と、の組合せを補助記憶装置１３に記憶するものとする。そして、補助記憶装置１３には、これらの組合せをレコードとして保有する指定被指定対応テーブル（図示せず）が格納されているものとする。

【0070】

ステップＳ４０１において、アクセス権限管理装置１のアクセス権限変更部２２は、判定対象従業員一覧３６（図７）を作成する。具体的には、アクセス権限変更部２２は、第１に、判定対象従業員一覧３６の新たなレコードを作成する。この時点では、レコードの各欄は空欄である。
アクセス権限変更部２２は、第２に、ステップＳ３０２の「第１」において受信した異動対象レコードの、企業ＩＤ、従業員ＩＤ及び異動基準日を取得する。
アクセス権限変更部２２は、第３に、ステップＳ３０２の「第２」において取得した異動理由及びステップＳ３０２「第３」において取得したロールを検索キーとして、ＩＤ削除時期情報３３（図６（ｂ））を検索し、該当したセルの削除時期を取得する。

【0071】

アクセス権限変更部２２は、第４に、新たなレコードの企業ＩＤ欄１３１及び従業員ＩＤ欄１３２に、ステップＳ４０１の「第１」において取得した、それぞれ、企業ＩＤ及び従業員ＩＤを記憶する。
アクセス権限変更部２２は、第５に、ステップＳ４０１の「第２」において取得した異動基準日に対して、ステップＳ４０１の「第３」において取得した削除時期を加算した年月日を、新たなレコードのＩＤ削除日欄１３４に記憶する。

【0072】

なお、ステップＳ３０１からステップＳ３０４“ＹＥＳ”を経てステップＳ４０１に至る処理が所定の回数だけ繰り返された後初めて、アクセス権限変更部２２は、次のステップＳ４０２に進むものとする。すなわち、所定の数だけ（例えば１０）判定対象従業員一覧３６のレコードを蓄えた後、ステップＳ４０２に進むものとする。

【0073】

ステップＳ４０２において、アクセス権限変更部２２は、判定者に判定対象従業員一覧３６を送信する。具体的には、アクセス権限変更部２２は、第１に、判定対象従業員一覧３６の任意の１つのレコードの、企業ＩＤ及び従業員ＩＤを検索キーとする。そして、当該検索キーを使用して、指定被指定対応テーブルの「指定された従業員の企業ＩＤ及び従業員ＩＤ」の欄を検索し、該当したレコードのうちから、最新の「指定が行われた年月日」を有するレコードを抽出する。さらに、抽出されたレコードの、「指定を行った従業員の企業ＩＤ及び従業員ＩＤ」を取得する。当該「第１」の処理は、判定対象従業員一覧３６の各レコードについて実行される。

【0074】

アクセス権限変更部２２は、第２に、判定対象従業員一覧３６の新たなレコードの指定者ＩＤ欄１３３に、ステップＳ４０２の「第１」において取得した「指定を行った従業員の従業員ＩＤ」を、すでに記憶されている（指定された従業員を特定する）従業員ＩＤに対応する指定者ＩＤとして記憶する。
アクセス権限変更部２２は、第３に、判定対象従業員一覧３６のレコードを、指定者ＩＤごとにソートする。
アクセス権限変更部２２は、第４に、ステップＳ４０２の「第３」においてソートした、判定対象従業員一覧３６のレコードの部分ごとに、指定を行った従業員の企業ＩＤ及び従業員ＩＤに基づいて、従業員情報３４（図２）を参照し、指定を行った従業員のメールアドレスを取得する。

【0075】

アクセス権限変更部２２は、第５に、ステップＳ４０２の「第４」において取得したメールアドレスを使用して、指定を行った従業員が使用するユーザ端末装置４に通知を送信する。当該通知には、判定対象従業員一覧３６の部分（通知が送られたユーザ端末装置４を使用する従業員（指定を行った従業員）が過去に指定した、下位の従業員の一覧）が添付され、この部分は、ユーザ端末装置４の出力装置に表示されることになる。そして、当該通知には、『一覧の従業員のうちから１名を指定し、その１名の従業員について「継続」又は「削除」の何れかを選択してください』のようなメッセージも付され、このメッセージもユーザ端末装置４の出力装置に表示されることになる。

【0076】

当該通知を受信したユーザ端末装置４は、指定を行った従業員が、指定された従業員の企業ＩＤ、従業員ＩＤ及び削除条件（「継続」又は「削除」のうちの何れかである）をユーザ端末装置４の入力装置を介して入力するのを受け付け、当該指定された従業員の企業ＩＤ、従業員ＩＤ及び削除条件を、アクセス権限管理装置１に送信する。

【0077】

ステップＳ４０３において、アクセス権限変更部２２は、削除条件は「継続」であるか否かを判断する。具体的には、アクセス権限変更部２２は、第１に、ステップＳ４０２においてアクセス権限管理装置１に送信されてきた、指定された従業員の企業ＩＤ、従業員ＩＤ及び削除条件を受信する。
アクセス権限変更部２２は、第２に、受信した削除条件が「継続」である場合（ステップＳ４０３“ＹＥＳ”）は、ステップＳ４０６に進み、それ以外の場合（ステップＳ４０３“ＮＯ”）は、ステップＳ４０４に進む。

【0078】

ステップＳ４０４において、アクセス権限変更部２２は、削除時期を取得する。具体的には、アクセス権限変更部２２は、ステップＳ４０３において受信した企業ＩＤ及び従業員ＩＤを検索キーとして、判定対象従業員一覧３６（図７）を検索し、該当したレコードの削除時期を取得する。

【0079】

ステップＳ４０５において、アクセス権限変更部２２は、ＩＤ削除日を記憶する。具体的には、アクセス権限変更部２２は、第１に、対象異動レコード（この場合も、対象異動レコードは、符号１１８ｃのレコードであるとする）の異動基準日を取得する。そして、取得した異動基準日に対して、ステップＳ４０４において取得した削除時期を加算した年月日を、ＩＤ削除日とする。
アクセス権限変更部２２は、第２に、ステップＳ３０２の「第３」においてロールを取得したアクセス権限情報３１（図４）のレコードのＩＤ削除日欄１２８に、ＩＤ削除日を記憶する。

【0080】

ステップＳ４０６において、アクセス権限変更部２２は、アクセス権限情報３１（図４）のレコードを追加する。具体的には、アクセス権限変更部２２は、第１に、アクセス権限情報３１の新たなレコードを作成する。
アクセス権限変更部２２は、第２に、新たなレコードの企業ＩＤ欄１２１及び従業員ＩＤ欄１２４に、対象異動レコードのうちの他方（レコード１１８ｄ）のそれぞれ、企業ＩＤ及び従業員ＩＤを記憶する。

【0081】

アクセス権限変更部２２は、第３に、新たなレコードのロール欄１２２及びアクセス可能業務欄１２５に、ステップＳ４０５においてＩＤ削除日を記憶したレコードの、それぞれロール及びアクセス可能業務を記憶し、新たなレコードのユーザＩＤ欄１２３に、ユーザＩＤを採番したうえで記憶（当該従業員のユーザＩＤを採番済みの場合はそのまま記憶）する。
アクセス権限変更部２２は、第４に、新たなレコードのパスワード欄１２６に、他と重複しない文字列をランダムに発生させたうえで記憶（当該従業員のパスワードを既に付与済みの場合はそのまま記憶）し、新たなレコードのＩＤ適用開始日欄１２７に、ステップＳ４０５においてＩＤ削除日を記憶したレコードのＩＤ削除日を記憶する。
その後、アクセス権限変更処理手順を終了する。

【0082】

（変形例４）
アクセス権限変更部２２は、ＩＤ削除日が到来した時点において、アクセス権限管理装置１がユーザ端末装置４から削除条件を未だ受信していない場合は、前任者の従業員ＩＤを一括して削除してもよい。
すなわち、アクセス権限変更部２２は、ステップＳ４０２の処理の直後、判定対象従業員一覧３６（図７）のレコードごとに、ＩＤ削除日を管理する。そして、アクセス権限変更部２２は、当該ＩＤ削除日までの期間に、ユーザ端末装置４から、指定された従業員の従業員ＩＤ及び削除条件を受信しない場合は、当該ＩＤ削除日において、ステップＳ４０４及びステップＳ４０５の処理を実行する。

【0083】

（本実施形態の効果）
本実施形態によれば、人事発令があった日を基準として予め設定しておいた期日に、前任者のユーザＩＤ及びパスワードを無効にすることが、簡便に行える。そして、当該期日は、人事異動の類型に応じて設定しておくことが可能である。
さらに、企業内で上位の職位にいる者が、下位の職位にいる者に対して、業務の割り当てを重複することなく行うことが容易になる。

【0084】

本発明は、前記した実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で、変更実施が可能である。

【符号の説明】

【0085】

１ アクセス権限管理装置
２ 人事管理サーバ
３ 人事業務サーバ
４ ユーザ端末装置
５ ネットワーク
１１ 中央制御装置（制御部）
１２ 主記憶装置（記憶部）
１３ 補助記憶装置（記憶部）
１４ 入力装置
１５ 出力装置
１６ 通信インタフェース
２１ アクセス権限初期登録部
２２ アクセス権限変更部
２３ 異動情報送信部
３１ アクセス権限情報
３２ ＩＤ削除条件情報
３３ ＩＤ削除時期情報
３４ 従業員情報
３５ 異動情報
３６ 判定対象従業員一覧

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】