人事データ基盤（ピープルアナリティクス基盤）の設計で最初に理解すべきは、人事データが「最も機密性が高く、最もサイロ化されており、最も分析の価値が高い」という三重の特性を持つことです。SmartHR・Workdayなどの人事基幹システム、勤怠管理、評価・サーベイシステムに散在するデータを統合し、離職予測・採用最適化・エンゲージメント分析を実現することで、データドリブンな人的資本経営が可能になります。本記事では人事データ基盤の設計から従業員マスタのモデリング・分析ユースケース・プライバシー配慮まで体系的に解説します。
ピープルアナリティクスとデータ基盤
ピープルアナリティクスとは、従業員に関するデータを収集・統合・分析し、人材マネジメントの意思決定に活用する実践です。「なぜ優秀な人材が離職するのか」「どの採用チャネルが高いパフォーマンスの人材を生み出すか」「どの部門でバーンアウトリスクが高まっているか」——こうした問いにデータで答えられる組織が、人材競争で優位に立てます。
しかし多くの企業では、人事データが複数のシステムに分散しており、手作業でのExcel集計が横行しています。採用管理システム・人事基幹システム・勤怠システム・評価システム・サーベイツールがそれぞれ独立したサイロを形成しており、統合的な分析が困難な状態です。
人事データ基盤の構築は、こうしたサイロを解消し、People Dataを組織の戦略資源として活用するための基盤投資です。財務データと同様に、人事データもデータモデリングの設計精度が分析品質を左右します。
人事データの全体像
人事データは大きく6つのソースカテゴリから構成されます。各システムの特性を把握した上でインジェスト設計を行うことが重要です。
| データソース | システム例 | 主なデータ内容 | 更新頻度 | 主な分析用途 |
|---|---|---|---|---|
| 人事基幹システム | SmartHR / Workday / SAP HCM | 氏名/部署/役職/給与/入退社日 | リアルタイム～日次 | 従業員マスタ・組織分析 |
| 勤怠管理 | KING OF TIME / 就業奉行 | 出退勤/残業時間/有休取得率 | 日次 | 労務コスト・バーンアウトリスク |
| 評価管理 | Kaonavi / HRMos / Workday | 目標/考課点/360度フィードバック | 半期/年次 | パフォーマンス分析・昇進予測 |
| エンゲージメントサーベイ | Wevox / Culture Amp / Qualtrics | スコア/回答選択肢/自由記述 | 月次/四半期 | エンゲージメント分析・離職予測 |
| 採用管理 | Greenhouse / Jobvite / Recruit | 応募者数/選考通過率/内定承諾率 | リアルタイム | 採用チャネル効率・Time to Hire |
| 研修・スキル管理 | Cornerstone / SmartHR学習 | 受講履歴/資格/スキルタグ | 都度 | スキルギャップ分析・育成計画 |
特に重要なのはアクセス制御の設計です。給与・評価・健康診断に関するデータは人事部門のみが参照可能とし、分析担当者には個人を特定できない集計レベルのデータのみを提供する設計が求められます。個人情報保護法とデータ基盤への対応を基盤設計の初期段階から組み込むことが必須です。
従業員マスタの設計
人事データ基盤の核心は「従業員マスタ（ディメンションテーブル）の設計」です。部署異動・役職変更・給与改定などが頻繁に発生する人事データには、Slowly Changing Dimension（SCD）Type2による履歴管理が適しています。
SCD Type2では、変更前の状態と変更後の状態を別レコードとして保持し、effective_date（有効開始日）とexpiry_date（有効終了日）で有効期間を管理します。これにより「この従業員が3年前にどの部署に所属していたか」という時点クエリが可能になります。
MERGE INTO dim_employee AS target
USING staging.stg_employee_changes AS source
ON target.employee_id = source.employee_id
AND target.is_current = TRUE
WHEN MATCHED AND (
target.department_id != source.department_id OR
target.job_title != source.job_title OR
target.salary != source.salary
) THEN
UPDATE SET
target.expiry_date = source.updated_at,
target.is_current = FALSE
WHEN NOT MATCHED BY TARGET THEN
INSERT (employee_id, department_id, job_title, salary,
effective_date, expiry_date, is_current)
VALUES (source.employee_id, source.department_id, source.job_title,
source.salary, source.updated_at, '9999-12-31', TRUE);従業員マスタのキー設計も重要です。システムが変わってもユニークに従業員を識別するために、各社固有の社員番号をナチュラルキーとして使用し、DWH内部ではサロゲートキーを採番します。退職後に同じ社員番号が再利用されるケースがある場合は、入社日を組み合わせた複合キーで管理します。
給与データは特に機密性が高いため、DWH上でのマスキングまたは給与範囲（レンジ）への変換が推奨されます。分析目的には正確な給与額より「L1/L2/L3」などのグレード情報や、中央値との比率で十分なケースがほとんどです。
分析ユースケース
人事データ基盤が整備されると、以下のような分析が可能になります。優先度の高いユースケースから段階的に実装することが推奨されます。
| ユースケース | 目的 | 必要データ | 手法 | 期待効果 |
|---|---|---|---|---|
| 離職予測 | 離職リスクの高い従業員を早期特定 | 勤怠/評価/残業/サーベイスコア | 機械学習(ロジスティック回帰/勾配ブースティング) | 採用コスト削減・重要人材の引き止め |
| 採用チャネル最適化 | 高ROIの採用チャネルを特定 | 応募ソース/内定率/入社後定着率/パフォーマンス評価 | コホート分析・漏斗分析 | 採用コスト削減・採用品質向上 |
| エンゲージメント分析 | スコアの低下部門の早期把握 | サーベイスコア/部門/役職/勤続年数 | 時系列分析・セグメント比較 | エンゲージメント向上・離職率低下 |
| スキルギャップ分析 | 育成投資が必要なスキル領域の特定 | スキルタグ/研修履歴/評価/採用要件 | マトリクス分析・ヒートマップ | 育成計画最適化・採用要件の精緻化 |
| 残業時間モニタリング | バーンアウトリスクの高い部門特定 | 勤怠/残業時間/休日出勤/有休取得率 | 集計分析・アラート閾値設定 | 労務コンプライアンス・健康経営 |
最初に取り組むべきユースケースとして、離職率の可視化と要因分析が推奨されます。部門別・勤続年数別・評価ランク別の離職率ダッシュボードを作成し、どのセグメントで離職が集中しているかを把握することが第一歩です。MetabaseなどのセルフサービスBIツールを活用すれば、SQLを書けない人事担当者でもデータを参照できます。
プライバシーと倫理的配慮
人事データは個人情報保護法上の「要配慮個人情報」（病歴・障害・健診結果等）を含む可能性があり、通常の個人情報より厳格な取り扱いが求められます。データ基盤設計時に組み込むべきプライバシー対策を解説します。
アクセス制御の厳格化
給与・評価・健康診断データへのアクセスは人事部門と指定された分析担当者に限定します。DWHでは行レベルセキュリティ（BigQueryの行アクセスポリシー、Snowflakeのロールベースアクセス制御等）を活用し、部門マネージャーは自部門の集計データのみ参照可能、個人データは人事部門のみ参照可能という権限設計を実装します。
個人特定不可能な集計
分析は基本的に集計レベルで行い、個人の特定が可能なレポートは最小限に抑えます。特に小規模部門（5名以下等）では、集計値から個人が特定されるリスクがあるため、一定人数以下の集計は非表示にする閾値設定が必要です。
データの目的外利用の禁止
採用時に収集したデータを採用目的以外に使用することは法的リスクを伴います。DWHのデータカタログに各データセットの収集目的と利用可能な分析範囲を明記し、データガバナンスポリシーとして文書化します。
倫理的配慮
AIを使った離職予測モデルの結果を人事評価や昇進判断に機械的に適用することは、アルゴリズムバイアスのリスクを伴います。モデルの出力は「人事担当者の意思決定支援ツール」として位置付け、最終判断は必ず人間が行う設計にすることが倫理的かつ法的にも安全です。
導入ステップと組織体制
人事データ基盤の導入は段階的に進めることが成功の鍵です。以下の4フェーズが現実的なアプローチです。
フェーズ1 (1〜2ヶ月): データ棚卸しとアクセス整理
現存する人事システムのデータリストアップ、アクセス権限の確認、個人情報の取り扱いポリシーの策定を行います。
フェーズ2 (2〜3ヶ月): 統合基盤の構築と従業員マスタ整備
DWHへのデータインジェスト設定、SCD Type2による従業員マスタの構築、最低限のアクセス制御実装を完了させます。
フェーズ3 (1〜2ヶ月): 基本ダッシュボードの提供
離職率・採用状況・勤怠サマリーの可視化ダッシュボードを人事部門に提供し、日常的な活用を促します。
フェーズ4 (継続): 高度な分析の実装
離職予測モデル・スキルギャップ分析・エンゲージメント時系列分析へと段階的に高度化します。エンタープライズ規模では、専任のピープルアナリティクスチームの設置が有効です。
まとめ
人事データ基盤の構築は、人材の採用・育成・定着という企業の最重要経営課題に直接貢献する投資です。SCD Type2による従業員マスタ設計・厳格なアクセス制御・段階的な分析高度化という3つの柱で設計することで、プライバシーを守りながらピープルアナリティクスの価値を最大化できます。まず離職率の可視化という具体的な価値を示し、人事部門との信頼関係を構築した上で高度な分析に展開することが成功への近道です。
よくある質問
Q. ピープルアナリティクスで最初に取り組むべき分析は?
離職率の可視化と要因分析です。部門別・勤続年数別の離職率ダッシュボードを作り、採用コスト削減に直結する施策を打てるようにします。まずこの一点で人事部門に価値を示すことが、データ基盤への信頼と予算確保につながります。
Q. 人事データの取り扱いで特に注意すべき点は?
評価・給与・健康診断データは要配慮個人情報に準じた取り扱いが必要です。アクセス権限を人事部門と分析担当に限定し、個人特定不可能な集計レベルでの分析を基本とします。小規模部門への集計は個人特定リスクがあるため閾値設定が必要です。
Q. 小規模企業でもピープルアナリティクスは必要ですか?
従業員100名以上であれば効果が出始めます。まずはBIツール(Metabase等)で勤怠・離職データの可視化から始め、段階的に高度化していくのが現実的です。専用のデータエンジニアがいなくても、SmartHRのAPIとBigQueryを連携させるだけで基本分析は実現できます。