人事管理システム：SuccessFactors Employee Centralの権限制御の仕組み

SuccessFactors Employee Centralは、SAP社がサービス提供している人事管理システムです。人事管理システムは、蓄積するデータが人に関するデータであることから、閲覧権限のコントロールが重要なファクターとなります。この記事では、SuccessFactors Employee Centralの権限制御の仕組みについて書こうと思います。

基本構造は「誰が」「誰の」「何を」閲覧できるか

権限制御の基本構造は、「誰が」「誰の」「何を」閲覧できるか、を設定することで成り立っています。

「誰が」と「誰の」にはユーザーを設定し、「何を」には人事データの項目を指定します。例えば、部長は、課長・係長・一般社員の基本情報（氏名、部署、役職、入社年度）と評価情報を閲覧できるとします。この場合、「誰が」に部長を、「誰の」に課長・係長・一般社員を、「何を」に基本情報と評価情報を設定するようなイメージです。

「誰が」と「誰の」を効率的に設定するユーザーグループ

「誰が」に部長を、「誰の」に課長・係長・一般社員を設定する際、従業員一人一人を登録していくのは時間がかかります。ここで登場する機能が、ユーザーグループです。

ユーザーグループとは、複数の従業員を1つのグループとしてまとめられる機能です。人事管理システムでは、従業員の役職や部署を、データとして登録していることがほとんどでしょう。

例えば、「部長グループ」という名のユーザーグループを作成し、「部長グループ=役職が部長の従業員」と設定するとします。すると、「部長」という役職がデータ登録されている従業員は「部長グループ」へ自動的に登録されます。

同様に、「課長グループ=役職が課長の従業員」「係長グループ=役職が係長の従業員」「一般社員グループ=役職が無い従業員」と設定することも可能です。

「誰が」に部長グループを、「誰の」に課長グループ・係長グループ・一般社員グループを設定していれば、従業員データの役職を変えると同時に、ユーザーグループにも適用され、もれなく権限設定を反映させることが可能です。部署単位で「人事グループ」や「営業グループ」というユーザーグループを作成することも可能です。

「誰が」「誰の」「何を」を定義する権限ロール

部長は、課長・係長・一般社員の基本情報と評価情報を閲覧できるという制御について話をしてきましたが、組織にはさまざまな役割があり、その役割によって、人事データの閲覧範囲を細かく制御したいというニーズがあると思います。

このニーズを実現するのが権限ロールです。例えば、組織に以下の3つのニーズがあるとします。

• 一般社員は、一般社員の基本情報を閲覧できる

• 部長は、課長・係長・一般社員の基本情報と評価情報を閲覧できる

• 人事は、人事以外の社員の基本情報と評価情報を閲覧できる

この3つのニーズを、「部長ロール」「一般社員ロール」「人事ロール」という形で制御できるのが、権限ロール機能です。権限ロールごとの閲覧可能範囲を、「誰が」「誰の」「何を」の設定によって実現します。

閲覧範囲の重複

上述した3つのニーズを満たす権限ロール設定において、2つ以上の権限ロールの「誰が」に属する社員がいます。例えば、人事の一般社員は、一般社員ロールの「誰が」と、人事ロールの「誰が」に属します。この場合、両方の権限ロールが適用されます。

つまり、一般社員ロールを利用して全社員の基本情報が閲覧できるうえに、人事ロールを利用して全社員（人事グループを除く）の基本情報と評価情報を閲覧できるということです。さらに補足すると、人事の一般社員は、人事所属社員の評価情報だけを閲覧できなということです。

同じように、人事部長は、3つすべての権限ロールの「誰が」に属します。この場合、人事部長は、人事部長以上の社員の評価情報以外すべてを閲覧できる状態となります。ここでのポイントは、閲覧範囲の重複をどのように取り扱うかです。取り扱い方は2パターンあります。

• 権限ロールごとに、閲覧可能な項目をすべて定義する

• 権限ロールごとに、追加で閲覧できる項目のみ定義する

1つ目のパターンは、前述した表のとおりです。2つ目のパターンは、権限ロールによって"追加で"見せたい項目のみ定義する手法です。表で示すと以下のようになります。

一般社員ロールによって、誰でも全従業員の基本情報は閲覧できます。そのため、部長ロールでは、"追加で"課長グループと係長グループの評価情報を閲覧できる設計とすることで、同じニーズを満たすことが可能です。同様に、人事ロールでは、"追加で"全社員（人事グループを除く）の評価情報を閲覧できる設計にできます。

全項目定義と追加のみ定義の善し悪し

2つのパターンには、それぞれ善し悪しがあります。全項目定義のパターンでは、権限ごとに閲覧できる項目が明確なので、分かりやすいというメリットがあります。しかし、閲覧可能項目が多い場合、大量の項目登録が必要なので、設定画面の視認性が悪くなります。

追加のみ定義の場合は、何を閲覧できるかに対する登録項目が少ないため、設定画面の視認性はよくなります。一方で、どの項目と比較して"追加"で閲覧できる情報なのかという差分整理を丁寧に行わない場合、その権限によって何を閲覧できるのか混乱してしまう恐れがあります。

一般社員ロールに対して追加で閲覧できる項目を、各権限ロールの「何を」に登録するといったシンプルなルールを採用することが望ましいでしょう。

さいごに

人事データは非常にセンシティブなため、取り扱いに気をつけなければなりません。一方で、人事データの利活用は、従業員満足度向上や企業の業績向上に貢献できる可能性もあります。

以下のUdemyコンテンツ（私が制作したもの）は、人事データ分析やピープルアナリティクスを導入したい人事担当者に向けて、目指すべきゴールイメージと現状の差分から、導入のためのファーストアクションが述べられています。ロードマップ案も提示し、中長期で、何を視野に入れるべきかについても紹介します。一部、無料公開されているので、ご興味あればぜひ。

【人事データ分析・ピープルアナリティクス導入ガイド】小さく始めるファーストアクションと、成功のためのロードマップ