VUCAに対応する柔軟な組織改編を支えるHRシステム【DeNA TechCon 2022】

組織変更や人事異動は企業運営に欠かせない業務の一種です。DeNAでは毎月のように組織変更や人事異動が実施され、その時々の状況に即して経営のレビューもいれながら基幹システムと同期をとっています。ただ業務の特性上、携わるメンバーも限られ手作業も多く属人化する傾向にありました。

この課題を解決するために、概念モデルとして Github などバージョン管理の仕組みを参考にしたシステムの開発に着手し、複雑に絡み合った業務のモデル化、業務を止めないシステム移行に取り組んできました。

このセッションでは、数千名規模の企業における組織改編業務をどのようにDXし、経営と現場とバックオフィスをつなぐ三方良しの仕組みを実現したか、その過程の課題や工夫をご紹介します。

資料内でのリンク集：
p3-1, https://fullswing.dena.com/archives/5495
p3-2, https://note.com/masaki_sawamura/n/n505420d7dc46

◆ You Tube
https://youtu.be/ZZsbgJKsufI

◆ You Tube チャンネル登録はこちら↓
https://youtube.com/c/denatech?sub_confirmation=1

◆ Twitter
https://twitter.com/DeNAxTech

◆ DeNA Engineering
https://engineering.dena.com/

◆ DeNA Engineer Blog
https://engineering.dena.com/blog/

◆ DeNA TechCon 2022 公式サイト
https://techcon2022.dena.dev/spring/

Transcript

1. VUCAに対応する 柔軟な組織改編を支えるHRシステム 森岡 志門
2. 自己紹介 2005年DeNA新卒入社。 サーバサイドエンジニアとして、EC、新規事業立ち上げ、ブラウザ版ソーシャルゲーム、メディアなど複数事業において 開発や運用、リードエンジニアを担当。途中技術人事や技術広報の経験も経て、2020年よりHR部門に設けられたHRTech領 域の開発チームに所属。社内ジョブボードや組織変更支援ツールの開発・運用を担当している。
3. チーム紹介 2019年4月〜、人材開発・組織開発を中心としたHR関連の ツールを内製開発し運用するチーム ミッションは「暗黙知を形式知に」「文化を仕組みに」 なぜHRテクノロジーなのか〜人事部の中に専門のグループができるまで ｜澤村正樹＠インハウスHRTech｜note 「社員の個性・能力を活かす仕組みを強化して いきたい」HR Techチームが進めるモノづくり とは | フルスイング - DeNA
4. TABLE CONTENTS 1.組織変更とは？ 2.組織変更支援ツール - Deck 3.ふりかえり
5. 誰向けか - 社内ツールの開発やバックオフィス業務のDXに関わられている方 - 企業でHRや組織開発等に取り組まれている方
6. 組織変更とは？
7. 組織変更・人事異動におけるVUCA 予め計画を立てていても予定通りにコントロールすることが難しい領域 Volatility:変動性 - 事業状況の変化への対応、メンバー育成観点からの異動 Uncertainty:不確実性 - メンバーのライフプラン変化や退職 Complexity:複雑性 - ステークホルダーが多く、必要とされる情報も多種多様 Ambiguity: 曖昧性 - 兼務や副業など会社や部署の境界を越えた働き方
8. DeNAの組織変更・人事異動の特徴 四半期ベースの組織変更 - その時々の状況に即して柔軟に適応 大黒柱を引っこ抜く企業文化 - 部門の枠を越えて人材を活用する考え方 シェイクハンズ制度・クロスジョブ制度 - 従業員が自ら手を上げて他部門へ異動や兼務を応募できる制度
9. 組織変更・人事異動業務で起きていた課題 企業運営で不可欠な業務かつ影響の大きく業務特性と裏腹に、属人化など持続性に懸念があった • ステークホルダーが多く変更コストが大きい • データ連携が大変 • 属人化
10. 課題：ステークホルダーが多く変更コストが大きい 多くのステークホルダーが関与して、影響範囲、変更コスト共に大きい 本社 人事 事業部A 経理 IR 経営管理 経営陣 レビュー 総務 派遣 管理 ・給与チーム ・出向チーム ・人員表担当 労務 事業部B 事業部C IT戦略 子会社人事 本社 人事 400人 100人 200人
11. 課題：ステークホルダーが多く変更コストが大きい 情報の集約し、統合とレビューを経て拡散。それぞれのフェーズで関わるステークホルダーも変わる 本社 人事 事業部A 経理 IR 経営管理 経営陣 レビュー 総務 派遣 管理 ・給与チーム ・出向チーム ・人員表担当 労務 事業部B 事業部C IT戦略 子会社人事 本社 人事 400人 100人 200人 集約 拡散 統合＆レビュー
12. 課題：ステークホルダーが多く変更コストが大きい 複数の事業部から組織変更や人事異動の情報を集約し統合 本社 人事 事業部A 経理 IR 経営管理 経営陣 レビュー 総務 派遣 管理 ・給与チーム ・出向チーム ・人員表担当 労務 事業部B 事業部C IT戦略 子会社人事 本社 人事 400人 100人 200人 集約 拡散 統合＆レビュー
13. 課題：ステークホルダーが多く変更コストが大きい 拡散フェーズでは、様々なバックオフィス部門と連携 本社 人事 事業部A 経理 IR 経営管理 経営陣 レビュー 総務 派遣 管理 ・給与チーム ・出向チーム ・人員表担当 労務 事業部B 事業部C IT戦略 子会社人事 本社 人事 400人 100人 200人 集約 拡散 統合＆レビュー
14. 課題：データ連携が大変 各部門から情報を集約し、経営陣レビューを通してバックオフィスへ伝搬する一連のプロセスを 表計算ソフトのデータ形式で連携していた 人事異動情報 データ整形 データ作成用 マクロ 組織情報マスター 経営陣レビュー資料 基幹システム連携データ 異動対象者リスト 兼務情報マスター 基幹システム連携データ 組織図 組織変更情報 バックオフィスへの情報伝播 5営業日前後 各部門からの情報集約 月初〜月中 情報の統合と経営陣レビュー 月中〜3営業日前後 事業部人事
15. 課題：属人化 機密性の高い業務特性もあり、限られた人員で運用 機密性ど業務負荷の高さ、ドキュメンテーションなど属人化の解消が進みづらい構造 若干名で対応 人事異動情報 データ整形 データ作成用 マクロ 組織情報マスター 経営陣レビュー資料 基幹システム連携データ 異動対象者リスト 兼務情報マスター 基幹システム連携データ 組織図 組織変更情報 バックオフィスへの情報伝播 5営業日前後 各部門からの情報集約 月初〜月中 情報の統合と経営陣レビュー 月中〜3営業日前後 事業部人事
16. 組織変更支援ツール - Deck
17. 組織変更支援ツール - Deck 人事異動を含む組織変更案を作成できる内製ツール 関係者レビューや、基幹システム等バックオフィスに連携する機能も含む （名称は、カードゲームのデッキ構成に由来）
18. なぜ内製か 社内： - HRTechのチームがあり、社内に整えられつつある複数のHRTech関連とのサービス連携も今後期待できる 競合： - 機能が多すぎたり、実現したいことができなかったり、帯に短し襷に長し 顧客： - 現場としてはクイックに変化に対応していきたい、経営としてはガバナンス効かせたい
19. 開発のスコープ 組織変更と人事異動におけるプロセスのうち、 データを集約し、経営陣レビュー、バックオフィスへ伝搬までを開発スコープとした 組織変更・人事異動業務システム化のドメイン 人事異動情報 データ整形 データ作成用 マクロ 組織情報マスター 経営陣レビュー資料 基幹システム連携データ 異動対象者リスト 兼務情報マスター 基幹システム連携データ 組織図 組織変更情報 バックオフィスへの情報伝播 5営業日前後 各部門からの情報集約 月初〜月中 情報の統合と経営陣レビュー 月中〜3営業日前後 事業部人事
20. 開発スコープと顧客 組織変更・人事異動案の有効化には、経営陣の承認とバックオフィスへの伝搬が不可欠 情報を一元化し、事業部人事・経営陣・バックオフィスの三者を確実につなげる必要がある 経営陣 事業部 人事 バック オフィス Deck 組織変更・人事異動の 編集・申請 レビュー データ連携
21. 社内外のシステムとの連携 組織情報や所属情報は基幹システムに依存するため、日次で取得 変更情報は月末までに基幹システムへ連携。基幹システムを通し、社外の給与計算サービスにも連携する
22. 概念モデル Git のバージョン管理を概念モデルとした 基幹システムに保持される組織情報・人事情報（所属情報）を基底ブランチとし、その変更差分を管理
23. 概念モデルと運用 運用してみると、想定よりも多く重複（コンフリクト）が発生。 重複(≒コンフリクト) を避ける運用をしても 発生してしまう コンフリクト解消は本 社人事担当が実施
24. 概念モデルと運用 cherry-pick 的な操作も可能に （役職を複数兼務するメンバーの異動など、部門を跨いで相互依存する変更情報が発生、特に組織変更時） 部門Aの組織変更を織 り込んだ異動情報を作 成したいといった cherry-pick も可能に
25. ER図 システムとしては、現状に関する情報を基幹システムから取得。その上で変更後の状態を保持し、差分を抽出
26. ふりかえり
27. 移行のタイムライン すでに動いている業務プロセスがあり、かつクリティカル。スコープアウトの余地も少ない 業務を止めないよう主だったモジュールごとに、フェーズを分けてリリース 試験運用→並行稼動→運用開始とした
28. 当初想定と異なったこと 要件の把握≒全体像の把握に時間がかかる - ヒアリングに時間がかかる - 経験と勘ではないが形式知化されていない業務プロセスもあった - 担当者が忙しい - ヒアリング先が多い - ステークホルダーが多い - 担当者自身も関わっている工程とその前後は解像度高く把握できているが、離れるほど解像度は下がる 要件が複雑 - ちょっとしたフラグが意外と複雑 - ディシジョンテーブルで数十パターンに - 部門や会社を跨いだ働き方が増えていることも遠因
29. 工夫したこと ステークホルダーを巻き込んでいく - コミュニケーションの改善 - 属人化したノウハウを聞き出すのは時間がかかる、繁忙期は担当者もまとまった時間確保しづらい - 間隔を縮めてこまめに開催（隔週→日次） - 確認したことを細かくアウトプットしてフィードバックを得る - 全体像の共有 - ヒアリングのプロセスで把握した組織変更業務の全体像を、関係者に共有 - 移行のステップを重ねることへの理解の醸成
30. 実現できたこと SPOFの低減 - システム化の過程でこれまで属人化していた業務プロセスを形式知化 工数削減 - データの集約や連携にかけていた人的工数を低減 - エラーチェックの負担も軽減
31. 今後の課題 さらなる工数の削減 - ヒヤリハット防止のUI/UX改善 - マージ作業の省力化 付加価値づくり - 組織変更や人事異動の効果検証 - e.g. 検討ログの集積、組織の変遷の（コミットグラフのような）追跡
32. まとめ ツールの整備 - 組織変更や人事異動をソフトウェアと捉えて、Git のバージョン管理を概念モデルに仕組みを構築 - 移行は、事業部人事、バックオフィス、経営陣向けレビューと用途に分けて段階的に実施 ステークホルダーとの関係構築 - ステークホルダーが多く、属人化した業務プロセスの要件は全体像が掴みづらい - 全体像をステークホルダーと共有し、理解醸成しておくことがDX推進の下地になる