概要と想定読者

この記事ではDeNAにおける人事領域でのエンジニアリング事例を解説します。DeNAでは2018年４月より内製のテクノロジーチームを置き、現場のマネジメントで活かされるよう、暗黙知を形式知にするというテーマでとりくんできました。人事情報は基幹システム、勤怠、給与、会計などなど様々なシステムとの連携が必要です。そしてそれらはどれも独自のローカルルールや特殊事情を抱えています。データ集約自体は数年前からとりくんできていましたが、何度も改修を経て各処理が複雑にからみあい、頻繁に不具合がおきる状況となっていました。まず基盤としてそれらのアーキテクチャを整え、さらに、現場に眠るよりソフトな情報をあつめるべくツール開発を行ってきました。

「HR Tech」が流行のワードとなって久しいですが、実際にデータ活用・テクノロジー活用には苦心されている方も多いかと思います。私たちも様々な試行錯誤をへて一定の方向性を持つに至りました。この記事が、これからテクノロジー活用を考えている方にとって参考になれば幸いです。

第5回 HRテクノロジー大賞　優秀賞（人事システム部門）受賞

ここで解説している取り組みは第５回 HRテクノロジー大賞で人事システム部門 優秀賞をいただきました。
第5回 HRテクノロジー大賞

なぜ内製チームか

HR領域ではたくさんのツールが市場に存在しています。しかし、DeNAグループは多数の事業部と多数の子会社からなり複雑な構成をとっており、おおくのHRツールはcsvでの入力/出力に依存しているため、その複雑さとリアルタイムでの変更に追従することが困難になっていっていました。また、より文化として組織に浸透させるためには、この後でも解説していくような課題をのりこえる必要があり、結果的には自分たちで開発していくのがもっともリーズナブルなのではないか、という点も理由の一つです。 そして、作りっぱなしでおわらないためには、他社や他部門に外注するのではなく、人事部門内にエンジニアリングのチームを置き、組織の肌感をもってスピーディに改善をまわしていくことが必要だろうと考えました。

フォーカスした領域

「HR Tech」と一言にいっても「採用」「労務」「人材開発／組織開発」の３分野にわかれてきます。私達がフォーカスしたのは最後の「人材開発／組織開発」の領域でした。理由としては、その３分野の中でももっともソフトな要素が強く、会社のカルチャー・文化が色濃くでるのがその点であり、様々な既存のツールを試したものの、やりたい世界観を実現できるものがなかったためです。そして、私達が考える弊社の最大の資産は人であり、文化であり、テクノロジーを活用し経営に資するという意味では、この領域がもっともレバレッジが効くはずだ、と判断しました。

HRデータを扱う難しさ

HRデータを使い人材開発／組織開発に役立てようとする場合、いくつか課題になってくるポイントがあります。３つほどあげます。

1. ハード情報とソフト情報

ここでは、ハード情報とよんでいるのは、所属、雇用形態、生年月日、等級などのいわゆる基幹情報システムで扱われているデータを指しています。多くの企業ではなんらかのシステムが導入されある程度のデータ化がされているのではないでしょうか。一方で、ソフト情報、つまり、従業員のモチベーション、キャリア志向性、強みや弱み、性格や対人の相性、などは本人とマネジャー、あるいは事業部人事担当者らの頭の中にはあるものの、なかなかデータ化されておらず、利用可能・引き継ぎ可能な状態になっていない場合が多いと思います。

弊社でもはやくからパルスサーベイ（月次の簡易な従業員アンケート）を導入したり、エクセル等をつかってのタレントマネジメントは行われていましたが、分散した状態にありまとまって使えるようにはなっていませんでした。

2. データの連携

データがあつまってきたとして、次に連携の問題もあります。HR領域はさまざまシステムにまたがる領域であり、またシステムは時代時代の経営方針にそうよう単純に集めてもデータ同士がむすびつかず単発で終わってしまう場合があります。例えば、弊社でも社員番号は2種類あり、部署を示すコードは用途によって複数のコード体系が存在していました。一時期に作られたシステムはAという体系だが、そのほかはBという体系である、といような状況でした。

余談ですが、上記のような経営戦略にあわせたシステム見直しは攻めの施策としてとるべきと考えており、その上でどれだけシンプルでリーズナブルなものにしていけるかが頭のつかいどころだと考えています。

3. 適切な権限分散

HRデータはその性格上、個人情報であり、極めてセンシティブなものも含まれます。本人とっては闇雲に共有されることでネガティブな影響がおきかねません。しかし、その結果、データの公開範囲が人事部だけに限られてしまい、結局現場でなかなか利用されていかない。利用するにあたって毎回人事部側の作業コストが必要となり、結局使われない、ということになりがちです。 現場に近いところにデータの入力手段と利用手段を提供する。利用サイクルにあわせて、かつ安全に権限を設定していくのが重要になってきます。

個別事例としてはパルスサーベイ等のあとに部門のマネジャー陣でクロスレビューしネクストアクションを定めるのを促すため、各マネジャーは同じ部内であれば横のグループの結果も見えるようにする、等の仕様をツールに盛り込んでいきました。実際にどう使われるか、使ってほしいかで権限のデザインを微調整し続けています。

ただし、原則は「本当に必要なもののみ提供」するというポリシーに則り特殊な権限付与には一定のプロセスを挟むようにもしています。

内製HR Techチームのミッション

前章であげたような課題をふまえ、チームのミッションを以下のように定めました。

• 暗黙知を形式知に
• 文化を仕組みに

組織がスケールしていくために、暗黙知になっているソフト情報をすいあげる。DeNAらしい文化、組織カルチャーを仕組みとして実装しより現場主導で組織が強くなっていく世界を目指しています。本記事ではおもに前者の「暗黙知を形式知に」にフォーカスし、やってきたことをご紹介をします。

やってきたこと

データアーキテクチャーの刷新

まずはデータ基盤の整備にとりかかりました。人事に関係するデータは多方面にわたり、ハード情報だけでも、基幹システム、勤怠システム、管理会計システム、評価システム等を組み合わせる必要があります。そして、DeNAでは歴史的な理由から社員番号体系が2種類あり、システムによってどちらに依存しているかが分かれていました。また、イレギュラーケースを扱うために各システムで独自のルールがあり、例えば社員番号が9からはじまったらそれは特殊な用途用のエントリである、といったローカルルールが随所に存在していました。また、DeNAグループは10数社の主要子会社があり、それぞれに位置づけが違うため、子会社ごとに管理方法に差分がありました。

そして、ソフト情報はおもにGoogle Spreadsheetやエクセルで管理されており、当然のようにヘッダ行のゆれや部署ごとの特殊な記法が存在していました。また評価情報のように時期ごとにポリシーを更新していっているものは、それに応じてフォーマットが微調整されていました。

上記のような状況に対し、以前からパッケージツールを利用したデータ集約は行われていましたが、漸進的な増改築が繰り返された結果、各処理を行うパイプラインが複雑にからみあり、中間データが意図せず再利用されるような構成になっていたため、全体像の把握がかなり困難になっていました。結果、改修のたびに思わぬところで不具合が発生していました。

このままだと以下のような課題がより顕著になっていくだろう、と考えました。

• 運用面の課題
  • 特殊な環境のツールであり運用者が不在となると、運用スキルおよび志向性のある方を探すのが困難でした
  • 基幹システムとの連携等も密結合になっている部分があり、部署間での改修で副作用がでる場合もありました
• 発展性の課題
  • 例えば外部APIを生やしてコンポーネント間を連携させていく等の拡張ができない状況にありました。
  • データ入力インターフェースをもてないので、現場の情報を集めるためにスプレッドシート等の手段を挟む必要がありました。

発展性の面で、データ活用時に具体的におきていた課題としては、情報を展開する際に前後にエクセル等での加工工程を挟む型式をとっていたため、例えば、パルスサーベイを収集し、部門に展開する場合にも、エクセル等に出力したものからローカルで分割加工し、最後に事業部人事によってメールで送信する、という手順をふむ関係で、前後で２〜３日のリードタイムを必要としていました。

そこで、以下のようなイメージの構成に順次移し替えていきました。

コンセプトとしては以下です。

• 可能なかぎりAPIを利用した結合に置き換える。（ただし、外部クラウドツールなどcsvしかないところはそれはそれで対応する）
• 無理に1コンポーネントに押し込まず、コンポーネント間がゆるやかに連携するようにする。
• 分析者にはJupyterを用意し自由度をもたせる

またチームが分析者とエンジニアとの混合チームであったことから共通言語であるPythonを基本の言語としました。 ひとつひとつのコンポーネントは一般的なRDBとPythonで書かれたAPI、そしてUIのあるものについてはVue.jsを用いてコンパクトなアプリケーションとして作られています。

上記のような構成にすることで、より鮮度の高い情報を少ない手順で提供できるようになりました。前章で上げたパルスサーベイにおいてはリードタイムがほぼ必要のない状態になりました。また、入力インターフェイスを現場マネジャーに提供することができるようになりました。

ツール開発

基盤をととのえるとともに暗黙知となっている情報を集めていくためツール開発にも力を入れました。

パルスサーベイビューワー / タレントマネジメントツール

月次でおこなっているパルスサーベイのビューワーと、メンバーのプロフィールやキャリア志向性を記録するツールを開発しました。 これにより、マネジャー視点のメンバー情報と本人によるリアルタイムに近いモチベーションの情報が集約され日々のマネジメントに使用されています。

マネジャー360°フィードバックツール

Google Formを用いて行っていたマネジャー向けの360°フィードバックをツール化しました。

ちなみに、よく驚かれる点なのですが、DeNAでは360°フィードバックを記名式でやっています。これは社員全員がまもるべき行動指針であるDeNA Qualityの中に「発言責任」「透明性」という言葉があり、どういった状況でも意見を言うことを推奨し、そしてそれをしっかり傾聴することが望ましいとされているためです。その上で、「誰が言ったかではなく、何を言ったか」（これもまたDeNAでよく聞かれる言葉です）を重視するため、記入者の表記は控えめにしています。このようにインターフェース設計においては会社として重視している考え方を意識した設計を行っています。

評価リファレンス収集ツール

組織が複雑になり、複数のプロジェクトにまたがって仕事をするケースや、評価期間の途中で評価者が変わるケースが増えてきていました。 既存の評価ツールでは適切に評価リファレンスを集める仕組みがなく、評価の制度や納得感に大きな課題がありました。 360°フィードバックで構築した仕組みを用いリファレンス収集の作業コストを下げることと、これまで分散してしまっていたデータの集約を行いました。

これから

ツールは増えてきましたが、やはりツールを作っておわりではではなく運用サイクルもセットで作っていくことが重要になってきます。 習慣化するところまで、ツールをベースに日々の組織運営がなされるところまで持っていくのが今後さらに大きなチャレンジになってくると考えています。 また、それぞれで集まってきたデータをつなぎあわせてシナジーをおこすところまではまだ到達できていないのが現実です。そういった面もこれからの試行錯誤していくポイントになっていきます。

おわりに 〜 エンジニアリングチームを導入するために

人事はアートｘクラフトｘサイエンスの掛け算です。データだけで全てを解決できるわけではないが、データなき意思決定はスケールしません。 その両方にめくばりをしつつ妥当なソリューションを提供していけるチーム組成が大切になってきます。 そして、ソリューション自体はメンテナンスを考えるとできるだけ標準的な方法を選択する方がべターでしょう。 そういう意味では人事領域の専門性にもったメンバーとエンジニアリングのできるメンバーを組み合わせてチームビルディングしていくことが必要になってきます。

そして、いきなり作りすぎないことも大切です。いわゆるPMF(プロダクト・マーケット・フィット)するかは導入してみないと分からない面があります。 私たちも代々の前任者たちがパッケージツールやエクセル等を使ってトライしてきた蓄積の上でやってきました。 まずは小さく早くはじめて徐々に洗練させていくような心づもりが必要になってくると考えています。

あまり前例のある領域ではありませんので、人事部のトップのバックアップがあること、そしてチームの方向性と会社の戦略が一致していることがなにより重要になってきます。 私たちが幸運だったのは、会社全体に「データをもとに意思決定する」という文化があったこと、先人たちの様々なトライがあり一定の信頼を得られていたこと、でした。場合によっては地ならしからはじめなければいけないこともあるでしょう。その場合も辛抱強く、まずは低い果実から採っていくことをおすすめします。

最後までお読みいただきありがとうございました。

関連書籍

日本能率協会マネジメントセンター様より発売中の「ピープルアナリティクスの教科書」に当社の事例が掲載されています。そちらもご参考ください。