[ServiceNow]人事的な「兼務」をどのように保持するか

ServiceNowにおいて、標準で人事情報を管理するDepartment[cmn_department]テーブルは兼務の情報を保持することができません。しかし、ユーザに対し複数の組織と紐づけたいという要望をよく聞きます。

この記事では、これまで私が関わった/話を聞いた事例をもとに、兼務を保持する場合の考慮点と、複数の実装方針をシェアします。なお、HRSDの利用は想定していません。

兼務の必要性

特に管理職レベルにおいて、複数の組織を同時に所属する「兼務」はよくあります。人事的には兼務が存在するが、それは無視して、ServiceNowには主務だけを保持する、という方針もありますが、組織情報を用いて承認者を自動導出したい場合などは、兼務を保持する必要があります。

主務と兼務

兼務を保持する場合には、所属の順序（例: 主務、兼務1、兼務2、…）を保持するかを検討する必要があります。実務的には、少なくとも主務は区別しておくことが好ましいです。具体的には、下記の様な場合に、そのユーザの主務はどこか？が明確でないと不都合が生じます。
・レポートなどで部署ごとの集計をしたい場合
・社用PCなどの貸与資産の責任部署を決めたい場合

兼務と役職

兼務を保持する場合には、役職との紐づけを考える必要があります。私の知る限り、下記の2つのパターンがあります。

 ① 役職がユーザに紐づく兼務
役職をユーザの属性の一つとして考える方法です。ロールを割り当てる場合は別途グループに所属させる等の工夫が必要ですが、この場合はユーザテーブル標準のTitleフィールドを利用して保持することができます。

② 役職が所属に紐づく兼務
所属ごとに役職を紐づける方法です。下図の例では、あるユーザが組織Aにはマネージャとして、組織Bにはスタッフとして所属しています。この場合は兼務をどのように保持するかで対応可否が変わってきます。

兼務の実現方法

これまで私が関わった/話を聞いた事例で採用されている兼務の実現方法を紹介します。

■ 兼務の実現方法
① ユーザと組織を多：多で紐づける中間テーブルを作成する
② ユーザテーブルに兼務組織を格納するカスタムフィールドを追加する
③ 標準でユーザと多：多の紐づけができるGroupテーブルに組織情報を格納する
④ 兼務ごとに異なるユーザを作ることで、ServiceNowの中に兼務を保持しなくてもいいようにする

① ユーザと組織を多：多で紐づける中間テーブルを作成する

これは、Groupと同様にユーザと組織を多：多で紐づける中間テーブルを作る方法です。中間テーブルに所属順序を保持するだけでもよいですが、主務をUserテーブルのDepartmentフィールドに保持することで、標準機能との整合性を保つことができます。この方法は、標準テーブルを一切変更することなく、かつ役職が所属に紐づく兼務も表現できるという点で最も優れていると考えます。

② ユーザテーブルに兼務組織を格納するカスタムフィールドを追加する

ユーザテーブルに標準で存在するDepartmentフィールドに加え、兼務を保持するためのDepartmentテーブルを参照するList型のフィールドを作成する方法です。この方法は兼務内の所属順序や役職が所属に紐づく場合の管理ができませんが、ユーザテーブルにフィールドを1つ追加するだけという最も簡易的な方法であるため、要件によっては採用されることがあると思います。

③ 標準でユーザと多：多の紐づけができるGroupテーブルに組織情報を格納する

Groupテーブルは標準でユーザと多：多の紐づけが可能です。さらに、Groupにはロールを付与することができたり、タスクのアサイン先として指定することもできるため、この方法を採用している事例を聞いたことがあります。また、この方法では多：多の紐づけを行う中間テーブルであるGroup Member（またはそれを継承したテーブル）に役職フィールドを加えることで役職が所属に紐づく場合にも対応できます。Groupテーブルに組織情報を格納する方針の場合には、必然的にこの方法が採用されます。組織をGroupに格納すべきかどうかは、下記の記事にまとめました。

④ 兼務ごとに異なるユーザを作ることで、ServiceNowの中に兼務を保持しなくてもいいようにする

これまでとは全く別のアプローチですが、例えばuser1が人事部とシステム部を兼務する場合には、user1.personel, user2.systemというように、所属ごとにユーザアカウントを払い出します。

主に承認の際に、どこの所属のメンバとして作業を行ったかを明確にするためにこのような実装にしたとのことですが、下記の様な様々な不都合が生じることが明らかであるため、避けるべき方法だと考えます。

・作業ごとにユーザを確認した上で、必要に応じてログインし直す必要があるためユーザビリティが下がる
・主務と兼務が区別できない
・住所変更などどの所属として行うべきかが明確でない場合にどのユーザを使うかが曖昧
・SSO設定を行っている場合、SSO基盤側にも同様に複数のアカウントを保持しておく必要がある（が、多くの場合ServiceNowのための特殊運用になると思われるため、運用負荷が高まる）

おわりに

ServiceNowにおいて「兼務」をどのように扱うべきかについてシェアしました。実際に兼務を扱う場合の実装案については、下記の要素も考慮が必要になるかもしれません。

HRSDとの親和性
私が使ったことがないので詳細まで言及できませんが、HRSDで兼務が管理できるのであれば、現時点では利用していなくても、将来的にHRSDを利用する予定がある場合、移行がしやすいかどうか、というのも一つの評価軸になりますね。

人事システムとの親和性
ServiceNowは全社的に使うシステムであるため、人事システムと連携し、定期的にユーザや組織情報を取り込むようにする場合が多いと思います。この場合に、人事システム側のテーブル構造に近いデータ構造にしておくことで、連携処理の実装が楽になるため、人事システムとの親和性も一つの評価軸になります。

以上です。他にも考慮点やイケてる実装案があれば是非教えていただきたいです。