人事管理の全フェイズをカバーしたPDCAサイクルを可能にするサービス
ビズリーチの新規事業として立ち上げられたHRMOSは、一言で言うと「人材活用に必要なデータによる意思決定や、PDCAサイクルを回せるサービス」だと大谷氏は言う。
「『人材採用』の段階から、入社後の『パフォーマンス』の計測・評価、『エンゲージメント』による従業員のモチベーション向上まで、3つの領域を連携させて管理ができるようになります。各々の評価と作業を紐づけ、採用後の人材の活躍を追跡し、評価結果を入社時にまでさかのぼって採用のパフォーマンスを測定するといったこともできます。将来的に、人事の各フェイズを通じたPDCAサイクルを継続的に回していける点が大きな特長です」
HRMOSのプラットフォームの中心は、従業員データベース 「HRMOS Core」だ。3つのモジュールをつなぐハブであると同時に、統合された人材データベースとして、人にまつわるすべてのデータを格納できる。
「HRMOS Coreの中で定義されているスキーマだけでなく、ユーザー自身が自由にデータ定義を行えるので、どんなデータでも必要に応じて格納できます。またWeb API経由で外部からもアクセスできるため、社外の保険・労務関係者などともデータの共有・活用が可能です」
クラウド型サービスの利点を生かして、複数の場所に分散している人材データの一括管理を実現。またロールベースによる詳細なアクセス権管理や、更新・変更履歴の保存といった機能で、堅牢なセキュリティを担保する。さらに人事部門の単純作業を自動化するといった、注目のRPA機能までも提供していると言う。
DBマスタをHRMOS Coreに統合 データの転記などの手作業を解消
ビズリーチでは、HRMOS Coreを自社で導入して、人事業務フローの刷新・改革の成果を挙げていると大谷氏は明かす。ここでは人手に依存しているタスクをいかに効率化・自動化して、より付加価値の高い業務に労力を振り向けてゆくかが課題だったと言う。
そこで最初にトライしたのが、「人手によるデータのディスパッチ作業の撤廃」だった。それまでは各部署からリクエストが来るたびに、IT総務の担当者が必要なデータ形式に加工して渡していた。これを一気にHRMOS Coreで省力化しようというのだ。
改善は2段階に分けて行われた。
第1ステップ：複数あったDBマスタをHRMOS Coreに統合
従来は複数存在していたマスタがHRMOS Coreに統合され、データが欲しい人は直接HRMOS Coreにアクセスできるようになり、中間の手作業が不要になった。
第2ステップ：採用管理からAPI経由でHRMOS Coreに連携
第1ステップ完了後も、採用内定者が決まると、採用担当者が人事担当者に連絡を入れ、人事担当者はその情報をもとに内定者からデータを受け取ってHRMOS Core上に展開していた。また身上変更も人事労務がデータを受け取った後に、人事企画に連絡する2段階だった。
そこで追加された機能改善は、以下の3つ。
- 採用内定が決まると、採用担当者がWeb API連携でHRMOS Coreに直接データを入力＝データの転記作業が不要に。
- 内定者本人も、入社前にHRMOS Coreに直接アクセスして、自分のデータを自ら入力できる。
- 身上変更の場合も、人事労務が直接データ入力できるようになり、人事企画の転記作業が不要に。
現在もこのシステム改良は続けられており、「各部署に残っている手作業をすべてシステムに取り込み、完全自動化するのを最終目標と考えています」と大谷氏は語る。
クラウドとシンプルな技術でリスクの少ない開発環境を実現
セッションの後半では、HRMOS Coreの開発にあたって、どのように技術選定を行っていったかが紹介された。
技術選定の基本方針は、（1）クラウドのマネージドな構成管理、（2）シンプルな構成、（3）シンプルなアーキテクチャの3つだったと大谷氏は振り返る。
「プロジェクトが始まったばかりで、余計な手間やリスクをできるだけ事前に排除する必要がありました。その点クラウドならば、自分たちで構成管理を行う必要もなく、肝心の開発作業にエネルギーを集中できます。またシンプルなアーキテクチャは、不測の事態を回避するのに最適かつ容易な手段でした」
クラウドプラットフォーム：AWS
最初は、HRMOS Coreが動く環境＝クラウドプラットフォームの選定だった。ここではAWS（Amazon Web Services）とGoogle Cloud Platformの2つを検討。パフォーマンスを比較した結果、AWSを選択した。
人事データベース：Amazon Aurora PostgreSQL
次は、人事データベース＝HRMOS Coreの開発技術の選定だ。Amazon Aurora PostgreSQL／MySQLを両者を比較検討した結果、MySQLは分析関数に不安があった。一方PostgreSQLは、分析用に巨大なリードレプリカが作れるアドバンテージが評価された。
アプリケーションサーバー：AWS Elastic Beanstalk（ECSに移行予定）
サーバーの選定では、従来のアプリケーションサーバーにするのか、マイクロサービスに挑戦するのか議論があった。しかしまだプロジェクト初期で、モジュール・データの依存関係が見えないことや、何よりエンジニアの熟練度を考慮して、アプリケーションサーバーを選択した。アプリケーション管理には、AWS Elastic Beanstalkを採用したが、将来的にAmazon Elastic Container Service（ECS）に移行する予定だ。
「この他、ユーザー認証にはAmazon Cognitoのユーザープールを使用しました。採用理由としては、自前でパスワード管理を行わずに済むこと、リスクベース認証などをマネージドサービスとして管理できるといったメリットが挙げられます。また、入社日や最終出社日などに合わせてデータベース変更などを自動で行うRPA化の機能には、AWS Lambdaを使っています」
Javaのスキルが生かせるKotlinをAppサーバーの開発言語に採用
今回のプロジェクトのトピックスの一つが、アプリケーションサーバー開発に、オブジェクト指向プログラミング言語の一つであるKotlin（コトリン）を採用した点だ。Kotlinは、言語自体はJavaとはまったく別のものでありながら、コンパイルされたコードはJava VM（virtual machine）で動かせるため、Javaのコード資産やスキルセットが生かせるのが大きな特長だ。
「当初の開発チームはもともとJavaがメインで、最近のプロダクトではScalaを多く使ってきました。こうした自社のスキルセットから考えて、Javaに近い言語が好ましいということでKotlinが選ばれました」
Kotlinには、Javaのエンジニアが学習しやすいという利点もある。JavaエンジニアがいきなりScalaを学ぶのは難易度が高いが、KotlinはJavaとScalaの中間的な言語なので、ビズリーチの技術陣にとっても学びやすい点が高く評価された。
また今回のプロジェクト経験から、大谷氏は「開発言語は、できるだけ統一させることが望ましいと実感した」と言う。その具体的な効果としては、学習コストの低減に加え、2つの異なる環境でロジックの再利用が可能になり、開発効率そのものが向上するといったメリットが挙げられる。
現在Kotlinで記述しているのは、アプリケーションサーバーとAWS Lambdaの部分だが、ここでの経験の蓄積が推進力となり、最近では社内の他のプロダクトでもKotlinを使い始めていると言う。
「とりわけ新規のプロダクトでは、最初からKotlinでいくケースも増えてきました。今後はこうした動きをさらに活性化させ、より効率化と省力化を進めながら、品質の高いサービスの開発体制を固めていきたい」と大谷氏は抱負を語り、セッションを締めくくった。
現在は、Kotlinをアプリケーション サーバーとAWS Lambdaの部分の記述に利用している
お問い合わせ
株式会社ビズリーチ
