人事データ基盤のシステム構成やアーキテクチャ概要
ここまではHRDX組織のなりたちや体制について見てきたので、ここからは人事のデータ基盤のシステム構成について解説していこう。
当初構築した背景には、データ活用が進んでいないという課題があった。人事で業務利用するシステムは多岐にわたるため、データを結合した分析を実践しづらかった。実業務では手作業でデータ加工するなど工数も発生しており（ミスも増える）、人材不足に拍車を掛けていた。またデータの定義がばらばらで集計するのに問い合わせなどで手間がかかるという状態だった。
そこで人事データに関する適切な活用を促進するために人事データ基盤を構築し、年間で新規BI案件やデータ分析案件のKPIを定めて運用していくことにした。また柳氏は「この人事データ基盤施策は人事本部向け戦略施策として推進する将来の人事テクノロジー活用に向け、データを一括管理することに意味がある。それだけではなく（構築して終わりではなく）HRDXグループとして人事本部がデータ活用し、会社や社員にプレゼンスを発揮できるように伴走することを目標として進めています」と話す。
人事データ基盤は社内システムや既存の外部サービスをデータソースとして、API連携やファイル連携などを通じてデータを集約している。アーキテクチャは6層（データソース、データ連携層、データ蓄積層、データ加工層、データ提供層、データ活用）で構成している。
特徴的なのは確定情報と未確定情報（計画段階）で分けているところだ。未確定でも最新情報を知りたい場合にはコネクタを通じてアクセスできるようになっており（図の青い部分）、確定情報はデータレイクに蓄積したデータをDWHにかけてアクセスできるようになっている。
データフローをデータソース、データ収集、データ蓄積、データ加工、活用といった流れで分解したものが下図になる。データ蓄積では、Cloud Storageの収集用バケットにデータを年月日でパーティションを区切り蓄積するようにした。その上でBigQueryで取り込み、加工する。
人事データなので、具体的には社員属性情報、給与情報、勤怠情報など従業員にかかわる情報となる。全部で12種類の情報があるなか、まずは業務利用頻度の高いものから連携を始め、2023年12月には一通り連携できるところまで到達した。
データ蓄積まで進むと、次はデータ加工・活用という流れになる。ここでデータ活用で使うBIとしてLookerを選定した背景について触れておこう。BI選定の要件としては、容易にアカウント数の増減（コスト）できること、データ取得を自動化かできること、個人情報が含まれるためデータアクセス制限は行や列単位で制御できること、人事データ基盤と親和性が高いことなどが挙げられ、最終的にはLookerを選定した。
