HRデータにおける権限の考え方
HR情報を管理しアプリケーションに組み込んでいく際に権限の設計は重要なポイントになります。ここをきめ細やかに実現できないと、HRデータの特性上、安全側に倒すことになり、結局、集約したデータを一部の担当者がクエリを書いて見ているだけという状態になりがちです。今回はわたしたちがこの課題にどう取り組んでいるのか、と今後の展望について書きます。
流れとしては以下のような形になります
ユーザー種別の洗い出し
ポリシーの設定
権限の設計
仕組みの実現
ユーザーは誰か
まずHR情報のユーザーとなえりえるのはどういった方々でしょうか？
まず人事担当者として３つの種類に分けられます
全社の組織開発・人材開発を担当するHR
各事業部門のHR（子会社HR）
職能等で横断的に人材開発を担う担当等
そしてもちろん、実際に現場のマネジメントを行う
部門のマネージャー、部門長
があげられます。こういった方が業務を遂行できるよう権限を設計していくことになります。
全体のポリシー : D2C
全体のポリシーとしてはD2C（Direct to Consumer）にならって、自分でできることはで自分でできるようにする。情報の非対称性があることで生まれる中間の仕事を減らすことを目指しています。
その上で本当に必要な情報のみを提供すること。とくに、本人にとってスティグマとなりえる情報は提供しない、ことをポリシーとしています。
レベル設計
そこで３段階の基本権限レベルを設定しました
レベル３ - 全社権限 - 全社の組織開発・人材開発に関わる方向けの権限レベル。あらゆる情報にアクセス可能
レベル２ - 事業部人事権限 - 担当する事業部門・子会社に現在所属する方について全ての情報にアクセス可能
レベル１ - 職種等の属性による横断的なデータアクセス、またはスポットでのデータ抽出に用いる権限
権限申請はワークフローにて用途ととも記録を残すようにし、そこで基本的な注意事項と心得を必ず確認してもらうようにしました。
レベル１に該当する、スポット抽出依頼もワークフロー化し用途を記録するようにしています。
権限の組み込み
レベルの設計ができたらそれを実際に組み込んでいきます。この時に大切になるのは、異動・組織変更にともなう対象従業員の所属変更を最小限のコストで追随できることです。
わたしたちの例では以下のイメージのように、各ユーザーが閲覧できる範囲の起点となる部署のIDを複数持つことで対応しています。
この構成にすることにより、基幹データの更新に追随して対象従業員の異動にともなって閲覧可否が反映されるようになっています。
今後：項目レベルでのコントロール、所属以外の属性での権限設定
現在のわたしたちの構成は、用途別にいくつかのウェブアプケーションで構成されており（例えば前回紹介したサーベイビューワー等）、閲覧できる項目のコントロールはアプリケーションを分けることで行なっています。今後より柔軟にデータ提供をしていくためには項目レベルでの細やかなコントロールをしていく必要があるでしょう。例えば、あるユーザーには評価関連の情報は隠す、等です。
また、所属以外の属性による横断的な権限管理も今後の検討事項になります。例えばある部署において「エンジニア」であれば閲覧可にする等、いくつかの条件をクロスすることができればより柔軟な情報提供が可能になるでしょう。
まとめ
HRデータは情報の性質上、権限設定を細くできないと閉じた情報となりがちです。なるべく各担当が必要な情報はとりだせるよう仕組みを整えておくおとが必要になります。この記事ではわたしたちが現在実装している考え方と実現方法について紹介しました。全体として、容易に複雑化しやすい点でもあるので、できるだけシンプルに基準を設け、日々のオペレーションコストが小さくなるよう一定割り切った実現方法をとるのが肝だと感じていいます。
このあたりのノウハウはなかなか表にでてこない点でもありますので、この記事を読んだ方で同様の課題に取り組んでいる方がいましたら、ぜひお話できたらと思います。
この記事が気に入ったらサポートをしてみませんか？