(57)【要約】【課題】複数の団体からなるグル−プが、個々の団体に属する人員の個人情報を、グル−プ全体として一元的に、かつ、過去と現在と未来の個人情報を一元的に管理できるようにする。【解決手段】  本発明は、団体に所属する人員をグル−プ内で一意に特定する個人識別情報と、個人情報の単位たるレコ−ドの有効期間を示す有効期間情報と、個人識別情報と前記有効期間情報との組み合わせに関連付けて、レコ−ド単位に関連情報とを記憶する記憶装置と、同一の個人識別情報を有するレコ−ド間においては、時間的に後の有効期間情報を有するレコ−ドを記憶する際に、当該後の有効期間情報を有するレコ−ドの有効期間情報の始期に基づき、直前のレコ−ドの有効期間情報の終期を更新することによって、有効期間が重複せず、かつ、連続したレコ−ドの集合たる個人情報を維持する手段を有する。【選択図】図１
2009053816.tif 000002
【特許請求の範囲】
【請求項１】
人員が所属する複数の団体からの情報に基づいて、前記団体が所属するグループが、前記団体に所属する人員の個人情報を管理するグループ個人情報管理装置であって、
前記グループ個人情報管理装置は、
前記団体に所属する人員をグループ内で一意に特定する個人識別情報と、個人情報の単位たるレコードの有効期間を示す有効期間情報と、前記個人識別情報と前記有効期間情報との組み合わせに関連付けられた関連情報とを記憶する記憶装置と、
同一の前記個人識別情報を有する前記レコード間においては、時間的に後の有効期間情報を有するレコードを記憶する際に、当該後の有効期間情報を有するレコードの有効期間情報の始期に基づき、直前のレコードの有効期間情報の終期を更新することによって、有効期間が重複せず、かつ、連続したレコードの集合たる個人情報を維持する手段と、を有すること、
を特徴とするグループ個人情報管理装置。
【請求項２】
前記記憶装置内に、前記個人情報を記憶する複数の管理領域を設け、当該各管理領域内でのみ、前記レコードの有効期間が重複せず、かつ、連続することとしたこと、
を特徴とする請求項１に記載のグループ個人情報管理装置。
【請求項３】
前記記憶装置内に、有効期間が重複し又は断続することを許容された前記レコードの集合たる個人情報を記憶する管理領域を併せ有し、前記個人情報を維持する手段は、当該管理領域においては、前記レコードの有効期間が重複し又は断続することを許容すること、
を特徴とする請求項１または請求項２に記載のグループ個人情報管理装置。
【請求項４】
人員が所属する複数の団体からの情報に基づいて、団体が所属するグループが、団体に所属する人員の個人情報を管理するグループ個人情報管理方法であって、
コンピュータが、団体に所属する人員をグループ内で一意に特定する個人識別情報と、
個人情報の単位たるレコードの有効期間を示す有効期間情報と、前記個人識別情報と前記有効期間情報との組み合わせに関連付けられた関連情報とを記憶装置に記憶させ、
同一の前記個人識別情報を有する前記レコード間においては、時間的に後の有効期間情報を有するレコードを記憶する際に、当該後の有効期間情報を有するレコードの有効期間情報の始期に基づき、直前のレコードの有効期間情報の終期を更新することによって、有効期間が重複せず、かつ、連続したレコードの集合たる個人情報を維持すること、
を特徴とするグループ個人情報管理方法。
【請求項５】
前記記憶装置内に、前記個人情報を記憶する複数の管理領域を設け、当該各管理領域内でのみ、前記レコードの有効期間が重複せず、かつ、連続することとしたこと、
を特徴とする請求項４に記載のグループ個人情報管理方法。
【請求項６】
前記記憶装置内に、有効期間が重複し又は断続することを許容された前記レコードの集合たる個人情報を記憶する管理領域を併せ有し、前期個人情報の維持は、当該管理領域においては、前記レコードの有効期間が重複し又は断続することを許容すること、
を特徴とする請求項４または請求項５に記載のグループ個人情報管理方法。
【請求項７】
人員が所属する複数の団体からの情報に基づいて、団体が所属するグループが、団体に所属する人員の個人情報を管理するグループ個人情報管理装置を機能させるグループ個人情報管理プログラムであって、
前記グループ個人情報管理プログラムは、
グループ個人情報管理装置の記憶装置に対し、団体に所属する人員をグループ内で一意に特定する個人識別情報と、個人情報の単位たるレコードの有効期間を示す有効期間情報と、前記個人識別情報と前記有効期間情報との組み合わせに関連付けられた関連情報とを記憶させるステップと
同一の前記個人識別情報を有する前記レコード間においては、時間的に後の有効期間情報を有するレコードを記憶する際に、当該後の有効期間情報を有するレコードの有効期間情報の始期に基づき、直前のレコードの有効期間情報の終期を更新することによって、有効期間が重複せず、かつ、連続したレコードの集合たる個人情報を維持するステップと、をコンピュータに実行させること、
を特徴とするグループ個人情報管理プログラム。
【請求項８】
前記記憶装置内に設けられた、前記個人情報を記憶する複数の管理領域において、当該各管理領域内でのみ、前記レコードの有効期間が重複せず、かつ、連続することとしたこと、
を特徴とする請求項７に記載のグループ個人情報管理プログラム。
【請求項９】
前記記憶装置内に併せ設けられた、有効期間が重複し又は断続することを許容された前記レコードの集合たる個人情報を記憶する管理領域において、前期個人情報を維持する手段は、当該管理領域においては、前記レコードの有効期間が重複し又は断続することを許容すること、
を特徴とする請求項７または請求項８に記載のグループ個人情報管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、グループ個人情報管理装置、グループ個人情報管理方法、及びグループ個人情報管理プログラムに関するものである。
【背景技術】
【０００２】
一般に、企業においては、所属する従業員の個人情報をコンピュータで管理することが行われている。
例えば、特許文献１に記載の発明では、企業において、従業員が、業務用企業内データベースにアクセスする条件として、データベースに対して従業員の個人情報を送信する必要があるとき、当該個人情報を自動的に検索し、送信する装置が紹介されている。
そして、このような個人情報を管理する人事部門においては、個別企業だけではなく、例えば資本的に関連があるグループ企業の従業員の個人情報を一元的に、かつ、過去、現在、未来に渡って管理し、グループ全体として、人員配置を適正化したいという要望がある。
【０００３】
しかしながら、例えば、社員番号は一企業内においてのみ一意であり、かつ、同一個人が一度退社した後再就職した場合には、別の社員番号が付与される等、個人情報は該当企業において就労している期間においてのみ一元管理されているに過ぎないのが一般的である。実際には企業グループ内では、出向や派遣などで人材は相互に利用されているため、企業単位ではなく、企業グループ内で個人情報を一元管理できることが望ましい。また、断続的な派遣や再就職時にも継続して、従業員の経歴を一元管理できることが望ましい。
【特許文献１】特開２００３−４４６３２号公報（段落０００５〜００２２、図１）
【発明の開示】
【発明が解決しようとする課題】
【０００４】
本発明は、複数の団体からなるグループが、個々の団体に属する人員の個人情報を、グループ全体として一元的に、かつ、過去と現在と未来の個人情報を一元的に管理できるグループ個人情報管理装置、グループ個人情報管理方法、及びグループ個人情報管理プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００５】
前記課題を解決するため、本発明は、団体に所属する人員をグループ内で一意に特定する個人識別情報と、個人情報の単位たるレコードの有効期間を示す有効期間情報と、個人識別情報と前記有効期間情報との組み合わせに関連付けて、レコード単位に関連情報とを記憶する記憶装置と、同一の個人識別情報を有するレコード間においては、時間的に後の有効期間情報を有するレコードを記憶する際に、当該後の有効期間情報を有するレコードの有効期間情報の始期に基づき、直前のレコードの有効期間情報の終期を更新することによって、有効期間が重複せず、かつ、連続したレコードの集合たる個人情報を維持する手段とを有することを特徴とする。
【発明の効果】
【０００６】
本発明によれば、複数の団体を有するグループが、個々の団体に属する人員の個人情報を、グループ全体として一元的に、かつ、過去と現在と未来の個人情報を一元的に管理できる。
【発明を実施するための最良の形態】
【０００７】
本発明を実施するための最良の形態（以下、「本実施形態」という）を、図面に従って、詳細に説明する。
【０００８】
（ハードウエア構成等）
図１は、本実施形態に係るハードウエア構成等を説明する図である。
複数の企業から構成される、企業グループを想定する。
グループ個人情報管理装置１は、企業グループに属する個別企業（以下、「グループ企業」という。特許請求の範囲における「団体」に相当。）に所属する従業員に係る個人情報を一元的に管理する装置である。グループ個人情報管理装置１は、通常は、企業グループ統括会社の人事部門等に設置される。
個別企業個人情報管理装置２は、個別企業に所属する従業員にかかる個人情報を、当該個別企業が管理する装置であり、通常は、個別グループ企業毎に１台、あるいは、管理対象ごとに適宜分割して複数台設置される。グループ個人情報管理装置１と、個別企業個人情報管理装置２とは、企業グループネットワーク３を介して接続されている。
【０００９】
グループ個人情報管理装置１および個別企業個人情報管理装置２は、ＣＰＵ（制御装置）１１、２１、主記憶装置１６、２６、補助記憶装置１２、２２、入力装置１３、２３、出力装置１４、２４、ネットワーク接続インターフェース（ＩＦ）１５、２５を有し、これらは、バスを介して接続されている。
【００１０】
グループ個人情報管理装置１は、個人情報統括部１０５、正社員個人情報処理部１０６、出向社員個人情報処理部１０７及び派遣社員個人情報処理部１０８を記憶する。これらはプログラムであり、以下、「○○部が」と主体を記した場合は、ＣＰＵ１１が、それぞれのプログラムを補助記憶装置１２から読み出して、主記憶装置１６にロードした上で実行し、各プログラムの機能を実現するものとする。
個別企業個人情報管理装置２は、個人情報管理部２７を記憶している。これは、プログラムであり、以下、「個人情報管理部２７が」と主体を記した場合は、ＣＰＵ２１が、当該プログラムを補助記憶装置２２から読み出して、主記憶装置２６にロードした上で実行し、当該プログラムの機能を実現するものとする。
【００１１】
グループ個人情報管理装置１は、正社員個人情報１０１、出向社員個人情報１０２、派遣社員個人情報１０３及び企業区分情報１０４の４つのデータベースを記憶している。これらのデータベースは、ＣＰＵ１１により、必要に応じて、補助記憶装置１２から読み出され、主記憶装置１６にロードされる。
個別企業個人情報管理装置２は、社員個人情報２００、送信用正社員個人情報２０１、送信用出向社員個人情報２０２及び送信用派遣社員個人情報２０３の４つのデータベースを記憶している。これらのデータベースは、ＣＰＵ２１により、必要に応じて、補助記憶装置２２から読み出され、主記憶装置２６にロードされる。
【００１２】
（用語の定義）
本実施形態においては、企業における一般的な人事管理の手法にならい「正社員」、「出向社員」及び「派遣社員」の３つの区分（以下、「就労区分」という）に基づいて、個人情報を管理する。なお、特許請求の範囲の「管理領域」には、当該「就労区分」によって区別して管理される領域が相当する。
「正社員」とは、企業が直接雇用する、雇用期間の定めのない従業員、及び嘱託や臨時員など雇用発生時から雇用終了日が確定している従業員を意味する。
「出向社員」とは、他企業より出向契約に基づき、自企業に出向してきている従業員を意味する。
「派遣社員」とは、出向契約以外の企業間の契約（以下、「出向除く企業間契約」という）に基づく従業員を意味する。
【００１３】
本実施形態を理解する上での前提となる、企業グループにおける人事異動の例を図面に沿って説明する。図２は、企業グループにおける人事異動の一例を示す図である。
Ａ社、Ｂ社及びＣ社はグループ企業であり、Ｄ社はグループ企業ではない。○○○○氏は、当該企業グループ内で一意な終身ＩＤ“１０００００１”を付与されている。
○○○○氏は、期間Ｔ１日〜Ｔ４日は、Ａ社の正社員であった。そしてその期間のうち、期間Ｔ２日〜Ｔ３日は、Ｂ社に出向していた。
○○○○氏は、Ｔ４日にＡ社を退職し、Ｔ５日（Ｔ４の翌日）にＢ社の正社員となり、Ｔ８日にＢ社を退職した。その期間のうち期間Ｔ６日〜Ｔ７日には、出向除く企業間契約によりＣ社の仕事をしていた。
○○○○氏は、期間Ｔ８＋１日〜Ｔ９−１日は無職であったが、期間Ｔ９日〜Ｔ１４日はＤ社の正社員であった。その期間のうち、期間Ｔ１０日〜Ｔ１１日は、出向除く企業間契約によりＡ社の仕事をし、かつＡ社とは別の出向除く企業間契約によりＢ社の仕事もしていた。
当該例は、○○○○氏の個人情報が企業グループとしてどのように一元管理されるかを後に見ていく際の前提となる。
なお、「Ｔ○」に対して「Ｔ○−１」はその前日を意味し、「Ｔ○＋１」はその翌日を意味する。
【００１４】
（データの内容）
グループ個人情報管理装置１には、個人情報が、正社員個人情報１０１、出向社員個人情報１０２、及び派遣社員個人情報１０３の３つの就労区分に分かれて記憶されている。したがって、個人情報の就労区分の判定は、各レコードのデータ項目（後記）を照会するのではなく、どのデータベースに記憶されているかによって判定する。
【００１５】
（正社員個人情報１０１）
図３は、本実施形態に係る正社員個人情報１０１の一例を示す図である。正社員個人情報１０１には、企業グループの全ての正社員の個人情報が記憶されている。縦軸にデータ項目が、横軸に個々のデータ（レコード）が並んでいる。
終身ＩＤ欄１１１には、終身ＩＤが記憶されている。終身ＩＤは、企業グループ内の個々の従業員に対して一対一に対応する識別子である（特許請求の範囲における「個人識別情報」に相当する）。一度採番され付与された終身ＩＤは、その後、たとえ異なる就労区分（出向社員、派遣社員）の従業員に対してであっても重複して付与されることはない。
【００１６】
有効開始年月日時欄１１２には、有効開始年月日時が、秒の単位まで、例えば、“２００５０４０１  ００：００：００”のように記憶されている（図では、後記説明の単純化のため、年月日部分を“Ｔ○”と表現した）。有効開始年月日時は、当該レコードが有効である期間の始期を意味する。
有効終了年月日時欄１１３には、有効終了年月日時が、秒の単位まで、例えば、“２００６０３３１  ２３：５９：５９”のように記憶されている（図では、後記説明の単純化のため、年月日部分を“Ｔ○”と表現した）。有効終了年月日時は、レコードが有効である期間の終期を意味する。
また、有効終了年月日時欄１１３に、システム上の「最大値」を設定する場合がある。「最大値」は、特に具体的な有効終了年月日時を設定せず、そのレコード状態が永久に連続する（将来の具体的予定が定まらない）ことを示し、値としては、“９９９９１２３１  ２３：５９：５９”が便宜的に設定されるものとする。なお、有効開始年月日時と有効終了年月日時との間の期間を「有効期間」ということがある。
【００１７】
氏名欄１１４には氏名が、生年月日欄１１５には生年月日が、性別欄１１６には性別が、所属企業欄１１７には所属企業が、所属欄１１８には所属部署が、出向先企業欄１１９には出向先企業が、入社日欄１２０には入社日が、退職日欄１２１には退職日が、その他情報欄１２２にはその他情報がそれぞれ記憶されている。
なお、特許請求の範囲における「関連情報」とは、氏名欄１１４からその他情報欄１２２までに記憶された情報が相当する。
【００１８】
正社員個人情報１０１においては、終身ＩＤ及び有効開始年月日時との組み合わせに関連付けて、それ以外の情報（有効終了年月日時からその他情報まで）が記憶されている。つまり、正社員個人情報１０１中に、同一の終身ＩＤを有するレコードは複数存在しうる。しかし、終身ＩＤと有効開始年月日時が両方とも同一のレコードは、一つしか存在しない。
本実施形態では、出向先企業、退職日、その他情報以外の項目は必須項目である。出向発生時に、出向先企業欄１１９に出向先企業を設定し、退職時に退職日欄１２１に退職日を設定する。また、本実施形態では、所属企業はグループ企業でなければならない。
【００１９】
ちなみに、図３は、図２における○○○○氏の正社員としての経緯を辿るべく、正社員個人情報１０１を、終身ＩＤ“１０００００１”を検索キーとして検索した場合の検索結果でもある。横軸方向に、当該終身ＩＤを持つ正社員たる“○○○○氏“のレコード（本実施形態例では、実データが入る縦の列を「レコード」という。以下同様。）が６つ（＃１〜＃６）並んでいる。各レコードの有効期間（有効開始年月日時及び有効終了年月日時）に着目すると、
レコード＃１が“Ｔ１  ００：００：００〜Ｔ２−１  ２３：５９：５９”、レコード＃２が“Ｔ２  ００：００：００〜Ｔ３  ２３：５９：５９”、レコード＃３が“Ｔ３＋１  ００：００：００〜Ｔ４−１  ２３：５９：５９”、レコード＃４が“Ｔ４  ００：００：００〜Ｔ５−１（Ｔ４）  ２３：５９：５９”、レコード＃５が“Ｔ５  ００：００：００〜Ｔ８−１  ２３：５９：５９”、レコード＃６が“Ｔ８  ００：００：００〜９９９９１２３１  ２３：５９：５９”のように、図２の人事異動例の「Ｔ○」に対応して、時間の経過とともに左から右に並んでいる。
【００２０】
レコード＃１は、Ｔ１日の００：００：００から、Ｔ２−１日の２３：５９：５９まで○○○○氏がＡ社のＰ部に所属する正社員であったことを示す。
レコード＃２は、Ｔ２日の００：００：００から、Ｔ３日の２３：５９：５９まで○○○○氏がＡ社のＰ部に所属しつつ、Ｂ社に出向していたことを示す。出向先企業欄１１９には、“Ｂ社”が設定されている。
レコード＃３は、Ｔ３＋１日の００：００：００から、Ｔ４-１日の２３：５９：５９まで○○○○氏がＡ社のＰ部に所属する正社員（Ｂ社への出向は解けた）であったことを示す。出向先企業欄１１９には、値が設定されていない。
レコード＃４は、○○○○氏がＴ４日にＡ社を退職したことを示す。退職日欄１２１に“Ｔ４”が設定されている。退職日は正社員としての最後の日であり、正社員の身分が無くなる（退職状態になる）のは退職日翌日からである。
レコード＃５は、Ｔ５日の００：００：００から、Ｔ８−１日の２３：５９：５９まで○○○○氏がＢ社のＱ部に所属する正社員であったことを示す。
レコード＃６は、○○○○氏がＴ８日にＢ社を退職し、退職日翌日から現在まで正社員の身分がない（退職状態である）ことを示す。退職日欄１２１に“Ｔ８”が設定されており、有効終了年月日時欄１１３には最大値が設定されている。
○○○○氏は、Ａ社からの退職日Ｔ４の翌日Ｔ５にＢ社の正社員となったため、レコード＃４は、有効期間が１日（退職日のみ）の短いレコードとなっている。仮に、Ｔ４日からＴ５日の間に相当の開きがあれば、レコード＃４は、退職日とその翌日以降の正社員の身分がない状態（退職状態）を表すレコードとなる。
さらに、ＴＸ日（Ｔ８日より後）に、○○○○氏がグループ企業の一つに正社員として雇用されると、＃６の次に有効期間が“ＴＸ  ００：００：００〜９９９９１２３１  ２３：５９：５９”であるレコード（図示せず）が追加される。このとき、レコード＃６の有効終了年月日時欄１１３は、“ＴＸ−１  ２３：５９：５９”に更新される。
【００２１】
例えば、同一企業内における部署間異動があった場合は、所属の変化があるたびにレコードが追加されることになる。
このように、正社員個人情報１０１内においては、同一の終身ＩＤを有するレコードは複数存在するが、同一の終身ＩＤ及び同一の有効開始年月日時を併せ持つレコードは１つしか存在しない。そして、有効終了年月日時は、基本的に当初は最大値で設定され、新たなレコードが追加されるたびに、次のレコードの有効開始年月日時−１秒に更新される。これにより、同一終身ＩＤのレコードは、時間的に重複することなく、過去・現在・未来に渡り時間的に連続して並ぶことになる。また、任意の一時点において終身ＩＤを検索キーにして検索すると、必ず１つのレコードのみがヒットする。
【００２２】
（出向社員個人情報１０２）
図４は、本実施形態に係る出向社員個人情報１０２の一例を示す図である。出向社員個人情報１０２には、企業グループの全ての出向社員の個人情報が記憶されている。縦軸にデータ項目が、横軸に個々のデータ（レコード）が並んでいる。
終身ＩＤ欄１３１における終身ＩＤは、図３の正社員個人情報１０１の終身ＩＤ欄１１１における終身ＩＤと同じものであり、○○○○氏であれば“１０００００１”になる。
【００２３】
有効開始年月日時欄１３２及び有効終了年月日時欄１３３については、正社員個人情報１０１におけるものと同様であるので説明は省略する。
氏名欄１３４には氏名が、生年月日欄１３５には生年月日が、性別欄１３６には性別が、出向先企業欄１３７には出向先企業が、出向先所属欄１３８には出向先所属部署が、出向元企業欄１３９には出向元企業が、出向開始日欄１４０には出向開始日が、出向終了日欄１４１には出向終了日が、その他情報欄１４２にはその他情報がそれぞれ記憶されている。
なお、特許請求の範囲における「関連情報」とは、氏名欄１３４からその他情報欄１４２までに記憶された情報が相当する。
【００２４】
出向社員個人情報１０２においては、終身ＩＤ及び有効開始年月日時との組み合わせに関連付けて、それ以外の情報（有効終了年月日時からその他情報まで）が記憶されている。つまり、出向社員個人情報１０２中に、同一の終身ＩＤを有するレコードは複数存在しうる。しかし、終身ＩＤと有効開始年月日時が両方とも同一のレコードは、一つしか存在しない。
本実施形態では、出向終了日、その他情報以外の項目は必須項目である。出向終了時に、出向終了日欄１４１に出向終了日を設定する。また、本実施形態では、出向先企業はグループ企業でなければならない。
【００２５】
ちなみに、図４は、図２における○○○○氏の出向社員としての経緯を辿るべく、出向社員個人情報１０２を、終身ＩＤ“１０００００１”を検索キーとして検索した場合の検索結果でもある。横軸方向に、当該終身ＩＤを持つ出向社員たる“○○○○氏“のレコードが４つ（＃１〜＃４）並んでいる。各レコードの有効期間（有効開始年月日時及び有効終了年月日時）に着目すると、
レコード＃１が“Ｔ２  ００：００：００〜Ｔ３−１  ２３：５９：５９”、レコード＃２が“Ｔ３  ００：００：００〜Ｔ１２−１  ２３：５９：５９”、レコード３が“Ｔ１２  ００：００：００〜Ｔ１３−１  ２３：５９：５９”、レコード＃４が“Ｔ１３  ００：００：００〜９９９９１２３１  ２３：５９：５９”のように、図２の人事異動例の「Ｔ○」に対応して、時間の経過とともに左から右に並んでいる。
【００２６】
レコード＃１は、Ｔ２日の００：００：００から、Ｔ３−１日の２３：５９：５９まで○○○○氏がＢ社のＱ部に出向する出向社員であったことを示す。
レコード＃２は、○○○○氏が、Ｔ３日にＢ社への出向を終了し、出向終了日翌日からＴ１２−１日までは、出向社員の身分がなかったことを示す。出向終了日欄１４１には“Ｔ３”が設定されている。出向終了日は出向社員としての最後の日であり、出向社員の身分が無くなるのは出向終了日翌日からである。
レコード＃３は、Ｔ１２日の００：００：００から、Ｔ１３−１日の２３：５９：５９まで○○○○氏がＣ社のＲ部に出向する出向社員であったことを示す。
レコード＃４は、○○○○氏がＴ１３日にＣ社への出向を終了し、出向終了日翌日から現在まで出向社員の身分がないことを示す。出向終了日欄１４１には“Ｔ１３”が設定されている。
さらに、ＴＹ日（Ｔ１３日より後）に、○○○○氏がグループ企業の一つに出向すると、＃４の次に有効期間が“ＴＹ  ００：００：００〜９９９９１２３１  ２３：５９：５９”であるレコード（図示せず）が追加される。このとき、レコード＃４の有効終了年月日時１３３は、“ＴＹ−１  ２３：５９：５９”に更新される。
【００２７】
例えば、出向先企業において部署間異動があった場合は、出向先所属の変化があるたびにレコードが追加されることになる。
このように、出向社員個人情報１０２内においては、同一の終身ＩＤを有するレコードは複数存在するが、同一の終身ＩＤ及び同一の有効開始年月日時を併せ持つレコードは１つしか存在しない。そして、有効終了年月日時は、基本的に当初は最大値で設定され、新たなレコードが追加されるたびに、次のレコードの有効開始年月日時−１秒に更新される。これにより、同一終身ＩＤのレコードは、時間的に重複することなく、過去・現在・未来に渡り時間的に連続して並ぶことになる。また、任意の一時点において終身ＩＤを検索キーにして検索すると、必ず１つのレコードのみがヒットする。
【００２８】
（派遣社員個人情報１０３）
図５は、本実施形態に係る派遣社員個人情報１０３の一例を示す図である。派遣社員個人情報１０３には、企業グループの全ての派遣社員の個人情報が記憶されている。縦軸にデータ項目が、横軸に個々のデータ（レコード）が並んでいる。
終身ＩＤ欄１５１における終身ＩＤは、図３、図４のものと同じである。
【００２９】
契約番号欄１５２には、契約番号が記憶されている。契約番号は、派遣先企業内で出向除く企業間契約を一意に特定する番号である。派遣先企業欄１５３には、派遣先企業が記憶されている。派遣先企業とは出向除く企業間契約の当事者であり、契約を発注する企業である。
有効開始年月日時欄１５４には、有効開始年月日時が、秒の単位まで、例えば、“２００５０４０１  ００：００：００”のように記憶されている（図では、説明の単純化のため、年月日部分を“Ｔ○”と表現した）。有効開始年月日時は、レコードが有効である期間の始期を意味する。なお、年月日部分は、後記契約開始日と同じ値を設定する。
有効終了年月日時欄１５５には、有効終了年月日時が、秒の単位まで、例えば、“２００６０３３１  ２３：５９：５９”のように記憶されている（図では、説明の単純化のため、年月日部分を“Ｔ○”と表現した）。有効終了年月日時は、レコードが有効である期間の終期を意味する。なお、年月日部分は、後記契約終了日と同じ値を設定する。
【００３０】
さらに、氏名欄１５６には氏名が、生年月日欄１５７には生年月日が、性別欄１５８には性別が、契約開始日欄１５９には契約開始日が、契約終了日欄１６０には契約終了日が、派遣先所属欄１６１には派遣先企業における所属部署が、派遣元企業欄１６２には派遣元企業が記憶されている。派遣元企業とは出向除く企業間契約の当事者であり、契約を受注する企業である。派遣元所属欄１６３には、派遣元企業での所属部署が、在籍元企業欄１６４には在籍元企業が記憶されている。在籍元企業とは、当該派遣社員が正社員または出向社員として属する企業である。在籍元所属欄１６５には在籍元企業における所属部署が、その他情報欄１６６にはその他の情報が記憶されている。
なお、特許請求の範囲における「関連情報」とは、契約番号欄１５２、派遣先企業欄１５３、氏名欄１５６からその他情報欄１６６までに記憶された情報が相当する。
【００３１】
派遣社員個人情報１０３においては、終身ＩＤ、契約番号、及び派遣先企業の組み合わせに関連付けて、それ以外の情報（有効開始年月日時からその他情報まで）が記憶されている。つまり、派遣社員個人情報１０３中に、同一の終身ＩＤを有するレコード、または同一の契約番号を有するレコードは複数存在しうる。また、同一の終身ＩＤかつ同一の契約番号を有するレコードも複数存在しうる。しかし、終身ＩＤと契約番号と派遣先企業とが全て同一のレコードは、一つしか存在しない。
本実施形態では、生年月日、性別、派遣先所属、派遣元所属、在籍元所属、その他情報以外の項目は必須項目である。また、本実施形態では、派遣先企業はグループ企業でなければならない。
【００３２】
ちなみに、図５は、図２における○○○○氏の派遣社員としての経緯を辿るべく、派遣社員個人情報１０３を、終身ＩＤ“１０００００１”を検索キーとして検索した場合の検索結果でもある。横軸方向に、当該終身ＩＤを持つ派遣社員たる“○○○○氏“のレコードが３つ（＃１〜＃３）並んでいる。各レコードの有効期間（有効開始年月日時及び有効終了年月日時）に着目すると、
レコード＃１が“Ｔ６  ００：００：００〜Ｔ７  ２３：５９：５９”、レコード＃２が“Ｔ１０  ００：００：００〜Ｔ１１  ２３：５９：５９”、レコード＃３が“Ｔ１０  ００：００：００〜Ｔ１１  ２３：５９：５９”のように、図２の人事異動例の「Ｔ○」に対応して、時間の経過とともに左から右に並んでいる。そして、当該例では時間的には＃２と＃３は重複している。
【００３３】
レコード＃１は、Ｔ６日の００：００：００から、Ｔ７日の２３：５９：５９まで○○○○氏が契約番号“２０００００１”の出向除く企業間契約に基づき、Ｃ社の仕事をしていることを示す。
レコード＃２は、Ｔ１０日の００：００：００から、Ｔ１１日の２３：５９：５９まで○○○○氏が契約番号“２０００００２”の出向除く企業間契約に基づき、Ａ社の仕事をしていることを示す。
レコード＃３は、Ｔ１０日の００：００：００から、Ｔ１１日の２３：５９：５９まで○○○○氏が契約番号“２０００００２”の出向除く企業間契約に基づき、Ｂ社の仕事をしていることを示す。
さらに、ＴＺ日（Ｔ１１日より後）に、○○○○氏の派遣元企業とグループ企業の一つとの間で、契約終了日がＴＺＺ日（ＴＺ日より後）である出向除く企業間契約が締結されると、＃３の次に有効期間が“ＴＺ  ００：００：００〜ＴＺＺ  ２３：５９：５９”であるレコード（図示せず）が追加される。このとき、直近レコード＃３を含む既存レコードには何の変化も生じない。
【００３４】
このように、派遣社員個人情報１０３内においては、同一の終身ＩＤを有するレコードは複数存在するが、同一の終身ＩＤ、同一の契約番号及び同一の派遣先企業を併せ持つレコードは１つしか存在しない。出向除く企業間契約は期間を定めて締結されるものであるから、有効開始年月日時の年月日部分、有効終了年月日時の年月日部分は、それぞれ契約開始日、契約終了日に一致し、派遣社員個人情報１０３内においては、正社員個人情報１０１及び出向社員個人情報１０２における最大値の概念はない。そして、新レコードが追加されることによる、既存レコードの有効終了年月日時の値の更新もない。
これにより、同一終身ＩＤのレコードは、時間的重複を許容され、過去・現在・未来に渡り並ぶことになる。しかし、任意の一時点において終身ＩＤを検索キーにして検索すると、１つまたは複数のレコードがヒットすることもあるし、全くヒットしないこともある。つまり、レコードの時間的断続も許容される。
【００３５】
（企業区分情報１０４）
図６は、本実施形態に係る企業区分情報１０４の一例を示す図である。企業区分情報１０４には、正社員個人情報１０１、出向社員個人情報１０２及び派遣社員個人情報１０３において記憶される企業（所属企業１１７、出向先企業１１９、１３７、出向元企業１３９、派遣先企業１５３、派遣元企業１６２、在籍元企業１６４）が、グループ企業か否かを区別する情報を記憶する。縦軸にデータ項目が、横軸に個々のデータ（レコード）が並んでいる。
企業名欄１７１には企業名が、企業区分欄１７２には、企業名に関連付けて企業区分が記憶されている。企業区分とは具体的には、当該企業がグループ企業である場合は、“内”、グループ企業でない場合は“外”である。
ちなみに、レコード＃１〜＃３は、Ａ社、Ｂ社及びＣ社がグループ企業であることを、レコード＃４はＤ社がグループ企業ではないことをそれぞれ示している。
【００３６】
（データ内容）
個別企業個人情報管理装置２には、従業員の個人情報が、社員個人情報２００、送信用正社員個人情報２０１、送信用出向社員個人情報２０２、及び送信用派遣社員個人情報２０３の４つに分かれて記憶されている。このうち、社員個人情報２００は、グループ企業が独自に有する個人情報であり、特にデータ項目等の形式（図示せず）は特定されず、例えば就労区分別に複数の別々のデータベースとしてもよい。
しかしながら、グループ個人情報管理装置１において企業グループ全体で個人情報を一元管理するためには、当該社員個人情報２００から、前記正社員個人情報１０１等で管理される項目を抽出した上でフォーマットを統一してグループ個人情報管理装置１に対し送信する必要がある（図１の“個人情報フォーマット”とその左の矢印はこのことを示している）。
このために、個人情報管理部２７は、社員個人情報２００を就労区分ごとに、送信用正社員個人情報２０１、送信用出向社員個人情報２０２、又は送信用派遣社員個人情報２０３に作り直す。
【００３７】
（送信用正社員個人情報２０１）
図７は、本実施形態に係る送信用正社員個人情報２０１の一例を示す図である。
送信用正社員個人情報２０１は、グループ個人情報管理装置１の正社員個人情報１０１が常に最新の情報を維持できるように、個別企業個人情報管理装置２の個人情報管理部２７が、当該個別企業で人事異動等がある都度、正社員個人情報１０１のレコードの新規追加・追加・更新・削除を指示すべく、社員個人情報２００に基づき作成した上で、グループ個人情報管理装置１に対して送信する情報である。なお、情報の作成及び送信は、レコード単位（一つずつ、あるいは一度に複数個纏めて）である。本実施形態では、図７に示したようなデータベース全体を一度に作成、送信するのではない。
【００３８】
縦軸にデータ項目が、横軸に個々のデータ（レコード）が並んでいる。縦軸のデータ項目は、基本的に正社員個人情報１０１の項目に対応している。データ項目のうち異なる点は、就労区分欄２１１、ＩＦ処理区分欄２１２が追加されていること、及び、有効終了年月日時欄に相当する欄を有さないことの２点である。
就労区分欄２１１には就労区分が記憶されている。就労区分は、「正社員」、「出向社員」及び「派遣社員」の中から選択された１つの区分である。
ＩＦ処理区分欄２１２にはＩＦ処理区分が記憶されている。ＩＦ処理区分とは、「新規」「更新」「削除」の中から選択された１つの区分である。
終身ＩＤ欄２１３、有効開始年月日時欄２１４、氏名欄２２１からその他情報欄２２９については、正社員個人情報１０１の項目と同じであるので説明を省略する。
【００３９】
本実施形態では、出向先企業、退職日、その他情報以外の項目は必須項目である。終身ＩＤは、ＩＦ処理区分が「更新」又は「削除」の場合にのみ必須項目である。出向発生時に、出向先企業欄２２６に出向先企業を設定し、雇用終了時に退職日欄２２８に退職日を設定する。また、本実施形態では、所属企業はグループ企業でなければならない。
ちなみに、図７のレコード＃１〜＃６は、図２の○○○○氏の人事異動について、Ａ社（＃１〜＃４）、Ｂ社（＃５〜＃６）から、Ｔ１等の各時点に送信されたものでもある。
本来別々に送信される、各企業からの情報が図７のように一覧されることは実際にはない。しかし、ここでは説明の便宜上、一覧的に表示する。なお、情報送信元を欄外下部に併記した（後記する送信用出向社員個人情報２０２、送信用派遣社員個人情報２０３についても同様）。
【００４０】
レコード＃１は、Ｔ１日に○○○○氏がＡ社の正社員となったとき、Ａ社から送信した情報である（実際の送信時点はＴ１日での人事異動が確定した時点であり、Ｔ１日の少し前になる。以下同様である。）。就労区分欄２１１が“正社員”、ＩＦ処理区分欄２１２が“新規”であり、終身ＩＤ欄２１３は空欄（○○○○氏は過去にグループ企業に所属したことがない）になっている。
レコード＃２は、Ｔ２日に○○○○氏がＢ社へ出向したとき、Ａ社から送信した情報である。就労区分欄２１１が“正社員”、ＩＦ処理区分欄２１２が“更新”であり、終身ＩＤ欄２１３には既に付与されている“１０００００１”が設定されている。出向先企業欄２２６に“Ｂ社”が設定されている。
レコード＃３は、Ｔ３＋１日に○○○○氏がＢ社での出向社員の身分がなくなったとき、Ａ社から送信した情報である。出向先企業欄２２６から値が抹消されている。
レコード＃４は、Ｔ４日に○○○○氏がＡ社を退職したとき、Ａ社から送信した情報である。退職日欄２２８に“Ｔ４”が設定されている。
レコード＃５は、Ｔ５日に○○○○氏がＢ社の正社員となったとき、Ｂ社から送信した情報である。就労区分欄２１１が“正社員”、ＩＦ処理区分欄２１２が“新規”であり、終身ＩＤ欄２１３には既に付与されている“１０００００１”が設定されている。入社日欄２２７には“Ｔ５”が設定されている。
レコード＃６は、Ｔ８日に○○○○氏がＢ社を退職したとき、Ｂ社から送信した情報である。退職日欄２２８に“Ｔ８”が設定されている。
【００４１】
（送信用出向社員個人情報２０２）
図８は、本実施形態に係る送信用出向社員個人情報２０２の一例を示す図である。
送信用出向社員個人情報２０２は、グループ個人情報管理装置１の出向社員個人情報１０２が常に最新の情報を維持できるように、個別企業個人情報管理装置２の個人情報管理部２７が、当該個別企業で人事異動等がある都度、出向社員個人情報１０２のレコードの新規追加・追加・更新・削除を指示すべく、社員個人情報２００に基づき作成した上で、グループ個人情報管理装置１に対して送信する情報である。なお、情報の作成及び送信は、レコード単位（一つずつ、あるいは一度に複数個纏めて）である。本実施形態では、図８に示したようなデータベース全体を一度に作成、送信するのではない。
【００４２】
縦軸にデータ項目が、横軸に個々のデータ（レコード）が並んでいる。縦軸のデータ項目は、基本的に出向社員個人情報１０２の項目に対応している。データ項目のうち異なる点は、就労区分欄２４１、ＩＦ処理区分欄２４２が追加されていること、及び、有効終了年月日時欄１３３に相当する欄を有さないことの２点である。
就労区分欄２４１及びＩＦ処理区分欄２４２については、送信用正社員個人情報２０１におけるものと同様であるので説明は省略する。
終身ＩＤ欄２４３からその他情報欄２５３については、出向社員個人情報１０２の項目と同じであるので説明は省略する。
【００４３】
本実施形態では、出向終了日、その他情報以外の項目は必須項目である。終身ＩＤは、ＩＦ処理区分が「更新」又は「削除」の場合にのみ必須項目である。出向終了時に、出向終了日欄２５２に出向終了日を設定する。また、本実施形態では、出向先企業はグループ企業でなければならない。
ちなみに、図８のレコード＃１〜＃４は、図２の○○○○氏の人事異動について、Ｂ社（＃１、＃２）、Ｃ社（＃３、＃４）から、Ｔ２等の各時点に送信されたものでもある。
【００４４】
レコード＃１は、Ｔ２日に○○○○氏がＢ社の出向社員となったとき、Ｂ社から送信した情報である。就労区分欄２４１が“出向社員”、ＩＦ処理区分欄２４２が“新規”であり、終身ＩＤ欄２４３には“１０００００１”が設定されている（○○○○氏は過去にグループ企業Ａ社の正社員であり終身ＩＤを付与されていた）。出向先企業欄２４８には“Ｂ社”が設定されている。
レコード＃２は、Ｔ３日に○○○○氏のＢ社への出向が終了したとき、Ｂ社から送信した情報である。就労区分欄２４１が“出向社員”、ＩＦ処理区分欄２４２が“更新”であり、終身ＩＤ欄２１３には “１０００００１”が設定されている。出向終了日欄２５２に“Ｔ３”が設定されている。
レコード＃３は、Ｔ１２日に○○○○氏がＣ社の出向社員となったとき、Ｃ社から送信した情報である。出向先企業欄２４８には“Ｃ社”が設定されている。
レコード＃４は、Ｔ１３日に○○○○氏のＣ社への出向が終了したとき、Ｃ社から送信した情報である。出向終了日欄２５２に“Ｔ１３”が設定されている。
【００４５】
（送信用派遣社員個人情報２０３）
図９は、本実施形態に係る送信用派遣社員個人情報２０３の一例を示す図である。
送信用派遣社員個人情報２０３は、グループ個人情報管理装置１の派遣社員個人情報１０３が常に最新の情報を維持できるように、個別企業個人情報管理装置２の個人情報管理部２７が、当該個別企業が発注した出向除く企業間契約の訂正等がある都度、派遣社員個人情報１０３のレコードの新規追加・追加・更新・削除を指示すべく、社員個人情報２００に基づき作成した上で、グループ個人情報管理装置１に対して送信する情報である。なお、情報の作成及び送信は、レコード単位（一つずつ、あるいは一度に複数個纏めて）である。本実施形態では、図９に示したようなデータベース全体を一度に作成、送信するのではない。
【００４６】
縦軸にデータ項目が、横軸に個々のデータ（レコード）が並んでいる。縦軸のデータ項目は、基本的に派遣社員個人情報１０３のデータ項目に対応している。データ項目のうち異なる点は、就労区分欄２６１、ＩＦ処理区分欄２６２が追加されていることである。
就労区分欄２６１及びＩＦ処理区分欄２６２については、送信用正社員個人情報２０１におけるものと同様であるので説明は省略する。
終身ＩＤ欄２６３からその他情報欄２７８については、派遣社員個人情報１０３の項目と同じであるので説明は省略する（一部並び方の順が異なるが項目は同じである）。
【００４７】
本実施形態では、生年月日、性別、派遣先所属、派遣元所属、在籍元所属、その他情報以外の項目は必須項目である。終身ＩＤは、ＩＦ処理区分が「更新」又は「削除」の場合にのみ必須項目である。また、本実施形態では、派遣先企業はグループ企業でなければならない。
ちなみに、図８のレコード＃１〜＃３は、図２の○○○○氏の人事異動について、Ｃ社（＃１）、Ａ社（＃２）、Ｂ社（＃３）から、Ｔ６等の各時点に送信されたものでもある。
【００４８】
レコード＃１は、Ｔ６日に○○○○氏がＣ社の派遣社員となったとき、Ｃ社から送信した情報である。就労区分欄２６１が“派遣社員”、ＩＦ処理区分欄２６２が“新規”であり、終身ＩＤ欄２６３には“１０００００１”が設定されている（○○○○氏は過去にグループ企業Ａ社の正社員であり終身ＩＤを付与されていた）。派遣先企業欄２６６には“Ｃ社”が設定されている。契約番号欄２６５には“２０００００１”が設定されている。契約開始日欄２７１には、“Ｔ６”が、契約終了日欄２７２には“Ｔ７”が設定されており、これらは、それぞれ、有効開始年月日時欄２６４の年月日、有効終了年月日時欄２６７の年月日と同一である。
レコード＃２、＃３については、＃１とほぼ同様であるので説明は省略する。
また、本実施形態においては、出向除く企業間契約の契約終了日は予定されている日であるので、当該予定された契約終了日が到来した場合に、その旨を伝えるデータの送信は不要としている。この点が、雇用終了又は出向終了時における処理手順とは異なる。また、出向除く企業間契約を締結した場合、契約当事者のうち派遣先企業が、データを送信することとしている。
【００４９】
（処理手順：総括）
図１０は、本実施形態に係るグループ個人情報管理装置１の処理手順の全体構成を示すフローチャートである。
ステップＳ４００において、個人情報統括部１０５は、個人情報受信を行う。具体的には、個別企業個人情報管理装置２から送信された、送信用正社員個人情報２０１、送信用出向社員個人情報２０２、送信用派遣社員個人情報２０３のうちの少なくとも一つのデータベースの少なくとも一つのレコード（以下、「送信データ」という）を受信する。
ステップＳ５００において、個人情報統括部１０５は、受信件数確認を行う。具体的には、１度の受信に含まれる送信データの件数を数え、当該件数（「Ｎ」とする）を一時的に主記憶装置１６に記憶する。
【００５０】
ステップＳ６００において、個人情報統括部１０５は、未処理件数確認をする。具体的には、上記Ｎを主記憶装置１６から読み出し、Ｎが０より大きい場合は（ステップＳ６００“＞”）ステップＳ７００に進む。Ｎが０である場合（ステップＳ６００“＝”）はステップＳ１２００に進む。
ステップＳ７００において、個人情報統括部１０５は、就労区分振分を行う。具体的には、送信データに含まれる就労区分２１１、２４１、２６１を照会し、就労区分に応じて、以降の処理手順を選択する。当該就労区分が「正社員」である場合（ステップＳ７００“正社員”）はステップＳ８００に進み、「出向社員」である場合（ステップＳ７００“出向社員”）はステップＳ９００に進み、「派遣社員」である場合（ステップＳ７００“派遣社員”）はステップＳ１０００に進む。
【００５１】
ステップＳ８００においては、正社員個人情報処理部１０６は正社員個人情報処理を行う。ステップＳ９００においては、出向社員個人情報処理部１０７が出向社員個人情報処理を行う。ステップＳ１０００においては、派遣社員個人情報処理部１０８が派遣社員個人情報処理を行う。これら各処理部での具体的処理手順は後記するが、要するに、送信データが、正社員個人情報１０１等の各データベースの内容を変化させる（新規追加、追加、更新、削除の処理をする）ことができるか否かを判断するサブルーチンである。そして、できる場合はデータベースの内容を変化させて終了し、できない場合は、送信データは異常と判断して、上記データベースの内容を変化させずにサブルーチンは終了し（サブルーチンの終了は、図においては「Ｒｅｔｕｒｎ」とした）、次のステップに進む。
【００５２】
なお、正社員、出向社員においては、それぞれの就労区分の中で、任意の一時点で、終身ＩＤと有効開始年月日時の組み合わせでレコードが一意に特定されるように、かつ、特定の終身ＩＤを有するレコードが過去、現在、未来と時間的に連続するように、前記処理がなされることを特徴とする（詳細後記）。
【００５３】
ステップＳ１１００において、個人情報統括部１０５は、未処理件数算出を行う。具体的には、上記Ｎを主記憶装置１６から読み出し、Ｎから1を減じ、その値を再度主記憶装置１６に記憶する。そして、ステップＳ６００に戻る。
ステップＳ１２００において、個人情報統括部１０５は、処理結果返信を行う。具体的には、終了した各処理内容（新たに採番した終身ＩＤを含む）を、あるいは、送信データが異常であり予定の各処理が行われなかった旨を、個別企業個人情報管理装置２に対して返信して全ての処理手順が終了する。
【００５４】
（処理手順：正社員）
図１１、図１２、図１３は、本実施形態に係る正社員個人情報処理部１０６の処理手順を示すフローチャートである。当該フローチャートは、図１０のフローチャートの一部（ステップＳ８００）の詳細内容（サブルーチン）をなすものである。
ステップＳ８０１において、正社員個人情報処理部１０６は、送信元企業の確認をする。具体的には、送信データを送信してきた送信元企業と、送信データの所属企業とを比較する。両者が異なる場合（ステップＳ８０１“≠”）は、ステップＳ８０２に進み、エラー処理をしてサブルーチンを終了する（サブルーチンの終了を、図においては「Ｒｅｔｕｒｎ」と記している。サブルーチンが終了すると、具体的にはステップＳ１１００に進むことになる。以下同様。）。両者が同一である場合（ステップＳ８０１“＝”）は、ステップＳ８０３に進む。
ここで、他企業に所属する正社員についての処理は排除される。
【００５５】
ステップＳ８０３において、正社員個人情報処理部１０６は、ＩＦ処理区分判定を行う。具体的には、送信データに記載のＩＦ処理区分が「新規」、「更新」、「削除」のうちのいずれであるかを判断する。「新規」である場合（ステップＳ８０３“新規”）はステップＳ８１１へ、「更新」である場合（ステップＳ８０３“更新”）はステップＳ８３１（図１２）へ、「削除」である場合（ステップＳ８０３“削除”）はステップＳ８５１（図１３）へそれぞれ進む。
【００５６】
ステップＳ８１１からステップＳ８１８までは、ＩＦ処理区分２１２が「新規」、すなわち雇用が発生した場合の処理である。
ステップＳ８１１において、正社員個人情報処理部１０６は、送信データの必須項目を確認する。終身ＩＤは、ＩＦ処理区分が「新規」である場合は必須項目ではない。必須項目が全て記載されていない場合（ステップＳ８１１“ＮＧ”）は、ステップＳ８１２に進み、エラー処理をしてサブルーチンを終了する。必須項目が全て記載されている場合（ステップＳ８１１“ＯＫ”）は、ステップＳ８１３に進む。
ステップＳ８１３において、正社員個人情報処理部１０６は、送信データは終身ＩＤを含むか否かを確認する。具体的には、送信データの終身ＩＤ欄２１３に値が設定されているか否かを確認する。当該終身ＩＤ欄２１３に値が設定されていない場合（ステップＳ８１３“無”）は、ステップＳ８１４に進み、当該終身ＩＤ欄２１３に値が設定されている場合（ステップＳ８１３“有”）は、ステップＳ８１６に進む。
【００５７】
ステップＳ８１４において、正社員個人情報処理部１０６は、送信データに対し、新たな終身ＩＤを付与する。
ステップＳ８１５において、正社員個人情報処理部１０６は、新たな終身ＩＤを付与された送信データを、正社員個人情報１０１に対し、新たなレコードとして新規追加（「新規追加」の意味は後記）する。このとき、有効終了年月日時には、最大値を設定する（期間雇用正社員の場合は、退職日が一応決まっている前提であるが、実際には、退職が確定するまでは退職日を設定せず、有効終了年月日時には最大値を設定する運用とする）。その後、処理結果正常でサブルーチンを終了する。
ステップＳ８１６において、正社員個人情報処理部１０６は、送信データに記載されている終身ＩＤを確認する。ステップＳ８１６の処理内容は、複雑であるので後記するが、要するに、正社員個人情報１０１におけるレコードのユニーク性維持、及びレコードの時間的連続性維持の観点から判断し、「確認結果正常」又は「確認結果異常」のいずれかの判断結果を生じるものとする。そして、確認結果異常の場合（ステップＳ８１６“ＮＧ”）は、ステップＳ８１７に進みエラー処理をしてサブルーチンを終了する。確認結果正常の場合（ステップＳ８１６“ＯＫ”）は、ステップＳ８１８に進む。
【００５８】
ステップＳ８１８において、正社員個人情報処理部１０６は、送信データに基づいて正社員個人情報１０１のレコードを、新規追加、追加、又は更新する。
ここで、「新規追加」とは、当該終身ＩＤを有するレコードが存在しない場合に、当該終身ＩＤを含むレコードを、初めて作製することをいう。「追加」とは、当該終身ＩＤを有するレコードが既に存在する場合に、同一終身ＩＤを有する別のレコードをさらに作製することをいう。「更新」とは、当該終身ＩＤを有するレコードが既に存在する場合に、当該レコードの内容を修正することをいう。ＩＦ処理区分の「更新」とは別の意味で、ステップＳ８１８で当該語を使用している（後記ステップＳ８３５、Ｓ８５５、Ｓ９１８、Ｓ９３５、Ｓ９５５、Ｓ１０１８、Ｓ１０３５においても同様）。
【００５９】
ステップＳ８１８の処理手順を詳細に説明する。
まず、正社員個人情報処理部１０６は、送信データの終身ＩＤを含み、かつ、送信データの有効開始年月日時を有効期間に含むレコードを、正社員個人情報１０１のなかで検索する。検索結果は、レコードが１件発見される、あるいは全く発見されない、のいずれかである。
検索結果が０件の場合、正社員個人情報処理部１０６は、送信データの内容を正社員個人情報１０１に新規追加する。このとき、新規追加レコードの有効終了年月日時には最大値を設定し（期間雇用正社員の場合も）、処理結果正常でサブルーチンを終了する。
検索結果が１件の場合、正社員個人情報処理部１０６は、検索の結果発見したレコード（以降「検索結果レコード」という）の有効終了年月日時の値を、送信データに記載の有効開始年月日時の値−１秒に更新し、同時に、送信データの内容を正社員個人情報１０１に新レコードとして追加する。このとき、追加レコードの有効終了年月日時には最大値を設定し（期間雇用正社員の場合も）、処理結果正常でサブルーチンを終了する。
【００６０】
図１２のステップＳ８３１からステップＳ８３５までは、ＩＦ処理区分が「更新」、すなわち異動（退職含む）等により、正社員個人情報１０１の情報を訂正する必要が発生した場合の処理である。
ステップＳ８３１において、正社員個人情報処理部１０６は、送信データの必須項目を確認する。必須項目が全て記載されていない場合（ステップＳ８３１“ＮＧ”）は、ステップＳ８３２に進み、エラー処理をしてサブルーチンを終了する。必須項目が全て記載されている場合（ステップＳ８３１“ＯＫ”）は、ステップＳ８３３に進む。
【００６１】
ステップＳ８３３において、正社員個人情報処理部１０６は、送信データの終身ＩＤを確認する。具体的には、送信データの終身ＩＤを含み、かつ、送信データの所属企業を含み、かつ、送信データの有効開始年月日時を有効期間に含むレコードを、正社員個人情報１０１のなかで検索する。検索結果は、レコードが１件発見される、あるいは全く発見されない、のいずれかである。
検索結果が０件の場合（ステップＳ８３３“ＮＧ”）、ステップＳ８３４に進み、エラー処理をしてサブルーチンを終了する。
検索結果が１件で、かつ、送信データの退職日欄２２８に値が設定されており、かつ、送信データの退職日＜送信データの有効開始年月日時である場合（ステップＳ８３３“ＮＧ”）も、ステップＳ８３４に進み、エラー処理をしてサブルーチンを終了する。ここで、退職日翌日以降の正社員の身分がない状態（退職状態）の正社員個人情報の更新処理は排除される。
上記以外の場合は、ステップＳ８３５に進む。
以降、２つの日時を示す値の間に「＜」、「＞」「≦」、「≧」を記した場合は、その前に記した日時が後に記した日時に比して、それぞれ、先であること、後であること、先であるか又は等しいこと、後であるか又は等しいことを意味する。「＝」、「≠」の場合は、２つの日時がそれぞれ、等しいこと、等しくないことを意味する。
【００６２】
ステップＳ８３５において、正社員個人情報処理部１０６は、送信データに基づいて正社員個人情報１０１のレコードを追加、又は更新する。
（ステップＳ８３５：パターン１）
検索結果レコードの有効終了年月日時＝最大値であり、かつ、検索結果レコードの有効開始年月日時≠送信データの有効開始年月日時である場合は、検索結果レコードの有効終了年月日時の値を、送信データの有効開始年月日時の値−１秒に更新し、同時に、送信データの内容を正社員個人情報１０１に新レコードとして追加する。このとき、追加レコードの有効終了年月日時には最大値を設定し、処理結果正常でサブルーチンを終了する。当該パターンは、企業内異動等、最も頻度が多いパターンである。
（ステップＳ８３５：パターン２）
検索結果レコードの有効終了年月日時＝最大値であり、かつ、検索結果レコードの有効開始年月日時＝送信データの有効開始年月日時である場合は、検索結果レコードの有効終了年月日時以外を送信データの内容に置き換えて更新し、処理結果正常でサブルーチンを終了する。当該パターンは、最遅レコードにおける単純誤記の修正等のパターンである。
（ステップＳ８３５：パターン３）
検索結果レコードの有効終了年月日時≠最大値であり、かつ、検索結果レコードの有効開始年月日時≠送信データの有効開始年月日時である場合は、検索結果レコードの有効終了年月日時の値を、送信データの有効開始年月日時の値−１秒に更新し、同時に、送信データの内容を正社員個人情報１０１に追加する。このとき、追加レコードの有効終了年月日時には、検索結果レコードの有効終了年月日時の値を設定し、処理結果正常でサブルーチンを終了する。当該パターンは、最遅レコード以前に、遡及して（送信し忘れていた）別レコードを挿入する等のパターンである。
（ステップＳ８３５：パターン４）
検索結果レコードの有効終了年月日時≠最大値であり、かつ、検索結果レコードの有効開始年月日時＝送信データの有効開始年月日時である場合は、検索結果レコードの有効終了年月日時以外を送信データの内容に置き換えて更新し、処理結果正常でサブルーチンを終了する。当該パターンは、最遅レコード以外のレコードおける単純誤記の修正等のパターンである。
【００６３】
退職の場合も、上記と同じ処理を行う。退職した場合、又は退職予定がある場合、退職日欄１２１に退職日が設定され、かつ、有効開始年月日時が退職日の「退職済み又は退職予定レコード」が正社員個人情報１０１に記憶されることになる（図３のレコード＃４、＃６参照）。
出向終了の場合も、上記と同じ処理を行う。出向終了した場合、又は出向終了予定がある場合、出向先企業欄１１９に値が設定されていない、かつ、有効開始年月日時が出向終了日翌日の「出向終了済み又は出向終了予定レコード」が正社員個人情報１０１に記憶されることになる（図３のレコード＃３参照）。
【００６４】
図１３のステップＳ８５１以降ステップＳ８５５までは、ＩＦ処理区分が「削除」、すなわち雇用取消が発生した場合の処理である。雇用取消と退職とは明確に区別され、雇用取消とは、将来における雇用予定の取消（内定取消）を意味する。
ステップＳ８５１において、正社員個人情報処理部１０６は、送信データの必須項目を確認する。必須項目が全て記載されていない場合（ステップＳ８５１“ＮＧ”）は、ステップＳ８５２に進み、エラー処理をしてサブルーチンを終了する。必須項目が全て記載されている場合（ステップＳ８５１“ＯＫ”）は、ステップＳ８５３に進む。
【００６５】
ステップＳ８５３において、正社員個人情報処理部１０６は、送信データの終身ＩＤを確認する。具体的には、まず、送信データの有効開始年月日時と現在年月日時を比較する。
送信データの有効開始年月日時＜現在年月日時である場合（ステップＳ８５３“ＮＧ”）は、ステップＳ８５４に進み、エラー処理をしてサブルーチンを終了する。雇用取消は、雇用開始前に実施されることを前提としている。
【００６６】
送信データの有効開始年月日時＜現在年月日時でない場合は、送信データの終身ＩＤを含み、かつ、送信データの所属企業を含み、かつ、有効開始年月日時が送信データの有効開始年月日時であるレコードを、正社員個人情報１０１のなかで検索する。検索結果は、レコードが１件発見される、あるいは全く発見されない、のいずれかである。
ここでは、雇用開始が内定した際に記憶したレコードを検索していることになる。
検索結果が０件の場合（ステップＳ８５３“ＮＧ”）も、ステップＳ８５４に進み、処理結果異常でサブルーチンを終了する。
検索結果が１件の場合（ステップＳ８５３“ＯＫ”）、ステップＳ８５５に進む。
【００６７】
ステップＳ８５５において、正社員個人情報処理部１０６は、送信データに基づいて正社員個人情報１０１のレコードを更新、又は削除する。
具体的には、まず、送信データの終身ＩＤを含み、かつ、有効終了年月日時が、ステップＳ８５３における検索結果レコードの有効開始年月日時の値−１秒であるレコードを、正社員個人情報１０１のなかで検索する。検索結果は、レコードが１件発見される、あるいは全く発見されない、のいずれかである。ここでは、雇用開始が内定する際に記憶したレコードの直前のレコード（正社員が一旦退職して復職が内定する場合など、退職状態を示すレコードが存在する）を検索していることになる。
（ステップＳ８５５：パターン１）
ステップＳ８５５における検索結果が０件である場合、ステップＳ８５３における検索結果レコードを削除し、処理結果正常でサブルーチンを終了する。当該パターンは、単純な雇用予定の取消（内定取消）のパターンである。
（ステップＳ８５５：パターン２）
ステップＳ８５５における検索結果が１件であり、かつ、ステップＳ８５３における検索結果レコードの有効終了年月日時＝最大値である場合、ステップＳ８５５における検索結果レコードの有効終了年月日時を最大値に更新する。同時に、ステップＳ８５３における検索結果レコードを削除し、処理結果正常でサブルーチンを終了する。
（ステップＳ８５５：パターン３）
ステップＳ８５５における検索結果が１件であり、かつ、ステップＳ８５３における検索結果レコードの有効終了年月日時≠最大値である場合（教育期間やその後の配属先等、入社日以降の異動が予め決まっており、当該雇用に係わるレコードが複数存在する場合）、ステップＳ８５５における検索結果レコードの有効終了年月日時をステップＳ８５３における検索結果レコードの有効終了年月日時に更新する。同時に、ステップＳ８５３における検索結果レコードを削除し、処理結果正常でサブルーチンを終了する。  
【００６８】
図１４は、本実施形態に係る正社員個人情報処理部１０６の処理手順のうち、ステップＳ８１６の詳細を示すフローチャートである。
ステップＳ８１６-１において、正社員個人情報処理部１０６は、送信データの終身ＩＤは既存か否かを確認する。具体的には、送信データの終身ＩＤを含むレコードが、正社員個人情報１０１、出向社員個人情報１０２又は派遣社員個人情報１０３のなかに既に存在しているか否かを確認する。存在しない場合（ステップＳ８１６−１“無”）、ステップＳ８１６-２に進み、確認結果異常でステップＳ８１６を終了する（図においては、「Ｒｅｔｕｒｎ」と記している）。存在する場合（ステップＳ８１６−１“有”）、ステップＳ８１６−３に進む。ここで、例えば桁違い等誤った終身ＩＤを有する送信データは排除される。
【００６９】
ステップＳ８１６−３において、正社員個人情報処理部１０６は、送信データの終身ＩＤを有するレコードが、正社員個人情報１０１の中に存在するか否かを確認する。存在しない場合（ステップＳ８１６-３“無”）、ステップＳ８１６−４に進み、確認結果正常でステップＳ８１６を終了する。存在する場合（ステップＳ８１６−３“有”）、ステップＳ８１６−５に進む。
【００７０】
ステップＳ８１６−５において、正社員個人情報処理部１０６は、レコ−ドに退職日が設定されているか否かを確認する。具体的には、送信デ−タの終身ＩＤ３を有し、かつ、送信デ−タの有効開始年月日時を有効期間に含むレコ−ドを正社員個人情報１０１の中で検索し、当該レコ−ドに退職日が設定されているか否かを確認する。退職日が設定されていない場合（ステップＳ８１６−５“ＮＯ”）は、ステップＳ８１６−６に進み、確認結果異常でステップＳ８１６を終了する。退職日が設定されている場合（ステップＳ８１６−５“ＹＥＳ”）は、ステップＳ８１６−７に進む。
【００７１】
ステップＳ８１６−７において、正社員個人情報処理部１０６は、ステップＳ８１６−５において検索したレコ−ドの退職日と送信デ−タの入社日を比較する。
検索結果レコ−ドの退職日＜送信デ−タの入社日である場合（ステップＳ８１６−７“＜”）は、ステップＳ８１６−８に進み、確認結果正常でステップＳ８１６を終了する。検索結果レコ−ドの退職日＜送信デ−タの入社日でない場合（ステップＳ８１６−７“≧”）は、ステップＳ８１６−９に進み、確認結果異常でステップＳ８１６を終了する。
ステップＳ８１６−３からステップＳ８１６−９の処理手順においては、正社員個人情報１０１の中で既存のレコ−ドと時間的に重複する、又は重複する可能性のある送信デ−タを排除していることになる。
（処理手順：出向社員）
【００７２】
図１５、図１６、図１７は、本実施形態に係る出向社員個人情報処理部１０７の処理手順を示すフローチャートである。当該フローチャートは、図１０のフローチャートの一部（ステップＳ９００）の詳細内容（サブルーチン）をなすものである。
ステップＳ９０１において、送信元企業の確認をする。具体的には、送信データを送信してきた送信元企業と、送信データの出向先企業とを比較する。両者が異なる場合（ステップＳ９０１“≠”）は、ステップＳ９０２に進み、エラー処理をしてサブルーチンを終了する。両者が同一である場合（ステップＳ９０１“＝”）は、ステップＳ９０３に進む。
ここで、他社に出向する出向社員についての処理は排除される。
【００７３】
ステップＳ９０３において、出向社員個人情報処理部１０７は、ＩＦ処理区分判定を行う。具体的には、送信データに記載のＩＦ処理区分が「新規」、「更新」、「削除」のうちのいずれであるかを判断する。「新規」である場合（ステップＳ９０３“新規”）はステップＳ９１１へ、「更新」である場合（ステップＳ９０３“更新”）はステップＳ９３１（図１６）へ、「削除」である場合（ステップＳ９０３“新規”）はステップＳ９５１（図１７）へそれぞれ進む。
【００７４】
ステップＳ９１１からステップＳ９１８までは、ＩＦ処理区分が「新規」、すなわち出向開始が発生した場合の処理である。
ステップＳ９１１において、出向社員個人情報処理部１０７は、送信データの必須項目を確認する。終身ＩＤは、ＩＦ処理区分が「新規」である場合は必須項目ではない。必須項目が全て記載されていない場合（ステップＳ９１１“ＮＧ”）は、ステップＳ９１２に進み、エラー処理をしてサブルーチンを終了する。必須項目が全て記載されている場合（ステップＳ９１１“ＯＫ”）は、ステップＳ９１３に進む。
【００７５】
ステップＳ９１３において、出向社員個人情報処理部１０７は、送信データは終身ＩＤを含むか否かを確認する。具体的には、送信データの終身ＩＤ欄に値が設定されているか否かを確認する。当該終身ＩＤ欄に値が設定されていない場合（ステップＳ９１３“無”）は、ステップＳ９１４に進み、当該終身ＩＤ欄２４３に値が設定されている場合（ステップＳ９１３“有”）は、ステップＳ９１６に進む。
【００７６】
ステップＳ９１４において、出向社員個人情報処理部１０７は、送信データに対し、新たな終身ＩＤを付与する。
ステップＳ９１５において、出向社員個人情報処理部１０７は、新たな終身ＩＤを付与された送信データを、出向社員個人情報１０２に対し、新たなレコードとして新規追加
する。このとき、有効終了年月日時には、最大値を設定する。その後、処理結果正常でサブルーチンを終了する。
ステップＳ９１６において、出向社員個人情報処理部１０７は、送信データの終身ＩＤ２４３を確認する。ステップＳ９１６の処理内容は、複雑であるので後記するが、要するに、出向社員個人情報１０２におけるレコードのユニーク性維持、及びレコードの時間的連続性維持の観点から判断し、「確認結果正常」又は「確認結果異常」のいずれかの判断結果を生じるものとする。そして、確認結果異常の場合（ステップＳ９１６“ＮＧ”）は、ステップＳ９１７に進み、エラー処理をしてサブルーチンを終了する。確認結果正常の場合（ステップＳ９１６“ＯＫ”）は、ステップＳ９１８に進む。
【００７７】
ステップＳ９１８において、出向社員個人情報処理部１０７は、送信データに基づいて出向社員個人情報１０２のレコードを、新規追加、追加、又は更新する。
ここで、「新規追加」、「追加」、「更新」の意味は、正社員個人情報処理部１０６の処理手順において説明した通りである。
ステップＳ９１８の処理手順を詳細に説明する。
まず、出向社員個人情報処理部１０７は、送信データの終身ＩＤを含み、かつ、送信データの有効開始年月日時を有効期間に含むレコードを、出向社員個人情報１０２のなかで検索する。検索結果は、レコードが１件発見される、あるいは全く発見されない、のいずれかである。
検索結果が０件の場合、出向社員個人情報処理部１０７は、送信データの内容を出向社員個人情報１０２に新規追加する。このとき、新規追加レコードの有効終了年月日時には最大値を設定し、処理結果正常で終了する
検索結果が１件の場合、出向社員個人情報処理部１０７は、検索結果レコードの有効終了年月日時の値を、送信データの有効開始年月日時の値−１秒に更新し、同時に、送信データの内容を出向社員個人情報１０２に新レコードとして追加する。このとき、追加レコードの有効終了年月日時には最大値を設定し、処理結果正常でサブルーチンを終了する。
【００７８】
図１６のステップＳ９３１からステップＳ９３５までは、ＩＦ処理区分が「更新」、すなわち出向先企業での異動（出向終了含む）等により、出向社員個人情報１０２の情報を訂正する必要が発生した場合の処理である。
ステップＳ９３１において、出向社員個人情報処理部１０７は、送信データの必須項目を確認する。必須項目が全て記載されていない場合（ステップＳ９３１“ＮＧ”）は、ステップＳ９３２に進み、エラー処理をしてサブルーチンを終了する。必須項目が全て記載されている場合（ステップＳ９３１“ＯＫ”）は、ステップＳ９３３に進む。
ステップＳ９３３において、出向社員個人情報処理部１０７は、送信データの終身ＩＤを確認する。具体的には、送信データの終身ＩＤを含み、かつ、送信データの出向先企業を含み、かつ、送信データの有効開始年月日時を有効期間に含むレコードを、出向社員個人情報１０２のなかで検索する。検索結果は、レコードが１件発見される、あるいは全く発見されない、のいずれかである。
【００７９】
検索結果が０件の場合（ステップＳ９３３“ＮＧ”）、ステップＳ９３４に進み、エラー処理をしてサブルーチンを終了する。
検索結果が１件で、かつ、送信データの出向終了日欄２５２に値が設定されており、かつ、送信データの出向終了日＜送信データの有効開始年月日時である場合（ステップＳ９３３“ＮＧ”）も、ステップＳ９３４に進み、エラー処理をしてサブルーチンを終了する。ここで、出向終了日翌日以降の出向社員の身分がない状態の出向社員個人情報の更新処理は排除される。
上記以外の場合は、ステップＳ９３５に進む。
【００８０】
ステップＳ９３５において、出向社員個人情報処理部１０７は、送信データに基づいて出向社員個人情報１０２のレコードを追加、又は更新する。
（ステップＳ９３５：パターン１）
検索結果レコードの有効終了年月日時＝最大値であり、かつ、検索結果レコードの有効開始年月日時≠送信データの有効開始年月日時である場合は、検索結果レコードの有効終了年月日時の値を、送信データの有効開始年月日時の値−１秒に更新し、同時に、送信データの内容を出向社員個人情報１０２に新レコードとして追加する。このとき、追加レコードの有効終了年月日時には最大値を設定し、処理結果正常でサブルーチンを終了する。当該パターンは、出向先企業内での異動等、最も頻度が多いパターンである。
（ステップＳ９３５：パターン２）
検索結果レコードの有効終了年月日時＝最大値であり、かつ、検索結果レコードの有効開始年月日時＝送信データの有効開始年月日時である場合は、検索結果レコードの有効終了年月日時以外を送信データの内容に置き換えて更新し、処理結果正常でサブルーチンを終了する。当該パターンは、最遅レコードにおける単純誤記の修正等のパターンである。
（ステップＳ９３５：パターン３）
検索結果レコードの有効終了年月日時≠最大値であり、かつ、検索結果レコードの有効開始年月日時≠送信データの有効開始年月日時である場合は、検索結果レコードの有効終了年月日時の値を、送信データに記載の有効開始年月日時の値−１秒に更新し、同時に、送信データの内容を出向社員個人情報１０２に追加する。このとき出向社員個人情報１０２における追加レコードの有効終了年月日時には、検索結果レコードの有効終了年月日時の値を設定し、処理結果正常でサブルーチンを終了する。当該パターンは、最遅レコード以前に、遡及して（送信し忘れていた）別レコードを挿入する等のパターンである。
（ステップＳ９３５：パターン４）
検索結果レコードの有効終了年月日時≠最大値であり、かつ、検索結果レコードの有効開始年月日時＝送信データの有効開始年月日時である場合は、検索結果レコードの有効終了年月日時以外を送信データの内容に置き換えて更新し、処理結果正常で終了する。当該パターンは、最遅レコード以外のレコードおける単純誤記の修正等のパターンである。
【００８１】
出向終了の場合も、上記と同じ処理を行う。出向終了した場合、又は出向終了予定がある場合、出向終了日欄１４１に出向終了日が設定され、かつ、有効開始年月日時が出向終了日の「出向終了済み又は出向終了予定レコード」が出向社員個人情報１０２に記憶されることになる（図４のレコード＃２、＃４参照）。
【００８２】
図１７のステップＳ９５１からステップＳ９５５までは、ＩＦ処理区分が「削除」、すなわち出向取消が発生した場合の処理である。出向取消と出向終了とは明確に区別され、出向取消とは、将来における出向予定の取消（内定取消）を意味する。
ステップＳ９５１において、出向社員個人情報処理部１０７は、送信データの必須項目を確認する。必須項目が全て記載されていない場合（ステップＳ９５１“ＮＧ”）は、ステップＳ９５２に進み、エラー処理をしてサブルーチンを終了する。必須項目が全て記載されている場合（ステップＳ９５１“ＯＫ”）は、ステップＳ９５３に進む。
【００８３】
ステップＳ９５３において、出向社員個人情報処理部１０７は、送信データの終身ＩＤを確認する。具体的には、まず、送信データの有効開始年月日時と現在年月日時を比較する。
送信データの有効開始年月日時＜現在年月日時である場合（ステップＳ９５３“ＮＧ”）は、ステップＳ９５４に進み、エラー処理をしてサブルーチンを終了する。出向取消は、出向開始前に実施されることを前提としている。
送信データの有効開始年月日時＜現在年月日時でない場合は、送信データの終身ＩＤを含み、かつ、送信データの出向先企業を含み、かつ、有効開始年月日時が送信データの有効開始年月日時であるレコードを、出向社員個人情報１０２のなかで検索する。検索結果は、レコードが１件発見される、あるいは全く発見されない、のいずれかである。ここでは、出向開始が内定した際に記憶したレコードを検索していることになる。
検索結果が０件の場合（ステップＳ９５３“ＮＧ”）も、ステップＳ９５４に進み、エラー処理をしてサブルーチンを終了する
検索結果が１件の場合（ステップＳ９５３“ＯＫ”）、ステップＳ９５５に進む。
【００８４】
ステップＳ９５５において、出向社員個人情報処理部１０７は、送信データに基づいて出向社員個人情報１０２のレコードを更新、又は削除する。
具体的には、まず、送信データに記載されている終身ＩＤを含み、かつ、有効終了年月日時が、ステップＳ９５３における検索結果レコードの有効開始年月日時の値−１秒であるレコードを、出向社員個人情報１０２のなかで検索する。検索結果は、レコードが１件発見される、あるいは全く発見されない、のいずれかである。ここでは、出向開始が内定する際に記憶したレコードの直前のレコード（出向社員が一旦出向終了して再度出向が内定する場合など、出向終了状態を示すレコードが存在する）を検索していることになる。
（ステップＳ９５５：パターン１）
ステップＳ９５５における検索結果が０件である場合、ステップＳ９５３における検索結果レコードを削除し、処理結果正常でサブルーチンを終了する。
（ステップＳ９５５：パターン２）
ステップＳ９５５における検索結果が１件であり、かつ、ステップＳ９５３における検索結果レコードの有効終了年月日時＝最大値である場合、ステップＳ９５５における検索結果レコードの有効終了年月日時を最大値に更新する。同時に、ステップＳ９５３における検索結果レコードを削除し、処理結果正常でサブルーチンを終了する。
（ステップＳ９５５：パターン３）
ステップＳ９５５における検索結果が１件であり、かつ、ステップＳ９５３における検索結果レコードの有効終了年月日時≠最大値である場合（教育期間やその後の配属先等、出向日以降の異動が予め決まっており、当該出向に係わるレコードが複数存在する場合）、ステップＳ９５５における検索結果レコードの有効終了年月日時をステップＳ９５３における検索結果レコードの有効終了年月日時に更新する。同時に、ステップＳ９５３における検索結果レコードを削除し、処理結果正常でサブルーチンを終了する。
【００８５】
図１８、図１９、図２０は、本実施形態に係る出向社員個人情報処理部１０７の処理手順のうち、ステップＳ９１６の詳細を示すフローチャートである。
ステップＳ９１６−１において、出向社員個人情報処理部１０７は、送信デ−タの終身ＩＤは既存か否かを確認する。具体的には、送信デ−タの終身ＩＤを含むレコ−ドが、正社員個人情報１０１、出向社員個人情報１０２、又は派遣社員個人情報１０３のなかに既に存在しているか否かを確認する。存在しない場合（ステップＳ９１６−１“無”）、ステップＳ９１６−２に進み、確認結果異常でステップＳ９１６を終了する。存在する場合（ステップＳ９１６−１“有”）、ステップＳ９１６−３に進む。ここで、例えば桁違い等誤った終身ＩＤを有する送信デ−タは排除される。
【００８６】
ステップＳ９１６−３において、出向社員個人情報処理部１０７は、送信デ−タの終身ＩＤを有するレコ−ドが、出向社員個人情報１０２の中に存在するか否かを確認する。存在しない場合（ステップＳ９１６−３“無”）、ステップＳ９１６−８（図１９）に進む。存在する場合（ステップＳ９１６−３“有”）、ステップＳ９１６−４に進む。
ステップＳ９１６−４において、出向社員個人情報処理部１０７は、レコ−ドに出向終了日が設定されているか否かを確認する。具体的には、送信デ−タの終身ＩＤを有し、かつ、送信デ−タの有効開始年月日時２４４を有効期間に含むレコ−ドを出向社員個人情報１０２の中で検索し、当該レコ−ドに出向終了日が設定されているか否かを確認する。出向終了日が設定されていない場合（ステップＳ９１６−４“ＮＯ”）は、ステップＳ９１６−５に進み、確認結果異常でステップＳ９１６を終了する。出向終了日が設定されている場合（ステップＳ９１６−４“ＹＥＳ”）は、ステップＳ９１６−６に進む。
【００８７】
ステップＳ９１６−６において、出向社員個人情報処理部１０７は、ステップＳ９１６−４において検索したレコ−ドの出向終了日と送信デ−タの出向開始日とを比較する。
検索結果レコ−ドの出向終了日＜送信デ−タの出向開始日である場合（ステップＳ９１６−６“＜”）は、ステップＳ９１６−８（図１９）に進む。検索結果レコ−ドの出向終了日＜送信デ−タの出向開始日でない場合（ステップＳ９１６−６“≧”）は、ステップＳ９１６−７に進み、確認結果異常でステップＳ９１６を終了する。
【００８８】
図１９のステップＳ９１６−８において、出向社員個人情報処理部１０７は、送信デ−タの終身ＩＤを有するレコ−ドが、正社員個人情報１０１の中に存在するか否かを確認する。存在しない場合（ステップＳ９１６−８“無”）、ステップＳ９１６−９に進み、確認結果正常でステップＳ９１６を終了する。存在する場合（ステップＳ９１６−８“有”）、ステップＳ９１６−１０に進む。
【００８９】
ステップＳ９１６−１０において、出向社員個人情報処理部１０７は、検索結果レコ−ドの所属企業と送信デ−タの出向元企業とを比較する。具体的には、送信デ−タの終身ＩＤを含み、かつ、送信デ−タの有効開始年月日時を有効期間に含むレコ−ドを正社員個人情報１０１内で検索し、検索結果レコ−ドの所属企業と、送信デ−タの出向元企業とを比較する。検索結果レコ−ドの所属企業≠送信デ−タの出向元企業である場合（ステップＳ９１６−１０“≠”）は、ステップＳ９１６−１６（図２０）に進む。検索結果レコ−ドの所属企業＝送信デ−タの出向元企業である場合（ステップＳ９１６−１０“＝”）は、ステップＳ９１６−１１に進む。
【００９０】
ステップＳ９１６−１１において、出向社員個人情報処理部１０７は、検索結果レコードに退職日が設定されているか否かを確認する。具体的には、ステップＳ９１６−１０における検索結果レコードの退職日に退職日が設定されていない場合（ステップＳ９１６−１１“ＮＯ”）は、ステップＳ９１６−１２に進み、確認結果正常でステップＳ９１６を終了する。ステップＳ９１６−１０における検索結果レコードの退職日に退職日が設定されている場合（ステップＳ９１６−１１“ＹＥＳ”）は、ステップＳ９１６−１３に進む。
【００９１】
ステップＳ９１６−１３において、出向社員個人情報処理部１０７は、検索結果レコードの退職日と送信データの出向開始日とを比較する。具体的には、ステップＳ９１６−１０における検索結果レコードの退職日＜送信データの出向開始日である場合（ステップＳ９１６−１３“＜”）は、ステップＳ９１６−１４に進み、確認結果異常でステップＳ９１６を終了する。ステップＳ９１６−１０における検索結果レコードの退職日≧送信データの出向開始日である場合（ステップＳ９１６−１３“≧”）は、ステップＳ９１６−１５に進み、確認結果正常でステップＳ９１６を終了する。
【００９２】
ステップＳ９１６−１６において、出向社員個人情報処理部１０７は、検索結果レコードに退職日が設定されているかを確認する。具体的には、ステップＳ９１６−１０における検索結果レコードの退職日に退職日が設定されていない場合（ステップＳ９１６−１６“ＮＯ”）は、ステップＳ９１６−１７に進み、確認結果異常でステップＳ９１６を終了する。ステップＳ９１６−１０における検索結果レコードの退職日に退職日が設定されている場合（ステップＳ９１６−１６“ＹＥＳ”）は、ステップＳ９１６−１８に進む。
【００９３】
ステップＳ９１６−１８において、出向社員個人情報処理部１０７は、検索結果レコードの退職日と送信データの出向開始日とを比較する。具体的には、ステップＳ９１６−１０における検索結果レコードの退職日＜送信データの出向開始日である場合（ステップＳ９１６−１８“＜”）は、ステップＳ９１６−１９に進み、確認結果正常でステップＳ９１６を終了する。ステップＳ９１６−１０における検索結果レコードの退職日≧送信データの出向開始日である場合（ステップＳ９１６−１８“≧”）は、ステップＳ９１６-２０に進み、確認結果異常でステップＳ９１６を終了する。
ステップＳ９１６−３からステップＳ９１６−２０の処理手順においては、出向社員個人情報１０２の中で既存のレコ−ドと時間的に重複する、又は重複する可能性のある送信デ−タ、及び正社員個人情報１０１における所属企業との矛盾を生じる送信デ−タは排除される。
【００９４】
（処理手順：派遣社員）
図２１、図２２、図２３は、本実施形態に係る派遣社員個人情報処理部１０８の処理手順を示すフローチャートである。当該フローチャートは、図１０のフローチャートの一部（ステップＳ１０００）の詳細内容（サブルーチン）をなすものである。
ステップＳ１００１において、送信元企業の確認をする。具体的には、送信データを送信してきた送信元企業と、送信データの派遣先企業とを比較する。両者が異なる場合（ステップＳ１００１“≠”）は、ステップＳ１００２に進み、エラー処理をしてサブルーチンを終了する。両者が同一である場合（ステップＳ１００１“＝”）は、ステップＳ１００３に進む。
ここで、他社が発注した派遣社員についての処理は排除される。
【００９５】
ステップＳ１００３において、派遣社員個人情報処理部１０８は、ＩＦ処理区分判定を行う。具体的には、送信データのＩＦ処理区分が「新規」、「更新」、「削除」のうちのいずれであるかを判断する。「新規」である場合（ステップＳ１００３“新規”）はステップＳ１０１１へ、「更新」である場合（ステップＳ１００３“更新”）はステップＳ１０３１（図２２）へ、「削除」である場合（ステップＳ１００３“新規”）はステップＳ１０５１（図２３）へそれぞれ進む。
【００９６】
ステップＳ１０１１からステップＳ１０１８までは、ＩＦ処理区分が「新規」、すなわち出向除く企業間契約が発生した場合の処理である。
ステップＳ１０１１において、派遣社員個人情報処理部１０８は、送信データの必須項目を確認する。終身ＩＤは、ＩＦ処理区分が「新規」である場合は必須項目ではない。必須項目が全て記載されていない場合（ステップＳ１０１１“ＮＧ”）は、ステップＳ１０１２に進み、エラー処理をしてサブルーチンを終了する。必須項目が全て記載されている場合（ステップＳ１０１１“ＯＫ”）は、ステップＳ１０１３に進む。
【００９７】
ステップＳ１０１３において、派遣社員個人情報処理部１０８は、送信データは終身ＩＤを含むか否かを確認する。具体的には、送信データの終身ＩＤ欄２６３に値が設定されているか否かを確認する。当該終身ＩＤ欄２６３に値が設定されていない場合（ステップＳ１０１３“無”）は、ステップＳ１０１４に進み、当該終身ＩＤ欄２６３に値が設定されている場合（ステップＳ１０１３“有”）は、ステップＳ１０１６に進む。
【００９８】
ステップＳ１０１４において、派遣社員個人情報処理部１０８は、送信データに対し、新たな終身ＩＤを付与する。
ステップＳ１０１５において、派遣社員個人情報処理部１０８は、新たな終身ＩＤを付与された送信データを、派遣社員個人情報１０３に対し、新たなレコードとして新規追加
する。このとき、新規追加レコードの有効終了年月日時には、送信データの有効終了年月日時の値を設定する（最大値を設定するのではない）。その後、処理結果正常でサブルーチンを終了する。
ステップＳ１０１６において、派遣社員個人情報処理部１０８は、送信データの終身ＩＤを確認する。ステップＳ１０１６の処理内容は、複雑であるので後記するが、要するに、「確認結果正常」又は「確認結果異常」のいずれかの判断結果を生じるものとする。そして、確認結果異常の場合（ステップＳ１０１６“ＮＧ”）は、ステップＳ１０１７に進み、エラー処理をしてサブルーチンを終了する。確認結果正常の場合（ステップＳ１０１６“ＯＫ”）は、ステップＳ１０１８に進む。
ステップＳ１０１８において、派遣社員個人情報処理部１０８は、送信データを新たなレコードとして派遣社員個人情報処理部１０８に新規追加する。その後、処理結果正常でサブルーチンを終了する。
【００９９】
図２２のステップＳ１０３１からステップＳ１０３５までは、ＩＦ処理区分が「更新」、すなわち出向除く企業間契約の変更等により、派遣社員個人情報１０３の情報を訂正する必要が発生した場合の処理である。
ステップＳ１０３１において、派遣社員個人情報処理部１０８は、送信データの必須項目を確認する。必須項目が全て記載されていない場合（ステップＳ１０３１“ＮＧ”）は、ステップＳ１０３２に進み、エラー処理をしてサブルーチンを終了する。必須項目が全て記載されている場合（ステップＳ１０３１“ＯＫ”）は、ステップＳ１０３３に進む。
【０１００】
ステップＳ１０３３において、派遣社員個人情報処理部１０８は、送信データの終身ＩＤを確認する。具体的には、送信データの終身ＩＤを含み、かつ、送信データの契約番号を含み、かつ、送信データの派遣先企業を派遣先企業に有するレコードを、派遣社員個人情報１０３のなかで検索する。検索結果は、レコードが１件発見される、もしくは全く発見されない、のいずれかである。検索結果が０件の場合（ステップＳ１０３３“ＮＧ”）、ステップＳ１０３４に進み、エラー処理をしてサブルーチンを終了する。上記以外の場合（ステップＳ１０３３“ＯＫ”）は、ステップＳ１０３５に進む。
ステップＳ１０３５において、派遣社員個人情報処理部１０８は、ステップＳ１０３３における検索結果レコードを、送信データの内容にて更新し、処理結果正常でサブルーチンを終了する。
【０１０１】
図２３のステップＳ１０５１からステップＳ１０５５までは、ＩＦ処理区分が「削除」、すなわち契約取消が発生した場合の処理である。
ステップＳ１０５１において、派遣社員個人情報処理部１０８は、送信データの必須項目を確認する。必須項目が全て記載されていない場合（ステップＳ１０５１“ＮＧ”）は、ステップＳ１０５２に進み、エラー処理をしてサブルーチンを終了する。必須項目が全て記載されている場合（ステップＳ１０５１“ＯＫ”）は、ステップＳ１０５３に進む。
【０１０２】
ステップＳ１０５３において、派遣社員個人情報処理部１０８は、送信データの終身ＩＤを確認する。具体的には、送信データの終身ＩＤを含み、かつ、送信データの契約番号を含み、かつ、送信データの派遣先企業を派遣先企業に有するレコードを、派遣社員個人情報１０３のなかで検索する。検索結果は、レコードが１件発見される、もしくは全く発見されない、のいずれかである。
検索結果が０件の場合（ステップＳ１０５３“ＮＧ”）、ステップＳ１０５４に進み、エラー処理をしてサブルーチンを終了する。それ以外の場合（ステップＳ１０５３“ＯＫ”）は、ステップＳ１０５５に進む。
ステップＳ１０５５において、派遣社員個人情報処理部１０８は、ステップＳ１０５３における検索結果レコードを削除し、処理結果正常でサブルーチンを終了する。
【０１０３】
図２４〜図２８は、本実施形態に係る派遣社員個人情報処理部１０８の処理手順のうち、ステップＳ１０１６の詳細を示すフローチャートである。
ステップＳ１０１６−１において、派遣社員個人情報処理部１０８は、送信データの終身ＩＤは既存か否かを確認する。具体的には、送信データの終身ＩＤを含むレコードが、正社員個人情報１０１、出向社員個人情報１０２、又は派遣社員個人情報１０３のなかに既に存在しているか否かを確認する。存在しない場合（ステップＳ１０１６−１“無”）、ステップＳ１０１６−２に進み、確認結果異常でステップＳ１０１６を終了する。存在する場合（ステップＳ１０１６−１“有”）、ステップＳ１０１６−３に進む。ここで、例えば桁違い等誤った終身ＩＤを有する送信デ−タは排除される。
【０１０４】
ステップＳ１０１６−３において、派遣社員個人情報処理部１０８は、レコ−ドが存在するか否かを確認する。具体的には、送信デ−タの終身ＩＤを含み、かつ、送信デ−タの契約番号を含み、かつ、送信デ−タの派遣先企業を派遣先企業に有するレコ−ドを、派遣社員個人情報１０３のなかで検索する。検索結果は、レコ−ドが１件発見される、もしくは全く発見されない、のいずれかである。検索結果が１件である場合（ステップＳ１０１６−３“有”）は、ステップＳ１０１６−４に進み、確認結果異常でステップＳ１０１６を終了する。検索結果が０件である場合（ステップＳ１０１６−３“無”）は、ステップＳ１０１６−５に進む。
【０１０５】
ステップＳ１０１６−５において、派遣社員個人情報処理部１０８は、送信デ−タの在籍元企業がグル−プ企業であるか否かを確認する。具体的には、送信デ−タの在籍元企業を企業名に有するレコ−ドを企業区分情報１０４のなかで検索する。検索結果レコ−ドの企業区分が“内”である場合（ステップＳ１０１６−５“ＹＥＳ”）、ステップＳ１０１６−２１（図２５）に進む。検索結果レコ−ドの企業区分が“外”である場合又は該当する検索結果レコ−ドが存在しない場合（ステップＳ１０１６−５“ＮＯ”）は、ステップＳ１０１６−６１（図２７）に進む。
【０１０６】
ステップＳ１０１６−５において、送信デ−タの在籍元企業がグル−プ企業である場合、退職前の正社員としてのレコ−ドが正社員個人情報１０１内に存在している、又は、出向終了前の出向社員としてのレコ−ドが出向社員個人情報１０２内に存在していなければならない。ステップＳ１０１６−２１からステップＳ１０１６−４９までは、このことを確認する処理手順である。
【０１０７】
図２５のステップＳ１０１６−２１において、派遣社員個人情報処理部１０８は、正社員としてのレコ−ドは存在するか否かを確認する。具体的には、送信デ−タの終身ＩＤを含むレコ−ドを、正社員個人情報１０１内で検索する。当該レコ−ドが存在しない場合（ステップＳ１０１６−２１“無”）、ステップＳ１０１６−４１（図２６）に進む。当該レコ−ドが存在する場合（ステップＳ１０１６−２１“有”）、ステップＳ１０１６−２２に進む。
ステップＳ１０１６−２２において、派遣社員個人情報処理部１０８は、検索結果レコ−ドの所属企業を確認する。具体的には、送信デ−タの終身ＩＤを含み、かつ、送信デ−タの有効開始年月日時を有効期間に含むレコ−ドを、正社員個人情報１０１内で検索し、検索結果レコ−ドの所属企業と送信デ−タの在籍元企業とを比較する。
検索結果レコ−ドの所属企業≠送信デ−タの在籍元企業である場合（ステップＳ１０１６−２２“≠”）は、ステップＳ１０１６−４１（図２６）に進む。
検索結果レコ−ドの所属企業＝送信デ−タの在籍元企業である場合（ステップＳ１０１６−２２“＝”）は、ステップＳ１０１６−２３に進む。
【０１０８】
ステップＳ１０１６−２３において、派遣社員個人情報処理部１０８は、検索結果レコ−ドの退職日が設定されているか否かを確認する。具体的には、ステップＳ１０１６−２２における検索レコ−ドに退職日が設定されていない場合（ステップＳ１０１６−２３“ＮＯ”）は、ステップＳ１０１６−２４に進み、確認結果正常でステップＳ１０１６を終了する。ステップＳ１０１６−２２における検索結果レコ−ドに退職日が設定されている場合（ステップＳ１０１６−２３“ＹＥＳ”）は、ステップＳ１０１６−２５に進む。
【０１０９】
ステップＳ１０１６−２５において、派遣社員個人情報処理部１０８は、検索結果レコ−ドの退職日と送信デ−タの契約開始日とを比較する。具体的には、ステップＳ１０１６−２２における検索結果レコ−ドの退職日＜送信デ−タの契約開始日である場合（ステップＳ１０１６−２５“＜”）は、ステップＳ１０１６−２６に進み、確認結果異常でステップＳ１０１６を終了する。ステップＳ１０１６−２２における検索結果レコ−ドの退職日≧送信デ−タの契約開始日である場合（ステップＳ１０１６−２５“≧”）は、ステップＳ１０１６−２７に進み、確認結果正常でステップＳ１０１６を終了する。
【０１１０】
図２６のステップＳ１０１６−４１において、派遣社員個人情報処理部１０８は、出向社員としてのレコ−ドの有無を確認する。具体的には、送信デ−タの終身ＩＤを含むレコ−ドを、出向社員個人情報１０２内で検索する。当該レコ−ドが存在しない場合（ステップＳ１０１６−４１“無”）、ステップＳ１０１６−４２に進み、確認結果異常でステップＳ１０１６を終了する。当該レコ−ドが存在する場合（ステップＳ１０１６−４１“有”）、ステップＳ１０１６−４３に進む。
【０１１１】
ステップＳ１０１６−４３において、派遣社員個人情報処理部１０８は、検索結果レコ−ドの出向先企業を確認する。具体的には、送信デ−タの終身ＩＤを含み、かつ、送信デ−タの有効開始年月日時を有効期間に含むレコ−ドを、出向社員個人情報１０２内で検索し、検索結果レコ−ドの出向先企業と送信デ−タの在籍元企業を比較する。
検索結果レコ−ドの出向先企業≠送信デ−タの在籍元企業である場合（ステップＳ１０１６−４３“≠”）は、ステップＳ１０１６−４４に進み、確認結果異常でステップＳ１０１６を終了する。
検索結果レコ−ドの出向先企業＝送信デ−タの在籍元企業である場合（ステップＳ１０１６−４３“＝”）は、ステップＳ１０１６−４５に進む。
【０１１２】
ステップＳ１０１６−４５において、派遣社員個人情報処理部１０８は、検索結果レコ−ドに出向終了日が設定されているか否かを確認する。具体的には、ステップＳ１０１６−４３における検索結果レコ−ドに出向終了日が設定されていない場合（ステップＳ１０１６−４５“ＮＯ”）は、ステップＳ１０１６−４６に進み、確認結果正常でステップＳ１０１６を終了する。ステップＳ１０１６−４３における検索結果レコ−ドに出向終了日が設定されている場合（ステップＳ１０１６−４５“ＹＥＳ”）は、ステップＳ１０１６−４７に進む。
【０１１３】
ステップＳ１０１６−４７において、派遣社員個人情報処理部１０８は、検索結果レコ−ドの出向終了日と送信デ−タの契約開始日とを比較する。具体的には、ステップＳ１０１６−４３における検索結果レコ−ドの出向終了日＜送信デ−タの契約開始日である場合（ステップＳ１０１６−４７“＜”）は、ステップＳ１０１６−４８に進み、確認結果異常でステップＳ１０１６を終了する。ステップＳ１０１６−４３における検索結果レコ−ドの出向終了日≧送信デ−タの契約開始日である場合（ステップＳ１０１６−４７“≧”）は、ステップＳ１０１６−４９に進み、確認結果正常でステップＳ１０１６を終了する。
【０１１４】
ステップＳ１０１６−５において、送信デ−タの在籍元企業がグル−プ企業でない場合、退職前の正社員としてのレコ−ドが正社員個人情報１０１内に存在してはならないし、かつ、出向終了前の出向社員としてのレコ−ドが出向社員個人情報１０２内に存在してはならない。ステップＳ１０１６−６１からステップＳ１０１６−８７までは、このことを確認する処理手順である。
【０１１５】
図２７のステップＳ１０１６−６１において、派遣社員個人情報処理部１０８は、正社員としてのレコ−ドの有無を確認する。具体的には、送信デ−タの終身ＩＤを含むレコ−ドを、正社員個人情報１０１内で検索する。当該レコ−ドが存在しない場合（ステップＳ１０１６−６１“無”）、ステップＳ１０１６−８１（図２８）に進む。当該レコ−ドが存在する場合（ステップＳ１０１６−６１“有”）、ステップＳ１０１６−６２に進む。
【０１１６】
ステップＳ１０１６−６２において、派遣社員個人情報処理部１０８は、検索結果レコ−ドに退職日が設定されているか否かを確認する。具体的には、送信デ−タの終身ＩＤを含み、かつ、送信デ−タの有効開始年月日時を有効期間に含むレコ−ドを、正社員個人情報１０１内で検索し、検索結果レコ−ドに退職日が設定されているか否かを確認する。退職日が設定されていない場合（ステップＳ１０１６−６２“ＮＯ”）、ステップＳ１０１６−６３に進み、確認結果異常でステップＳ１０１６を終了する。退職日が設定されている場合（ステップＳ１０１６−６３“ＹＥＳ”）、ステップＳ１０１６−６４に進む。
【０１１７】
ステップＳ１０１６−６４において、派遣社員個人情報処理部１０８は、検索結果レコ−ドの退職日と送信デ−タの契約開始日とを比較する。具体的には、ステップＳ１０１６−６２における検索レコ−ドの退職日＜送信デ−タの契約開始日である場合（ステップＳ１０１６−６４“＜”）は、ステップＳ１０１６−８１（図２８）に進む。ステップＳ１０１６−６２における検索結果レコ−ドの退職日≧送信デ−タの契約開始日である場合（ステップＳ１０１６−６４“≧”）は、ステップＳ１０１６−６５に進み、確認結果異常でステップＳ１０１６を終了する。
【０１１８】
図２８のステップＳ１０１６−８１において、派遣社員個人情報処理部１０８は、出向社員としてのレコ−ドの有無を確認する。具体的には、送信デ−タの終身ＩＤを含むレコ−ドを、出向社員個人情報１０２内で検索する。当該レコ−ドが存在しない場合（ステップＳ１０１６−８１“無”）、ステップＳ１０１６−８２に進み、確認結果正常でステップＳ１０１６を終了する。当該レコ−ドが存在する場合（ステップＳ１０１６−８１“有”）、ステップＳ１０１６−８３に進む。
【０１１９】
ステップＳ１０１６−８３において、派遣社員個人情報処理部１０８は、検索結果レコ−ドに出向終了日が設定されているか否かを確認する。具体的には、送信デ−タの終身ＩＤを含み、かつ、送信デ−タの有効開始年月日時を有効期間に含むレコ−ドを、出向社員個人情報１０２内で検索し、検索結果レコ−ドに出向終了日が設定されているか否かを確認する。出向終了日が設定されていない場合（ステップＳ１０１６−８３“ＮＯ”）、ステップＳ１０１６−８４に進み、確認結果異常でステップＳ１０１６を終了する。出向終了日が設定されている場合（ステップＳ１０１６−８３“ＹＥＳ”）、ステップＳ１０１６−８５に進む。
【０１２０】
ステップＳ１０１６−８５において、派遣社員個人情報処理部１０８は、検索結果レコ−ドの出向終了日と送信デ−タの契約開始日とを比較する。具体的には、ステップＳ１０１６−８３における検索結果レコ−ドの出向終了日＜送信デ−タの契約開始日である場合（ステップＳ１０１６−８５“＜”）は、ステップＳ１０１６−８６に進み、確認結果正常でステップＳ１０１６を終了する。ステップＳ１０１６−８３における検索結果レコ−ドの出向終了日≧送信デ−タの契約開始日である場合（ステップＳ１０１６−８５“≧”）は、ステップＳ１０１６−８７に進み、確認結果異常でステップＳ１０１６を終了する。
【図面の簡単な説明】
【０１２１】
【図１】本実施形態に係るハ−ドウエア構成等を説明する図である。
【図２】企業グル−プにおける人事異動の一例を示す図である。
【図３】本実施形態に係る正社員個人情報の一例を示す図である。
【図４】本実施形態に係る出向社員個人情報の一例を示す図である。
【図５】本実施形態に係る派遣社員個人情報の一例を示す図である。
【図６】本実施形態に係る企業区分情報の一例を示す図である。
【図７】本実施形態に係る送信用正社員個人情報の一例を示す図である。
【図８】本実施形態に係る送信用出向社員個人情報の一例を示す図である。
【図９】本実施形態に係る送信用派遣社員個人情報の一例を示す図である。
【図１０】本実施形態に係るグル−プ個人情報管理装置の処理手順の全体構成を示すフローチャートである。
【図１１】本実施形態に係る正社員個人情報処理部の処理手順を示すフローチャートである。
【図１２】本実施形態に係る正社員個人情報処理部の処理手順を示すフローチャートである。
【図１３】本実施形態に係る正社員個人情報処理部の処理手順を示すフローチャートである。
【図１４】本実施形態に係る正社員個人情報処理部の処理手順のうち、ステップＳ８１６の詳細を示すフローチャートである。
【図１５】本実施形態に係る出向社員個人情報処理部の処理手順を示すフローチャートである。
【図１６】本実施形態に係る出向社員個人情報処理部の処理手順を示すフローチャートである。
【図１７】本実施形態に係る出向社員個人情報処理部の処理手順を示すフローチャートである。
【図１８】本実施形態に係る出向社員個人情報処理部の処理手順のうち、ステップＳ９１６の詳細を示すフローチャートである。
【図１９】本実施形態に係る出向社員個人情報処理部の処理手順のうち、ステップＳ９１６の詳細を示すフローチャートである。
【図２０】本実施形態に係る出向社員個人情報処理部の処理手順のうち、ステップＳ９１６の詳細を示すフローチャートである。
【図２１】本実施形態に係る派遣社員個人情報処理部の処理手順を示すフローチャートである。
【図２２】本実施形態に係る派遣社員個人情報処理部の処理手順を示すフローチャートである。
【図２３】本実施形態に係る派遣社員個人情報処理部の処理手順を示すフローチャートである。
【図２４】本実施形態に係る派遣社員個人情報処理部の処理手順のうち、ステップＳ１０１６の詳細を示すフローチャートである。
【図２５】本実施形態に係る派遣社員個人情報処理部の処理手順のうち、ステップＳ１０１６の詳細を示すフローチャートである。
【図２６】本実施形態に係る派遣社員個人情報処理部の処理手順のうち、ステップＳ１０１６の詳細を示すフローチャートである。
【図２７】本実施形態に係る派遣社員個人情報処理部の処理手順のうち、ステップＳ１０１６の詳細を示すフローチャートである。
【図２８】本実施形態に係る派遣社員個人情報処理部の処理手順のうち、ステップＳ１０１６の詳細を示すフローチャートである。
【符号の説明】
【０１２２】
１      グル−プ個人情報管理装置
２      個別企業個人情報管理装置
３      企業グループネットワーク
１２    補助記憶装置
１６    主記憶装置
１０１  正社員個人情報
１０２  出向社員個人情報
１０３  派遣社員個人情報
１０４  企業区分情報
１０５  個人情報統括部
１０６  正社員個人情報処理部
１０７  出向社員個人情報処理部
１０８  派遣社員個人情報処理部
１１１，１３１，１５１，２１３，２４３，２６３  終身ＩＤ（個人識別情報）
１１２，１３２，１５４，２１４，２４４，２６４  有効開始年月日時
１１３，１３３，１５５，２６７  有効終了年月日時
１５２，２６５  契約番号
１５３，２６６  派遣先企業
２１１，２４１，２６１  就労区分
２１２，２４２，２６２  ＩＦ処理区分
２０１  送信用正社員個人情報
２０２  送信用出向社員個人情報
２０３  送信用派遣社員個人情報
【図１】
2009053816.tif 000003
【図２】
2009053816.tif 000004
【図３】
2009053816.tif 000005
【図４】
2009053816.tif 000006
【図５】
2009053816.tif 000007
【図６】
2009053816.tif 000008
【図７】
2009053816.tif 000009
【図８】
2009053816.tif 000010
【図９】
2009053816.tif 000011
【図１０】
2009053816.tif 000012
【図１１】
2009053816.tif 000013
【図１２】
2009053816.tif 000014
【図１３】
2009053816.tif 000015
【図１４】
2009053816.tif 000016
【図１５】
2009053816.tif 000017
【図１６】
2009053816.tif 000018
【図１７】
2009053816.tif 000019
【図１８】
2009053816.tif 000020
【図１９】
2009053816.tif 000021
【図２０】
2009053816.tif 000022
【図２１】
2009053816.tif 000023
【図２２】
2009053816.tif 000024
【図２３】
2009053816.tif 000025
【図２４】
2009053816.tif 000026
【図２５】
2009053816.tif 000027
【図２６】
2009053816.tif 000028
【図２７】
2009053816.tif 000029
【図２８】
2009053816.tif 000030