グループ会社の人材情報～統合管理するためには手段を選んでいられません～

さんたさんえ。しばたいやの、こんぱうんどTW280お、ためしてみたいです。よろしくおねがいします。

こんにちは。コーポレートエンジニアリング部の永田です。
この度、サーバーワークスのカレンダー | Advent Calendar 2023 - Qiita
で、ひと枠担当させていただく事になりました。
というわけで、本日は、サーバーワークスグループにおける人材管理サービスの統合についてご紹介したいと思います。

はじめに

サーバーワークスでは、現在4社が連結対象となっており、グループ会社全体として約500名弱で構成されています。
グループがスケールしていくにあたり、横串での社員基本情報の共有が急務となり、人材管理サービスを統合しました。
サービスは、従来よりサーバーワークスで採用していたkaonaviをベースに、クラウド屋はマルチカンパニーの夢を見ない〜グループ会社のクラウド構成〜

blog.serverworks.co.jp

でいうところの、密結合型(統合型) を選択しました。

なぜ密結合型(統合型)か

kaonaviでは、グループ戦略ポータルという機能・構成を選択することでも、グループ会社における統合管理が可能です。
こちらは、先述のグループ会社のクラウド構成でいうところの、疎結合型になります。
具体的には、グループ各社でkaonaviテナントを個別に契約管理し、グループとしての統合管理テナントも別途用意し統合ビューとして参照する構成となります。
なおkaonavi社のお話では、こちらはひとつの統合実現パターンであって、イチテナントで統合するべきかどうかはケース・バイ・ケースだそうです。

我々としては、

出向や会社跨りの兼務メンバを同一人物のレコードとして管理できること
グループ各社の負担するライセンスコストがそこそこ安価であること

が重要なポイントであったため、イチテナントで統合する密結合型(統合型)を選択しました。

その場合、先述のグループ会社のクラウド構成の「特徴相対比較」にあるように、特に権限制御の難易度が上がります。
そこは、後述の設計と運用である程度カバーできるようにしています。

どう実現したか

簡単にご紹介していきます。

認証基盤を統合

グループ各社では、採用しているIdPが各々違うわけですよ・・。IdPのグループ一本化の作業からやってくんかい・・。否。検討の結果、コーポレートエンジニアリング部の認証屋さんが疎結合型でさくっと統合しました。
詳細は、グループ会社ができて認証基盤を統合した話blog.serverworks.co.jpを参照ください。

グループ会社コードを定義

今回の統合を機に、グループ全社標準ルールとして、グループ会社コードを定義しました。
システム、サービス毎に個別のコード・命名体系を使わないことで、システム間連携のしやすさや保守性の向上を狙うためです。
具体的な想定用途としては、グループを横断するシステム・サービスのデータレコードや各種プレフィックスなどです。
アルファベット3桁のユニークな値を、グループ各社に割り当てています。

グループ会社内で一意の社員IDを新設

グループ会社コードに加えて、グループ社員番号も新設しました。
kaonaviテナント内ではユニークな社員番号を設定する必要があること、グループを横断するその他のシステム・サービスにおいてもグループ社員を特定するキーが必要になるためです。
命名規則は、既存の社員コードを流用しつつ、グループ会社が新たに増えた際グループ内で確実に重複することのないよう、「グループ会社コード+主所属会社の社員番号」としています。

グループ会社間での社員基本情報共有の合意

手続き関連も、おざなりにして進めるわけにはいきませんね。

以降は、kaonavi内の設計のお話になります。

シートを分割する

社員基本情報は、グループ全社共通の情報（例：グループ社員番号、氏名、生年月日）、グループ各社固有の情報（例：各社の社員番号、メールアドレス、役職）に大別されます。
グループ全社共通の項目を「基本情報」へ、グループ各社固有の項目をグループ各社の「シート」(以下の図でいう「各社_基本情報」)へ定義します。
※「シート」は、kaonavi内のDBの拡張テーブルみたいなもの。
出向社員や複数会社を跨る兼務社員は、関連する複数の「各社_基本情報」のレコードを保持することになります。

また、社員基本情報以外の管理情報（例：資格）のシートにも、必ず会社コードのプリフィックスを設け、どの会社の管理情報かを明確にして自由に増やしていけるようにしています。

所属ツリーの最上位組織を「グループ各社」にする

章タイトルに記載のとおり、最上位組織を「グループ各社」にすることで、グループ全社の組織階層を表現できるようにしています。
また、各組織の「所属コード」は、社員コードのように「グループ会社コード+既存の組織コード」と置き換えることで、グループ会社内でユニークになるように設定しています。
ここでも、グループ会社コードが重要な役割を果たします。

ロールを分割する

ロールに関しても、必ず会社コードのプリフィックスを設け、どの会社用のロールかを明確にして自由に増やしていけるようにしています。
密結合型(統合型)で最も悩ましいのが管理者(Adm)系のロールですね。
グループ各社の人事・労務担当者用ロールも用意しているものの、管理者(Adm)系だと権限が強すぎるし、一般ロール系ではグループ各社の人事・労務担当者に担ってもらえる設定作業が限定的になってしまいます。
サーバーワークスグループでは、kaonaviテナントのオーナーになる親会社サーバーワークスが管理者(Adm)系のロールを保持し、グループ各社の人事・労務担当者で操作できない設定作業（例：所属ツリーの変更）を代理で担う運用としています。
今後kaonaviで、管理者(Adm)系権限をより詳細にカスタマイズ設定できることを期待しています。

最後に

いかがでしょうか。簡単ではありますが、サーバーワークス流のkaonaviによるグループ会社統合についてご紹介しました。
SaaS、特にkaonaviでのグループ会社統合を検討中の方、少しでも参考になりましたら幸いです。

またサーバーワークスでは、今回ご紹介したkaonavi上の人事基本情報をAWS上のグループ人事DBへ定期データ連携し、履歴管理しています。
kaonaviをUIとして利用（人事情報UIはわざわざ作らない）し、正式な人事マスタデータを人事DBとして活用しています。
データ連携の取り組みに関しても、kaonaviを密結合型(統合型)でイチテナント集約できていることで、各社ごとにデータソースが分散することなく優位性はありましたね。
具体的なデータ連携の仕方や、人事DBマスタ設計など、試行錯誤あり奥深い領域なのですが、今後機会・要望があればご紹介したいと思います。

それでは、数日後の深夜の枕元に、新品のタイヤ4本が積まれていることを妄想して週末を過ごすことにします。
めりーくりすます。