会社のアイデンティティ管理は難しい

製造業の経験からの内容になりますが、様々な属性を見てきましたので、その体験を紹介します。

ディレクトリを設計する時の参考になれば幸いです。

社員の雇用形態

会社で一緒に働く人達には、実は様々な雇用形態や契約があります。これまでに出会った形態と簡単な説明を挙げていきます。

・社員（月給の人）
・準社員（日給の人）
・パート（時給の人）
・アルバイト（時給の人、ただし週の就業時間が40時間？に満たない人）
・派遣（派遣会社の人）
・業務委託（会社のメイン業務を請け負ってる人）
・取引先（外部の人でたまに来社する人）

また社員にも次のような分類が考えられます。

・プロパー社員（創業時、新卒からいる人）
・中途社員（中途採用の人）
・出向社員（他社から出向で来ている人）

このように様々な形態があるので適切に分類することがID管理で求められています（本当か？）

これらの雇用形態は、次のような観点で分類ができます。

会社から直接給与支払いがあるか

ポイントは、出向社員の取り扱いだと思います。会社の給与規定へのアクセス権を与えていいのか、会社の福利厚生にアクセス権を与えていいのか、といったセンシティブな部分に関わってくるケースが考えられるので、適切に分類できるように備えておくのがいいでしょう。

直接の指示命令権があるか

常駐業務委託のメンバーを社員を含むメーリングリストに含めると作業指示をしていると捉えられる場合があるので含めてはいけないというエピソードがありました。どこまできっちりするかという点ではありますが、こんなこともありましたという紹介です。

社員の役職、資格、等級

会社の制度設計や給与体系によって呼び方は様々だと思いますが、概ね次のような概念と関連性があるのではと思います。（コテコテ日本企業の例です）

役職は、よく耳にする呼称かと思います。それに対して管理職、非管理職（非組合員、組合員）があります。管理職の中にはさらに、マネジメント系なのか、そうじゃないのかというラインと、給与レンジに連動するラインが別で存在するイメージがあります。

情報を見せる、見せないや、承認フローは誰に回覧する必要があるのかを考えるときに必要となってくる概念だと思っており、アプリケーション側の人でここまでの体系を把握されているケースは稀です。アプリケーション側の人が実現したいイメージと、人事情報とのマッチングをしっかりすり合わせることが大事な領域です。

兼務

ID管理システム領域のパッケージソフト（主に海外製）をいくつも机上検討してきました（そんなに種類はない、片手で足りる程度かも）。その中での気付きは、兼務を扱えるソフトがない。日本的な概念かもしれない。ということです。

ディレクトリで兼務を表現する場合、1つのエントリの属性で表現する方法と複数のエントリで表現する方法が考えられます。それぞれの構成のポイントを紹介します。（ディレクトリでは、兼務を取り扱わないという方法もありです）

1つのエントリの属性で兼務を表現する

ID管理システム領域のパッケージソフトが兼務を扱えないので、パッケージの範囲で実施する場合、このように兼務用の属性を定義して値を表現することになると思います。

・従業員番号やメールアドレスなどのユニーク性が期待される属性、値がユニークになる
・1つのエントリに所属を表す属性を複数持つ→所属から検索する場合に考慮が必要
・1つのエントリの主務、兼務で役割が異なる場合がある（所属長かが異なる場合がよくある）→所属との組み合わせで決まるので、属性値を工夫する必要がある（例えば、「所属_資格_役割」のような値フォーマットを定義する）

複数のエントリで表現する

ID管理システム領域のパッケージソフトで実現するためには、激しいアドオン開発が必要になりそうな雰囲気です。

・従業員番号やメールアドレスなどのユニーク性が期待される属性、値が複数のエントリに存在する→メールアドレスがユニークになることを期待するアプリケーション実装があるとトラブルになる（検索条件を詳細に記述可能なら回避できる）

終わりに

まだ書き足りないものとして、出向（受け入れる方と差し出す方）と休職（傷病系の休職、育児休職）、産休と育休は違うんだよということ、など考えていましたが、完成までの道のりが遠そう（飽きてきた）なので一旦公開します。