ID管理に失敗しないための要件定義：今、見直されるアイデンティティ管理（2/3 ページ）

[�ﾔ嶋秀規、岡本孝，ITmedia]

ユーザー環境を整理する

　上記のようにどこまでをIDMの範囲とするかを検討したら、次はユーザー環境の整理を以下の項目に基づいて行う。

1. ユーザーカテゴリの整理
2. ユーザー情報の整理
3. イベントの整理
4. ビジネスロジックの整理

（1）ユーザーカテゴリの整理

　社員であるユーザーは、IDMの対象となるユーザーの源泉情報がどこから発生するのかによって分類される（図2）。まず、ヒューマンリソースとして人事情報で管理されているユーザーと、派遣社員などのそれ以外のユーザーとに分類できる。また、人事情報で管理されているユーザーであっても、プロジェクトなどにより通常の社員が持たない権限を与える必要のあるユーザーも存在する。そのほかグループ企業の社員や代理店社員、時には一般のユーザーまでをIDMの管理対象とする場合もある。

図2●ユーザーカテゴリ

（2）ユーザー情報の整理

　ユーザーのカテゴリによる分類ができれば、次にそれぞれのユーザー情報がどのような形で提供されるのかを検討する。例えば、CSVのファイル形式で提供されるグループ企業の従業員情報は、バッチ処理によりプロビジョニングDBに反映したり、派遣社員の情報が紙ベースまたは個人ごとの申請による場合にはワークフローによるユーザーインタフェースが必要となる（図3）。

図3●ユーザーカテゴリによるユーザー情報の反映方法の違い

　また、源泉から提供されるユーザー情報は、システム側で利用するデータを満足していなければならない。つまり、源泉である人事システムでは「部」「課」までしか管理していないが、管理対象のシステムにおいて「部」「課」および「係」まで必要となる場合には、マスタデータに対するメンテナンスとワークフローによるユーザーの申請も必要となる。

（3）イベントの整理

　入社、退職、部署異動、昇格／降格、休職、復職、出向、改姓――など、人に対する人事的イベントは多数発生するもの。これら人事イベントに対応して、源泉である人事システムにどのような動きが発生し、連携システムでどのようなイベントが発行されるのかを、図4のようなイベントマップとして整理する。このイベントマップを作成することにより、IDM上のイベントの洗い出しを行うのである。

　例えば、図5のように「休職」という人事イベントが発生した場合には、IDMコアからは「アカウント停止」というトリガーイベントが連携対象システムに発行される。これを通じて各システムでは「アカウント停止」や「アカウント削除」などの処理が行われることとなる。

図4●イベントマップ

図5●人事イベントに対するシステム連携

（4）ビジネスロジックの整理

　企業には、その企業の定めたアカウントに対するビジネスロジックが存在する。具体的には正社員／派遣社員、部署、役職などからビジネスロジックに沿ったグルーピングを行い、各システムに対する権限を発生させる。拠点が複数あるような場合には、ロケーションもビジネスロジックの要素とすることがある。

　また、人事情報を源泉としない派遣社員などによるアカウントの申請に対して、誰が承認する権限を持つのか、権限者の特定も企業のビジネスロジックにより決定される。経理システムであれば経理部長であり、人事システムであればシステムの業務的オーナーである人事部長、あるいは管理的オーナーである情報システム部門、といった具合に決定する。このビジネスロジックも業種により集約されるようなことは決してなく、企業によりさまざまであるので、整理した上で反映させることになる。