人事労務ソフトで求められる3つの技術的工夫　登録社数3万超えの「SmartHR」開発の勘所

人事労務が「集まって・蓄まって・活用できる」クラウド人事労務ソフト「SmartHR」

芹澤雅人氏（以下、芹澤）：それでは始めます。「クラウド人事労務ソフトウェア開発の勘所」というところですね。株式会社SmartHRのCTOを務めています芹澤から発表します。どうぞよろしくお願いします。

簡単に自己紹介をします。改めまして、芹澤と申します。株式会社SmartHRという会社で、「SmartHR」というサービスを作っています。私自身は、新卒以来ずっとWebアプリケーションエンジニアとしてキャリアを歩んでいて、SmartHRには2016年1月の、サービスがローンチされた直後ぐらいに参画しています。

長いこと開発業務に携わってきたのですが、2019年1月にCTOを拝命して、そこからはプロダクト開発・運用に関わるチームの全体の最適化だったり、ビジネスサイドの要望調整だったりをメインでやっています。

最初に、簡単にSmartHRのサービスの紹介させてください。SmartHRは、人事労務が「集まって・蓄まって・活用できる」というクラウド型ソフトウェアです。これは誰かが入社する時のやることリストみたいな感じで、SmartHRやクラウドソフトを使わないとけっこうやることがいっぱいあるのですが、SmartHRを使うと、かなりステップを省略できます。

ちょっと細かく見ていきます。まず内定が決まった従業員本人に、必要な個人情報や諸々の情報を入力依頼できます。紙やExcelで添付して送ることがよくあるかもしれませんが、そういった情報収集の手間がかなり省略されます。書き漏れが生じることがかなり少なくなって、やり取りの往復も削減されます。

手書きと比べて、95パーセントも時間の短縮になっているというデータもあります。また、ハローワークや年金事務所の労務担当者が多くの書類を提出しているのですが、そういった提出する書類を自動で生成する他、電子政府に対応しているものはサービス上から電子申請を行うことで、役所などに行かずにすべての書類が完結できます。

従業員が打ち込んだ諸々のデータは、SmartHR上のデータベースに反映されます。よく会社で個人情報を扱うExcelがあると思うのですが、そういったものがSmartHR上で一元管理できます。

その他、給与明細、賞与明細、源泉徴収票という働いていればよく目にするものも、SmartHRのサービス上で行えて、すべてペーパーレスで閲覧・配布ができるようになっています。また、配布ミスなどのセキュリティリスクの防止にもつながっていて、これはかなり好評をいただいています。

あとは年末調整の機能にも力を入れています。みなさん年末に、紙に小さい文字をいっぱい書いたことがあると思うのですが、Web上で、はい・いいえとアンケートに答えるだけであっという間に完了させられるというのが、このペーパーレス年末調整の機能となっています。

このような機能を提供していて、2015年11月に公開しているのですが、おかげさまで登録社数が3万社を超えていて、99パーセント以上のお客さまに継続利用をしていただいている状況です。導入している企業も小売、飲食、IT・EC、人材派遣・BPO、スポーツ、製造・卸売などで、大小さまざまな規模、かつ分野もさまざまなお客さまに幅広く使っていただくまでに進歩しています。

「SmartHR」開発においての技術的な工夫や勘所を3つ厳選

本日はSmartHRを開発するうえで求められる技術的な工夫や勘所についてお話しします。私は最近いろいろ登壇していて、組織論、マネジメント論、エンジニアのキャリアみたいな話が多かったのですが、今日はそういう話は抜きにして、けっこう技術よりのお話ができればなと思っています。久しぶりなのでけっこうドキドキしています。

伝えたい工夫がたくさんあるのですが、今日は15分という短い時間しかないので、厳選したトピックについてお話ししようと思います。ちょっと駆け足になるかもしれませんが、3つ厳選してお伝えできればと思います。

技術的な工夫その1　履歴管理

1つ目が履歴管理ですね。人事データベースに求められることでこんなことがありますよ、というので、ある時点でのデータを一覧で参照したい。先月の従業員一覧と、その情報を見たい、ですね。ほかにも、この人は実は〇月〇日時点で、こういう給料をもらっていたので修正したいですとか、さらに過去の履歴を修正した更新情報も残っていてほしいとかですね。

さらに言うと、この人は来月異動するので部署を入れておきたいとか、そういった未来のものもあります。けっこう時間軸が求められるんですね。

一般的なシステムにおけるレコードの更新処理はこんな感じです。例えば4月1日入社の新宿太郎さんという方がいて、この方が7月1日に姓が渋谷に変わるとすると、素直に考えたらだいたいこんな感じになるんですよね。

姓というフィールドが更新されて、作成日はそのままで、更新日がアップデートされるというのが、Railsで普通にアプリケーションを作った時のタイムスタンプの管理になると思うのですが、SmartHRにおける更新処理はけっこう違っていて、同じケースを想定すると、こんな感じで複雑なレコードが生成されます。

全部で3つになるというか、2行増えて1行そのままみたいな感じです。これを細かく説明すると、あっという間に15分が過ぎてしまうので、今回は説明しませんが、これはBiTemporal Data Modelというデータ構造を採用しています。

BiTemporal Data Modelは、2つの時間的なという意味です。2つの時間とは何かというと、有効時間とシステム的な時間という、この2つのことを指します。こういった2つの時間軸を別々に管理可能なデータモデルとなっています。

実世界では何月何日まで姓が新宿で、何月から渋谷に変わったというのがわかるし、システム上で何月何日に書き換えられるかという、この2つが両方ともきちんと管理できるようになっているんですね。なのでタイムスタンプが2個ずつあるイメージになっています。

BiTemporal Data Modelはけっこう専門的なので、詳しく知りたい方はこちらを見ていただければと思います。

SmartHRでは、現在40を超える数のモデル、テーブルがこのBiTemporal Data Modelの構造をとっています。その多くのモデルが関連を持っていて、複雑に組み合わさっています。参照や更新をする時には、それらのデータを時点を考慮したクエリを発行するのはもちろんですが、例えばバリデーションとかですね。これはデータとして有効なのかみたいなのを発動する際にも、時点の考慮が必須となっていて、けっこう難しいんですね。

SmartHR社ではいくつかのプロダクトを作っているのですが、全部Railsが採用されています。各アプリでこういった時点考慮のクエリを書くのはかなりツライし、Railsの標準機能では完全にないので、ActiveRecordを拡張するというけっこう危なかっしいGemを、OSSとして開発していたりします。

そんな感じでけっこう激しく履歴管理をやっているのですが、もちろん、ものによってはBiTemporal Data Modelを使わずに、もうちょっとライトに履歴管理をするのも可能です。履歴の特性として、あとから拡張して保存する仕組みを追加しても、それ以前に発生していた履歴は復元できないという特性があります。失われてしまうんですね。

また多くの場合、データ構造の抜本的な部分に手を加えることになるんですね。なので、データのトレーサビリティが求められるようなプロダクトにおいては、早めに履歴管理の設計を検討しておくといいなというのは勘所としてあります。

人事労務系のソフトウェアを作ると、必ずこれを言われるので、検討されている方は覚悟をしておくといいかなと思いますし、BiTemporal Gemは一般的に公開されているので、もしよかったらご利用いただければと思っています。

技術的な工夫その2　権限管理

次は権限管理ですね。権限はいろいろなサービスにあって実装したことがある方も多いかもしれませんが、権限あるあるみたいなところで、AdminとMemberみたいなものを最初に作るんですね。これらを区分値で定義して、随時 if admin? みたいな制御を入れて、管理者向けの機能とそうじゃない機能を分けることがあると思います。

「あぁ、なんかぜんぜんできるじゃん」と思っていたのですが、サービスを拡大していくと、この区分値の表現に限界が来て、こういう権限がほしいとか、もっとカスタマイズしたいというのがすぐにくるんですね。それを実直に応えると、カスタム権限設定みたいな概念が誕生するのですが、これを作ると各所に作っていた if admin? を駆逐するという作業が待っています。だから権限という作業は本当にドキドキするんですよね。

漏れがないかとか、体力的にも精神的にも苦しい作業が行われる。これはけっこう経験した人が多いんじゃないかなと思います。

権限適用は3つの観点があります。これはけっこう一般的に導き出されている解ですが、1つが機能の制限。これはそのユーザーのどの画面にアクセスできるのか、どの機能が使えるのか。参照のみなのか、更新もできるのかみたいな機能自体の制限と、あとは範囲の制限です。

誰のデータにアクセスできるのか。例えば自分の管掌する部署のメンバーのみなのか、はたまた全メンバーなのかとか。あとは属性の制限ですね。誰のデータにアクセスして、どの項目が見られるんですかというところです。一般的な名前だけなのか、所得や家族といったちょっと踏み込んだデータも閲覧可能なのかという、この3つの掛け合わせで権限機能が成り立つと考えていただければ間違いありません。

SmartHRの権限設定は、今でこそこれらが全部満たされていますが、最初からそうだったわけではありません。例に漏れず、区分値による権限設定から始まって、そこからカスタム権限設定へと変わっていくという歴史を歩んでいます。

いわゆるRole-Based Access ControlというRBACから、ABACと言われるAttribute-Based Access Controlに変わっていったのがここら辺です。その後は機能の制限、範囲の制限、属性の制限と、順に拡張していったのですが、最初から完璧に作ったのではなくて徐々に複雑にしたという歴史があります。

そういった酸いも甘いも経験したところから権限設計の勘所を言うのですが、権限のジレンマとして、シンプルなほうがユーザーの初期設定が楽なんですよね。ユーザーとしてもシンプルなほうがうれしい。ただディープに使おうとすると、確実に詰まる。一方で複雑なほうは、ユーザーの初期設定がメチャクチャ難しくなるし「うっかり見えちゃった」みたいな事故率も増えますが、ディープに使えます。

利用者のユースケースを踏まえつつ、シンプルさと複雑さのバランスを常に取って調整していくのが良いと思います。ただ注意点として、内部的にはある程度拡張性を見込んで作っておかないと、あとからこういった拡張をしたいとなった時に必ず地獄を見ます。なのでこれから権限を作っていく場合は、早めに考えておくといいかなと思います。

技術的な工夫その3　ドメイン知識・業務理解

次にドメイン知識・業務理解ですね。さっきのプレゼンでもけっこう質問があったかなと思うのですが、SmartHRも「みなさん入社前から人事労務の知識を持っていたんですか？」という質問をよくされるのですが、回答としては「ほとんどの人が何も知らない状態で入社して、業務を通して知識を付けていきます」という感じです。

人事労務のドメイン知識は何があるかというと、社会保険制度に関する知識だったり、さっき冒頭で説明したような書類の知識の内容と役割だったり、あとは人事労務担当者の年間スケジュールとか、覚えることはけっこうあるんですね。とはいえ、理解するのにメチャクチャ専門的な知識がいるわけではなくて、ググればけっこう解説も出てきます。

ただわりと細かくアップデートが入ってくるのと、仕組みを知ったとしても人事労務の現場や業務がわかるわけではないというのは、けっこう厄介かつ難しいポイントです。

僕の好きなネタなのですが、これは年末調整でいわゆるマル扶と呼ばれる書類です。書いてる側は気づかないかもしれませんが、これ、毎年地味にアップデートが入っているんですよね。この項目がこっちにズレたりとか、項目が減ったり増えたりするので、毎年追従していかないといけないし、新しいマル扶がわりと直前に発表されたりするんですよね。けっこう大変です。

どうやってそういう知識を吸収しているかというと、ドメインエキスパートという方が今はいます。人事労務のドメイン知識をプロダクトチームに還元していく人たちです。スクラムメンバーの一員としてチームに属していて、企画や開発、テストやヘルプページの作成など、いろいろなシーンで活躍してもらっています。

こういった方々を通してチーム全体のドメイン知識が底上げされて、安心・安全にソフトウェアの開発ができるようになっているんですね。ドメインエキスパートについてもいろいろな深い世界があるので、ぜひこちらの記事を見てもらえればと思います。

ユーザー体験や感覚を取り入れる施策

もう2つほど観点があって、1個はユーザビリティテストです。SmartHRの開発の性質として、開発している人たち自身がユーザーとしてほとんどの機能に触れないことが多いんですね。こんな状況下でユーザー側の体験や感覚を考慮してプロダクトに反映させていくために、ユーザビリティテストをやっています。

これは社内のいろいろなメンバーに協力してもらって、リリース前の機能を触った操作感などを率直に評価してもらうという取り組みです。こんな感じで、今はZoomで開催しているのですが、しゃべりながらいじってもらいます。「これはこっちなんですね」とか、「これはどこにボタンがあるんですか？」というのを言ってもらって、初めて見た人がどういう感想を抱くのかと、きちんと使えるのかというところを見ています。

毎回リンクの紹介になってしまって申し訳ないのですが、こっちの記事に詳細があるのでぜひ見てみてください。

もう1個、スプリントレビューにユーザーを呼ぶということもやっています。さらにユーザーの体験や感覚を色濃く取り入れるために、毎週やっているスプリントレビューに、たまにユーザーをお招きするという施策もやっています。開発途中の機能に対して実際に業務に使う方からのフィードバックを取り入れて、リリース時点での品質を高めています。

こちらもZoomで開催しているのですが、実際にユーザーの方に触ってもらっています。「こういうのを作りました。触ってみてください」とやっています。

こういった取り組みも、記事があるのでぜひ見てもらえればと思います。

ドメイン知識・業務理解の勘所ですが、SmartHRでも初期の頃はエンジニアや作る人が主体となってドメイン知識を吸収してプロダクトの開発をしていました。ただしプロダクトやユーザー規模が拡大してくると、要件の複雑さだったり専門性だったりが増してきて片手間でのキャッチアップが難しくなります。

手段はいろいろあると思いますが、常にユーザーファーストな感覚を持って開発を続けるために、こういったドメイン知識や業務理解を深める仕組みはなるべく早めに構築していくといいかなと思います。

最後、Internet Explorer対応はどうやっているかというのをしゃべろうと思っています。業務ソフトウェアを作っていくうえで切り離せない存在かと思うのですが、実は最近（※取材当時）「IE対応を終了します」というお知らせをして、無事に弊社はIE対応の苦しみから解放されました。

業務ソフトウェアとして日本のDXを推進していきたいですねというところで締めさせていただくのですが、最後にSmartHR社ではWebアプリケーションエンジニアを大募集していて、このプレゼンを聞いてSmartHRの雰囲気がちょっとでも伝わったかなと思うので、興味を持った方がいたら、カジュアル面談からの対応も可能なのでぜひ「SmartHR 採用」で調べてもらえればと思います。

駆け足になってしまったかもしれませんが、ご清聴ありがとうございました。