SmartHRのAPI活用で「人事システム内製化」を実現。コスト削減効果 年間約960万円

内製の人事DBとAPI連携できる「人事マスタ」が必要だった

従業員数を教えてください。

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

人事総務部で現在労務をご担当されているのは何名でしょうか？

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

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

事業としてはもちろん、人員規模としてもここ数年で急成長されています。SmartHR導入前の人事労務における課題とリンクしているのでしょうか？

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

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

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

最終的にSmartHRをお選びいただいた決め手は？

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

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

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

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

情シス部門が人事DB開発とAPI連携を主導し、約3ヶ月で実装

SmartHRの導入から、人事DBとのAPI連携はどのように進めましたか？

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

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

SmartHRと人事DBのAPI連携が、本格的に運用スタートするまではどれくらいの時間がかかりましたか？

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

内製の人事DB「CORP DIR」（画像提供：ラクスル株式会社）

API連携と人事DB構築は「運用レギュレーション」のトライアンドエラーが重要

運用開始時に苦労したことはありますか？

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

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

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

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

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

社員番号発番前の新入社員登録については、現在どのように対応されているのでしょうか？

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

ユニークキー以外に、運用レギュレーションの策定で大変だったことはありますか？

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

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

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

ありがとうございます。SmartHR導入後、API連携を活用した人事DB運用上の課題はありますか？

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

なるほど、運用レギュレーション策定にあたっては、実情に即して定めるのが重要ということですね。

従業員情報検索システムとの連携を実現。今後は人事評価システムも開発予定

人事DBの機能特徴について教えてください。

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

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

閲覧権限は細かく管理されているのでしょうか？

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

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

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

人事DBのほか、今後開発を予定している内製ツールはありますか？

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

リラックスできるコミュニケーションスペースと、温かみある木目の会議室やリフレッシュスペース。
天井高12メートルにおよぶ開放的な空間は「空中庭園」がモチーフになっているようです。

SmartHRのAPI活用と人事システム内製化。コスト削減効果、年間約960万円

SmartHR導入後、どのような変化がありましたか？

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

お気に入りの機能はありますか？

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

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

電子申請ご利用にあたっては、電子証明書を松田さんが取得されたのでしょうか？

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

SmartHR導入前と比べて、どれくらい業務効率化に繋がりましたか？

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

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

“考える仕事”の時間が増えたとのことですが、具体的にどのような内容でしょうか？

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

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

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

採用競争力、ひいては企業競争力を高めるために、「採用は採用、労務は労務」と分断して考えるのではなく、人事総務部一丸となって取り組んでいるんですね。

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

API活用による柔軟なシステム基盤構築と、理想的な人事体制の実現へ

そのほか、SmartHRへの感想があれば、ぜひお願いします。

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

インフルエンザ流行時期や花粉が飛ぶ季節などでも、外出に伴うリスクをお互いに減らせますしね。

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

ありがとうございます！ 最後に、SmartHRのおすすめポイントを教えていただけますか。

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

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

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

松田さん、素敵なメッセージをありがとうございました！