知見・人・API・DB・予算 ─ ナイナイ尽くしだった人事データ整備 with dbt、5年間の学び

Tokyo dbt Meetup #20

Transcript

1. Tokyo dbt Meetup #20 — 2026.07.02 知⾒‧⼈‧API‧DB‧予算 ナイナイ尽くしだった⼈事データ整備 with dbt、 5年間の学び 桑原 健⼀ 株式会社LELEPONO / 代表取締役
2. 直近10年間でやっていたこと ‧採⽤、労務、⼈事制度設計、海外⼦会社管理、開⽰関連、⼈員計画 ‧プロダクト/営業/マーケ/会計/⼈事データ基盤開発 自己紹介 ビジネス‧バックオフィス‧エンジニアを経て独⽴ （ライフセーバー） 営業 ライター ⼈事 データ
3. 今⽇話すこと 1 ドメインの事情 5つの「ナイナイ」 2 どう進めるか 制約の中での進め⽅
4. ドメインの事情 ⼈事は「⼈の情報」を扱う だから普通のデータ基盤より、制約が多く、慎重さが求められる 評価 給与 労務 サーベイ
5. ナイナイ尽くし 1 / 5 01 知⾒がない 人事側 技術⼒の不⾜ データ側 ⼈事業務の⽂脈を知らない ‧前提知識の違い ‧コミュニケーションスタイルの違い
6. ナイナイ尽くし 2 / 5 02 ⼈がいない ⼈事業務 データ エンジニアリング ごくわず か 両⽅が分かる⼈は 市場に少ない 社内で探しても、外から採ろうとしても、⾒つかりにくい。
7. ナイナイ尽くし 3 / 5 03 API‧DBがない 業務システム 例外対応 管理台帳 隙間の業務 → Excel / スプレッドシート API なし・DB なし 業務システムを⼊れても隙間の業務は残り、その多くをExcelやスプレッドシートが担う。
8. ナイナイ尽くし 4 / 5 04 予算がない 営業/マーケ/プロダクトの基盤以上に 投資対効果を説明しにくい ※従業員規模1000名以上 + 上場企業から相談を受けることが多い
9. ナイナイ尽くし 5 / 5 05 権限がない、簡単に共有できない 社内の他部署 同じ人事部門の中 評価‧給与 「⼿伝って」と⾔うこと⾃体がハードルになる
10. そこで必要になる橋渡し役 ⼈事部⾨ 橋渡し役 SQL 業務知識 dbt データチーム 求められるのは データエンジニアリング + ⼈事実務 データスチュワードに近い役割。情シスと⼈事の間にいる⼈が担える可能性がある。
11. 橋渡し役がもたらすもの 橋渡し役 堅牢な組織データ データチーム ビジネス プロダクト 組織データは⼈事のためだけのものではない ⽣産性分析など、⼈事の外側でも全社的な分析の⼟台として使われる。
12. どう進めるか dbtは、⼈事とデータチームの共通⾔語になりやすい コードで管理できる 技術スタックを揃えやすい 協働‧引き継ぎがしやすい
13. dbtがない世界を想像する 個別処理が散らばる世界 補正スクリプト 変換 function #12 ⼿動パッチ 誰かのメモ 誰も全体を把握できなくなる dbtプロジェクトの世界 staging staging → intermediate → mart ロジックを「プロジェクト」として 依存関係ご と管理できる ⼈事データは細かい変換‧補正が多い。変換ロジックを個別の処理に閉じ込めたくない。
14. なるべく低コストなデータ開発プロセスを踏む 1 とりあえずマートを作る 2 中間テーブルを整理 3 ディメンショナル モデリング 4 セマンティックレイヤー どうしても必要なときだけ
15. Trusted Data Development 参考: GitLab Handbook — Trusted Data Development https://handbook.gitlab.com/handbook/enterprise-data/how-we-work/data-development/#trusted-data-development
16. ⼈事はメトリクスよりリストを求める 多くの現場で求められているのはメトリクスではなく「リスト」 ただし裏側では 粒度を曖昧にしない employee_id email 1024 aaaa@hoge.com 2381 bbb@hoge.com 4551 ccc@hoge.com 集計するカラムは、ほとんどが従業員ID ‧ファクトテーブル が、ただの結合⽤のハブテーブルになりがち イベント ⼊社した‧異動した‧退職した 時点の状態 YYYY-MM-DD 時点の在籍者 プロセス 選考ステップ 分けて設計すれば、リストにも分析にも展開できる
17. 便利モデルを作っていく 例：組織ディメンション × 階層ブリッジテーブル dim_organization 組織ディメンション bridge_org_hierarchy 階層ブリッジテーブル 組織階層を使った分析 内製アプリのアクセス制御 ‧組織階層の増減に追従できる（例：組織再編で、先⽉までは階層レベル３が本部だったのに今⽉からレベル４が本部になった） ‧特定部⾨の時系列データ、特定部⾨の配下の従業員数など正しく抽出できる ‧階層の上下関係を扱えて堅牢
18. データソース管理に踏み込んでいく 例：縦持ち vs 横持ち 横持ち — 列が増え続ける id 項目A 項目B +新項目 +新項目 スキーマ変更の度に壊れる 縦持ち — 構造が安定する id 項目名 値 日付 新項⽬は「⾏」として増える。カラム変更は最⼩限 こういった情報を伝えていくことも重要な活動
19. データソース管理に踏み込んでいく 「分析したい」「可視化したい」 水面 ⼊⼒ルールがない 蓄積されていない 更新が揃わない 履歴が残らない 集計の前に ⼊⼒‧蓄積‧更新のルールが崩れて いることがある 初期は分析ニーズと業務ニーズが混ざりやすい。 成果優先のため、敢えて混ぜることもある。
20. dbt 例外補正 名寄せの⼿直し 特別ルール 歴史的事情 + さらに増える… ソースを直さない限り、変換ロジックは肥⼤化し続け る ⇄ 切り分ける 業務設計に戻す 直すべきは業務側の⼊⼒ルールか? この切り分けこそ、橋渡し役にしかできない仕事 データソース管理に踏み込んでいく
21. 権限設計は組織図どおりにいかない 本部 部A 部B 部C 報酬設計の負債 レポートラインと 評価ラインが別 組織図や役職由来のアクセス権限リストに加えて ⼿動オーバーライドもできるよう設計する 組織図どおりの権限付与はほぼ不可能。必ず個別事情でルールを崩す必要が出てくる。
22. ⼈事データ基盤の進化パターン 採⽤ / ⼈事管理システム このあたりから始める → その他の領域 順に広げる → 労務データ いちばん重いので最後に ⼈事側 プロジェクトマネージャー 開発者 私 2⼈体制が多い 営業‧プロダクト基盤のベストプラクティスを⼈事に持ち込めるのが武器に なる
23. 注目している領域 ワークフォースプランニング 採⽤データ サーベイデータ ⼈員計画 集約されていく 未来の組織を どうデザインするか ⼈とAIをどう組み合わせていくか？ 世界各国の防衛機関の労働⼒計画レポートが実践的で参考になる
24. まとめ ⼈事データ整備は、ナイナイ尽くしでも進められる 鍵は、⼈事とデータチームをつなぐ役割 dbtはそのための共通⾔語 ⼈事部⾨ 橋渡し役 dbt = 共通言語 データチーム 同じような制約と戦っている⽅の参考になれば。ありがとうございました。