第3回 ID管理システム、要件定義から基本設計まで

徳毛　博幸
京セラコミュニケーションシステム株式会社
BPO事業部　副事業部長
2009/6/19

　ID管理システムの基本設計

　基本設計フェイズでは、以下の2点が大きなテーマになる。

• 要件定義で定めたシステムと人事イベントをつなぐ
• 採用するID管理パッケージ製品にポリシーを落とし込む

　特に後者について、ID管理システムを自作するという判断もあるかもしれないが、これはあまりお勧めできない。これは筆者がID管理のパッケージベンダという顔を持つからだけではない。

　第1回「“ID管理システム化プロジェクト”のその後」でも触れたとおり、ID管理自体はやらなければならない業務ではあるものの、企業の競争力を増すものではない。このような業務に自社固有の要件を盛り込んで、オーダーメイドのシステムを作っていくことは、費用対効果やIT部門の機会損失という点で得策ではないと考える。

　「人事イベントをつなぐ」とは、管理対象とする各システムが必要なマスター情報の整理を行い、一方で人事システムなど、源泉となる情報を持つシステムがどのような属性を保持しているのかを確認し、それらを付き合わせるという作業である。

　当然ここにはギャップが存在する。各システム間にもギャップがあり、また、源泉データともギャップがあるだろう。例えば、以下のようなギャップである。

源泉となる人事システムには、氏名のフリガナは格納されているが、ローマ字表記は格納されていない。 　Aシステムでは、氏名欄にはローマ字表記の氏名が必要である。従ってフリガナからローマ字に変換する処理を組み込む必要がある。同じように、システムには必要だが、人事情報にないものとして、メールアドレスなどがある。 　Bシステム、Cシステムともに、ユーザー情報に加えて、所属組織属性も必要とする。Bシステムでは組織名は最大256文字だが、Cシステムでは組織名は64文字しか入らない。現実の組織名は、「営業一課」という名前の課が各事業所に存在するなどの理由で、最下層の組織名だけでは判別がつかない。従って、ある程度上位階層から連結して表示する必要がある。 　しかし、最上位階層からたどると「○○事業所○○本部○○事業部○○部○○課○○係……」となり、100文字を超えるものも出てくる。

　これらのデータの過不足について、システムが自動的に生成するのか、システム運用担当者やエンドユーザーが確認するのかといった、情報の補完の仕方をパッケージ製品のスペックを見ながら決めていく必要がある。

　また、重複している類似の属性なども、将来の管理工数削減のために統一化を図っていくべきだろう。

　IDのライフサイクル、タイミング

　ここまでで源泉データと管理対象システムの属性のマッピングができるわけだが、もう1つ重要なのが、どのタイミングでどの人事イベントをID管理システムに連携させ、最終的に下位のシステムに反映させるかといった、IDのライフサイクルやタイミングの問題である。

　例えば、以下のような運用を行っている企業は多い。

人事システム上は、異動発令と同時に各従業員の所属組織は切り替わるが、現実には、発令から実異動まで2週間程度を引き継ぎ期間として両組織を兼務させるようシステム権限を設定している。

　こういった引き継ぎや一時的な兼務が、機能として実装されているパッケージもあるが、そうでない場合は、それをどう実現するかを十分に検討しなければならない。

　例えば、いったん人事システムどおりに異動させ、必要な従業員からは都度申請を上げてもらうと割り切るか、それでは異動が多いときなど大変なので、人事システムとID管理システムの間で、兼務状態にデータを改変するようプログラムを追加開発するなど、いくつかの方法が考えられるが、採用するパッケージの特性と合わせて検討することになる。特に後者のような追加開発プログラムは、第1回で触れた事例B社のように、将来に禍根を残すことになりかねないので、あまりお勧めしない。どうしてもこの要件が外せないというのであれば、それが可能なパッケージを選定するべきだろう。

　また、ID管理のシステム化による危険性についても少し触れておきたい。この危険性とは次のようなものである。

万が一、人事システムからID管理システムに誤った情報が投入されると、当然、下位のシステムにも誤った情報が反映され、IDが削除されたり、必要以上の権限が与えられたりなどの事故につながる。

　「万が一」と書いたが、実は、ID管理のシステム化を行った企業が一度は体験してしまうことでもある。このような危険性についても、事前にリスクを低減できるよう、人事イベントの反映タイミングと合わせて考慮しておきたい。

　次回は、移行・導入とその後の運用、ID管理の今後について触れる。

3/3

Index
ID管理システム、要件定義から基本設計まで
	Page1 要件定義フェイズで決めるべきこと トリガーとなる人事イベント
	Page2 人事イベントをシステムにどう反映させるか 状況の変化に合わせてIDを維持／管理 システムの属性項目も確認すべし
	Page3 ID管理システムの基本設計 IDのライフサイクル、タイミング

Profile

徳毛　博幸（とくも　ひろゆき） 京セラコミュニケーションシステム株式会社 BPO事業部　副事業部長 1998年京セラコミュニケーションシステム入社以来、ID管理、ファイル管理、プロセス管理などのパッケージソフトウェア「GreenOffice」シリーズの構築に携わり、2005年10月ソリューション部長に就任。 数十社のJ-SOX対応を目的としたID管理ソリューション、ファイル管理ソリューションの構築、コンサルティングに携わる。

実践・アフターJ-SOX時代のID管理 連載インデックス

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）