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

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

Info

Publication number
JP2017021553A
JP2017021553A JP2015138370A JP2015138370A JP2017021553A JP 2017021553 A JP2017021553 A JP 2017021553A JP 2015138370 A JP2015138370 A JP 2015138370A JP 2015138370 A JP2015138370 A JP 2015138370A JP 2017021553 A JP2017021553 A JP 2017021553A
Authority
JP
Japan
Prior art keywords
information
range
role
organization
attribute
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2015138370A
Other languages
English (en)
Inventor
広之 和田
Hiroyuki Wada
広之 和田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nomura Research Institute Ltd
Original Assignee
Nomura Research Institute Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nomura Research Institute Ltd filed Critical Nomura Research Institute Ltd
Priority to JP2015138370A priority Critical patent/JP2017021553A/ja
Publication of JP2017021553A publication Critical patent/JP2017021553A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

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

Description

本発明は、データ処理技術に関し、特に組織や人に関する属性情報を管理する技術に関する。
企業において人に割当てられた属性情報を一元的に管理し、その属性情報を連携先のリポジトリに配信するID管理システムが提案されている(例えば特許文献1参照)。
特開2009−129289号公報
企業における人事異動等を契機として、社員が人事上所属していない組織における権限をその社員に付与する必要が生じる場合がある。しかし、従来のID管理システムでは、人事上所属していない組織における権限を社員に付与した状態を効率的に管理することは困難であり、システムの保守性等が低下してしまうことがあった。
本願発明は上記課題に鑑みたもので、その主な目的は、様々な組織における役割が特定の人に付与されうる状況において、人の役割の効率的な管理を支援する技術を提供することである。
上記課題を解決するために、本発明のある態様の属性情報管理装置は、人と、その人が人事上所属する組織と、範囲IDとを含むユーザ情報を保持するユーザ情報保持部と、各組織に設けられる複数の役割と、各役割に付与される権限とを対応付けた役割情報を保持する役割情報保持部と、役割を範囲IDに対応付けた範囲情報を保持する範囲情報保持部と、ユーザ情報設定部と、を備える。ユーザ情報設定部は、ある人の役割または権限を変更すべき場合、ユーザ情報に含まれるその人の範囲IDを別の範囲IDに変更する。ユーザ情報保持部は、人が人事上所属する組織を示すユーザ情報を保持してもよい。役割情報保持部は、複数の組織に共通して適合する情報であって、各組織に設けられる複数の役割と、各役割に付与される権限とを対応付けた役割情報を保持してもよい。範囲情報保持部は、1つ以上の組織のそれぞれにおける役割を1つの範囲に対応付けた範囲情報を保持してもよい。ユーザ情報保持部は、各人に付与された範囲を含むユーザ情報を保持することにより、ある人に付与された範囲にもとづいてその人に付与された1つ以上の組織のそれぞれにおける役割と権限を識別可能にしてもよい。ユーザ情報設定部は、ある人の役割を変更すべき場合、ユーザ情報が示すその人の範囲を、範囲情報で定められた別の範囲に変更してもよい。
本発明の別の態様は、属性情報管理方法である。この方法は、人と、その人が人事上所属する組織と、範囲IDとを含むユーザ情報と、各組織に設けられる複数の役割と、各役割に付与される権限とを対応付けた役割情報と、役割を範囲IDに対応付けた範囲情報とを所定の記憶領域に記憶する情報処理装置が、ある人の役割または権限を変更すべき場合、ユーザ情報に含まれるその人の範囲IDを別の範囲IDに変更する。ユーザ情報に、各人に付与された範囲を記録することにより、ある人に付与された範囲にもとづいてその人に付与された1つ以上の組織のそれぞれにおける役割と権限を識別可能にするステップステップをさらに実行してもよい。
なお、以上の構成要素の任意の組合せ、本発明の表現を、装置、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
本発明によれば、様々な組織における役割が特定の人に付与されうる状況において、人の役割の効率的な管理を支援できる。
実施の形態のID管理システムの構成を示す図である。 第1の実施の形態のID管理装置の機能構成を示すブロック図である。 先付属性保持部に格納される先付属性情報の一例を示す図である。 現在過去属性保持部に格納される現在過去属性情報の一例を示す図である。 定義情報保持部に格納される定義情報の詳細を示す図である。 従来のID管理システムにおける権限情報の構成を示す図である。 1人の社員に付与すべきロールを示す模式図である。 ロール範囲の概念を示す図である。 第2の実施の形態のID管理装置の機能構成を示すブロック図である。 現在過去属性保持部における権限管理のためのテーブル構成を示す図である。 権限情報を含むJSONデータを示す図である。 第3の実施の形態の範囲テーブルを示す図である。 権限情報を含むJSONデータを示す図である。 権限情報を含むJSONデータを示す図である。 権限情報を含むJSONデータを示す図である。 第4の実施の形態のID管理装置の機能構成を示すブロック図である。 シミュレーション用リポジトリの構成を示す図である。 ID管理装置が提供するユーザ画面を示す図である。 ID管理装置が提供するユーザ画面を示す図である。 ID管理装置が提供するユーザ画面を示す図である。
図1は、実施の形態のID管理システム10の構成を示す。ID管理システム10は、企業の組織や従業員等に関する各種属性情報の管理に係る情報処理システムである。ID管理システム10は、ID管理装置12、人事部システム14、経営企画部システム16、業務部門システム18、連携先システム20で総称されるシステムA用リポジトリ20a、システムB用リポジトリ20b、システムC用リポジトリ20cを備える。これらの各システム・装置は企業のイントラネットで接続される。なお、ID管理装置12に接続される各装置・システムは、社内(社内網内)に構築された装置・システムに限らず、クラウド等、社外に構築された装置・システムであってもよい。
ID管理装置12は、企業に設けられた複数の組織や、企業に雇用された複数の社員に関する様々な属性情報を一元的に管理する情報処理装置である。社員に関する属性情報は、社員番号や氏名、所属組織、役職、権限等を含み、またそれらの識別情報であるIDを含む。人事部システム14は、人事部に設置されたPC等の各種装置を含み、人事異動に関する異動情報22をID管理装置12へ送信する。経営企画部システム16は、経営企画部に設置されたPC等の各種装置を含み、組織改編に関する組織改編情報24をID管理装置12へ送信する。
業務部門システム18は、人事部、経営企画部以外の組織に構築される情報システムである。図1では1つの業務部門システム18を描いているが、例えば営業部・開発部・コンサルティング部等、種々の本部・部・課のそれぞれに構築された複数の業務部門システム18が存在する。業務部門システム18のPC等は、付加情報26をID管理装置12へ送信する。付加情報26は、人事異動や組織改編以外の情報であり、実際の業務遂行において必要となる各種属性情報を含む。例えば、連絡先情報(電話番号等)、組織におけるロール、権限(システム利用権限等)を含む。
なお、実施の形態におけるロールは、組織において社員(ユーザ)が果すべき役割を意味し、また、組織においてユーザに付与された役割・役職・権限を意味する。後述するように、部長ロール、会計ロール、総括ロール等、複数種類のロールが存在する。
システムA用リポジトリ20a、システムB用リポジトリ20b、システムC用リポジトリ20cのそれぞれは、連携先のシステムA、システムB、システムCに設置された属性情報管理用のリポジトリデータベースである。連携先システム20は、例えば業務部門システム18であってもよい。ID管理装置12は、連携先システム20のそれぞれへ、連携先システム20ごとに予め定められた項目の属性情報28を定期的に配信する。
実施の形態のID管理装置12は、1)属性情報管理のためのリポジトリ構造、2)権限管理における範囲の概念の導入、3)シミュレーション機能を主な特徴として備える。以下、1)属性情報管理のためのリポジトリ構造について第1の実施の形態で説明し、2)権限管理における範囲の概念の導入について第2および第3の実施の形態で説明し、3)シミュレーション機能について第4の実施の形態で説明する。
(第1の実施の形態)
図2は、第1の実施の形態のID管理装置12の機能構成を示すブロック図である。ID管理装置12は、通信部30、制御部32、記憶部34を備える。通信部30は、種々の通信プロトコルにしたがって外部装置との通信処理を実行する。通信対象の外部装置は、ID管理対象の企業内に構築された装置に限らず、クラウド等の企業外に構築された装置も含む。制御部32は、組織や社員に関する属性情報管理のための各種データ処理を実行する。制御部32は、通信部30を介して外部装置とデータを送受する。記憶部34は、制御部32によるデータ処理のための各種データを記憶する記憶領域である。
本明細書のブロック図において示す各ブロックは、ハードウェア的には、コンピュータのCPUやメモリをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。例えば、制御部32内の各ブロックは、プログラムモジュールとして実装されてID管理装置12のストレージに格納され、ID管理装置12のCPUがそれらのプログラムモジュールをメインメモリに読み出して適宜実行することにより、各ブロックの機能が発揮されてよい。
記憶部34は、先付データ保持部36、属性リポジトリ38、定義情報保持部44を備える。先付データ保持部36は、人事部システム14から送信された異動情報22、経営企画部システム16から送信された組織改編情報24、業務部門システム18から送信された付加情報26を保持する。以下、異動情報22、組織改編情報24、付加情報26を総称して「先付データ」とも呼ぶ。先付データは、後述の先付属性情報に反映させるべき組織や社員に関する属性情報を含む。
属性リポジトリ38は、組織や社員に関する現在・過去・未来の属性情報を保持する。属性リポジトリ38は、先付属性保持部40と現在過去属性保持部42を含む。属性リポジトリ38は、ID管理装置12とは物理的に別の装置・筐体に設けられてもよい。例えば、属性リポジトリ38を備えるリポジトリサーバ(データベースサーバ)がID管理装置12とは別に設けられ、ID管理装置12は、通信網を介してリポジトリサーバの属性リポジトリ38にアクセスしてもよい。
現在過去属性保持部42は、組織や社員に関する現在適用中の属性と、過去適用された属性の両方を含む情報(以下「現在過去属性情報」と呼ぶ)を保持する。現在過去属性情報のうち現在の属性情報と過去の属性情報を区別する場合、前者を「現在属性情報」と呼び、後者を「過去属性情報」と呼ぶ。先付属性保持部40は、組織や社員に関する将来の属性を示す情報(以下「先付属性情報」と呼ぶ)を保持する。先付属性情報は、現在は未確定であるが、将来の割当て・付与が予定されている先日付(未来日付)の属性情報である。現在過去属性情報と先付属性情報の具体例は後述する。
定義情報保持部44は、後述の適用処理部50による適用処理の内容を規定した定義情報を保持する。定義情報の具体例は後述する。
制御部32は、先付データ取得部46、属性情報取込部48、適用処理部50、属性情報提供部54を備える。先付データ取得部46は、人事部システム14、経営企画部システム16、業務部門システム18から送信された先付データを取得し、先付データ保持部36へ格納する。
属性情報取込部48は、先付データ保持部36に新たな先付データが格納されたことを検出すると、その先付データが示す組織や社員の属性情報を先付属性情報として先付属性保持部40へ格納する。属性情報取込部48は、1日の予め定められた時刻になったことを契機に、このような先付属性情報取込処理を実行してもよい。
図3は、先付属性保持部40に格納される先付属性情報の一例を示す。同図は、先付データとしての異動情報22に基づいて設定された先付属性情報を示している。先付属性情報は、先付データの内容をそのまま転記したものでもよい。先付属性情報は、その属性値を現在属性情報へ反映すべきタイミング(日付、時刻等)を示す適用開始日を含む。具体的に図3の先付属性情報は、12月1日に「野村太郎」がコンサルティング部の部長へ異動となり、12月1日に「野村花子」が退職することを示している。なお、適用開始日は、人事異動や組織改編の発令日が設定されてもよい。
適用開始日は先付データに含まれてもよい。また、適用開始日が先付データに含まれない場合等、属性情報取込部48は、先付属性情報を設定する際に、所定の規則にしたがって適用開始日を自律的に設定してもよい。例えば、先付データが異動情報22であれば、現在日から半月先や1月先の未来日付を自動設定してもよい。また、先付データが付加情報26であれば、当日日付や1日後の比較的近傍の未来日付を自動設定してもよい。
なお、属性情報取込部48は、所定の削除操作の入力や、所定の削除指示データの受信に応じて、先付属性保持部40に格納済の先付属性情報を削除してもよい。この削除操作や削除指示データでは、削除対象の先付属性情報を特定するためのキー(例えば社員IDと適用開始日の組み合わせ)が指定されてもよい。同様に属性情報取込部48は、所定の更新操作の入力や、所定の更新指示データの受信に応じて、先付属性保持部40に格納済の先付属性情報を更新・変更してもよい。この更新操作や更新指示データでは、更新対象の先付属性情報を特定するためのキーと、属性の更新値が指定されてもよい。このように、先付属性保持部40に格納された先付属性情報は、その適用開始日に至るまでの期間に更新・削除されうる。
属性情報提供部54は、現在過去属性保持部42に格納された最新の現在属性情報から連携先システム20ごとに予め定められた項目を抽出して、各連携先システム20向けの属性情報28を生成する。例えば、現在属性情報の差分を配信する場合、適用開始日が当日日付の現在属性情報を識別し、その現在属性情報から所定項目を抽出して属性情報28を生成してもよい。属性情報提供部54は、複数の連携先システム20へ属性情報28を送信する。属性情報提供部54は、属性情報配信処理を定期的に実行してもよく、例えば、1日1回、適用処理部50による適用処理完了を契機に実行してもよい。
適用処理部50は、先付属性保持部40に格納された先付属性情報のうち適用開始日に到達した先付属性情報にしたがって、新たな現在属性情報を現在過去属性保持部42に格納する適用処理を実行する。適用処理部50は、1日の所定の時刻に到達した場合にバッチ処理として適用処理を実行してもよい。また適用処理部50は、ID管理装置12のOSが管理する現在日付を参照して、適用処理の対象とする先付属性情報を識別してもよい。適用処理部50は、適用開始日に未達の先付属性情報は適用処理の対象外とする。
変形例として、適用処理部50は、適用処理の対象とする先付属性情報を識別する基準として、現在日付に代えて運用日付を使用してもよい。運用日付は、日付を跨いで実行されるバッチファイル(いわゆる夜間バッチ)を考慮した日付である。例えば、適用処理のバッチファイルが23時に開始〜翌日1時に終了する場合、適用処理の開始前に運用日付を現在日付+1日に設定する。具体例として、11月30日の23時から12月1日の1時まで実行される適用処理では、運用日付が12月1日であるため、適用開始日が12月1日の先付属性情報を対象としてもよい。
図4は、現在過去属性保持部42に格納される現在過去属性情報の一例を示す。同図は、社員属性を示す現在過去属性情報を示している。現在過去属性情報は、適用開始日と適用終了日を含む。適用開始日は、そのレコードが現在属性情報として設定された日付を示し、典型的には設定元の先付属性情報の適用開始日と同じ値となる。社員属性を示す現在過去属性情報のキーは、社員IDと適用開始日の組み合わせになる。
適用終了日は、そのレコードが現在属性情報から過去属性情報へ移行した日付を示し、言い換えれば、新たな現在属性情報が記録されたことに伴い現在属性情報として無効になった日付が設定される。なお、社員属性を示す現在属性情報では、雇用期間の取決めがある契約社員の場合は雇用期間の終了日が適用終了日として設定され、雇用期間の取決めがない正社員の場合は2999年末日が適用終了日として設定される。
図4(a)は、図3の先付属性情報を適用前の現在過去属性情報を示し、例えば2014年11月30日の現在過去属性情報を示している。図4(b)は、図3の先付属性情報を適用後の現在過去属性情報を示し、例えば2014年12月1日の現在過去属性情報を示している。適用処理部50は、12月1日の適用処理において、図3の先付属性情報にしたがって、図4(b)の属性情報80と属性情報82を現在過去属性保持部42に格納する。実施の形態では、退職者についてはその所属を「退職」にすることで識別可能にする。変形例として、他の項目・属性を「退職」としてもよく、また、他の項目・属性に所定のデータを設定する等、任意の退職者フラグ設定処理を実行してもよい。
適用処理部50は、属性情報80と属性情報82を格納するまで現在属性情報であった属性情報84と属性情報86について、その適用終了日を過去日(図では前日)に変更することで、属性情報84と属性情報86が過去属性情報であることを識別可能にする。現在過去属性保持部42は、新たな現在属性情報が格納された場合に、それまでの現在属性情報を過去属性情報として継続して保持する。退職者(図4の野村花子)についても、現在過去属性情報を継続して保持する。
図2に戻り、適用処理部50は、定義実行エンジン52を含む。定義実行エンジン52は、定義情報保持部44に予め格納された定義情報が示す規則にしたがって、現在過去属性情報への先付属性情報のルールベースの反映処理を実行するルールエンジンである。定義実行エンジン52は、公知のルールエンジンであってもよい。
図5は、定義情報保持部44に格納される定義情報の詳細を示す。定義情報は、取得データ定義60、差分判定ルール定義62、適用ルール定義64を含む。取得データ定義60は、先付属性保持部40に格納された先付属性情報と、現在過去属性保持部42に格納された現在過去属性情報の中のどのデータ(情報項目)を処理対象とするかを定める。例えば、図3・図4の例で示す社員属性情報の場合、社員ID・氏名・所属・役職を処理対象として定めてもよい。
差分判定ルール定義62について説明する。一般的に、異動情報22の属性量(すなわち情報項目数)<現在過去属性情報の属性量(すなわち属性リポジトリ38で管理する情報項目数)であるため、単純に比較すると常に差分が生じることになる。そこで差分判定ルール定義62は、差分判定において無視すべき情報項目を定める。また、属性値の加工・編集方法およびその結果を判定して適用有無を決定するロジック等を定める。
適用ルール定義64は、取得データ定義60による取得データの識別処理と、差分判定ルール定義62による判定処理の結果に基づいた、現在過去属性保持部42に格納すべき新たな現在属性情報の生成規則を定める。適用ルール定義64は、複数のより詳細な定義を含み、実施の形態では属性マッピング定義66、属性引継定義67、退職情報作成定義68を含むこととする。
属性マッピング定義66は、先付属性情報の情報項目と、現在過去属性情報(現在属性情報)の情報項目とのマッピングのための対応関係を定める。例えば、図3・図4に示す社員属性の場合は、先付属性情報の「所属」を現在過去属性情報の「所属」に対応付け、先付属性情報の「役職」を現在過去属性情報の「役職」に対応付ける。このような単純なマッピング以外にも、属性マッピング定義66は、名称が不一致である場合のマッピング規則を含む。また、先付属性情報の1項目を現在過去属性情報の複数項目に対応付けるマッピング規則や、逆に先付属性情報の複数項目を現在過去属性情報の1項目に対応付けるマッピング規則を含む。
属性引継定義67は、属性情報の引継処理、言い換えれば、マッピング処理の詳細を定める。例えば属性引継定義67は、先付属性情報の属性値や、現在過去属性情報(典型的には適用処理実行前までの現在属性情報)の属性値に応じた引継処理の定義を含む。また属性引継定義67は、属性値の引継条件を示す論理式である条件式を含む。例えば、if(ある項目の属性値が○○であれば等の条件)、then(属性値の編集等を含むアクション)を定義した条件式を含む。
属性引継定義67の具体例を示す。例えば属性引継定義67は、適用処理実行前までの現在属性情報が示す役職が「部長」の場合、先付属性情報における「着任日」属性の有無に関わらず、現在日付が適用開始日以降であれば当該現在属性情報を即時削除することを定めてもよい。なお、実施の形態における削除処理は、適用終了日を過去日に設定し、それまでの現在属性情報を過去属性情報に切り替えることで、それまでの現在属性情報を無効にする処理である。変形例として記憶領域からデータを消去する処理であってもよい。
また属性引継定義67は、適用処理実行前までの現在属性情報が示す役職が「部長」以外で、かつ、先付属性情報に「着任日」属性がある場合、現在日付が着任日以降であれば当該現在属性情報を削除することを定めてもよい。着任日は、新所属組織の業務部門システム18から送信される付加情報26に記録されて、ID管理装置12へ通知されてもよい。典型的には着任日は、旧所属組織での業務引継等を完了した日であり、適用開始日以降の日付となる。したがって、適用開始日〜着任日の間は、適用処理前の属性と、適用処理後の属性の両方が現在属性情報として有効にされてもよい。すなわち、両方の適用終了日が未来日に設定された状態が維持されてもよい。
また属性引継定義67は、適用処理実行前までの現在属性情報が示す役職が「部長」以外で、かつ、先付属性情報に「着任日」属性がない場合は、現在日付が適用開始日+30日以降であれば当該属性情報を削除することを定めてもよい。一般的に部長が可能な承認や決済の権限は非常に強力であるため、旧属性が部長の場合には、発令日を迎えると即時に旧権限を削除する一方、他の役職であれば着任日に応じて旧権限を削除するような柔軟な属性引継処理がルールベースによって可能になる。
別の例として、先付属性情報における所属組織および/または役職の属性値が特定の値を示す場合に、現在日付が、先付属性情報が示す適用開始日+30日以降になったことを契機に適用処理を実行するよう制御することもできる。このように、実施の形態の引継処理では、「属性項目」より下位のレベルの「属性値」に基づいて引継処理の態様を制御できる。また、特許文献1における「これまでの属性を有効にする」「新たな属性を有効にする」「新属性と旧属性の両方を有効にする」という固定的な引継ポリシーではなく、ルールベースによる柔軟な引継ポリシーの設定を実現できる。また、ルールベースの記述により、条件式による判定も可能になる。
退職情報作成定義68は、先付属性情報が社員の退職を示す場合に、現在過去属性情報とは別の情報であり、退職者の属性を記録した退職情報を作成する処理の定義や、退職情報の形式等を定める。
以上の構成による図1のID管理システム10の動作を説明する。
人事部システム14、経営企画部システム16、業務部門システム18は、人事異動や組織改編、業務状況に応じた様々なタイミングで先付データをID管理装置12へ送信する。ID管理装置12の先付データ取得部46は、先付データを受信し、先付データ保持部36へ格納する。属性情報取込部48は、先付データに設定された組織または社員の属性情報を先付属性情報として先付属性保持部40に格納する。
予め定められた適用処理の開始タイミングになると、適用処理部50は、先付属性保持部40に格納された先付属性情報のうち適用開始日に至った先付属性情報を適用処理対象として識別する。そして、適用処理対象の先付属性情報にもとづいて新たな現在属性情報を生成し、その新たな現在属性情報を現在過去属性保持部42へ格納する。その際に、それまでの現在属性情報を過去属性情報とするよう更新する。
適用処理部50は、過去属性情報へ移行対象となるそれまでの現在属性情報の属性値、または、新たな現在属性情報へ移行対象となる先付属性情報の属性値と、定義情報保持部44に予め格納された定義情報(例えば条件式)にしたがってルールベースの適用処理を実行する。属性情報提供部54は、適用処理部50によって現在過去属性保持部42に格納された新たな現在属性情報を連携先システム20へ配信する。
第1の実施の形態のID管理装置12では、先付属性情報を保持する先付属性保持部40を、現在過去属性情報を保持する現在過去属性保持部42とは別に設けた。先付属性情報は、適用開始日に至るまでの期間に変更されうる未確定のデータである。現在過去属性保持部42に未確定のデータを入力する場合、現在確定している属性を取得し、また更新することが複雑になってしまう。また未確定の属性を配信してしまうリスクも高まる。ID管理装置12では、確定した属性情報の記憶領域と、未確定の属性情報の記憶領域を明確に区別することで、属性情報管理を安全かつ効率的に実現する。
またID管理装置12では、企業の組織や社員、退職者に関する現在属性情報だけでなく、過去属性情報も現在過去属性保持部42に保持する。これにより、任意の過去時点における属性情報を容易に取得でき、また、組織や社員の現在属性を過去の任意時点の状態に戻すことも容易になる。
第1の実施の形態の変形例を説明する。
上記実施の形態では、現在過去属性保持部42に、新たな現在属性情報を順次蓄積していく(言い換えれば追加していく)構成を説明した。変形例として、ID管理装置12は、現在属性情報の訂正や削除を要求する所定のデータがID管理装置12に入力された場合、入力データにしたがって、現在過去属性保持部42に格納済の現在過去属性情報(典型的には現在属性情報)を更新し、または削除する現在属性変更部をさらに備えてもよい。
上記実施の形態では、属性情報提供部54は、現在過去属性保持部42に格納された現在属性情報を連携先システム20へ配信した。変形例として、将来の付与が予定されている属性情報を必要とする連携先システム20に対しては、先付属性保持部40に格納された将来属性情報を配信してもよい。また、属性情報提供部54は、連携先システム20からの属性情報提供要求を受信した場合に、その要求で指定された過去属性情報、現在属性情報、または将来属性情報を連携先システム20へ提供してもよい。
(第2の実施の形態)
まず概要を説明する。従来のID管理システムでは、業務権限やシステム利用権限等、各種権限の管理と制御を、組織横断的なロール情報と、所属組織の情報の組み合わせで実現してきた。図6は、従来のID管理システムにおける権限情報の構成を示す。ロールは、典型的には単一の企業や企業グループにおいて複数の組織に共通して適合する。例えば、A本部AA部の部長の権限は、A本部AB部の部長の権限と同等である。
多くの日本企業では、人事上所属する組織における権限とは別に、人事上未所属の組織における権限が必要になるケースがある。人事上未所属の組織は、典型的には人事部門が定めた正式な所属組織とは別の組織を意味する。例えば、1)業務都合で、人事上は所属していない他部署のシステム利用権限が必要なケース、2)グループ会社でシステムを共有しており、その利用権限が必要なケース、3)異動直後の引継期間中に、前部署の権限を維持すべきケース等がある。
従来のID管理システムでは、人事上所属する組織におけるユーザの権限と、人事上未所属の組織におけるユーザの権限の両方を正しく表現することは困難であった。例えば図7に示すように、AA部に所属し、AA部の部長権限を有するユーザに対して、異なるAB部の会計権限を付与した事実を、システム上で正規化を崩すことなく上手く表現することは困難であった。
例えば、特開2008−210117号公報には、ユーザ情報管理システムにおいて、ユーザに付与する管理用権限を、サブシステム毎に異なる権限情報の組み合わせに対応付けた権限変換情報を設けることが記載されている(段落0036〜0037、0054、図1、図5等)。ここで、上記公報の管理用権限情報は実施の形態におけるロールに対応すると言え、サブシステム毎の権限は本明細書における権限に対応すると言える。
上記公報の段落0037には、『管理用権限情報は、ユーザの属する部門に応じて決定することも可能である。例えば、人事部門のユーザに対しては、人事部門において必要な処理が実行可能な「丙1」という管理用権限を付与し、営業部門のユーザに対しては、営業部門において必要な処理が実行可能な「丙2」という管理用権限を付与する。なお、一ユーザに対して複数の管理用権限を付与するようにしてもよい。』と記載されている。すなわち、1人のユーザに対して、組織毎に異なる複数の管理者権限を付与することが記載されている。
上記公報の技術では組織とロールとが密に結びついている。そのため、組織改編のたびに、組織毎に新たなロールを作成して権限変換情報を更新する必要があり、運用保守の負荷が高い。また、上記公報の図5に示される権限変換情報のテーブルには(組織×ロール)個のレコードが登録される必要があり、ユーザ数が多い大企業等ではレコード数が増大し、保守性が低下してしまう。また、上記文献のテーブル構成では、ユーザが保持する権限が、人事上所属している組織に対する権限か、人事上未所属の組織に対する権限かを識別することが困難である。
そこで実施の形態では、「範囲」(以下「ロール範囲」とも呼ぶ)の概念を導入する。図8はロール範囲の概念を示す。図8(a)はロール範囲を含むER図であり、図8(b)は社員に対する権限付与の模式図である。ロール範囲は、人事上の所属とは無関係に定義が可能であり、複数のロールを含みうる。またロール範囲は、人事上所属する組織とは独立して定められた、業務上権限が必要な組織の範囲と言える。また、人事部が取決めたユーザが正式に所属する組織を超えて、現実の業務遂行のために権限をもつべき組織と役割の1つ以上の組み合わせとも言える。
図9は、第2の実施の形態のID管理装置12の機能構成を示すブロック図である。第2の実施の形態のID管理装置12は、第1の実施の形態のID管理装置12の機能を包含し、範囲の概念を導入した権限管理機能をさらに有する。図9の機能ブロックのうち第1の実施の形態と同一または対応する機能ブロックには図2と同一の符号を付している。以下、第1の実施の形態と重複する説明は省略する。
図10は、現在過去属性保持部42における権限管理のためのテーブル構成を示す。現在過去属性保持部42は、社員の権限を定める現在過去属性情報を、組織マスタテーブル70、社員マスタテーブル72、範囲テーブル74、ロールマスタテーブル76、権限マスタテーブル78により保持する。図10では現在属性情報としての権限情報を示しているが、実際の各テーブルは適用開始日と適用終了日の列を含み、過去属性情報としての権限情報も含む。
社員マスタテーブル72では、社員IDに、組織マスタテーブル70のキーである組織IDと、範囲テーブル74のキーである範囲IDが対応付けられる。ロールマスタテーブル76では、ロールIDに、権限マスタテーブル78のキーである権限IDが対応付けられる。図8(a)に示したように、ロールと権限は1対nの関係であり、ロールマスタテーブル76と権限マスタテーブル78の組み合わせによりロールの権限が規定される。なお、会社によってはロールと権限を1対1の関係とすることも可能である。ただしロール自体は、組織と直接紐付かない。言い換えれば、ロールの定義には、組織毎の権限(上記公報におけるサブシステム毎の権限に対応)を含まない。
範囲テーブル74では、範囲IDに、組織マスタテーブル70のキーである組織IDと、ロールマスタテーブル76のロールIDが対応付けられる。ここで図10の社員ID「10011」に付与される権限は、図8(b)に対応する。実施の形態では、社員毎に範囲を設定する。例えば、範囲テーブル74におけるID=1の範囲は、社員ID=10011に付与された範囲であり、範囲テーブル74におけるID=2の範囲は、社員ID=10012に付与された範囲である。
第2の実施の形態のID管理装置12は、異動情報22や付加情報26にしたがって範囲を自動設定し、自動設定した範囲をユーザに自動的に付与する。そのために、第2の実施の形態のID管理装置12は範囲設定部56をさらに含む。
範囲設定部56は、特定の社員に対して特定の組織における特定の役割を付与する旨の異動情報22が入力された場合に、特定の組織と特定の役割を対応付けた範囲情報を生成し、生成した範囲情報を範囲テーブル74へ格納する。適用処理部50は、範囲設定部56が設定した範囲であり、すなわち特定の組織と特定の役割を対応付けた範囲を識別し、その範囲と、特定の社員とを対応付けた社員情報を社員マスタテーブル72へ格納する。その際にロールマスタテーブル76の内容は変更されない。
また、特定の社員に対して、特定の組織(例えば人事上所属する組織とは異なる組織)における役割を変更する旨の異動情報22や付加情報26が入力された場合、範囲設定部56は、社員マスタテーブル72においてその特定の社員に付与された範囲を識別し、範囲テーブル74におけるその範囲情報を変更する。ここでの変更は、ロールの新規付与、ロールの追加、全てもしくは一部のロールの削除を含む。この場合もロールマスタテーブル76の内容は変更されない。
図10の権限情報は、異動情報22や付加情報26等にしたがって、保守者(例えば企業のID管理担当者)が手動にて設定・編集することもできる。例えば、範囲設定部56は、範囲情報の編集画面を所定の表示装置に表示させてもよい。また範囲設定部56は、その編集画面で編集された範囲情報であって、保守者による編集後の範囲情報を範囲テーブル74に格納してもよい。またID管理装置12は、図10の各テーブルの内容を保守者に編集させるための画面を表示させ、その編集結果を各テーブルに反映する属性変更支援部をさらに備えてもよい。
以上の構成による図1のID管理システム10の動作を説明する。
ここでは図8(b)に示す例に沿って説明する。人事部システム14は、人事異動により、社員の野村太郎に、AA部の部長ロールを付与する旨の異動情報22をID管理装置12へ送信する。ID管理装置12の属性情報取込部48は、その異動情報22の内容を先付属性情報として先付属性保持部40へ格納する。適用処理の開始タイミングになると、適用処理部50は、異動情報22に対応する先付属性情報と定義情報保持部44の定義情報にしたがって、ルールベースの適用処理、すなわち新たな現在属性情報の設定処理を開始する。
適用処理部50は、先付属性情報がロールの変更(付与や削除等)に関するものであることを所定のキーワード等により検出すると、範囲設定部56を起動する。範囲設定部56は、ロールの変更に関する先付属性情報が検出された場合に、範囲情報を自律的かつ自動的に生成し、または変更して、その範囲情報を記録する。ここでは、組織AA部と部長ロールとの組み合わせを含む範囲(範囲ID=1とする)を新たに生成し、その範囲情報を範囲テーブル74へ格納する。適用処理部50は、野村太郎の社員IDと所属組織に、範囲ID=1を対応付けた社員情報を社員マスタテーブル72へ格納する。
属性情報提供部54は、現在過去属性保持部42に格納された現在属性情報を連携先システム20へ提供する。権限情報としては、組織マスタテーブル70、社員マスタテーブル72、範囲テーブル74、ロールマスタテーブル76、権限マスタテーブル78に記録された最新の権限情報、例えば適用開始日が当日の権限情報を連携先システム20へ提供する。これにより、ID管理装置12が管理する権限情報と、連携先システム20が管理する権限情報とを同期させる。
次に、AB部の業務部門システム18は業務都合により、野村太郎に、AB部の会計ロールおよび総括ロールを付与する旨の付加情報26をID管理装置12へ送信する。例えばAB部は人事異動前の野村太郎の所属組織である。付加情報26の内容は、先付属性情報として先付属性保持部40へ格納される。範囲設定部56は、社員マスタテーブル72において野村太郎に対応付けられた範囲ID=1を識別し、範囲ID=1、組織AB部、会計ロールの組み合わせを示す新たな範囲情報を範囲テーブル74へ追加する。さらに、範囲ID=1、組織AB部、総括ロールの組み合わせを示す新たな範囲情報を範囲テーブル74へ追加する。これにより、野村太郎のロールおよび権限が拡充される。範囲テーブル74の更新結果は、属性情報提供部54により連携先システム20へ配信される。
次に、AB部の業務部門システム18は、野村太郎の引継業務が完了したため、AB部の会計ロールおよび総括ロールを野村太郎から剥奪する旨の付加情報26をID管理装置12へ送信する。付加情報26の内容は、先付属性情報として先付属性保持部40へ格納される。範囲設定部56は、社員マスタテーブル72において野村太郎に対応付けられた範囲ID=1を識別し、範囲ID=1、組織AB部、会計ロールの組み合わせを示す範囲情報を範囲テーブル74から削除する。また、範囲ID=1、組織AB部、総括ロールの組み合わせを示す範囲情報を範囲テーブル74から削除する。既述したように、削除の場合、実際にレコードを削除することなく所定の削除フラグを設定してもよく、また、適用終了日を過去日に設定してもよい。
図10のテーブル構成にて権限情報を管理するID管理装置12および連携先システム20は、各社員に付与された範囲に基づいて、各社員に付与された複数の組織に亘る役割と権限を識別することができる。ここでは社員ID=10011の社員の権限を識別する例を説明する。ID管理装置12および連携先システム20は、社員マスタテーブル72を参照し、社員ID=10011に対応付けられた範囲ID=1を特定する。次に、範囲テーブル74を参照し、範囲ID=1に対応付けられた(組織ID=1とロールID=1)(組織ID=2とロールID=2)(組織ID=2とロールID=3)を特定する。
以降、組織マスタテーブル70、ロールマスタテーブル76、権限マスタテーブル78を参照して、社員ID=10011の社員に付与されたロールおよび権限として、1)AA部・部長ロール・承認、2)AB部・会計ロール・承認、3)AB部・総括ロール・参照を特定する。なお、社員ID=10011の社員が所属する組織は社員マスタテーブル72を参照することで、AA部と識別できる。すなわち、上記1)は、人事上所属する組織の権限であり、2)3)は人事上所属しない組織の権限であることを識別可能である。
第2の実施の形態のID管理装置12によると、ロールが組織と直接紐づかないため、新たなロールを作成しない限りロールマスタテーブル76の保守は不要になる。そもそもロール(部長ロールや課長ロール等)は人事異動や組織改編があっても不変であり、本来変更すべきものではない。ID管理装置12では、業務の都合上、複数の組織に亘る複数のロールを1人に付与した事実を、ロールより上位概念の範囲により吸収することで、ロールの独立性を高め、保守性を向上する。
またID管理装置12によると、異動情報22や付加情報26等の入力に応じて、範囲の設定や範囲の付与を自動的に実行する。これにより、運用保守の負荷を低減できる。またID管理装置12によると、社員に付与されたロールのうち、人事上所属している組織のロールと、人事上所属している組織のロールの区別も可能になる。
第2の実施の形態の変形例を説明する。
上記実施の形態では、権限情報をテーブルで保持することとしたが、他の形式で権限情報を保持してもよい。図11は、権限情報を含むJSON(JavaScript(登録商標) Object Notation)データを示す。図11のJSONデータは、図10の社員マスタテーブル72、範囲テーブル74と形式は異なるが、論理構造は同じであり、図10の社員マスタテーブル72と範囲テーブル74を統合した内容を含む。
図11の範囲情報88は、論理的に図10のID=1の範囲を形成し、すなわち図10の範囲テーブル74におけるID=1のレコードと同内容を示す。また、図11の範囲情報90は、論理的に図10のID=2の範囲を形成し、すなわち図10の範囲テーブル74におけるID=2のレコードと同内容を示す。ID管理装置12の適用処理部50、範囲設定部56は、ある社員の権限情報を設定、変更すべき場合に、その社員の社員IDに対応するJSONデータにおける範囲情報を設定、変更してもよい。この変形例でも、図10の組織マスタテーブル70、ロールマスタテーブル76、権限マスタテーブル78の情報は、人事異動では変更されないマスタ情報として現在過去属性保持部42(および先付属性保持部40)に格納されてもよい。
また上記実施の形態では言及していないが、先付属性保持部40も現在過去属性保持部42と同様のテーブル構成(図10)で将来属性情報としての権限情報を保持してもよい。この場合、先付データ(異動情報22、付加情報26等)に基づいて先付属性情報を設定する際に、属性情報取込部48と範囲設定部56は、実施の形態の適用処理部50と範囲設定部56が実行した範囲設定処理および範囲付与処理を実行してもよい。
また、第2の実施の形態に記載した権限情報管理技術、すなわち範囲の概念を導入して権限情報を管理する技術は、先付属性保持部40と現在過去属性保持部42を備える構成のID管理装置12に限らず適用可能である。例えば、現在属性情報のみを管理する一般的な属性管理装置にも広く適用可能である。このような一般的な属性管理装置に適用した場合も、第2の実施の形態と同様の効果を奏する。
(第3の実施の形態)
第3の実施の形態でも、第2の実施の形態と同様に、人の権限管理において「範囲」の概念を導入する。第2の実施の形態でも既述したが、範囲は、業務の必要に応じて所属組織とは独立して定まる組織とロールとの1つ以上の組み合わせの識別子とも言える。
ただし第2の実施の形態とは異なり、第3の実施の形態では原則として、範囲は人とは独立して予め定められ、人には既存の範囲を割当てる。また原則として人事異動等により範囲そのものの定義は変更されない。第3の実施の形態のID管理装置12は図9に示す機能構成となる。すなわち機能ブロックの粒度では第2の実施の形態と同様である。以下、第2の実施の形態と重複する説明は省略し、異なる点を主に説明する。
図12は、図10の(c)に対応し、第3の実施の形態の範囲テーブル74を示す。範囲テーブル74では、範囲IDに、組織マスタテーブル70のキーである組織IDと、ロールマスタテーブル76のキーであるロールIDが対応付けられる。一部既述したように、第3の実施の形態では原則として、範囲IDにより識別される各範囲は、各社員に現実に付与されるロールとは独立して用意され、原則として変更されない。例えば、各範囲には、組織とロールの典型的な1つ以上の組み合わせが予め設定される。大企業や大規模な企業グループの場合、数十から数百の範囲が予め設定されてよい。
図10(a)の組織マスタテーブル70、図10(b)の社員マスタテーブル72、図10(d)のロールマスタテーブル76、図10(e)の権限マスタテーブル78は、第3の実施の形態にも当てはまる。すなわち第2の実施の形態と同様に、社員マスタテーブル72に、各人に付与された範囲IDを格納することにより、ある人に付与された範囲に基づいてその人に付与された組織のそれぞれにおけるロールと権限が識別可能になる。
適用処理部50は、社員マスタテーブル72に保持された所属組織と範囲の組み合わせである社員情報を設定するユーザ情報設定部として機能する。具体的には、適用処理部50は、ある社員のロールを変更すべき場合、社員マスタテーブル72におけるその社員のレコードの範囲フィールドの値を、範囲テーブル74で予め定められた別の範囲(範囲ID)に変更する。変更対象となるロールは、その社員が人事上所属している組織のロールであってもよく、人事上所属していない組織、言い換えれば、業務都合で権限が付与された組織のロールであってもよい。
また適用処理部50は、特定の社員に対して特定の組織における特定のロールを付与する旨の人事情報や付加情報が入力された場合、特定の社員の社員情報を自動的に設定する。具体的には、社員マスタテーブル72における特定の社員のレコードの範囲フィールドに対して、範囲テーブル74で予め定められた特定の組織と特定のロールとを対応付けた範囲(範囲ID)を自動的に格納する。
また適用処理部50は、人事情報や付加情報が示す特定の組織と特定のロールの組み合わせ(以下「特定組み合わせ」と呼ぶ。)をキーとして範囲テーブル74を検索する。特定組み合わせを示す範囲レコードが範囲テーブル74に存在すれば、その既存の範囲IDを社員情報に設定する。その一方、特定組み合わせを示す範囲レコードが範囲テーブル74に定められていない場合、そのことを検出して範囲設定部56を起動する。範囲設定部56は、その特定組み合わせを示す新たな範囲レコードを範囲テーブル74に追加し、適用処理部50は範囲設定部56により生成された新たな範囲IDを社員情報に設定する。
なお図10および図12に示す組織情報、社員情報、範囲情報、ロール情報、権限情報は、異動情報22や付加情報26等にしたがって、保守者(例えば企業のID管理担当者)が手動にて設定・編集することもできる。例えば、不図示の権限設定支援部は、これらの情報の編集画面を所定の表示装置に表示させてもよい。また適用処理部50は、その編集画面で編集された社員情報を保守者の操作に応じて社員マスタテーブル72へ格納してもよい。同様に範囲設定部56は、編集画面で編集された範囲情報を保守者の操作に応じて範囲テーブル74へ格納してもよい。このように、適用処理部50および範囲設定部56は、保守者の操作をトリガとして図10および図12の各種情報を変更してもよい。
以上の構成による図1のID管理システム10の動作を説明する。
初期状態として、社員の野村太郎はAB部に所属し、AB部の会計ロールと総括ロールが付与されているとする。この場合、図12の範囲テーブル74では範囲ID「4」が該当するため、社員マスタテーブル72の野村太郎のレコードには、組織ID「2」範囲ID「4」が設定されている。
人事部システム14は、野村太郎がAA部の部長へ異動する旨の異動情報22をID管理装置12へ送信する。ID管理装置12の属性情報取込部48は、その異動情報22の内容を先付属性情報として先付属性保持部40へ格納する。適用処理の開始タイミングになると、適用処理部50は、異動情報22に対応する先付属性情報と定義情報保持部44の定義情報にしたがって、ルールベースの適用処理、すなわち新たな現在属性情報の設定処理を開始する。
適用処理部50は、先付属性情報がロールの変更(付与や削除等)に関するもの(ここでは異動情報22)であることを所定のキーワード等により検出すると、その異動情報22が示す組織「AA部」ロール「部長」に一致する範囲が存在するかを範囲テーブル74において検索する。図12の範囲テーブル74では範囲ID「1」が該当するため、適用処理部50は、社員マスタテーブル72の野村太郎のレコードを、組織ID「1」範囲ID「1」に更新する。社員マスタテーブル72の更新結果は、属性情報提供部54により連携先システム20へ提供される。
例外処理として、仮に異動情報22が示す組織「AA部」ロール「部長」に一致する範囲が範囲テーブル74に存在しなければ、範囲設定部56は、組織ID「1」ロールID「1」の新たな範囲(例えば範囲ID「99」)を範囲テーブル74に追加する。この場合、適用処理部50は、社員マスタテーブル72の野村太郎のレコードを、組織ID「1」範囲ID「99」に更新する。このように、社員への付与が必要なロールに対応する範囲が存在しなければ、新たな範囲を動的に作成して社員へ付与するため、可能性がある全ての範囲を予め範囲テーブル74に登録しておく必要はない。
次に、AB部における業務引継のため、AB部の業務部門システム18は、野村太郎に、AB部の会計ロールおよび総括ロールを付与する旨の付加情報26をID管理装置12へ送信する。付加情報26の内容は、先付属性情報として先付属性保持部40へ格納される。適用処理部50は、その付加情報26が示す組織「AB部」ロール「会計」「総括」に一致する範囲が存在するか否かを範囲テーブル74において検索する。図12の範囲テーブル74では範囲ID「4」が該当するため、適用処理部50は、社員マスタテーブル72の野村太郎のレコードに範囲ID「4」を追加する。この結果、社員マスタテーブル72の野村太郎のレコードは、組織ID「1」範囲ID「1」「4」に更新される。社員マスタテーブル72の更新結果は、属性情報提供部54により連携先システム20へ提供される。
次に、AB部における業務引継完了に伴い、AB部の業務部門システム18は、野村太郎から、AB部の会計ロールおよび総括ロールを剥奪する旨の付加情報26をID管理装置12へ送信する。付加情報26の内容は、先付属性情報として先付属性保持部40へ格納される。適用処理部50は、その付加情報26が示す組織「AB部」ロール「会計」「総括」に一致する範囲が存在するか否かを範囲テーブル74において検索する。図12の範囲テーブル74では範囲ID「4」が該当するため、適用処理部50は、社員マスタテーブル72の野村太郎のレコードから範囲ID「4」を削除する。この結果、野村太郎のレコードは、組織ID「1」範囲ID「1」に更新される。社員マスタテーブル72の更新結果は、属性情報提供部54により連携先システム20へ提供される。
第3の実施の形態のID管理装置12によると、人事異動や業務都合により社員のロール変更の必要が発生しても原則として範囲テーブル74の変更は不要になり、社員マスタテーブル72における範囲IDを変更することで対応可能になる。また、1人の社員に対して複数の組織の複数の役割を付与する場合も重複する情報を管理する必要はなく、また複数の社員間で共通の範囲を再利用することができる。これにより、社員の権限情報管理を容易化でき、また保守性も向上できる。
第3の実施の形態の変形例を説明する。
上記実施の形態では権限情報をテーブルで管理することとしたが、第2実施形態の変形例でも示したようにJSONデータにより管理してもよい。例えば、属性リポジトリ38(先付属性保持部40と現在過去属性保持部42の少なくとも一方)に格納される図10および図12の社員情報は、JSON形式のデータであってもよい。図13〜図15は、権限情報を含むJSONデータを示す。具体的には、上記動作の説明における野村太郎(社員ID=10011)の権限情報を含むJSONデータを示している。これらのJSONデータは、図10(b)の社員マスタテーブル72の社員情報と、図12の範囲テーブル74の範囲情報を含む。
図13の範囲情報92は、上記動作の説明における初期状態の範囲情報を示し、すなわち野村太郎がAB部に所属し、AB部の会計ロールと総括ロールが付与されている状態の範囲情報を示している。ここで、野村太郎がAA部の部長へ異動する旨の異動情報22が受け付けられると、適用処理部50は、JSONデータの所属組織を変更するとともに、範囲情報92を組織ID「1」ロールID「1」へ変更する。その結果、図14で示すJSONデータに更新される。なお適用処理部50は、組織情報やロール情報のマスタ情報を参照して、各組織や各ロールのIDを識別してもよい。
次に、AB部の会計ロールおよび総括ロールを野村太郎に付与する旨の付加情報26が受け付けられると、適用処理部50は、範囲情報90に、組織ID「2」ロールID「2」と、組織ID「2」ロールID「3」を追加する。その結果、図15で示すJSONデータに更新される。次に、AB部の会計ロールおよび総括ロールを野村太郎から剥奪する旨の付加情報26が受け付けられると、適用処理部50は、範囲情報90から、組織ID「2」ロールID「2」と、組織ID「2」ロールID「3」を削除する。その結果、図14で示すJSONデータに更新される。
権限情報をJSON形式で管理することは拡張性および性能の面でメリットがある。
まず拡張性のメリットを説明する。JSONには、RDBやディレクトリサーバと異なり事前のスキーマ定義が不要という特徴がある。一般的に、ID管理製品が管理対象とする属性(データモデル)は、企業によってバラバラであり、ID管理製品側で決めきれるものではない。特に企業規模が大きいほど、扱うべき情報が多く、独自の属性も多くなる傾向がある。ID管理のデータ格納方式にRDBやディレクトリサーバを採用する場合、各企業のデータモデルにあわせて属性を変更することは容易でなく、また変更できても多大なコストが生じうる。さらにまた、一旦運用が開始された後で属性を変更することはかなり困難である。その一方、ID管理のデータ格納方式にJSONを採用すると、導入先の企業のデータモデルにあわせて低コストで柔軟に属性変更等の対応が可能になる。
次に性能面のメリットを説明する。ID管理のデータ格納方式にJSONを採用する場合、データ管理手段として、一般的なRDB製品ではなく、NoSQLデータベースを使用できる。例えば、ドキュメント指向データベースであるMongoDB等を使用できる。この場合、属性リポジトリ38(先付属性保持部40と現在過去属性保持部42の少なくとも一方)における社員情報管理機能を、1つ以上の装置に導入されたNoSQLデータベースにより実現してもよい。RDBはそのアーキテクチャ上、スケールアウト(例えば複数台のサーバを横並びで構成すること)による性能向上は難しい。その一方、NoSQLデータベースは、その仕組みからスケールアウトによるパフォーマンス向上(言い換えれば水平スケーラビリティの確保)が容易である。したがって、ID管理のデータ格納方式にJSONを採用し、必要に応じてNoSQLデータベースを横並びに増やす(例えば複数のサーバを並行稼働させる)ことで容易に性能向上を図ることができる。
(第4の実施の形態)
まず概要を説明する。日本企業では4月と10月に大規模な人事異動や組織改編が行われることが多い。大規模な人事異動や組織改編は、社員や組織に関する属性情報に大量の変更が生じる。これまでは、事前に属性情報の変更に関する想定データをID管理システム上に準備し、誤りがないかチェックの上、人事異動や組織改編の発令日に変更後の属性情報を配信していた。
しかし、従来のチェック作業は人手で行っている部分が多く、非効率であり、ミスが発生する可能性も高かった。例えば、経営企画部から組織改編の第1案がシステム部門へ提供され、後日その修正案が提供されることがある。この場合、組織改編の差分をシステム部門で調べており、差分把握に時間を要していた。また、その差分情報を見て、組織マスタ情報を手作業で修正しなければならず、ミスが生じやすかった。
第4の実施の形態のID管理装置12は、人事異動や組織改編に対するシミュレーションサービスをユーザ端末へ提供することで、人や組織に関する属性情報変更の効率化とミス削減を実現する。例えば、仮の変更情報の入力を受け付け、現在または過去の属性情報との差分を可視化する。また、人事異動や組織改編に関する複数案間の差分を可視化し、さらに、複数案のマージや複数案間での不整合検出を自動化する。そして、シミュレーションリポジトリでの作業結果を、属性リポジトリ38の現在属性情報や先付属性情報に反映させる。
第4の実施の形態でのユーザ端末は、シミュレーションサービス利用者の端末を意味し、例えば、人事異動の案を作成する人事部のシステム(PC端末等)を含む。また、組織改編の案を作成する経営企画部のシステム(PC端末等)を含む。また、人事部や経営企画部から案を受領して、ID管理システム10に反映させるシステム部門のシステム(PC端末等)を含む。
図16は、第4の実施の形態のID管理装置12の機能構成を示すブロック図である。第4の実施の形態のID管理装置12は、第1〜第3の実施の形態のID管理装置12の機能を包含し、シミュレーション機能をさらに有する。図16の機能ブロックのうち第1〜第3の実施の形態と同一または対応する機能ブロックには図2・図9と同一の符号を付している。なお通信部30のブロックは省略している。以下、第1〜第3の実施の形態と重複する説明は省略する。
ID管理装置12は、シミュレーション用リポジトリ100とシミュレーション部102をさらに備える。シミュレーション部102は、ユーザ画面表示部104、属性情報読出し部106、属性情報出力部108、編集情報取得部110、マージ部112、編集結果記録部114、差分検出部116、反映部118を含む。
図17は、シミュレーション用リポジトリ100の構成を示す。図17では、シミュレーション用データをテーブル形式で保持する例を示すが、図11、図13〜図15に示したJSON形式等、他の形式で保持してもよい。シミュレーション用リポジトリ100は、オブジェクトグラフ構造で作業履歴を保持し、具体的には1回の作業に対応するオブジェクト(以下「ノード」とも呼ぶ。)を単位としてシミュレーション用データを保持する。
シミュレーション用リポジトリ100は、ノードID、タイトル、属性情報、親ノード、適用開始日、反映場所等を対応付けたシミュレーション用データを保持する。このうち属性情報には、人事や組織に関する現在の属性情報や、変更後の属性情報が格納される。適用開始日と反映場所は、デフォルトでは親ノードの値を引き継ぐが、ユーザにより編集可能である。図17には不図示だが、シミュレーション用データは、ノードの作成者と作成日時の情報も含む。なお、図17のノードIDは、後述の図18〜図20で示す各ノードのIDに対応する。
ユーザ画面表示部104は、シミュレーション機能の利用者が作業する画面(以下「ユーザ画面」とも呼ぶ。)を所定の表示装置に表示させる。ID管理装置12がウェブサーバの機能を有する場合、ユーザ画面表示部104は、ユーザ画面のウェブページをユーザ端末へ送信し、ユーザ端末のウェブブラウザに当該ウェブページを表示させてもよい。後述するようにユーザ画面は、履歴一覧画面、詳細表示画面、編集画面、比較画面、マージ画面を含む。
属性情報読出し部106は、ユーザ画面でユーザが指定するリポジトリ、具体的には先付属性保持部40または現在過去属性保持部42から、ユーザ指定した属性情報を読出す。例えば、現在過去属性保持部42に格納された人事や組織に関する現在の属性情報を読出し、また先付属性保持部40に格納された将来の属性情報を読出す。属性情報読出し部106は、読出した属性情報を、新規ノード(例えば図17のノード1)と対応付けてシミュレーション用リポジトリ100に格納する。
属性情報出力部108は、ユーザ画面でユーザが指定する属性情報をCSV(Comma-Separated Values)形式のファイルデータ(以下「属性編集用ファイル」と呼ぶ。)として所定の記憶領域へ出力する。属性編集用ファイルへの出力対象は、ユーザ画面に表示中の属性情報であってもよい。また出力データの形式は、ユーザが編集可能な形式であればCSV以外でもよいことはもちろんである。
編集情報取得部110は、変更情報取得部とも言え、ユーザによる属性情報の変更結果・編集結果を示す情報をユーザ端末から取得する。変更元となるデータは、現在過去属性保持部42に格納された現在属性情報、先付属性保持部40に格納された先付属性情報、シミュレーション用リポジトリ100において各ノードに対応付けられた属性情報を含む。例えばシミュレーション用リポジトリ100は、ユーザ端末からアップロードされた属性編集用ファイルから、ユーザによる編集後の属性情報を読出す。また、ユーザ画面においてユーザが属性情報を編集した場合、編集後の属性情報をユーザ端末から取得する。
マージ部112は、ユーザ画面でユーザが指定する複数のノードの属性情報を1つのノードの属性情報として統合する。属性情報が行と列で表現可能である場合、マージ部112は、各ノードの属性情報における行と列を統合してもよい。例えば、第1ノードがA本部AA部に所属する50人分の属性情報(レコード数50)を含み、第2ノードがA本部AB部に所属する100人分の属性情報(レコード数100)を含む場合、これらをマージしたA本部150人分の属性情報(レコード数150)を生成してもよい。また、第1ノードが20人分の属性情報(属性項目数10)を含み、第2ノードが当該20人分の属性情報(属性項目数5)を含む場合、これらをマージした当該20人分の属性情報(属性項目数15)を生成してもよい。
マージ部112は、統合対象となる複数ノードの属性情報間に競合が存在する場合、その競合を検出する。競合は情報の不整合と言え、属性項目または属性値レベルの不整合と言える。例えば、統合対象の第1ノードが定める社員Aの所属組織(または役職)と、統合対象の第2ノードが定める社員Aの所属組織(または役職)が異なる場合、競合として検出する。また、第1ノードの属性情報と、第2ノードの属性情報間で、同じ組織コードに異なる組織が割当てられている場合、競合として検出する。
編集結果記録部114は、属性情報変更部とも言え、編集情報取得部110により取得された編集後の属性情報と、マージ部112により統合された属性情報をシミュレーション用リポジトリ100に格納する。その際、編集前の属性情報とは異なるノードの属性情報としてシミュレーション用リポジトリ100に記録する。また、編集前の属性情報のノードを親ノードとして記録することでノード間の親子関係(前後関係)を記録する。またマージ部112によるマージ処理にて競合が検出された場合、編集結果記録部114は、競合(エラー)を示す情報を編集後の属性情報に対応付けて記録する。
差分検出部116は、ユーザ画面でユーザが指定する複数ノード間で属性情報が異なる場合、その差分を検出する。例えば、同一主体(人または組織)の属性項目値がノード間で異なる場合、双方のノードに記録された当該主体の当該属性項目値を抽出し、差分情報としてシミュレーション用リポジトリ100に記録してもよい。また、双方のノードに記録された当該主体の属性情報全体を抽出対象としてもよい。
反映部118は、ユーザ画面でユーザが指定するノードの属性情報を、ユーザが指定するリポジトリ、具体的には先付属性保持部40または現在過去属性保持部42へ格納する。現在過去属性保持部42に格納する場合、現在適用中の属性情報に対して、ユーザによる変更内容を即時反映することになる。また、先付属性保持部40に格納する場合、将来適用要諦の属性情報に対して、ユーザによる変更内容を反映することになる。
以上の構成によるID管理システム10の動作を説明する。
図18は、ID管理装置12が提供するユーザ画面を示す。同図のユーザ画面は、履歴一覧画面120、詳細表示画面122、編集画面124を含む。履歴一覧画面120は、ユーザの作業に伴うノードの親子関係や生成順を示すノード履歴グラフ、作業履歴グラフとも言える。
事前にユーザは、現在過去属性保持部42から現在の組織情報を読み込ませ、その組織情報を案1と案2のそれぞれに基づいて編集済である。図17で示すように、履歴一覧画面120のノード1は現在の組織情報に対応し、編集情報取得部110が生成したものである。また、履歴一覧画面120のノード2は案1による変更後の組織情報に対応し、ノード3は案2による変更後の組織情報に対応し、それぞれ編集結果記録部114が生成したものである。
履歴一覧画面120でユーザがノード2に対する選択操作を入力すると、ユーザ画面表示部104は、案1を反映したノード2の属性情報をシミュレーション用リポジトリ100から取得し、詳細表示画面122に表示させる。詳細表示画面122でユーザが編集開始操作を入力すると、ユーザ画面表示部104は編集画面124を表示させる。編集画面124でユーザが属性情報を編集後、保存操作を入力すると、編集結果記録部114は、ノード2を親ノードとするノード4を生成する。そしてノード4のデータとして、編集画面124に入力された編集後の属性情報をシミュレーション用リポジトリ100に格納する。
図19も、ID管理装置12が提供するユーザ画面を示す。履歴一覧画面120でユーザがノード3に対する選択操作を入力すると、ユーザ画面表示部104は、案2を反映したノード3の属性情報をシミュレーション用リポジトリ100から取得し、詳細表示画面122に表示させる。詳細表示画面122でユーザが比較開始操作を入力すると、ユーザ画面表示部104は、比較元としてノード3を自動選択した比較画面126を表示させる。比較画面126でユーザは比較先(例えばノード2)を選択する。なお、履歴一覧画面120で比較開始操作が入力されると比較画面126へ遷移し、この場合、ユーザは比較元と比較先の両方を手動で選択する。
比較画面126でユーザが比較実行を入力すると、差分検出部116は、比較元ノードと比較先ノードの差分を検出する。例えば差分検出部116は、一方のノードが含み、他方のノードが含まない組織IDのレコードを差分として検出する。また、両方のノードが同じ組織IDのレコードを含む場合に、双方の属性項目(例えば存続区分)や属性値(例えば存続または廃止)が異なる事実を差分として検出する。
ユーザ画面表示部104は、差分検出部116により検出された差分を比較結果として比較画面126に表示させる。比較結果として、互いに異なる比較元ノードのレコードと比較先ノードのレコードの両方を並べて表示させてもよい。また、一方のノード(例えば比較元ノード)のレコードのみを表示させてもよく、また、差分が検出された部分(属性項目や属性値)を通常より強調した態様で表示させてもよい。
図20も、ID管理装置12が提供するユーザ画面を示す。履歴一覧画面120でユーザがノード3に対する選択操作を入力すると、ユーザ画面表示部104は、案2を反映したノード3の属性情報をシミュレーション用リポジトリ100から取得し、詳細表示画面122に表示させる。詳細表示画面122でユーザがマージ開始操作を入力すると、ユーザ画面表示部104は、マージ先としてノード3を自動選択したマージ画面128を表示させる。マージ画面128でユーザはマージ先のノードへマージするノード(例えばノード2であり、以下「マージ元ノード」と呼ぶ。)を選択する。なお、履歴一覧画面120でマージ開始操作が入力されるとマージ画面128へ遷移し、この場合、ユーザはマージ先とマージ元の両方を手動で選択する。
マージ画面128でユーザがマージ実行操作を入力すると、マージ部112は、マージ先ノードのデータに対してマージ元ノードのデータを統合した新規ノードのデータ(図のノード5)をシミュレーション用リポジトリ100に格納する。マージ部112は、マージ先ノードが30レコードを含み、マージ元ノードが20レコードを含む場合、50レコードを含む新規ノードを生成してもよい。ユーザ画面表示部104は、マージ結果として、新規ノードのデータをマージ画面128に表示させる。
マージ部112は、統合対象のデータ間に競合を検出すると、競合を示す情報を記録し、ユーザ画面表示部104は、その競合を示す情報を付加してマージ結果を表示させる。競合結果を示す確認画面をマージ画面128とは別に表示させてもよい。ユーザは、競合箇所毎に、手作業での修正にてマージ結果を入力してもよい。また、マージ処理を中断させてもよく、マージ処理全体をロールバックさせてもよく、図のノード5を削除させてもよい。マージ部112は、ユーザが入力した修正内容を反映した新規ノードをシミュレーション用リポジトリ100に格納してもよい。
なお、ユーザ画面表示部104は、ノードデータの適用開始日や反映場所をユーザに設定させるためのノード設定画面を表示させてもよい。例えば、履歴一覧画面120で選択されたノードに関する詳細表示画面122でユーザが反映操作を入力した場合に、ノード設定画面を表示させてもよい。反映部118は、ノード設定画面の設定情報にしたがって、選択ノードが定める属性情報を現在属性情報として現在過去属性保持部42へ格納し、または、将来属性情報として先付属性保持部40へ格納する。
例えば、図17のノード5について、ユーザは、適用開始日として将来日付を設定し、反映場所として先付属性保持部40を設定してもよい。反映部118は、ノード5が定める組織情報や人事情報に適用開始日を対応付けた先付属性情報を先付属性保持部40に格納する。このように、現在過去属性保持部42に格納された現在適用中の現組織データを、複数の案をもとに改編し、各案を修正し、比較検討し、マージした結果である新組織データを、将来適用予定の新組織データとして保存することができる。
以上、本発明を実施の形態をもとに説明した。これらの実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せによりいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。
12 ID管理装置、 40 先付属性保持部、 42 現在過去属性保持部、 44 定義情報保持部、 48 属性情報取込部、 50 適用処理部、 54 属性情報提供部、 56 範囲設定部、 110 編集情報取得部、 112 マージ部、 116 差分検出部。

Claims (4)

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

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2015138370A JP2017021553A (ja) 2015-07-10 2015-07-10 属性情報管理装置、属性情報管理方法およびコンピュータプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2015138370A JP2017021553A (ja) 2015-07-10 2015-07-10 属性情報管理装置、属性情報管理方法およびコンピュータプログラム

Publications (1)

Publication Number Publication Date
JP2017021553A true JP2017021553A (ja) 2017-01-26

Family

ID=57890154

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015138370A Pending JP2017021553A (ja) 2015-07-10 2015-07-10 属性情報管理装置、属性情報管理方法およびコンピュータプログラム

Country Status (1)

Country Link
JP (1) JP2017021553A (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020530927A (ja) * 2017-08-10 2020-10-29 成都牽牛草信息技術有限公司Chengdu Qianniucao Information Technology Co., Ltd. 使用者に承認プロセスとその承認ノードの権限を与える方法
JP7339415B1 (ja) 2022-11-16 2023-09-05 株式会社アクシオ 業務システム用の権限管理システム

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020530927A (ja) * 2017-08-10 2020-10-29 成都牽牛草信息技術有限公司Chengdu Qianniucao Information Technology Co., Ltd. 使用者に承認プロセスとその承認ノードの権限を与える方法
JP7429390B2 (ja) 2017-08-10 2024-02-08 成都牽牛草信息技術有限公司 使用者に承認プロセスとその承認ノードの権限を与える方法
JP7339415B1 (ja) 2022-11-16 2023-09-05 株式会社アクシオ 業務システム用の権限管理システム
JP2024072450A (ja) * 2022-11-16 2024-05-28 株式会社アクシオ 業務システム用の権限管理システム

Similar Documents

Publication Publication Date Title
US10783213B2 (en) Flexible graph system for accessing organization information
US10970114B2 (en) Systems and methods for task scheduling
US11997101B2 (en) Systems and methods for role-based permission integration
US8396863B2 (en) Temporal class loader
CN103473256B (zh) 用于内容管理的方法和系统
EP2610762A1 (en) Database version management system
US8805785B2 (en) Shared storage of categorization, labeling or tagging of objects in a collaboration system
BRPI0901505A2 (pt) dados de aplicativo de central de atendimento (call center) e arquitetura de interoperação para uma central de serviços de telecomunicação
JP2006099751A (ja) プロジェクトを構成するタスクに人員を割当てるための方法、プログラムおよびコンピュータ
US12019646B2 (en) Information system with temporal data
JP2016148907A (ja) 属性情報管理装置、属性情報管理方法およびコンピュータプログラム
KR101725142B1 (ko) 전략맵 관리 방법과 장치 및 이를 기록한 기록매체
JP2017021553A (ja) 属性情報管理装置、属性情報管理方法およびコンピュータプログラム
JP6167138B2 (ja) ワークフロー情報管理装置及びそのプログラム
JP2009151402A (ja) 組織情報変更反映方法およびシステム
US20180268374A1 (en) Electronic change planning manager
JP2013218575A (ja) Id情報管理システム、id情報管理サーバ及びプログラム
JP2012128582A (ja) 設計情報管理運用システム、設計情報管理運用方法、および設計情報管理運用プログラム
JP2004258971A (ja) スケジュール管理システム、プログラムおよび記録媒体
JP2004259019A (ja) スケジュール管理システム、プログラムおよび記録媒体
Perry et al. Patterns
Scannapieco et al. IP-UML
JP4166101B2 (ja) スケジュール管理システム、プログラムおよび記録媒体
JP2004259029A (ja) スケジュール管理システム、プログラムおよび記録媒体
JP2001297079A (ja) 文書一元管理システム