JP2017021553A - 属性情報管理装置、属性情報管理方法およびコンピュータプログラム - Google Patents

Abstract

【課題】様々な組織における役割が特定の人に付与されうる状況において、人の役割の効率的な管理を支援する。【解決手段】現在過去属性保持部４２は、人と、その人が人事上所属する組織と、範囲ＩＤとを含むユーザ情報と、各組織に設けられる複数の役割と、各役割に付与される権限とを対応付けた役割情報と、前記役割を範囲ＩＤに対応付けた範囲情報を保持する。適用処理部５０は、ある人の役割または権限を変更すべき場合、前記ユーザ情報に含まれるその人の範囲ＩＤを別の範囲ＩＤに変更する。【選択図】図９

Description

本発明は、データ処理技術に関し、特に組織や人に関する属性情報を管理する技術に関する。

企業において人に割当てられた属性情報を一元的に管理し、その属性情報を連携先のリポジトリに配信するＩＤ管理システムが提案されている（例えば特許文献１参照）。

特開２００９−１２９２８９号公報

企業における人事異動等を契機として、社員が人事上所属していない組織における権限をその社員に付与する必要が生じる場合がある。しかし、従来のＩＤ管理システムでは、人事上所属していない組織における権限を社員に付与した状態を効率的に管理することは困難であり、システムの保守性等が低下してしまうことがあった。

本願発明は上記課題に鑑みたもので、その主な目的は、様々な組織における役割が特定の人に付与されうる状況において、人の役割の効率的な管理を支援する技術を提供することである。

上記課題を解決するために、本発明のある態様の属性情報管理装置は、人と、その人が人事上所属する組織と、範囲ＩＤとを含むユーザ情報を保持するユーザ情報保持部と、各組織に設けられる複数の役割と、各役割に付与される権限とを対応付けた役割情報を保持する役割情報保持部と、役割を範囲ＩＤに対応付けた範囲情報を保持する範囲情報保持部と、ユーザ情報設定部と、を備える。ユーザ情報設定部は、ある人の役割または権限を変更すべき場合、ユーザ情報に含まれるその人の範囲ＩＤを別の範囲ＩＤに変更する。ユーザ情報保持部は、人が人事上所属する組織を示すユーザ情報を保持してもよい。役割情報保持部は、複数の組織に共通して適合する情報であって、各組織に設けられる複数の役割と、各役割に付与される権限とを対応付けた役割情報を保持してもよい。範囲情報保持部は、１つ以上の組織のそれぞれにおける役割を１つの範囲に対応付けた範囲情報を保持してもよい。ユーザ情報保持部は、各人に付与された範囲を含むユーザ情報を保持することにより、ある人に付与された範囲にもとづいてその人に付与された１つ以上の組織のそれぞれにおける役割と権限を識別可能にしてもよい。ユーザ情報設定部は、ある人の役割を変更すべき場合、ユーザ情報が示すその人の範囲を、範囲情報で定められた別の範囲に変更してもよい。

本発明の別の態様は、属性情報管理方法である。この方法は、人と、その人が人事上所属する組織と、範囲ＩＤとを含むユーザ情報と、各組織に設けられる複数の役割と、各役割に付与される権限とを対応付けた役割情報と、役割を範囲ＩＤに対応付けた範囲情報とを所定の記憶領域に記憶する情報処理装置が、ある人の役割または権限を変更すべき場合、ユーザ情報に含まれるその人の範囲ＩＤを別の範囲ＩＤに変更する。ユーザ情報に、各人に付与された範囲を記録することにより、ある人に付与された範囲にもとづいてその人に付与された１つ以上の組織のそれぞれにおける役割と権限を識別可能にするステップステップをさらに実行してもよい。

なお、以上の構成要素の任意の組合せ、本発明の表現を、装置、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、様々な組織における役割が特定の人に付与されうる状況において、人の役割の効率的な管理を支援できる。

実施の形態のＩＤ管理システムの構成を示す図である。 第１の実施の形態のＩＤ管理装置の機能構成を示すブロック図である。 先付属性保持部に格納される先付属性情報の一例を示す図である。 現在過去属性保持部に格納される現在過去属性情報の一例を示す図である。 定義情報保持部に格納される定義情報の詳細を示す図である。 従来のＩＤ管理システムにおける権限情報の構成を示す図である。 １人の社員に付与すべきロールを示す模式図である。 ロール範囲の概念を示す図である。 第２の実施の形態のＩＤ管理装置の機能構成を示すブロック図である。 現在過去属性保持部における権限管理のためのテーブル構成を示す図である。 権限情報を含むＪＳＯＮデータを示す図である。 第３の実施の形態の範囲テーブルを示す図である。 権限情報を含むＪＳＯＮデータを示す図である。 権限情報を含むＪＳＯＮデータを示す図である。 権限情報を含むＪＳＯＮデータを示す図である。 第４の実施の形態のＩＤ管理装置の機能構成を示すブロック図である。 シミュレーション用リポジトリの構成を示す図である。 ＩＤ管理装置が提供するユーザ画面を示す図である。 ＩＤ管理装置が提供するユーザ画面を示す図である。 ＩＤ管理装置が提供するユーザ画面を示す図である。

図１は、実施の形態のＩＤ管理システム１０の構成を示す。ＩＤ管理システム１０は、企業の組織や従業員等に関する各種属性情報の管理に係る情報処理システムである。ＩＤ管理システム１０は、ＩＤ管理装置１２、人事部システム１４、経営企画部システム１６、業務部門システム１８、連携先システム２０で総称されるシステムＡ用リポジトリ２０ａ、システムＢ用リポジトリ２０ｂ、システムＣ用リポジトリ２０ｃを備える。これらの各システム・装置は企業のイントラネットで接続される。なお、ＩＤ管理装置１２に接続される各装置・システムは、社内（社内網内）に構築された装置・システムに限らず、クラウド等、社外に構築された装置・システムであってもよい。

ＩＤ管理装置１２は、企業に設けられた複数の組織や、企業に雇用された複数の社員に関する様々な属性情報を一元的に管理する情報処理装置である。社員に関する属性情報は、社員番号や氏名、所属組織、役職、権限等を含み、またそれらの識別情報であるＩＤを含む。人事部システム１４は、人事部に設置されたＰＣ等の各種装置を含み、人事異動に関する異動情報２２をＩＤ管理装置１２へ送信する。経営企画部システム１６は、経営企画部に設置されたＰＣ等の各種装置を含み、組織改編に関する組織改編情報２４をＩＤ管理装置１２へ送信する。

業務部門システム１８は、人事部、経営企画部以外の組織に構築される情報システムである。図１では１つの業務部門システム１８を描いているが、例えば営業部・開発部・コンサルティング部等、種々の本部・部・課のそれぞれに構築された複数の業務部門システム１８が存在する。業務部門システム１８のＰＣ等は、付加情報２６をＩＤ管理装置１２へ送信する。付加情報２６は、人事異動や組織改編以外の情報であり、実際の業務遂行において必要となる各種属性情報を含む。例えば、連絡先情報（電話番号等）、組織におけるロール、権限（システム利用権限等）を含む。

なお、実施の形態におけるロールは、組織において社員（ユーザ）が果すべき役割を意味し、また、組織においてユーザに付与された役割・役職・権限を意味する。後述するように、部長ロール、会計ロール、総括ロール等、複数種類のロールが存在する。

システムＡ用リポジトリ２０ａ、システムＢ用リポジトリ２０ｂ、システムＣ用リポジトリ２０ｃのそれぞれは、連携先のシステムＡ、システムＢ、システムＣに設置された属性情報管理用のリポジトリデータベースである。連携先システム２０は、例えば業務部門システム１８であってもよい。ＩＤ管理装置１２は、連携先システム２０のそれぞれへ、連携先システム２０ごとに予め定められた項目の属性情報２８を定期的に配信する。

実施の形態のＩＤ管理装置１２は、１）属性情報管理のためのリポジトリ構造、２）権限管理における範囲の概念の導入、３）シミュレーション機能を主な特徴として備える。以下、１）属性情報管理のためのリポジトリ構造について第１の実施の形態で説明し、２）権限管理における範囲の概念の導入について第２および第３の実施の形態で説明し、３）シミュレーション機能について第４の実施の形態で説明する。

（第１の実施の形態）
図２は、第１の実施の形態のＩＤ管理装置１２の機能構成を示すブロック図である。ＩＤ管理装置１２は、通信部３０、制御部３２、記憶部３４を備える。通信部３０は、種々の通信プロトコルにしたがって外部装置との通信処理を実行する。通信対象の外部装置は、ＩＤ管理対象の企業内に構築された装置に限らず、クラウド等の企業外に構築された装置も含む。制御部３２は、組織や社員に関する属性情報管理のための各種データ処理を実行する。制御部３２は、通信部３０を介して外部装置とデータを送受する。記憶部３４は、制御部３２によるデータ処理のための各種データを記憶する記憶領域である。

本明細書のブロック図において示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵやメモリをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。例えば、制御部３２内の各ブロックは、プログラムモジュールとして実装されてＩＤ管理装置１２のストレージに格納され、ＩＤ管理装置１２のＣＰＵがそれらのプログラムモジュールをメインメモリに読み出して適宜実行することにより、各ブロックの機能が発揮されてよい。

記憶部３４は、先付データ保持部３６、属性リポジトリ３８、定義情報保持部４４を備える。先付データ保持部３６は、人事部システム１４から送信された異動情報２２、経営企画部システム１６から送信された組織改編情報２４、業務部門システム１８から送信された付加情報２６を保持する。以下、異動情報２２、組織改編情報２４、付加情報２６を総称して「先付データ」とも呼ぶ。先付データは、後述の先付属性情報に反映させるべき組織や社員に関する属性情報を含む。

属性リポジトリ３８は、組織や社員に関する現在・過去・未来の属性情報を保持する。属性リポジトリ３８は、先付属性保持部４０と現在過去属性保持部４２を含む。属性リポジトリ３８は、ＩＤ管理装置１２とは物理的に別の装置・筐体に設けられてもよい。例えば、属性リポジトリ３８を備えるリポジトリサーバ（データベースサーバ）がＩＤ管理装置１２とは別に設けられ、ＩＤ管理装置１２は、通信網を介してリポジトリサーバの属性リポジトリ３８にアクセスしてもよい。

現在過去属性保持部４２は、組織や社員に関する現在適用中の属性と、過去適用された属性の両方を含む情報（以下「現在過去属性情報」と呼ぶ）を保持する。現在過去属性情報のうち現在の属性情報と過去の属性情報を区別する場合、前者を「現在属性情報」と呼び、後者を「過去属性情報」と呼ぶ。先付属性保持部４０は、組織や社員に関する将来の属性を示す情報（以下「先付属性情報」と呼ぶ）を保持する。先付属性情報は、現在は未確定であるが、将来の割当て・付与が予定されている先日付（未来日付）の属性情報である。現在過去属性情報と先付属性情報の具体例は後述する。

定義情報保持部４４は、後述の適用処理部５０による適用処理の内容を規定した定義情報を保持する。定義情報の具体例は後述する。

制御部３２は、先付データ取得部４６、属性情報取込部４８、適用処理部５０、属性情報提供部５４を備える。先付データ取得部４６は、人事部システム１４、経営企画部システム１６、業務部門システム１８から送信された先付データを取得し、先付データ保持部３６へ格納する。

属性情報取込部４８は、先付データ保持部３６に新たな先付データが格納されたことを検出すると、その先付データが示す組織や社員の属性情報を先付属性情報として先付属性保持部４０へ格納する。属性情報取込部４８は、１日の予め定められた時刻になったことを契機に、このような先付属性情報取込処理を実行してもよい。

図３は、先付属性保持部４０に格納される先付属性情報の一例を示す。同図は、先付データとしての異動情報２２に基づいて設定された先付属性情報を示している。先付属性情報は、先付データの内容をそのまま転記したものでもよい。先付属性情報は、その属性値を現在属性情報へ反映すべきタイミング（日付、時刻等）を示す適用開始日を含む。具体的に図３の先付属性情報は、１２月１日に「野村太郎」がコンサルティング部の部長へ異動となり、１２月１日に「野村花子」が退職することを示している。なお、適用開始日は、人事異動や組織改編の発令日が設定されてもよい。

適用開始日は先付データに含まれてもよい。また、適用開始日が先付データに含まれない場合等、属性情報取込部４８は、先付属性情報を設定する際に、所定の規則にしたがって適用開始日を自律的に設定してもよい。例えば、先付データが異動情報２２であれば、現在日から半月先や１月先の未来日付を自動設定してもよい。また、先付データが付加情報２６であれば、当日日付や１日後の比較的近傍の未来日付を自動設定してもよい。

なお、属性情報取込部４８は、所定の削除操作の入力や、所定の削除指示データの受信に応じて、先付属性保持部４０に格納済の先付属性情報を削除してもよい。この削除操作や削除指示データでは、削除対象の先付属性情報を特定するためのキー（例えば社員ＩＤと適用開始日の組み合わせ）が指定されてもよい。同様に属性情報取込部４８は、所定の更新操作の入力や、所定の更新指示データの受信に応じて、先付属性保持部４０に格納済の先付属性情報を更新・変更してもよい。この更新操作や更新指示データでは、更新対象の先付属性情報を特定するためのキーと、属性の更新値が指定されてもよい。このように、先付属性保持部４０に格納された先付属性情報は、その適用開始日に至るまでの期間に更新・削除されうる。

属性情報提供部５４は、現在過去属性保持部４２に格納された最新の現在属性情報から連携先システム２０ごとに予め定められた項目を抽出して、各連携先システム２０向けの属性情報２８を生成する。例えば、現在属性情報の差分を配信する場合、適用開始日が当日日付の現在属性情報を識別し、その現在属性情報から所定項目を抽出して属性情報２８を生成してもよい。属性情報提供部５４は、複数の連携先システム２０へ属性情報２８を送信する。属性情報提供部５４は、属性情報配信処理を定期的に実行してもよく、例えば、１日１回、適用処理部５０による適用処理完了を契機に実行してもよい。

適用処理部５０は、先付属性保持部４０に格納された先付属性情報のうち適用開始日に到達した先付属性情報にしたがって、新たな現在属性情報を現在過去属性保持部４２に格納する適用処理を実行する。適用処理部５０は、１日の所定の時刻に到達した場合にバッチ処理として適用処理を実行してもよい。また適用処理部５０は、ＩＤ管理装置１２のＯＳが管理する現在日付を参照して、適用処理の対象とする先付属性情報を識別してもよい。適用処理部５０は、適用開始日に未達の先付属性情報は適用処理の対象外とする。

変形例として、適用処理部５０は、適用処理の対象とする先付属性情報を識別する基準として、現在日付に代えて運用日付を使用してもよい。運用日付は、日付を跨いで実行されるバッチファイル（いわゆる夜間バッチ）を考慮した日付である。例えば、適用処理のバッチファイルが２３時に開始〜翌日１時に終了する場合、適用処理の開始前に運用日付を現在日付＋１日に設定する。具体例として、１１月３０日の２３時から１２月１日の１時まで実行される適用処理では、運用日付が１２月１日であるため、適用開始日が１２月１日の先付属性情報を対象としてもよい。

図４は、現在過去属性保持部４２に格納される現在過去属性情報の一例を示す。同図は、社員属性を示す現在過去属性情報を示している。現在過去属性情報は、適用開始日と適用終了日を含む。適用開始日は、そのレコードが現在属性情報として設定された日付を示し、典型的には設定元の先付属性情報の適用開始日と同じ値となる。社員属性を示す現在過去属性情報のキーは、社員ＩＤと適用開始日の組み合わせになる。

適用終了日は、そのレコードが現在属性情報から過去属性情報へ移行した日付を示し、言い換えれば、新たな現在属性情報が記録されたことに伴い現在属性情報として無効になった日付が設定される。なお、社員属性を示す現在属性情報では、雇用期間の取決めがある契約社員の場合は雇用期間の終了日が適用終了日として設定され、雇用期間の取決めがない正社員の場合は２９９９年末日が適用終了日として設定される。

図４（ａ）は、図３の先付属性情報を適用前の現在過去属性情報を示し、例えば２０１４年１１月３０日の現在過去属性情報を示している。図４（ｂ）は、図３の先付属性情報を適用後の現在過去属性情報を示し、例えば２０１４年１２月１日の現在過去属性情報を示している。適用処理部５０は、１２月１日の適用処理において、図３の先付属性情報にしたがって、図４（ｂ）の属性情報８０と属性情報８２を現在過去属性保持部４２に格納する。実施の形態では、退職者についてはその所属を「退職」にすることで識別可能にする。変形例として、他の項目・属性を「退職」としてもよく、また、他の項目・属性に所定のデータを設定する等、任意の退職者フラグ設定処理を実行してもよい。

適用処理部５０は、属性情報８０と属性情報８２を格納するまで現在属性情報であった属性情報８４と属性情報８６について、その適用終了日を過去日（図では前日）に変更することで、属性情報８４と属性情報８６が過去属性情報であることを識別可能にする。現在過去属性保持部４２は、新たな現在属性情報が格納された場合に、それまでの現在属性情報を過去属性情報として継続して保持する。退職者（図４の野村花子）についても、現在過去属性情報を継続して保持する。

図２に戻り、適用処理部５０は、定義実行エンジン５２を含む。定義実行エンジン５２は、定義情報保持部４４に予め格納された定義情報が示す規則にしたがって、現在過去属性情報への先付属性情報のルールベースの反映処理を実行するルールエンジンである。定義実行エンジン５２は、公知のルールエンジンであってもよい。

図５は、定義情報保持部４４に格納される定義情報の詳細を示す。定義情報は、取得データ定義６０、差分判定ルール定義６２、適用ルール定義６４を含む。取得データ定義６０は、先付属性保持部４０に格納された先付属性情報と、現在過去属性保持部４２に格納された現在過去属性情報の中のどのデータ（情報項目）を処理対象とするかを定める。例えば、図３・図４の例で示す社員属性情報の場合、社員ＩＤ・氏名・所属・役職を処理対象として定めてもよい。

差分判定ルール定義６２について説明する。一般的に、異動情報２２の属性量（すなわち情報項目数）＜現在過去属性情報の属性量（すなわち属性リポジトリ３８で管理する情報項目数）であるため、単純に比較すると常に差分が生じることになる。そこで差分判定ルール定義６２は、差分判定において無視すべき情報項目を定める。また、属性値の加工・編集方法およびその結果を判定して適用有無を決定するロジック等を定める。

適用ルール定義６４は、取得データ定義６０による取得データの識別処理と、差分判定ルール定義６２による判定処理の結果に基づいた、現在過去属性保持部４２に格納すべき新たな現在属性情報の生成規則を定める。適用ルール定義６４は、複数のより詳細な定義を含み、実施の形態では属性マッピング定義６６、属性引継定義６７、退職情報作成定義６８を含むこととする。

属性マッピング定義６６は、先付属性情報の情報項目と、現在過去属性情報（現在属性情報）の情報項目とのマッピングのための対応関係を定める。例えば、図３・図４に示す社員属性の場合は、先付属性情報の「所属」を現在過去属性情報の「所属」に対応付け、先付属性情報の「役職」を現在過去属性情報の「役職」に対応付ける。このような単純なマッピング以外にも、属性マッピング定義６６は、名称が不一致である場合のマッピング規則を含む。また、先付属性情報の１項目を現在過去属性情報の複数項目に対応付けるマッピング規則や、逆に先付属性情報の複数項目を現在過去属性情報の１項目に対応付けるマッピング規則を含む。

属性引継定義６７は、属性情報の引継処理、言い換えれば、マッピング処理の詳細を定める。例えば属性引継定義６７は、先付属性情報の属性値や、現在過去属性情報（典型的には適用処理実行前までの現在属性情報）の属性値に応じた引継処理の定義を含む。また属性引継定義６７は、属性値の引継条件を示す論理式である条件式を含む。例えば、ｉｆ（ある項目の属性値が○○であれば等の条件）、ｔｈｅｎ（属性値の編集等を含むアクション）を定義した条件式を含む。

属性引継定義６７の具体例を示す。例えば属性引継定義６７は、適用処理実行前までの現在属性情報が示す役職が「部長」の場合、先付属性情報における「着任日」属性の有無に関わらず、現在日付が適用開始日以降であれば当該現在属性情報を即時削除することを定めてもよい。なお、実施の形態における削除処理は、適用終了日を過去日に設定し、それまでの現在属性情報を過去属性情報に切り替えることで、それまでの現在属性情報を無効にする処理である。変形例として記憶領域からデータを消去する処理であってもよい。

また属性引継定義６７は、適用処理実行前までの現在属性情報が示す役職が「部長」以外で、かつ、先付属性情報に「着任日」属性がある場合、現在日付が着任日以降であれば当該現在属性情報を削除することを定めてもよい。着任日は、新所属組織の業務部門システム１８から送信される付加情報２６に記録されて、ＩＤ管理装置１２へ通知されてもよい。典型的には着任日は、旧所属組織での業務引継等を完了した日であり、適用開始日以降の日付となる。したがって、適用開始日〜着任日の間は、適用処理前の属性と、適用処理後の属性の両方が現在属性情報として有効にされてもよい。すなわち、両方の適用終了日が未来日に設定された状態が維持されてもよい。

また属性引継定義６７は、適用処理実行前までの現在属性情報が示す役職が「部長」以外で、かつ、先付属性情報に「着任日」属性がない場合は、現在日付が適用開始日＋３０日以降であれば当該属性情報を削除することを定めてもよい。一般的に部長が可能な承認や決済の権限は非常に強力であるため、旧属性が部長の場合には、発令日を迎えると即時に旧権限を削除する一方、他の役職であれば着任日に応じて旧権限を削除するような柔軟な属性引継処理がルールベースによって可能になる。

別の例として、先付属性情報における所属組織および／または役職の属性値が特定の値を示す場合に、現在日付が、先付属性情報が示す適用開始日＋３０日以降になったことを契機に適用処理を実行するよう制御することもできる。このように、実施の形態の引継処理では、「属性項目」より下位のレベルの「属性値」に基づいて引継処理の態様を制御できる。また、特許文献１における「これまでの属性を有効にする」「新たな属性を有効にする」「新属性と旧属性の両方を有効にする」という固定的な引継ポリシーではなく、ルールベースによる柔軟な引継ポリシーの設定を実現できる。また、ルールベースの記述により、条件式による判定も可能になる。

退職情報作成定義６８は、先付属性情報が社員の退職を示す場合に、現在過去属性情報とは別の情報であり、退職者の属性を記録した退職情報を作成する処理の定義や、退職情報の形式等を定める。

以上の構成による図１のＩＤ管理システム１０の動作を説明する。
人事部システム１４、経営企画部システム１６、業務部門システム１８は、人事異動や組織改編、業務状況に応じた様々なタイミングで先付データをＩＤ管理装置１２へ送信する。ＩＤ管理装置１２の先付データ取得部４６は、先付データを受信し、先付データ保持部３６へ格納する。属性情報取込部４８は、先付データに設定された組織または社員の属性情報を先付属性情報として先付属性保持部４０に格納する。

予め定められた適用処理の開始タイミングになると、適用処理部５０は、先付属性保持部４０に格納された先付属性情報のうち適用開始日に至った先付属性情報を適用処理対象として識別する。そして、適用処理対象の先付属性情報にもとづいて新たな現在属性情報を生成し、その新たな現在属性情報を現在過去属性保持部４２へ格納する。その際に、それまでの現在属性情報を過去属性情報とするよう更新する。

適用処理部５０は、過去属性情報へ移行対象となるそれまでの現在属性情報の属性値、または、新たな現在属性情報へ移行対象となる先付属性情報の属性値と、定義情報保持部４４に予め格納された定義情報（例えば条件式）にしたがってルールベースの適用処理を実行する。属性情報提供部５４は、適用処理部５０によって現在過去属性保持部４２に格納された新たな現在属性情報を連携先システム２０へ配信する。

第１の実施の形態のＩＤ管理装置１２では、先付属性情報を保持する先付属性保持部４０を、現在過去属性情報を保持する現在過去属性保持部４２とは別に設けた。先付属性情報は、適用開始日に至るまでの期間に変更されうる未確定のデータである。現在過去属性保持部４２に未確定のデータを入力する場合、現在確定している属性を取得し、また更新することが複雑になってしまう。また未確定の属性を配信してしまうリスクも高まる。ＩＤ管理装置１２では、確定した属性情報の記憶領域と、未確定の属性情報の記憶領域を明確に区別することで、属性情報管理を安全かつ効率的に実現する。

またＩＤ管理装置１２では、企業の組織や社員、退職者に関する現在属性情報だけでなく、過去属性情報も現在過去属性保持部４２に保持する。これにより、任意の過去時点における属性情報を容易に取得でき、また、組織や社員の現在属性を過去の任意時点の状態に戻すことも容易になる。

第１の実施の形態の変形例を説明する。
上記実施の形態では、現在過去属性保持部４２に、新たな現在属性情報を順次蓄積していく（言い換えれば追加していく）構成を説明した。変形例として、ＩＤ管理装置１２は、現在属性情報の訂正や削除を要求する所定のデータがＩＤ管理装置１２に入力された場合、入力データにしたがって、現在過去属性保持部４２に格納済の現在過去属性情報（典型的には現在属性情報）を更新し、または削除する現在属性変更部をさらに備えてもよい。

上記実施の形態では、属性情報提供部５４は、現在過去属性保持部４２に格納された現在属性情報を連携先システム２０へ配信した。変形例として、将来の付与が予定されている属性情報を必要とする連携先システム２０に対しては、先付属性保持部４０に格納された将来属性情報を配信してもよい。また、属性情報提供部５４は、連携先システム２０からの属性情報提供要求を受信した場合に、その要求で指定された過去属性情報、現在属性情報、または将来属性情報を連携先システム２０へ提供してもよい。

（第２の実施の形態）
まず概要を説明する。従来のＩＤ管理システムでは、業務権限やシステム利用権限等、各種権限の管理と制御を、組織横断的なロール情報と、所属組織の情報の組み合わせで実現してきた。図６は、従来のＩＤ管理システムにおける権限情報の構成を示す。ロールは、典型的には単一の企業や企業グループにおいて複数の組織に共通して適合する。例えば、Ａ本部ＡＡ部の部長の権限は、Ａ本部ＡＢ部の部長の権限と同等である。

多くの日本企業では、人事上所属する組織における権限とは別に、人事上未所属の組織における権限が必要になるケースがある。人事上未所属の組織は、典型的には人事部門が定めた正式な所属組織とは別の組織を意味する。例えば、１）業務都合で、人事上は所属していない他部署のシステム利用権限が必要なケース、２）グループ会社でシステムを共有しており、その利用権限が必要なケース、３）異動直後の引継期間中に、前部署の権限を維持すべきケース等がある。

従来のＩＤ管理システムでは、人事上所属する組織におけるユーザの権限と、人事上未所属の組織におけるユーザの権限の両方を正しく表現することは困難であった。例えば図７に示すように、ＡＡ部に所属し、ＡＡ部の部長権限を有するユーザに対して、異なるＡＢ部の会計権限を付与した事実を、システム上で正規化を崩すことなく上手く表現することは困難であった。

例えば、特開２００８−２１０１１７号公報には、ユーザ情報管理システムにおいて、ユーザに付与する管理用権限を、サブシステム毎に異なる権限情報の組み合わせに対応付けた権限変換情報を設けることが記載されている（段落００３６〜００３７、００５４、図１、図５等）。ここで、上記公報の管理用権限情報は実施の形態におけるロールに対応すると言え、サブシステム毎の権限は本明細書における権限に対応すると言える。

上記公報の段落００３７には、『管理用権限情報は、ユーザの属する部門に応じて決定することも可能である。例えば、人事部門のユーザに対しては、人事部門において必要な処理が実行可能な「丙１」という管理用権限を付与し、営業部門のユーザに対しては、営業部門において必要な処理が実行可能な「丙２」という管理用権限を付与する。なお、一ユーザに対して複数の管理用権限を付与するようにしてもよい。』と記載されている。すなわち、１人のユーザに対して、組織毎に異なる複数の管理者権限を付与することが記載されている。

上記公報の技術では組織とロールとが密に結びついている。そのため、組織改編のたびに、組織毎に新たなロールを作成して権限変換情報を更新する必要があり、運用保守の負荷が高い。また、上記公報の図５に示される権限変換情報のテーブルには（組織×ロール）個のレコードが登録される必要があり、ユーザ数が多い大企業等ではレコード数が増大し、保守性が低下してしまう。また、上記文献のテーブル構成では、ユーザが保持する権限が、人事上所属している組織に対する権限か、人事上未所属の組織に対する権限かを識別することが困難である。

そこで実施の形態では、「範囲」（以下「ロール範囲」とも呼ぶ）の概念を導入する。図８はロール範囲の概念を示す。図８（ａ）はロール範囲を含むＥＲ図であり、図８（ｂ）は社員に対する権限付与の模式図である。ロール範囲は、人事上の所属とは無関係に定義が可能であり、複数のロールを含みうる。またロール範囲は、人事上所属する組織とは独立して定められた、業務上権限が必要な組織の範囲と言える。また、人事部が取決めたユーザが正式に所属する組織を超えて、現実の業務遂行のために権限をもつべき組織と役割の１つ以上の組み合わせとも言える。

図９は、第２の実施の形態のＩＤ管理装置１２の機能構成を示すブロック図である。第２の実施の形態のＩＤ管理装置１２は、第１の実施の形態のＩＤ管理装置１２の機能を包含し、範囲の概念を導入した権限管理機能をさらに有する。図９の機能ブロックのうち第１の実施の形態と同一または対応する機能ブロックには図２と同一の符号を付している。以下、第１の実施の形態と重複する説明は省略する。

図１０は、現在過去属性保持部４２における権限管理のためのテーブル構成を示す。現在過去属性保持部４２は、社員の権限を定める現在過去属性情報を、組織マスタテーブル７０、社員マスタテーブル７２、範囲テーブル７４、ロールマスタテーブル７６、権限マスタテーブル７８により保持する。図１０では現在属性情報としての権限情報を示しているが、実際の各テーブルは適用開始日と適用終了日の列を含み、過去属性情報としての権限情報も含む。

社員マスタテーブル７２では、社員ＩＤに、組織マスタテーブル７０のキーである組織ＩＤと、範囲テーブル７４のキーである範囲ＩＤが対応付けられる。ロールマスタテーブル７６では、ロールＩＤに、権限マスタテーブル７８のキーである権限ＩＤが対応付けられる。図８（ａ）に示したように、ロールと権限は１対ｎの関係であり、ロールマスタテーブル７６と権限マスタテーブル７８の組み合わせによりロールの権限が規定される。なお、会社によってはロールと権限を１対１の関係とすることも可能である。ただしロール自体は、組織と直接紐付かない。言い換えれば、ロールの定義には、組織毎の権限（上記公報におけるサブシステム毎の権限に対応）を含まない。

範囲テーブル７４では、範囲ＩＤに、組織マスタテーブル７０のキーである組織ＩＤと、ロールマスタテーブル７６のロールＩＤが対応付けられる。ここで図１０の社員ＩＤ「１００１１」に付与される権限は、図８（ｂ）に対応する。実施の形態では、社員毎に範囲を設定する。例えば、範囲テーブル７４におけるＩＤ＝１の範囲は、社員ＩＤ＝１００１１に付与された範囲であり、範囲テーブル７４におけるＩＤ＝２の範囲は、社員ＩＤ＝１００１２に付与された範囲である。

第２の実施の形態のＩＤ管理装置１２は、異動情報２２や付加情報２６にしたがって範囲を自動設定し、自動設定した範囲をユーザに自動的に付与する。そのために、第２の実施の形態のＩＤ管理装置１２は範囲設定部５６をさらに含む。

範囲設定部５６は、特定の社員に対して特定の組織における特定の役割を付与する旨の異動情報２２が入力された場合に、特定の組織と特定の役割を対応付けた範囲情報を生成し、生成した範囲情報を範囲テーブル７４へ格納する。適用処理部５０は、範囲設定部５６が設定した範囲であり、すなわち特定の組織と特定の役割を対応付けた範囲を識別し、その範囲と、特定の社員とを対応付けた社員情報を社員マスタテーブル７２へ格納する。その際にロールマスタテーブル７６の内容は変更されない。

また、特定の社員に対して、特定の組織（例えば人事上所属する組織とは異なる組織）における役割を変更する旨の異動情報２２や付加情報２６が入力された場合、範囲設定部５６は、社員マスタテーブル７２においてその特定の社員に付与された範囲を識別し、範囲テーブル７４におけるその範囲情報を変更する。ここでの変更は、ロールの新規付与、ロールの追加、全てもしくは一部のロールの削除を含む。この場合もロールマスタテーブル７６の内容は変更されない。

図１０の権限情報は、異動情報２２や付加情報２６等にしたがって、保守者（例えば企業のＩＤ管理担当者）が手動にて設定・編集することもできる。例えば、範囲設定部５６は、範囲情報の編集画面を所定の表示装置に表示させてもよい。また範囲設定部５６は、その編集画面で編集された範囲情報であって、保守者による編集後の範囲情報を範囲テーブル７４に格納してもよい。またＩＤ管理装置１２は、図１０の各テーブルの内容を保守者に編集させるための画面を表示させ、その編集結果を各テーブルに反映する属性変更支援部をさらに備えてもよい。

以上の構成による図１のＩＤ管理システム１０の動作を説明する。
ここでは図８（ｂ）に示す例に沿って説明する。人事部システム１４は、人事異動により、社員の野村太郎に、ＡＡ部の部長ロールを付与する旨の異動情報２２をＩＤ管理装置１２へ送信する。ＩＤ管理装置１２の属性情報取込部４８は、その異動情報２２の内容を先付属性情報として先付属性保持部４０へ格納する。適用処理の開始タイミングになると、適用処理部５０は、異動情報２２に対応する先付属性情報と定義情報保持部４４の定義情報にしたがって、ルールベースの適用処理、すなわち新たな現在属性情報の設定処理を開始する。

適用処理部５０は、先付属性情報がロールの変更（付与や削除等）に関するものであることを所定のキーワード等により検出すると、範囲設定部５６を起動する。範囲設定部５６は、ロールの変更に関する先付属性情報が検出された場合に、範囲情報を自律的かつ自動的に生成し、または変更して、その範囲情報を記録する。ここでは、組織ＡＡ部と部長ロールとの組み合わせを含む範囲（範囲ＩＤ＝１とする）を新たに生成し、その範囲情報を範囲テーブル７４へ格納する。適用処理部５０は、野村太郎の社員ＩＤと所属組織に、範囲ＩＤ＝１を対応付けた社員情報を社員マスタテーブル７２へ格納する。

属性情報提供部５４は、現在過去属性保持部４２に格納された現在属性情報を連携先システム２０へ提供する。権限情報としては、組織マスタテーブル７０、社員マスタテーブル７２、範囲テーブル７４、ロールマスタテーブル７６、権限マスタテーブル７８に記録された最新の権限情報、例えば適用開始日が当日の権限情報を連携先システム２０へ提供する。これにより、ＩＤ管理装置１２が管理する権限情報と、連携先システム２０が管理する権限情報とを同期させる。

次に、ＡＢ部の業務部門システム１８は業務都合により、野村太郎に、ＡＢ部の会計ロールおよび総括ロールを付与する旨の付加情報２６をＩＤ管理装置１２へ送信する。例えばＡＢ部は人事異動前の野村太郎の所属組織である。付加情報２６の内容は、先付属性情報として先付属性保持部４０へ格納される。範囲設定部５６は、社員マスタテーブル７２において野村太郎に対応付けられた範囲ＩＤ＝１を識別し、範囲ＩＤ＝１、組織ＡＢ部、会計ロールの組み合わせを示す新たな範囲情報を範囲テーブル７４へ追加する。さらに、範囲ＩＤ＝１、組織ＡＢ部、総括ロールの組み合わせを示す新たな範囲情報を範囲テーブル７４へ追加する。これにより、野村太郎のロールおよび権限が拡充される。範囲テーブル７４の更新結果は、属性情報提供部５４により連携先システム２０へ配信される。

次に、ＡＢ部の業務部門システム１８は、野村太郎の引継業務が完了したため、ＡＢ部の会計ロールおよび総括ロールを野村太郎から剥奪する旨の付加情報２６をＩＤ管理装置１２へ送信する。付加情報２６の内容は、先付属性情報として先付属性保持部４０へ格納される。範囲設定部５６は、社員マスタテーブル７２において野村太郎に対応付けられた範囲ＩＤ＝１を識別し、範囲ＩＤ＝１、組織ＡＢ部、会計ロールの組み合わせを示す範囲情報を範囲テーブル７４から削除する。また、範囲ＩＤ＝１、組織ＡＢ部、総括ロールの組み合わせを示す範囲情報を範囲テーブル７４から削除する。既述したように、削除の場合、実際にレコードを削除することなく所定の削除フラグを設定してもよく、また、適用終了日を過去日に設定してもよい。

図１０のテーブル構成にて権限情報を管理するＩＤ管理装置１２および連携先システム２０は、各社員に付与された範囲に基づいて、各社員に付与された複数の組織に亘る役割と権限を識別することができる。ここでは社員ＩＤ＝１００１１の社員の権限を識別する例を説明する。ＩＤ管理装置１２および連携先システム２０は、社員マスタテーブル７２を参照し、社員ＩＤ＝１００１１に対応付けられた範囲ＩＤ＝１を特定する。次に、範囲テーブル７４を参照し、範囲ＩＤ＝１に対応付けられた（組織ＩＤ＝１とロールＩＤ＝１）（組織ＩＤ＝２とロールＩＤ＝２）（組織ＩＤ＝２とロールＩＤ＝３）を特定する。

以降、組織マスタテーブル７０、ロールマスタテーブル７６、権限マスタテーブル７８を参照して、社員ＩＤ＝１００１１の社員に付与されたロールおよび権限として、１）ＡＡ部・部長ロール・承認、２）ＡＢ部・会計ロール・承認、３）ＡＢ部・総括ロール・参照を特定する。なお、社員ＩＤ＝１００１１の社員が所属する組織は社員マスタテーブル７２を参照することで、ＡＡ部と識別できる。すなわち、上記１）は、人事上所属する組織の権限であり、２）３）は人事上所属しない組織の権限であることを識別可能である。

第２の実施の形態のＩＤ管理装置１２によると、ロールが組織と直接紐づかないため、新たなロールを作成しない限りロールマスタテーブル７６の保守は不要になる。そもそもロール（部長ロールや課長ロール等）は人事異動や組織改編があっても不変であり、本来変更すべきものではない。ＩＤ管理装置１２では、業務の都合上、複数の組織に亘る複数のロールを１人に付与した事実を、ロールより上位概念の範囲により吸収することで、ロールの独立性を高め、保守性を向上する。

またＩＤ管理装置１２によると、異動情報２２や付加情報２６等の入力に応じて、範囲の設定や範囲の付与を自動的に実行する。これにより、運用保守の負荷を低減できる。またＩＤ管理装置１２によると、社員に付与されたロールのうち、人事上所属している組織のロールと、人事上所属している組織のロールの区別も可能になる。

第２の実施の形態の変形例を説明する。
上記実施の形態では、権限情報をテーブルで保持することとしたが、他の形式で権限情報を保持してもよい。図１１は、権限情報を含むＪＳＯＮ（JavaScript（登録商標） Object Notation）データを示す。図１１のＪＳＯＮデータは、図１０の社員マスタテーブル７２、範囲テーブル７４と形式は異なるが、論理構造は同じであり、図１０の社員マスタテーブル７２と範囲テーブル７４を統合した内容を含む。

図１１の範囲情報８８は、論理的に図１０のＩＤ＝１の範囲を形成し、すなわち図１０の範囲テーブル７４におけるＩＤ＝１のレコードと同内容を示す。また、図１１の範囲情報９０は、論理的に図１０のＩＤ＝２の範囲を形成し、すなわち図１０の範囲テーブル７４におけるＩＤ＝２のレコードと同内容を示す。ＩＤ管理装置１２の適用処理部５０、範囲設定部５６は、ある社員の権限情報を設定、変更すべき場合に、その社員の社員ＩＤに対応するＪＳＯＮデータにおける範囲情報を設定、変更してもよい。この変形例でも、図１０の組織マスタテーブル７０、ロールマスタテーブル７６、権限マスタテーブル７８の情報は、人事異動では変更されないマスタ情報として現在過去属性保持部４２（および先付属性保持部４０）に格納されてもよい。

また上記実施の形態では言及していないが、先付属性保持部４０も現在過去属性保持部４２と同様のテーブル構成（図１０）で将来属性情報としての権限情報を保持してもよい。この場合、先付データ（異動情報２２、付加情報２６等）に基づいて先付属性情報を設定する際に、属性情報取込部４８と範囲設定部５６は、実施の形態の適用処理部５０と範囲設定部５６が実行した範囲設定処理および範囲付与処理を実行してもよい。

また、第２の実施の形態に記載した権限情報管理技術、すなわち範囲の概念を導入して権限情報を管理する技術は、先付属性保持部４０と現在過去属性保持部４２を備える構成のＩＤ管理装置１２に限らず適用可能である。例えば、現在属性情報のみを管理する一般的な属性管理装置にも広く適用可能である。このような一般的な属性管理装置に適用した場合も、第２の実施の形態と同様の効果を奏する。

（第３の実施の形態）
第３の実施の形態でも、第２の実施の形態と同様に、人の権限管理において「範囲」の概念を導入する。第２の実施の形態でも既述したが、範囲は、業務の必要に応じて所属組織とは独立して定まる組織とロールとの１つ以上の組み合わせの識別子とも言える。

ただし第２の実施の形態とは異なり、第３の実施の形態では原則として、範囲は人とは独立して予め定められ、人には既存の範囲を割当てる。また原則として人事異動等により範囲そのものの定義は変更されない。第３の実施の形態のＩＤ管理装置１２は図９に示す機能構成となる。すなわち機能ブロックの粒度では第２の実施の形態と同様である。以下、第２の実施の形態と重複する説明は省略し、異なる点を主に説明する。

図１２は、図１０の（ｃ）に対応し、第３の実施の形態の範囲テーブル７４を示す。範囲テーブル７４では、範囲ＩＤに、組織マスタテーブル７０のキーである組織ＩＤと、ロールマスタテーブル７６のキーであるロールＩＤが対応付けられる。一部既述したように、第３の実施の形態では原則として、範囲ＩＤにより識別される各範囲は、各社員に現実に付与されるロールとは独立して用意され、原則として変更されない。例えば、各範囲には、組織とロールの典型的な１つ以上の組み合わせが予め設定される。大企業や大規模な企業グループの場合、数十から数百の範囲が予め設定されてよい。

図１０（ａ）の組織マスタテーブル７０、図１０（ｂ）の社員マスタテーブル７２、図１０（ｄ）のロールマスタテーブル７６、図１０（ｅ）の権限マスタテーブル７８は、第３の実施の形態にも当てはまる。すなわち第２の実施の形態と同様に、社員マスタテーブル７２に、各人に付与された範囲ＩＤを格納することにより、ある人に付与された範囲に基づいてその人に付与された組織のそれぞれにおけるロールと権限が識別可能になる。

適用処理部５０は、社員マスタテーブル７２に保持された所属組織と範囲の組み合わせである社員情報を設定するユーザ情報設定部として機能する。具体的には、適用処理部５０は、ある社員のロールを変更すべき場合、社員マスタテーブル７２におけるその社員のレコードの範囲フィールドの値を、範囲テーブル７４で予め定められた別の範囲（範囲ＩＤ）に変更する。変更対象となるロールは、その社員が人事上所属している組織のロールであってもよく、人事上所属していない組織、言い換えれば、業務都合で権限が付与された組織のロールであってもよい。

また適用処理部５０は、特定の社員に対して特定の組織における特定のロールを付与する旨の人事情報や付加情報が入力された場合、特定の社員の社員情報を自動的に設定する。具体的には、社員マスタテーブル７２における特定の社員のレコードの範囲フィールドに対して、範囲テーブル７４で予め定められた特定の組織と特定のロールとを対応付けた範囲（範囲ＩＤ）を自動的に格納する。

また適用処理部５０は、人事情報や付加情報が示す特定の組織と特定のロールの組み合わせ（以下「特定組み合わせ」と呼ぶ。）をキーとして範囲テーブル７４を検索する。特定組み合わせを示す範囲レコードが範囲テーブル７４に存在すれば、その既存の範囲ＩＤを社員情報に設定する。その一方、特定組み合わせを示す範囲レコードが範囲テーブル７４に定められていない場合、そのことを検出して範囲設定部５６を起動する。範囲設定部５６は、その特定組み合わせを示す新たな範囲レコードを範囲テーブル７４に追加し、適用処理部５０は範囲設定部５６により生成された新たな範囲ＩＤを社員情報に設定する。

なお図１０および図１２に示す組織情報、社員情報、範囲情報、ロール情報、権限情報は、異動情報２２や付加情報２６等にしたがって、保守者（例えば企業のＩＤ管理担当者）が手動にて設定・編集することもできる。例えば、不図示の権限設定支援部は、これらの情報の編集画面を所定の表示装置に表示させてもよい。また適用処理部５０は、その編集画面で編集された社員情報を保守者の操作に応じて社員マスタテーブル７２へ格納してもよい。同様に範囲設定部５６は、編集画面で編集された範囲情報を保守者の操作に応じて範囲テーブル７４へ格納してもよい。このように、適用処理部５０および範囲設定部５６は、保守者の操作をトリガとして図１０および図１２の各種情報を変更してもよい。

以上の構成による図１のＩＤ管理システム１０の動作を説明する。
初期状態として、社員の野村太郎はＡＢ部に所属し、ＡＢ部の会計ロールと総括ロールが付与されているとする。この場合、図１２の範囲テーブル７４では範囲ＩＤ「４」が該当するため、社員マスタテーブル７２の野村太郎のレコードには、組織ＩＤ「２」範囲ＩＤ「４」が設定されている。

人事部システム１４は、野村太郎がＡＡ部の部長へ異動する旨の異動情報２２をＩＤ管理装置１２へ送信する。ＩＤ管理装置１２の属性情報取込部４８は、その異動情報２２の内容を先付属性情報として先付属性保持部４０へ格納する。適用処理の開始タイミングになると、適用処理部５０は、異動情報２２に対応する先付属性情報と定義情報保持部４４の定義情報にしたがって、ルールベースの適用処理、すなわち新たな現在属性情報の設定処理を開始する。

適用処理部５０は、先付属性情報がロールの変更（付与や削除等）に関するもの（ここでは異動情報２２）であることを所定のキーワード等により検出すると、その異動情報２２が示す組織「ＡＡ部」ロール「部長」に一致する範囲が存在するかを範囲テーブル７４において検索する。図１２の範囲テーブル７４では範囲ＩＤ「１」が該当するため、適用処理部５０は、社員マスタテーブル７２の野村太郎のレコードを、組織ＩＤ「１」範囲ＩＤ「１」に更新する。社員マスタテーブル７２の更新結果は、属性情報提供部５４により連携先システム２０へ提供される。

例外処理として、仮に異動情報２２が示す組織「ＡＡ部」ロール「部長」に一致する範囲が範囲テーブル７４に存在しなければ、範囲設定部５６は、組織ＩＤ「１」ロールＩＤ「１」の新たな範囲（例えば範囲ＩＤ「９９」）を範囲テーブル７４に追加する。この場合、適用処理部５０は、社員マスタテーブル７２の野村太郎のレコードを、組織ＩＤ「１」範囲ＩＤ「９９」に更新する。このように、社員への付与が必要なロールに対応する範囲が存在しなければ、新たな範囲を動的に作成して社員へ付与するため、可能性がある全ての範囲を予め範囲テーブル７４に登録しておく必要はない。

次に、ＡＢ部における業務引継のため、ＡＢ部の業務部門システム１８は、野村太郎に、ＡＢ部の会計ロールおよび総括ロールを付与する旨の付加情報２６をＩＤ管理装置１２へ送信する。付加情報２６の内容は、先付属性情報として先付属性保持部４０へ格納される。適用処理部５０は、その付加情報２６が示す組織「ＡＢ部」ロール「会計」「総括」に一致する範囲が存在するか否かを範囲テーブル７４において検索する。図１２の範囲テーブル７４では範囲ＩＤ「４」が該当するため、適用処理部５０は、社員マスタテーブル７２の野村太郎のレコードに範囲ＩＤ「４」を追加する。この結果、社員マスタテーブル７２の野村太郎のレコードは、組織ＩＤ「１」範囲ＩＤ「１」「４」に更新される。社員マスタテーブル７２の更新結果は、属性情報提供部５４により連携先システム２０へ提供される。

次に、ＡＢ部における業務引継完了に伴い、ＡＢ部の業務部門システム１８は、野村太郎から、ＡＢ部の会計ロールおよび総括ロールを剥奪する旨の付加情報２６をＩＤ管理装置１２へ送信する。付加情報２６の内容は、先付属性情報として先付属性保持部４０へ格納される。適用処理部５０は、その付加情報２６が示す組織「ＡＢ部」ロール「会計」「総括」に一致する範囲が存在するか否かを範囲テーブル７４において検索する。図１２の範囲テーブル７４では範囲ＩＤ「４」が該当するため、適用処理部５０は、社員マスタテーブル７２の野村太郎のレコードから範囲ＩＤ「４」を削除する。この結果、野村太郎のレコードは、組織ＩＤ「１」範囲ＩＤ「１」に更新される。社員マスタテーブル７２の更新結果は、属性情報提供部５４により連携先システム２０へ提供される。

第３の実施の形態のＩＤ管理装置１２によると、人事異動や業務都合により社員のロール変更の必要が発生しても原則として範囲テーブル７４の変更は不要になり、社員マスタテーブル７２における範囲ＩＤを変更することで対応可能になる。また、１人の社員に対して複数の組織の複数の役割を付与する場合も重複する情報を管理する必要はなく、また複数の社員間で共通の範囲を再利用することができる。これにより、社員の権限情報管理を容易化でき、また保守性も向上できる。

第３の実施の形態の変形例を説明する。
上記実施の形態では権限情報をテーブルで管理することとしたが、第２実施形態の変形例でも示したようにＪＳＯＮデータにより管理してもよい。例えば、属性リポジトリ３８（先付属性保持部４０と現在過去属性保持部４２の少なくとも一方）に格納される図１０および図１２の社員情報は、ＪＳＯＮ形式のデータであってもよい。図１３〜図１５は、権限情報を含むＪＳＯＮデータを示す。具体的には、上記動作の説明における野村太郎（社員ＩＤ＝１００１１）の権限情報を含むＪＳＯＮデータを示している。これらのＪＳＯＮデータは、図１０（ｂ）の社員マスタテーブル７２の社員情報と、図１２の範囲テーブル７４の範囲情報を含む。

図１３の範囲情報９２は、上記動作の説明における初期状態の範囲情報を示し、すなわち野村太郎がＡＢ部に所属し、ＡＢ部の会計ロールと総括ロールが付与されている状態の範囲情報を示している。ここで、野村太郎がＡＡ部の部長へ異動する旨の異動情報２２が受け付けられると、適用処理部５０は、ＪＳＯＮデータの所属組織を変更するとともに、範囲情報９２を組織ＩＤ「１」ロールＩＤ「１」へ変更する。その結果、図１４で示すＪＳＯＮデータに更新される。なお適用処理部５０は、組織情報やロール情報のマスタ情報を参照して、各組織や各ロールのＩＤを識別してもよい。

次に、ＡＢ部の会計ロールおよび総括ロールを野村太郎に付与する旨の付加情報２６が受け付けられると、適用処理部５０は、範囲情報９０に、組織ＩＤ「２」ロールＩＤ「２」と、組織ＩＤ「２」ロールＩＤ「３」を追加する。その結果、図１５で示すＪＳＯＮデータに更新される。次に、ＡＢ部の会計ロールおよび総括ロールを野村太郎から剥奪する旨の付加情報２６が受け付けられると、適用処理部５０は、範囲情報９０から、組織ＩＤ「２」ロールＩＤ「２」と、組織ＩＤ「２」ロールＩＤ「３」を削除する。その結果、図１４で示すＪＳＯＮデータに更新される。

権限情報をＪＳＯＮ形式で管理することは拡張性および性能の面でメリットがある。
まず拡張性のメリットを説明する。ＪＳＯＮには、ＲＤＢやディレクトリサーバと異なり事前のスキーマ定義が不要という特徴がある。一般的に、ＩＤ管理製品が管理対象とする属性（データモデル）は、企業によってバラバラであり、ＩＤ管理製品側で決めきれるものではない。特に企業規模が大きいほど、扱うべき情報が多く、独自の属性も多くなる傾向がある。ＩＤ管理のデータ格納方式にＲＤＢやディレクトリサーバを採用する場合、各企業のデータモデルにあわせて属性を変更することは容易でなく、また変更できても多大なコストが生じうる。さらにまた、一旦運用が開始された後で属性を変更することはかなり困難である。その一方、ＩＤ管理のデータ格納方式にＪＳＯＮを採用すると、導入先の企業のデータモデルにあわせて低コストで柔軟に属性変更等の対応が可能になる。

次に性能面のメリットを説明する。ＩＤ管理のデータ格納方式にＪＳＯＮを採用する場合、データ管理手段として、一般的なＲＤＢ製品ではなく、ＮｏＳＱＬデータベースを使用できる。例えば、ドキュメント指向データベースであるＭｏｎｇｏＤＢ等を使用できる。この場合、属性リポジトリ３８（先付属性保持部４０と現在過去属性保持部４２の少なくとも一方）における社員情報管理機能を、１つ以上の装置に導入されたＮｏＳＱＬデータベースにより実現してもよい。ＲＤＢはそのアーキテクチャ上、スケールアウト（例えば複数台のサーバを横並びで構成すること）による性能向上は難しい。その一方、ＮｏＳＱＬデータベースは、その仕組みからスケールアウトによるパフォーマンス向上（言い換えれば水平スケーラビリティの確保）が容易である。したがって、ＩＤ管理のデータ格納方式にＪＳＯＮを採用し、必要に応じてＮｏＳＱＬデータベースを横並びに増やす（例えば複数のサーバを並行稼働させる）ことで容易に性能向上を図ることができる。

（第４の実施の形態）
まず概要を説明する。日本企業では４月と１０月に大規模な人事異動や組織改編が行われることが多い。大規模な人事異動や組織改編は、社員や組織に関する属性情報に大量の変更が生じる。これまでは、事前に属性情報の変更に関する想定データをＩＤ管理システム上に準備し、誤りがないかチェックの上、人事異動や組織改編の発令日に変更後の属性情報を配信していた。

しかし、従来のチェック作業は人手で行っている部分が多く、非効率であり、ミスが発生する可能性も高かった。例えば、経営企画部から組織改編の第１案がシステム部門へ提供され、後日その修正案が提供されることがある。この場合、組織改編の差分をシステム部門で調べており、差分把握に時間を要していた。また、その差分情報を見て、組織マスタ情報を手作業で修正しなければならず、ミスが生じやすかった。

第４の実施の形態のＩＤ管理装置１２は、人事異動や組織改編に対するシミュレーションサービスをユーザ端末へ提供することで、人や組織に関する属性情報変更の効率化とミス削減を実現する。例えば、仮の変更情報の入力を受け付け、現在または過去の属性情報との差分を可視化する。また、人事異動や組織改編に関する複数案間の差分を可視化し、さらに、複数案のマージや複数案間での不整合検出を自動化する。そして、シミュレーションリポジトリでの作業結果を、属性リポジトリ３８の現在属性情報や先付属性情報に反映させる。

第４の実施の形態でのユーザ端末は、シミュレーションサービス利用者の端末を意味し、例えば、人事異動の案を作成する人事部のシステム（ＰＣ端末等）を含む。また、組織改編の案を作成する経営企画部のシステム（ＰＣ端末等）を含む。また、人事部や経営企画部から案を受領して、ＩＤ管理システム１０に反映させるシステム部門のシステム（ＰＣ端末等）を含む。

図１６は、第４の実施の形態のＩＤ管理装置１２の機能構成を示すブロック図である。第４の実施の形態のＩＤ管理装置１２は、第１〜第３の実施の形態のＩＤ管理装置１２の機能を包含し、シミュレーション機能をさらに有する。図１６の機能ブロックのうち第１〜第３の実施の形態と同一または対応する機能ブロックには図２・図９と同一の符号を付している。なお通信部３０のブロックは省略している。以下、第１〜第３の実施の形態と重複する説明は省略する。

ＩＤ管理装置１２は、シミュレーション用リポジトリ１００とシミュレーション部１０２をさらに備える。シミュレーション部１０２は、ユーザ画面表示部１０４、属性情報読出し部１０６、属性情報出力部１０８、編集情報取得部１１０、マージ部１１２、編集結果記録部１１４、差分検出部１１６、反映部１１８を含む。

図１７は、シミュレーション用リポジトリ１００の構成を示す。図１７では、シミュレーション用データをテーブル形式で保持する例を示すが、図１１、図１３〜図１５に示したＪＳＯＮ形式等、他の形式で保持してもよい。シミュレーション用リポジトリ１００は、オブジェクトグラフ構造で作業履歴を保持し、具体的には１回の作業に対応するオブジェクト（以下「ノード」とも呼ぶ。）を単位としてシミュレーション用データを保持する。

シミュレーション用リポジトリ１００は、ノードＩＤ、タイトル、属性情報、親ノード、適用開始日、反映場所等を対応付けたシミュレーション用データを保持する。このうち属性情報には、人事や組織に関する現在の属性情報や、変更後の属性情報が格納される。適用開始日と反映場所は、デフォルトでは親ノードの値を引き継ぐが、ユーザにより編集可能である。図１７には不図示だが、シミュレーション用データは、ノードの作成者と作成日時の情報も含む。なお、図１７のノードＩＤは、後述の図１８〜図２０で示す各ノードのＩＤに対応する。

ユーザ画面表示部１０４は、シミュレーション機能の利用者が作業する画面（以下「ユーザ画面」とも呼ぶ。）を所定の表示装置に表示させる。ＩＤ管理装置１２がウェブサーバの機能を有する場合、ユーザ画面表示部１０４は、ユーザ画面のウェブページをユーザ端末へ送信し、ユーザ端末のウェブブラウザに当該ウェブページを表示させてもよい。後述するようにユーザ画面は、履歴一覧画面、詳細表示画面、編集画面、比較画面、マージ画面を含む。

属性情報読出し部１０６は、ユーザ画面でユーザが指定するリポジトリ、具体的には先付属性保持部４０または現在過去属性保持部４２から、ユーザ指定した属性情報を読出す。例えば、現在過去属性保持部４２に格納された人事や組織に関する現在の属性情報を読出し、また先付属性保持部４０に格納された将来の属性情報を読出す。属性情報読出し部１０６は、読出した属性情報を、新規ノード（例えば図１７のノード１）と対応付けてシミュレーション用リポジトリ１００に格納する。

属性情報出力部１０８は、ユーザ画面でユーザが指定する属性情報をＣＳＶ（Comma-Separated Values）形式のファイルデータ（以下「属性編集用ファイル」と呼ぶ。）として所定の記憶領域へ出力する。属性編集用ファイルへの出力対象は、ユーザ画面に表示中の属性情報であってもよい。また出力データの形式は、ユーザが編集可能な形式であればＣＳＶ以外でもよいことはもちろんである。

編集情報取得部１１０は、変更情報取得部とも言え、ユーザによる属性情報の変更結果・編集結果を示す情報をユーザ端末から取得する。変更元となるデータは、現在過去属性保持部４２に格納された現在属性情報、先付属性保持部４０に格納された先付属性情報、シミュレーション用リポジトリ１００において各ノードに対応付けられた属性情報を含む。例えばシミュレーション用リポジトリ１００は、ユーザ端末からアップロードされた属性編集用ファイルから、ユーザによる編集後の属性情報を読出す。また、ユーザ画面においてユーザが属性情報を編集した場合、編集後の属性情報をユーザ端末から取得する。

マージ部１１２は、ユーザ画面でユーザが指定する複数のノードの属性情報を１つのノードの属性情報として統合する。属性情報が行と列で表現可能である場合、マージ部１１２は、各ノードの属性情報における行と列を統合してもよい。例えば、第１ノードがＡ本部ＡＡ部に所属する５０人分の属性情報（レコード数５０）を含み、第２ノードがＡ本部ＡＢ部に所属する１００人分の属性情報（レコード数１００）を含む場合、これらをマージしたＡ本部１５０人分の属性情報（レコード数１５０）を生成してもよい。また、第１ノードが２０人分の属性情報（属性項目数１０）を含み、第２ノードが当該２０人分の属性情報（属性項目数５）を含む場合、これらをマージした当該２０人分の属性情報（属性項目数１５）を生成してもよい。

マージ部１１２は、統合対象となる複数ノードの属性情報間に競合が存在する場合、その競合を検出する。競合は情報の不整合と言え、属性項目または属性値レベルの不整合と言える。例えば、統合対象の第１ノードが定める社員Ａの所属組織（または役職）と、統合対象の第２ノードが定める社員Ａの所属組織（または役職）が異なる場合、競合として検出する。また、第１ノードの属性情報と、第２ノードの属性情報間で、同じ組織コードに異なる組織が割当てられている場合、競合として検出する。

編集結果記録部１１４は、属性情報変更部とも言え、編集情報取得部１１０により取得された編集後の属性情報と、マージ部１１２により統合された属性情報をシミュレーション用リポジトリ１００に格納する。その際、編集前の属性情報とは異なるノードの属性情報としてシミュレーション用リポジトリ１００に記録する。また、編集前の属性情報のノードを親ノードとして記録することでノード間の親子関係（前後関係）を記録する。またマージ部１１２によるマージ処理にて競合が検出された場合、編集結果記録部１１４は、競合（エラー）を示す情報を編集後の属性情報に対応付けて記録する。

差分検出部１１６は、ユーザ画面でユーザが指定する複数ノード間で属性情報が異なる場合、その差分を検出する。例えば、同一主体（人または組織）の属性項目値がノード間で異なる場合、双方のノードに記録された当該主体の当該属性項目値を抽出し、差分情報としてシミュレーション用リポジトリ１００に記録してもよい。また、双方のノードに記録された当該主体の属性情報全体を抽出対象としてもよい。

反映部１１８は、ユーザ画面でユーザが指定するノードの属性情報を、ユーザが指定するリポジトリ、具体的には先付属性保持部４０または現在過去属性保持部４２へ格納する。現在過去属性保持部４２に格納する場合、現在適用中の属性情報に対して、ユーザによる変更内容を即時反映することになる。また、先付属性保持部４０に格納する場合、将来適用要諦の属性情報に対して、ユーザによる変更内容を反映することになる。

以上の構成によるＩＤ管理システム１０の動作を説明する。
図１８は、ＩＤ管理装置１２が提供するユーザ画面を示す。同図のユーザ画面は、履歴一覧画面１２０、詳細表示画面１２２、編集画面１２４を含む。履歴一覧画面１２０は、ユーザの作業に伴うノードの親子関係や生成順を示すノード履歴グラフ、作業履歴グラフとも言える。

事前にユーザは、現在過去属性保持部４２から現在の組織情報を読み込ませ、その組織情報を案１と案２のそれぞれに基づいて編集済である。図１７で示すように、履歴一覧画面１２０のノード１は現在の組織情報に対応し、編集情報取得部１１０が生成したものである。また、履歴一覧画面１２０のノード２は案１による変更後の組織情報に対応し、ノード３は案２による変更後の組織情報に対応し、それぞれ編集結果記録部１１４が生成したものである。

履歴一覧画面１２０でユーザがノード２に対する選択操作を入力すると、ユーザ画面表示部１０４は、案１を反映したノード２の属性情報をシミュレーション用リポジトリ１００から取得し、詳細表示画面１２２に表示させる。詳細表示画面１２２でユーザが編集開始操作を入力すると、ユーザ画面表示部１０４は編集画面１２４を表示させる。編集画面１２４でユーザが属性情報を編集後、保存操作を入力すると、編集結果記録部１１４は、ノード２を親ノードとするノード４を生成する。そしてノード４のデータとして、編集画面１２４に入力された編集後の属性情報をシミュレーション用リポジトリ１００に格納する。

図１９も、ＩＤ管理装置１２が提供するユーザ画面を示す。履歴一覧画面１２０でユーザがノード３に対する選択操作を入力すると、ユーザ画面表示部１０４は、案２を反映したノード３の属性情報をシミュレーション用リポジトリ１００から取得し、詳細表示画面１２２に表示させる。詳細表示画面１２２でユーザが比較開始操作を入力すると、ユーザ画面表示部１０４は、比較元としてノード３を自動選択した比較画面１２６を表示させる。比較画面１２６でユーザは比較先（例えばノード２）を選択する。なお、履歴一覧画面１２０で比較開始操作が入力されると比較画面１２６へ遷移し、この場合、ユーザは比較元と比較先の両方を手動で選択する。

比較画面１２６でユーザが比較実行を入力すると、差分検出部１１６は、比較元ノードと比較先ノードの差分を検出する。例えば差分検出部１１６は、一方のノードが含み、他方のノードが含まない組織ＩＤのレコードを差分として検出する。また、両方のノードが同じ組織ＩＤのレコードを含む場合に、双方の属性項目（例えば存続区分）や属性値（例えば存続または廃止）が異なる事実を差分として検出する。

ユーザ画面表示部１０４は、差分検出部１１６により検出された差分を比較結果として比較画面１２６に表示させる。比較結果として、互いに異なる比較元ノードのレコードと比較先ノードのレコードの両方を並べて表示させてもよい。また、一方のノード（例えば比較元ノード）のレコードのみを表示させてもよく、また、差分が検出された部分（属性項目や属性値）を通常より強調した態様で表示させてもよい。

図２０も、ＩＤ管理装置１２が提供するユーザ画面を示す。履歴一覧画面１２０でユーザがノード３に対する選択操作を入力すると、ユーザ画面表示部１０４は、案２を反映したノード３の属性情報をシミュレーション用リポジトリ１００から取得し、詳細表示画面１２２に表示させる。詳細表示画面１２２でユーザがマージ開始操作を入力すると、ユーザ画面表示部１０４は、マージ先としてノード３を自動選択したマージ画面１２８を表示させる。マージ画面１２８でユーザはマージ先のノードへマージするノード（例えばノード２であり、以下「マージ元ノード」と呼ぶ。）を選択する。なお、履歴一覧画面１２０でマージ開始操作が入力されるとマージ画面１２８へ遷移し、この場合、ユーザはマージ先とマージ元の両方を手動で選択する。

マージ画面１２８でユーザがマージ実行操作を入力すると、マージ部１１２は、マージ先ノードのデータに対してマージ元ノードのデータを統合した新規ノードのデータ（図のノード５）をシミュレーション用リポジトリ１００に格納する。マージ部１１２は、マージ先ノードが３０レコードを含み、マージ元ノードが２０レコードを含む場合、５０レコードを含む新規ノードを生成してもよい。ユーザ画面表示部１０４は、マージ結果として、新規ノードのデータをマージ画面１２８に表示させる。

マージ部１１２は、統合対象のデータ間に競合を検出すると、競合を示す情報を記録し、ユーザ画面表示部１０４は、その競合を示す情報を付加してマージ結果を表示させる。競合結果を示す確認画面をマージ画面１２８とは別に表示させてもよい。ユーザは、競合箇所毎に、手作業での修正にてマージ結果を入力してもよい。また、マージ処理を中断させてもよく、マージ処理全体をロールバックさせてもよく、図のノード５を削除させてもよい。マージ部１１２は、ユーザが入力した修正内容を反映した新規ノードをシミュレーション用リポジトリ１００に格納してもよい。

なお、ユーザ画面表示部１０４は、ノードデータの適用開始日や反映場所をユーザに設定させるためのノード設定画面を表示させてもよい。例えば、履歴一覧画面１２０で選択されたノードに関する詳細表示画面１２２でユーザが反映操作を入力した場合に、ノード設定画面を表示させてもよい。反映部１１８は、ノード設定画面の設定情報にしたがって、選択ノードが定める属性情報を現在属性情報として現在過去属性保持部４２へ格納し、または、将来属性情報として先付属性保持部４０へ格納する。

例えば、図１７のノード５について、ユーザは、適用開始日として将来日付を設定し、反映場所として先付属性保持部４０を設定してもよい。反映部１１８は、ノード５が定める組織情報や人事情報に適用開始日を対応付けた先付属性情報を先付属性保持部４０に格納する。このように、現在過去属性保持部４２に格納された現在適用中の現組織データを、複数の案をもとに改編し、各案を修正し、比較検討し、マージした結果である新組織データを、将来適用予定の新組織データとして保存することができる。

以上、本発明を実施の形態をもとに説明した。これらの実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せによりいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。

１２ ＩＤ管理装置、 ４０ 先付属性保持部、 ４２ 現在過去属性保持部、 ４４ 定義情報保持部、 ４８ 属性情報取込部、 ５０ 適用処理部、 ５４ 属性情報提供部、 ５６ 範囲設定部、 １１０ 編集情報取得部、 １１２ マージ部、 １１６ 差分検出部。

Claims (4)

1. 人と、その人が人事上所属する組織と、範囲ＩＤとを含むユーザ情報を保持するユーザ情報保持部と、
   各組織に設けられる複数の役割と、各役割に付与される権限とを対応付けた役割情報を保持する役割情報保持部と、
   前記役割を範囲ＩＤに対応付けた範囲情報を保持する範囲情報保持部と、
   ユーザ情報設定部と、
   を備え、
   前記ユーザ情報設定部は、ある人の役割または権限を変更すべき場合、前記ユーザ情報に含まれるその人の範囲ＩＤを別の範囲ＩＤに変更することを特徴とする属性情報管理装置。
2. 前記ユーザ情報設定部は、特定の人に対して特定の組織における特定の役割を付与する旨の人事情報が入力された場合に、前記ユーザ情報に含まれる前記特定の人の範囲ＩＤに、前記範囲情報で定められた前記特定の組織と前記特定の役割とを対応付けた範囲ＩＤを自動的に設定することを特徴とする請求項１に記載の属性情報管理装置。
3. 人と、その人が人事上所属する組織と、範囲ＩＤとを含むユーザ情報と、各組織に設けられる複数の役割と、各役割に付与される権限とを対応付けた役割情報と、前記役割を範囲ＩＤに対応付けた範囲情報とを所定の記憶領域に記憶する情報処理装置が、
   ある人の役割または権限を変更すべき場合、前記ユーザ情報に含まれるその人の範囲ＩＤを別の範囲ＩＤに変更することを特徴とする属性情報管理方法。
4. 人と、その人が人事上所属する組織と、範囲ＩＤとを含むユーザ情報と、各組織に設けられる複数の役割と、各役割に付与される権限とを対応付けた役割情報と、前記役割を範囲ＩＤに対応付けた範囲情報とを所定の記憶領域に記憶する情報処理装置に、
   ある人の役割または権限を変更すべき場合、前記ユーザ情報に含まれるその人の範囲ＩＤを別の範囲ＩＤに変更する機能を実現させるためのコンピュータプログラム。

Images