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

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

システム上の異動と人の異動、両者間で起こる問題

　システムで発生する異動と実際の人の異動では時間的なギャップができ、それにより問題が発生することがある。

　部署異動によってシステム上のグループ変更が行われると、以前の権限は使用できなくなってしまう。しかし、実際の業務では担当者の引き継ぎ期間などがあり、即座にアカウントの権限変更が起こることが運用上問題となることもある。このような問題は、タイマー処理で設定期間を過ぎると以前の古い権限が利用できなくなる仕組みにして、新旧のどちらの権限も使用できる「ラップ期間」を設けることで解決できる。

　このように、人事システムに異動イベントが反映される前にIDM側にデータを反映できれば対応が可能であるが、逆に人事システムへのデータ変更が実際の人事異動発令日よりも後にエントリされるような場合には、状況が異なってくる。人事システムでも給与システムを主体とするような人事・給与システムでは、給与計算上必要でなければ、システム上でのグループの変更がエントリされていなくても問題とはならないため、人事異動発令日にIDM側は古いユーザー情報のまま、という事態も考えられる。このようなシステムを源泉システムとして選定するのは問題がある。

　IDMの構築は、「ライセンスを購入してセットアップすれば完了」というものではなく、ユーザー環境を整理して上で選択したIDM製品の機能でどこまで要求に対応できるのか、また、どの程度の開発が必要となるのかを見極めることが重要となる。この要件定義／概要設計は、設計というよりもむしろコンサルティングの意味合いが強い。ユーザー環境調査において、ヒアリングやチェック項目が数百となることも茶飯事なのである。