データの発生源を調べ、疑う

データ分析を始めるときには、何らかの手段でデータを集めることになります。ピープルアナリティスクの場合、組織で運用している人事給与システムのデータが軸になります。そして、分析テーマに応じて勤怠、旅費、タレントマネジメントなど関連システムのデータや、組織サーベイやアセスメント結果なども利用していきます。場合によっては、SFAや財務会計などの他業務のデータまで手を広げることもあるかもしれません。

もしデータレイクやデータウェアハウスといったデータ基盤が整っている場合は、データ基盤にアクセスして抽出してくることになります。そうでない場合は、各システム・データの管理部門とコミュニケーションをとって集めてくることになるでしょう。

データ抽出と集約にかかる時間は組織によって違いがあるものですが、それなりに時間がかかる印象です。人事データアナリストの皆さんは、分析プロジェクトのデッドラインを気にしながらデータの到着を待った経験があるのではないでしょうか。これは、データ分析プロジェクトが遅延する代表的な要因です。

このようなとき、人事データアナリストが打てる手はいくつかあります。第一に分析アプローチの検討を深めること。第二にデータ項目や発生源に関する情報をできるかぎり集めておくことです。そして、これらの情報を踏まえて体制や環境を整え、スタートダッシュをかけられるようにしておくとよいでしょう。

そうこうしているうちに、アナリストの手元にようやくデータがやってきました。分析アプローチも明確になっているのですぐに分析できる状況ですが、すぐに分析に着手すべきでしょうか？

データを丁寧に確認する

データが到着したら、まずはデータを丁寧に確認することから始めるべきです。いきなり回帰モデルを作ったり、とりあえず機械学習のアルゴリズムに突っ込んだりするのではなく。

手元にあるデータの件数や項目数を確認するところからはじめ、各データ項目にどのような値が含まれているかなど丁寧に確認する必要があります。なぜなら、データに欠損や漏れがあったら分析に意味がなくなるからです。基本的な話ではありますが、データアナリストにとって大切なステップです。

この確認作業をするときには、徹底的に「疑ってかかる」ことが大切だと考えています。特にデータ基盤が整備されていないときや、いつもと違う部門やシステムからデータを入手した場合は慎重にやるべきです。プロジェクトのコミュニケーションサイクルが長い場合は、手戻りが厳しくなりますので、初期の段階で丁寧に確認しておく必要があります。

基本的な確認

私は以下のようなことがあると想定し、まずは基本的な問題の確認から行います。

データの抽出が途中で止まってないか。一部だけ抽出されていないか。
データが二重に含まれていないか。
データに欠損や異常値が含まれていないか。
データ列に含まれる値とデータ項目定義はあっているか。
データ列の正しいデータ型・変数種別は何か。
データはいつ時点で抽出されたものか。
文字コードや改行コードは何か。
csvファイルの場合にエスケープ処理が正しくされているか。

以上の点はピープルアナリティスクに限らず、どのようなデータ分析タスクでも確認すべきことだと思います。

仮にデータベースの仕様書やクライアントからの説明資料が手元にあったとしても、それは本当だろうか？と確認することが大切です。ドキュメントが間違っていることもありますし、データ抽出にミスがあることもあるからです。私が過去に遭遇したトラブルをいくつかあげてみます。

ある量的変数について、特定のグループに属するデータ（全体の20%程度）がほぼゼロで上書きされていた。特定の業務オペレーション上必要な処置であったものの、データ分析上は意味のないデータとなっていた。
整数のデータ項目値にハイフン"-"や"12-18"などの値が入っており、データ分析ライブラリに取り込んだときに文字列と認識されていた。
複数のデータテーブルをつなぐキー項目が、それぞれのテーブルでずれていた。
データ項目名に改行や空白が入っていた。
ひとつのcsvファイルにデータ項目数の異なる複数のテーブルが混在していた。
文字コードや改行コードが異なる複数のファイルが届けられた。
誤って一年前のデータが届けられた。
差分で提供されるはずのデータが差分でなく全量含まれていた。

これらのトラブルは常に起きるとは限りません。しかし、新しいプロジェクトや環境では起きる可能性があります。私は様々な業種・業務の新規データ分析プロジェクトに携わってきましたので、こうしたトラブルはつきものでした。データ基盤が整ってくればこうした問題は減少していくと思われます。

データの発生源を調べる

基本的な確認と並行して、データの発生源を調べることも大切です。システムから出力されたデータであれば、そのシステムの位置づけや利用者の範囲、稼働状況を確認すべきでしょう。

特に人事関連システムの場合、システムによって管理対象が異なる場合もあるので注意が必要です。具体的には、基幹となる人事給与システムでは全従業員が管理対象となっているが、別のシステムでは一部の職種や部門が対象外になっているということもあります。その場合、データ結合で問題になるだけでなく、データ分析の目的に沿えるデータであるが確認しなくてはなりません。

また、利用自体が任意となっているシステムについては稼働状況も含めて確認すべきでしょう。例えば、オンライン系のラーニングシステムの利用が任意となっていて、しかもまだ組織内に浸透していない場合、他のデータと紐づけて分析するのはリスクがあります。関連分析の前に利用状況をデータからも確認し、クライアントに提示すべきです。

組織サーベイの結果を利用する場合は、サーベイの位置づけや回答状況を確認します。パルスサーベイような定期的なものなのか、それともスポットのサーベイか。回答必須のサーベイか、それとも任意回答かなどなど。

これらの確認は、データアナリスト自身の確認作業に加え、データ提供元やクライアントとコミュニケーションをとって進めます。そうすることで、お互いの頭の中にある「当たり前だよね」という前提のずれを是正できます。思いのほか暗黙知は多いものです。

人事データ特有の確認事項

以上の確認に加えて、人事データ特有の観点もあげてみたいと思います。

履歴

まず第一に、各データテーブルが履歴を持つかどうか確認すべきでしょう。人事給与システムは履歴データのかたまりで、かつ複雑なものになっています。基幹システムとして双璧をなす財務会計システムと比べて、人事給与システムの履歴の持ち方はより複雑だという印象をもっています。従業員の様々な変動を年月日単位で記録しているからです。代表的慣れ歴の例をあげてみましょう。

所属歴（主務、兼務）
職種歴
グレード・等級歴
職名・地位の歴
上司歴（あるいは管理対象従業員の歴）
教育受講歴
出退勤や時間外などの労務記録
勤務形態や雇用形態の歴
休職・派遣歴

こうした履歴を管理するために、多くの場合、変更日付や適用期間、対象年月日などの日付項目をもって履歴が作成されます。こうした履歴がある場合は、データ分析上の意味のあるデータを抽出しなくてはなりません。

もし、情報の性質上履歴があるはずなのに最新履歴しか保持しない場合はどうすればよいでしょうか？その場合は、(1)手元にあるデータが参照用だととらえて履歴を求めるか、(2)最新履歴しかないという条件で分析アプローチを軌道修正する、という対応になるかと思います。

人事給与系のシステムでこういう問題は起きにくいものですが、BPOでオペレーションを外出しにしている場合や、名称のコード系（名称履歴）を持たないシステムの場合、起きるリスクがあります。また、社内コラボレーションを行うシステムは人事系の履歴を有さない場合が多い印象です。

レコードの有効性

次に、データテーブルに含まれるレコードの有効性をコントロールする項目がないか確認しましょう。有効性とは、業務上参照することに意味があるかどうか、ということです。有効でないレコードを参照してしまうと数字をダブルカウントするなど弊害があります。過去に遭遇した例をあげてみます。

従業員の退職を人事基本情報のとある列で表現しており、退職済みのレコードは集計対象外にする必要があった。
ある分析で、休職や派遣などで在席していない従業員を集計対象外にする必要があった。
一つのテーブルに主務と兼務の情報が混在しており、しかも正規化がなされていなかったことから主務の情報に絞り込んで分析した。

ここで、1は基本的な母集団の絞り込みということで、多くの場合思いつくところだと思います。2については分析テーマ次第で、ヘッドカウントとして何を基準にすべきかという問題です。

一方、3はデータテーブルの捉え方の問題ですが、ある程度データ結合がなされたテーブルを見る場合は、よく起きる問題です。かちっとした人事給与システムのテーブルは基本的に第3正規形で設計されているので、こうした問題は生じません。しかし、こうした生のテーブルをデータアナリストに渡すことは限りません。なぜなら、かちっとしたシステムであるほど、人が読んでもわからないテーブルになっているからです。

人事システムのテーブルについて

最後に人事システムのデータについて少し掘り下げてみます。

人事データ分析に慣れている方からすると当たり前だよねと思われると思いますが、他分野から来られた方はギョッとしてしまうかもしれません。

例えば、所属履歴テーブルは以下のようなイメージになってるはずです。

従業員ID	開始年月日	終了年月日	所属内部ID	主務区分
18771	2022/4/1		332	1
18771	2020/4/1	2022/3/31	331	1
18771	2018/8/1		331	2

このテーブルは、従業員がどの所属にどの期間在席しているかを示すものです。ここで、従業員IDも所属内部IDもシステム内部で管理されている、内部コードだとしましょう。内部コードは一般的に利用者が見えないので、その値を見てもさっぱりわかりません。また、主務か兼務を区別する列もあるのでさらに複雑になっていますね。

ここで所属に着目すると、例えば次のようなテーブルが存在しているかもしれません。

所属内部ID	所属名称	所属コード	適用開始日	上位所属	所属レベル
330	公共本部	30001	2018/4/1		1
331	第一営業部	30010	2018/4/1	330	2
332	第二営業部	30011	2018/4/1	330	2
332	パートナー開発部	30011	2023/4/1	330	2

こちらを見ると所属名称を取り出すだけでも結構大変な気がします。そろそろ頭が痛くなってきそうですね。単に有効なレコードを連結するだけだと上位所属を含めた名称も見えません。

しかし、ここまで正規化することにより、様々な所属再編や機構改革を行いながらも、所属としての継続性を管理できるのです。実際の人事システムは所属分割や統合も管理できるので、もう少し複雑な情報をもっていることもあります。

もしこのような生テーブルをアナリストに渡してしまうと、その解析や結合に過大なる時間がかかってしまいます。昔そういったプロジェクトをやったことがあるのですが、テーブル結合だけで結構な時間がかかりました。

さて、こうした事態をさけるため、人事システムには人にとってわかりやすい情報を一括で出力できる機能が設けられています。それを使うと、例えば以下のようなテーブルを得ることができます。

従業員ID	主務区分	所属1コード	所属1名称	所属2コード	所属2名称	開始年月日	終了年月日
18771	1	30001	公共本部	30011	パートナー開発部	2023/4/1
18771	1	30001	公共本部	30011	第二営業部	2022/4/1	2023/3/31
18771	2	30001	公共本部	30010	第一営業部	2022/4/1
18771	1	30001	公共本部	30010	第一営業部	2018/8/1	2022/3/31