「仕組みを変えれば、世界はもっと良くなる」をビジョンに掲げ、日本の伝統的な産業に次々と革新を起こし続けるラクスル株式会社。

印刷・広告のシェアリングプラットフォーム「ラクスル」、物流シェアリングプラットフォームの「ハコベル」を展開し、2018年5月には東証マザーズ上場を果たしています。

2009年の創業以来、驚くべき速度で企業成長を続ける同社。その裏側には、競争力の源泉たる人事を支える労務の活躍があります。

入社から約4年、急成長を後押ししてきた人事総務部の松田 智美さんにお話を伺いました。

松田さん：2018年10月時点で217名です。

松田さん：労務手続きを担当しているのは私1人です。あとは、重要なポイントのダブルチェックだけ上司を通している状態です。

入社時は労務以外にも総務にも携わるなど、もう少し業務範囲が幅広かったのですが、従業員数が増えるにつれ人事制度の整備など、労務にかける比率が高まっていきました。現在では労務の専任になっています。

松田さん：従業員数が増えるとともに、紙作業も増大しており手続きの電子化を進めたいと思っていました。

また、それ以外にも大きな課題があったんです。人事の中でも様々な担当者がいるのですが、皆が皆社員情報を別々で管理しており、Excelやスプレッドシートが点在していました。

さらに従業員間でも、顔と名前が一致しないなどの課題が顕在化するなど、人事データベース（以下「人事DB」）の必要性を各所で感じていました。

松田さん：まず、散らばった人事情報の中で、どれを正として管理していいかわからない状態だったため、その対策として一元管理していくために、従業員情報検索もできる人事DBを自社で内製しました。

一方で、この人事DBのマスタとなるサービスが同時に必要でした。

その中でSmartHRは、求める機能を抑えていただけでなく、非常にデータを取り出しやすいAPIを公開しています。このAPIを我々が内製した人事DBと連携させ、PoC（Proof of
Concept；概念実証）したところ、非常に使いやすかったんです。

さらに、デザインやユーザーインターフェイス（以下、UI）も見やすいなと感じました。これもひとつの決め手になっています。実際に人事DBを運用していくには従業員まで含めて「使いやすいかどうか」を非常に重視していました。そもそもの入口となる従業員情報収集をしっかりと行うには何より従業員が使いこなせるかが大切だからです。

松田さん：SmartHRの導入自体は私が担当しましたが、人事DB開発やAPI連携は、情報システム部門のメンバーにプロジェクトマネージャー（以下、PM）を担ってもらいました。

PMとともに週1でミーティングを実施して要件を洗い出していき、要件定義後はPMとエンジニアが一緒になって機能開発を進めていきました。

松田さん：あまり時間はかからなかったですね。SmartHR自体のPoCに1ヶ月、その後実際に人事DBの作成で2ヶ月ほどなので、連携リリースまでの合計期間は3ヶ月ほどでした。

松田さん：PMやエンジニアからは、技術的に難しかったポイントは無いと聞いています。一方、しっかり運用できるよう、レギュレーション策定はトライアンドエラーを重ねました。

例えば、「SmartHRと人事DBを紐付けるために、どの情報を個人のユニークキーにするのか？」などです。

当初、SmartHRから人事DBにデータ連携する際、個人のユニークキーとしてメールアドレスにしていたんですが、入社前に個人のメールアドレスだったものを、入社後に会社のメールアドレスに変えるとうまく連携できなくなってしまったんです。

「じゃあ、社員番号をユニークキーにしようか」となったんですが、今度は社員番号を発番していない新入社員を登録するにはどうしたらいいかな……という話にもなり。

従業員情報の中で最も不変な情報は社員番号という認識で、最終的には、「社員番号」をユニークキーとしました。

松田さん：入社手続きフローを見直しました。以前はSmartHRへの情報登録タイミングを定めていませんでしたが、現在は社員番号発番後にSmartHR登録する流れを徹底しています。

松田さん：当初、人事DBからSmartHRにデータを戻さないようにしていました。人事DBでデータを書き換えた後にSmartHRに戻そうとすると、マスタとなるSmartHRのデータがぐちゃぐちゃになってしまうためです。

でも、「運用していくにはデータの書き換えは必要だね」という考えに至りました。例えば、8月1日にマネージャーに昇格する人を8月1日に設定するのでは遅い、でも先に変わってしまっても困る。だから事前に予約設定しておいて、実際に変更されるのは8月1日にしたい。とはいえ現状SmartHRに予約変更機能はないので自社の人事DBに実装させたい。

このような人事労務の要望のもと、人事DBに予約変更機能を実装してもらいました。実装後は、人事DB側で書き換えられたデータをSmartHRに戻すレギュレーションにしています。

松田さん：特に課題やトラブルもなく、順調に運用できています。連携前に定めた要件と導入後の実情とで色々変わる部分がでてきたものの、トライアンドエラーを重ねてうまく運用レギュレーションを策定できたと思います。

松田さん：基本的には従業員情報の検索システムとなっています。組織図などもこちらから閲覧できます。

そのほか、従業員ごとのマイページもあり、こちらにはSmartHRのカスタム項目も紐付けられています。例えば、エンジニアのGitHubアカウントなどもこちらに記載しています。

松田さん：はい。管理職だけ閲覧できる情報など、権限ごとに区分けています。また、表示される情報としても上手くコントロールできるよう「ディスプレイオン」「ディスプレイオフ」という機能もあります。

これは何かというと、例えば5月入社予定の方を事前登録してはいるものの、一覧には表示させたくない時は「ディスプレイオフ」に設定します。同様に、入社が決まっているけど前職との退職交渉中で、入社する情報自体を隠しておきたいという方のためにも活用できます。

制御自体は人事DB上で行っているため、従業員情報検索の一覧には出ないものの、SmartHR上にはデータとして登録している状態です。

松田さん：評価システムや端末管理システムなどの開発を予定しています。SmartHRをマスタとしつつ、API活用を通して今後も様々な機能開発を検討中です。

松田さん：拠点が東京と京都とで分かれていて、これまでは京都の従業員については書類郵送で対応していましたが、SmartHR導入後はオンライン上で実施できるのが嬉しいです。

松田さん：外国籍の従業員が増えていますが、ビザ情報を入力してもらうにも、外国人従業員用に従業員招待フォームをカスタムし、日本人従業員と使い分けられるのでとても便利だなと感じています。

あと、電子申請機能が非常に便利ですね。住所変更にも対応しておりありがたいです。

松田さん：そうですね。最初に取得したのは2017年で、当時はe-Govの電子申請を使用していましたが、ここにデータを打ち込んでいくのは大変でした。SmartHR導入後は、マスタとして存在している従業員情報をそのまま活用できるため、効率的に電子申請できるようになりました。

松田さん：月間40時間ほどの工数削減に繋がったかと思います。導入以前は色んな事務作業に追われていましたが、今は“考える仕事”の時間が増えたのが嬉しいです。

また、マスタとしてのSmartHRを活用しつつ、人事DBや評価システムを内製化し組み合わせることで、月額約80万円、年間にすると約960万円のコストメリットに繋がっています。

松田さん：採用人数も従業員数も増え、自社の人事制度をアップデートする時期が来ていると思います。

例えば勤務時間。就業規則上の定時は9時〜18時ですが、フレックスタイムとして10時から19時という勤務も可能としました。その後、「エンジニアにしてみたらフルフレックスのほうが働きやすいのではないか
」などの議論が生まれ、現在は一部雇用形態を対象にフルフレックスタイム制度を導入しています。

サービスづくりをしていく上で、エンジニア採用は重要な注力ポイントですので、他社と比較されても負けないような体制を築くためにも、労務から後押ししていきたいと思っています。

松田さん：そうですね、おっしゃるとおりです。

松田さん：導入サポート時に丁寧にご対応いただけたのに加え、ウェブ会議だったのが嬉しかったです。対面するのが難しい日に会議予定があったんですが、ウェブ会議だったため問題なく実施できました。

松田さん：また、チャットサポートの方々にも、いつも丁寧かつスピーディにご対応いただき助かっています。チャットだと、返信を待ってる間に他の従業員から話しかけられたとしても柔軟に対応できますし、並行して作業も可能なので便利ですね。

松田さん：機能も開発スピードも「Smart」なことだと思います。

また、情報システム部門からのおすすめポイントとして、「SmartHRのデータはシンプルで取得しやすく、非常に優れたAPI」だと聞いています。

どんな企業でも、どのようなツールを使ったとしても100％理想とマッチするのは難しく、それを実現しようと思うとツール内製化が最終手段になります。その点、SmartHRはAPIを活用しやすいため、内製ツールとうまく組み合わせることで、より効率的で柔軟なシステム基盤構築と、理想の人事体制実現に近づけるのではないでしょうか。