人事データ分析の前処理で気をつけること
人事データを分析するときには、まず手始めに既往の人事システムからデータを抽出した上で、分析目的に応じてテーブルを結合し加工する必要があります。統合的な人事データ分析基盤を構築している場合は、ある程度整ったデータにアクセスすることが可能です。しかし、人事システムや関連システムからデータをかき集めて分析をするような場合には、前処理に様々な手間がかかります。
こうした手間は人事分野に限った話ではありません。しかし、人事データならではの難しさが潜んでいます。この記事では、人事データ分析の前処理で気をつけることをまとめました。
データソースが分散している
ピープル・アナリティクスにおける主たる分析対象は人事システムに蓄積されたデータですが、関連システムを含めると多種多様なデータをかけ合わせて分析する必要があります。例えば、人事内に閉じた分析をする場合であっても次のようなデータが必要となります。
人事情報（人事システム）
評価情報（人事システムまたは周辺システム）
勤怠情報（総務事務システムまたは勤怠管理システム）
研修受講情報（研修管理システム）
従業員サーベイ情報（サーベイシステムまたはExcelなど）
これらに加えて、業務実績との関連や生産性を分析する場合は、会計システムや業務管理システムのデータも必要になります。
こうしたデータは管理部門異なっている場合もあるため、社内調整に時間がかかることもあるでしょう。更に、データ形式が統一されていない場合もあり、分析者の前処理の負荷を上げる要因にもなっています。
このため、こうしたデータを分析用に一元的に保持したくなってきます。
人事系マスタは人が解釈できない（コード問題）
人事システムは複雑な人の履歴を保持しながら、採用、配置、評価、退職に至るプロセスを管理する必要があります。一方、一般的に組織構成は経年で変わり、人も異動していきます。また、職種や職位なども制度変更によって変わることがあります。こうした変更があるたびにテーブルデータに含まれる名称を更新するのは合理的ではありません。この問題を解消するため、人事システムを始めとする業務システムでは、名称をカテゴリ化して記号で保持する形になっていることが一般的です。人事システムではしばしばこの記号（符号）のことを「コード」と呼びます。
コードの利用により、人事システムのDBは驚くほど制度変更に柔軟性を持つのですが、その弊害としてマスタの生データを見ても人が解釈できないという問題があります。理解するには常にコード表で翻訳する必要があるわけです。しかも、コードに対する名称や意味が暦年で変わることを前提としているため、正確な名称を取るためには日付を意識したコードの翻訳が必要になってきます。
この問題は人事システムのDBを直接参照した場合に問題となるものですが、通常人事システムのマスタに直接アクセスすることはなく、特定の管理者が特別な機構を通じてデータを抽出する場合が多いでしょう。この際は、各コードの翻訳がどの日付を基準としているのか、その仕様を押さえる必要があります。
あらゆるマスタが履歴を持つ
人事マスタの情報は履歴を持っている場合が多いため、ターゲットとなるデータにアクセスするためには、常に日付を意識する必要があります。一見すると、参照キー項目に日付を含めれば良いように感じますが、簡単に行かない場合があります。
例えば、所属のIDや所属名を管理する機構管理系マスタにおいては、その歴は変更日のみが記載されることが多いです。この場合、2022年6月20日に機構改革とともにとある所属名が変更された場合、名称違いの同一所属IDのキーのレコードがもう一件挿入され、その基準日が2022年6月20日となります。一方、この所属に配置されている従業員のデータから所属IDを元に所属名称を引っ張る場合、これらのレコードのどちらを参照するか選択しなくてはなりません。
ここで、最新を引っ張ればよいではないかと想像されますが、正確には分析で対象としている事象、もしくは結合しようとしているデータの意味的な日付に合うものを参照する必要があります。これを実現するために特定の条件で抽出したり結合したりできるルーチンを準備する必要があります。
これは所属だけでなく、先に述べたコードの翻訳も同様の問題が起きます。とはいえ、最も厄介なのは所属履歴の扱いでしょう。
集計の単位に多様性がある（特徴量化）
人事データを何らかの形で集計する場合は、概ね①人、②所属、③時系列の3つの軸で検討する場合が多いでしょう。このとき、人については個人単位だけでなく性別、年代、採用区分などの属性を利用していくことになります。
所属については、本部・統括部・部・課のような階層構造別に集計していくことがあります。したがって、これら人の属性や所属階層をデータ項目として持っておくと集計に便利です。
時系列の観点でみると、データ管理上の最小単位は日となります。その上で、月・四半期・年といった区切りで集計する場合もあります。人事関連データで最も記録単位が最小となるのは勤怠データですが、全従業員の日時のデータを分析のたびに集計していると手間と時間がかかってしまいます。このため、月や年で集計したデータを保持しておくと何かと便利です。
このように、分析の切り口が多様であるがゆえに、データの集計単位にも多様性が生まれます。これを分析のたびにアドホックに対応していると前処理の負荷が高くなってしまいますので、あるところで月次や年次での集計データを保持する作戦を取る必要が出てきます。これは効率化のために重要ですが、先に述べた履歴の問題が常につきまとってきます。
ここで述べた①人、②所属、③集計単位として時系列の区切り目は必ずしも揃っていません。このため、集計用テーブルを作る場合に所属を参照したりコードを翻訳したりすると、どこかで妥協する必要がでてきます。わかりやすい例でいうと、年月単位の集計をする際に月途中で異動した従業員のデータがあった場合、どちらの所属で集計すべきか？という論点が発生します。
これは分析者やデータ抽出処理設計者に委ねられる点ですが、人やシステムによってポリシーが異なった場合、後々問題が起きることになるわけです。
まとめ
今回は人事データ分析の前処理で気をつけることを整理してみました。人事データや業務システムに触れたことがある方にとっては当たり前の話に見えるかもしれません。しかし、人事以外のデータ分析に慣れている方からすると驚くこともあると思います。
ここであげた話を裏返してみると、人事データの分析基盤を作ることのメリットが見えてくると思います。
この記事が気に入ったらサポートをしてみませんか？