ラクスの人事労務システム「楽楽人事（旧・楽楽労務）」は、2022年に惜しくも新規開発停止となりました。一方で意欲的な技術的挑戦も多々あったプロダクトだと思います。改めてその技術選定から関わった大平さんに、開発にかけた思いや次へ活きた知見を伺っていきたいと思います！

大平さんご自身について、簡単に自己紹介をお願いします。

2013年にラクスに入社し、気付いたらちょうど10年になってしまいました。当時、海外進出を目指して北米向けのソーシャルメディアマーケティングサービスを開発しており、チャレンジできそうで面白そうだなと思って応募しました。その後、いまやCMでおなじみの楽楽精算や、今回ご紹介いただく楽楽人事などいくつかのサービス開発に携わっています。開発チームでは、テックリードとして技術的な意思決定や開発のベースとなる仕組みづくり、メンバーのコードレビューなどに軸足をおいて活動することが多いですね。

業務外では、あまり趣味が多い方ではないので、本を読んだり、山歩きをしたりといった感じでしょうか。収集癖があるみたいで、マンホールの絵柄が気になってからは、旅行などにいくとマンホールを探してしまいますね。最近、ミャクミャクさまのマンホールを見つけてテンションが上りました。

楽楽人事について、簡単に紹介いただけますか？

楽楽人事は、人事・労務に関する業務を効率化するための、クラウド型のサービスです。入社時に必要な情報を入社予定者からWeb上で収集したり、社会保険手続きの届出書を自動作成したりと、これまで紙に手書きベースでおこなっていた業務をシステム化して、人事労務担当者の手間を減らすことができます。また、従業員の情報を一元管理できるので、人事データベースとしてもお使いいただけます。残念ながら2022年に新規販売が終了となってしまい、お客様にはご迷惑をおかけしてしまいました。

当時の楽楽人事開発チーム内での役割を教えてください。立ち上げ期から技術選定に関わられたのでしょうか。

はい。厳密には法要件の確認や実行基盤の検討に先行着手してくれていたメンバーがいたのですが、2018年のプロジェクト開始当時から具体的な技術スタックの選定に関わったという意味では、初期メンバーと言って差し支えないのかなと思います。リリースを重ねてチームが大きくなるにつれてチームのリーダーや外部設計など他の役割もするようになりましたが、立ち上げ期はメンバーも数人だったので、技術選定だけでなく、開発プロセスの整備から実装、テストまでそれこそ何でもやりましたね。

楽楽人事の技術はモダンなものが選定された印象です。選定思想や導入目的、最終的に選ばれた技術スタックを教えてください。

そうですね。当時のメンバーの想いが詰まり過ぎていたと冗談を言われるぐらいには、想いが詰まっていたと思います。当時からラクスにはビジネス的に成功したサービスが複数ありましたが、開発者としては積年の技術的な負債や変更の難しさに苦労していました。バックエンドでビューをレンダリングして返す昔ながらのWebアプリケーションになっていて、テストコードも少なく、開発環境を準備するのも一苦労といった感じです。そういった課題感をメンバー全員がもっていたこともあって、新サービスを機に「売れているけどレガシーなサービス」でもなく、「モダンだけど売れていないサービス」でもなく、「モダンで売れているサービス」を目指してやるぞ、という想いは強かったです。持続的に変更し続けられるシステムを目指して、技術スタックの刷新を試みました。

とはいっても最先端の技術を詰め込んだというよりは、すでに世の中で広く受け入れられていた技術に追いつこうとしたという方が感覚的には近いかなと思います。インフラ変更の柔軟性やインフラリソース調達の早さを重視して実行基盤にはAWSを、実装技術やミドルウェアをアプリ開発者が選択しやすいようにコンテナを、バックエンドとフロントエンドを疎結合にするためにREST APIによるSPAを、継続的な変更を支えるためにユニットテストを書く前提の開発プロセスを、と順当に決まっていったと記憶しています。細かい技術要素は挙げればきりがありませんが、フロントエンドはJavaScript + Vue.js + Vuetify、バックエンドはJava + Spring Boot + Doma2、あたりをメインに選択しました。

技術選定についてエンジニアチーム内で工夫された具体的トピックがあれば、紹介いただけますか？

2018年当時の判断としてあえて外したものはありますね。例えば、TypeScriptは今なら無条件で採用すると思いますが、当時はReactではなくVue.jsを採用したこともあって、Vue.jsとの組み合わせやノウハウ不足の懸念から避けました。最初はコードベースも小さいので、必要なら初期リリース後に書き換えられるだろうぐらいに考えていたというのもありますが、この点は当てが外れましたね。

あとはKotlinも候補には挙がりましたが、社内にも社外にもJavaエンジニアの方が多いので、JVM系を採用するなら無難にJavaの方がチームをスケールさせやすいのではないかという話になって見送りました。アンテナ感度の高いエンジニアにはむしろKotlinの方が採用で響くのでは、という話も出るには出たのですが。

コンテナやフロントエンドフレームワークなど何と言われようと今回新しく挑戦するぞという部分と、とはいえ短期的な開発スピードを優先して妥協というかバランスをとるぞという部分と、開発者の想いだけが先行しすぎないように考えたつもりではあります。

このような議論はチームメンバーで発案して進めたのでしょうか？

はい、そうです。何を作るかは製品企画など開発外のメンバーと議論して決めますが、どう作るかは開発に一任されていますので。大きく費用がかかる場合には予算調整が必要ですが、そうでなければ開発者が自分たちに合った技術やツールを話し合って決めますね。TypeScriptやKotlinをどうするかという話は初期メンバーで立ち話しながら決めたような記憶がうっすらあります。スペシャリスト志向のエンジニアの役割も整備されてきているので、楽楽人事に限らず、どのチームでもテックリードやリードエンジニアを中心として技術判断することが多いのかなと思います。

また、ラクスのサービスは一度作って終わりではないので、立ち上げ時だけでなく、新しい機能を開発するたびにこういった議論を繰り返していくことになります。ある機能開発で専用サーバーを立てるよりAWS Lambdaの方がうまく対応できそうな要件があって、そのときはデータ量やコストを試算して開発から提案したりもしましたね。

新たな技術スタックで進めてみて、メリットを感じたことはありますか？

技術選定したときに狙った効果はおおむね得られたのかなと思います。Vue.jsであればjQueryが主流だった頃と比べてUIコンポーネントの部品化・再利用が格段にしやすくなりましたし、コンテナであればアプリ開発者側でコントロールできる範囲が増えて、コンテナイメージだけをインフラチームに渡せばよくなりました。AWSを採用したことで文字通り秒でサーバーリソースを確保できるようにもなりました。自動テストを書くことをチームのルールとしたことも、バージョンアップを繰り返す中でのデグレ検出や内部品質維持に大いに役立ってくれたと考えています。

あとは、開発者が使いたい技術を使った方が楽しいし、モチベーションが上がるというのが、何だかんだで一番大きいのかなと思います。自分たちで選択した技術であれば、うまくいった場合だけでなく、うまくいかなかった場合にも責任をもって何とかしようとしますし。机上ではなく実際のプロダクトで使ってみた経験が次にも活きてくると思っています。

逆にデメリットと、それに対する対応策はいかがでしたか？

選択した技術自体の問題ではないですが、やはり立ち上げ期になかなか開発スピードが出なかったというのが一番の課題としてありましたね。対象領域の業務知識を増やしながら、新しく採用した技術もキャッチアップしつつ、新サービスなのでアプリケーションのベースとなる仕組みもあれこれ作らないといけません。既存の他サービスから流用できるとよいのですが、技術スタックを刷新しているのでそれもできず、地道に作っていくしかありませんでした。テストコードや内部品質をもっと妥協したら？という声もあって葛藤はありましたね。技術的な部分はどうしても習熟するのに時間がかかってしまうので、最終的には開発者を増やしたり、開発プロセスを軽量化したり、といった手段で調整しました。

結局、技術力がすべてだということを改めて痛感させられました。プロダクトとして提供する価値とか、プロジェクトの運営とか、もちろんほかの要因も色々あってサービスを軌道に乗せられなかったのだとは思いますが、それでも大前提として、作りたいものを早く作る力がないとどうしようもないなと。新しい技術を選択するのはよいし、やっていくべきだと思いますが、その選択を後悔がないように正解までもっていくことをセットで肝に銘じたいなと思いました。

採用した技術の知見（選定軸・設計のノウハウなども含め）具体的に次に活かされているものはありますか？

分かりやすい部分では、勤怠領域の新サービスとして楽楽勤怠を開発することになったときに、技術選定のスタート地点として参考にしてもらえたことがあるでしょうか。楽楽人事がリリースされたことで、新サービスを開発するときにゼロから考えないといけなかった部分は多少減ったのかなと思います。ただ、ラクスの場合は標準的な技術スタックを固定するといったことはしていないので、各サービスで適切と思ったものを自分たちで選択することになっています。なので、楽楽人事と楽楽勤怠を比べても、同じ部分もあれば違う部分もあって、個性が出ている感じですね。テストコードを書いたり、フロントエンドとバックエンドを分離したり、といった部分は当たり前に受け継がれていっているかなと思います。

あとは新しい技術やツールを先行検証する技術推進課が立ち上がって、その活動が本格化しました。楽楽人事だけが直接の理由ではないですが、サービスを立ち上げながら／新機能を追加しながら、先行技術にも投資していくというのは現実問題としてやはり大変なので、そういったミッションをもった組織をつくった形ですね。本音を言うと、私は自分たちのサービスに必要なものは自分たちで考えていくべきと思っているのですが、各サービスが抱える課題を吸い上げたり、新しい解決策を提案したりと、横断的に支援してくれるチームがいるのは心強いし、ありがたいです。

ありがとうございました。新しい技術スタックとサービスの成長スピードの両立は大変だったと思いますが、開発組織としては貴重な知見を得られたのではないかと思います。振り返ってみていかがでしょうか。

正直なところ、ショックが大きかったんですよね。エンジニア歴が長くても、自分が最初から最後まで面倒を見ることになったサービスは初めてでしたし、チームメンバーにも恵まれて4年間頑張ってきたので、すごく愛着もありました。売れるサービスにまで育ててあげられなくて申し訳ないという気持ちも強かったです。

正式に新規販売の終了が決まってちょっと落ち着いてから、今回選定した技術やツールがどうだったかのふりかえりを社内で共有しました。他サービスの技術選定に関わるメンバーを中心に多くの開発者が参加してくれて、それでようやく一区切りできたという気がしましたね。楽楽人事はこういう結果になってしまいましたが、他のサービスや今後続くだろうまだ見ぬ新サービスに何かしら残せていれば嬉しいですね。もちろん私も今回の経験を踏まえてまたチャレンジしていきたいと思っています。自動テストに寄せきった開発や、バッチサイズを小さくした軽量なリリースプロセスなんかも試してみたいですね。