【3周年記念】開発者が語るジョブカン労務管理の成長の裏側
執筆者：Taisei
ジョブカン労務管理開発にて2019年11月からインターン中。現在は主に新機能の実装を担当。
ジョブカン労務管理は2020年10月10日でリリースから3周年を迎えました。
ジョブカンシリーズの5サービス目となったジョブカン労務管理は、この3年間でのべ50万人以上に利用されるサービスまで成長しました。
本日は、ジョブカン労務管理の機能開発を担うエンジニアから4名の方にお越しいただき、ジョブカン労務管理のこれまでの開発の歴史についてざっくばらんにお話を伺います。
－ ジョブカン労務管理の3周年おめでとうございます。リリースしてからの３年間で50万人以上に利用されるサービスまで成長しましたが、リリース当初は大変だったと聞きました。当時はどういった状況だったのでしょうか。
Wei
座談会メンバーだと自分が一番古いですね。自分が開発に参加したときは、実は自分より前に労務管理の開発を担当していた方は既に辞めていました（笑）。
引き継ぎ等も不十分で、残った作りかけのソースコードを見ながらの開発だったので色々と戸惑うことも多かったです。
残されたコードを見ていくと、開発の方針はReactを用いてSPA（Single Page Application）で実装し、サーバーサイドはRuby on Railsで実装するといったものだとわかりました。
当時は自分ともう一人エンジニアがいたのですが、二人ともReactがわからない状態だったので、役割分担をしつつ一から勉強して開発を進めていきました。
少ししてからエンジニアがもう一人増えたので主に帳票周りの対応をお願いしていましたが、結局リリース時もエンジニアは三人体制でしたね。
－ リリース前後の様子についてもう少し教えてください。
Wei
自分が入社したのが2017年の4月で、リリースが10月なので、約半年かけて残りを実装しました。
何とか一通りの機能を実装してリリースしましたが、リリース後も問題はたくさんありましたね。
当時はタスクの分散や進捗の管理がしっかりと行われていないなど、チームとしての体制が整っていませんでした。
そのため、業務委託のエンジニアやデザイナーの方が働きにくく、人の入れ替わりが激しかったです。
それなのに、辞めた人の引継ぎが整っていなかったり、業務の属人化が進んでいたりして、負の連鎖になっていました。
－ リリース後１年くらいの時に今のリードエンジニアを務めるToshiakiさんが入社されましたよね。当時の様子はどうでしたか。
Toshiaki
Weiさんの話だと大変な時期もあったようですが、私はあまりそれは感じませんでしたね。
リリースからだいぶ時間も経って落ち着いてたんじゃないでしょうか。前に居た現場と比較するとエンジニアも多くて仲もよく、恵まれた環境だと感じました。
開発の面では、最初は電子申請機能を担当していました。
これまで労務管理でしか使えなかった電子申請機能を、シリーズサービスである「ジョブカン給与計算」で作成した帳票でも申請できるようにするためですね。
リリース当時の担当者も辞めていて、機能のメンテナンスも放置気味だったので、手を加えるところは多かったです。
今後の労務管理の開発スケジュール等も聞いて、将来的な拡張性も踏まえながら内部設計から修正をしていきました。
ちなみに、電子申請機能を開発するのって意外と難しいんですよね。
電子申請機能を開発する際に利用する外部連携APIは政府が公開しているんですが、開発者にとっても複雑な内容があり、最初は戸惑う部分も多かったです。
ただ、ユーザの利用状況を見ていると、当時からよく使われていた機能だったのでやりがいはありました。
－ 電子申請機能は途中からKazukiさんも開発に加わったと思いますが、どのような部分を担当されていましたか。
Kazuki
自分の入社時点で、既にToshiakiさんが設計を対応してくださっていたので、主に実装を手分けして担当しました。
全体的な構想が、電子申請機能部分を外部サービス化して、複数サービスからアクセスできるようにするというものだったので、自分は労務管理と電子申請機能をgRPCで繋ぐところを実装していました。
－ これまでは労務管理チームではgRPCを採用していなかったと聞きました。なぜ導入に至ったのですか。
Toshiaki
ジョブカンシリーズは、勤怠、労務、給与といった単位でコードが分かれており、独立したサービスとして設計しています。巨大な一つのチームではなく、小さなチームで素早く開発ができている反面、サービス間の連携コストが問題になってきます。
問題は2つあり:
- 通信規約など、開発者同士のコミュニケーションコスト
- システム同士の通信負荷
を、同時に解決する必要があります。そこで、これらの問題がより大きな規模で起こっている「マイクロサービスアーキテクチャ」で利用されているgRPCであれば、これらの問題を解決できると見込んで採用しました。
－ Daikiさんは新卒で入社されていますが、チームの雰囲気はどうでしたか。
Daiki
チームの雰囲気は和気藹々としていてよかったです。入る前はエンジニアってあまり喋らないイメージがあってちょっとビクビクしていたんですけど、初日から気軽に冗談の会話をできたりしていい意味で予想を裏切られました。
その一方で仕事に関してはちょっとでも最適化できる場所があったら妥協せず指摘しあって直すなど、より良いコードを書こうという意識がチームとして染み付いているなと感じています。
僕は一社目なので他社と比較できないんですけど最初にここで開発の仕事ができてよかったなと思っています。
－ 機能開発の面ではどういうものを対応されていますか。
Daiki
新卒で入社したタイミングでちょうど元号が「令和」になったので、最初の仕事はジョブカン労務管理で利用している全ての帳票を新しいものに変えるというものでした。
元号部分が変わるだけだと思っていましたが、それ以外のところも一緒に仕様変更があるものもあって結構大変でした…。
ただ、一通りの手続きを理解できたのは今となっては良かったと思います。
－ 入社して1年半ほど経つと思いますが、今はどういう機能を開発していますか。
Daiki
今はストレスチェックという新機能の開発をしています。従業員が一定数以上いる企業では年に１回国が指定するストレスチェックを行うことが義務化されているのですが、そのストレスチェックの実施や結果の管理などをサポートする機能になっています。
ストレスチェックは電子申請と同じく労務管理とは別のシステムとして作成し、労務管理とはgRPCによって通信を行なっています。
開発当初はまだ入社して１年程度で経験値としては少なかったと思うのですが、このストレスチェックという大型機能の開発を任せてもらえたのはとてもいい経験になりました。一方でやはり難しかった部分も多く、特に初期の環境設定ではgRPCなどの使い方を調べつつずっと試行錯誤を続けていました。
ストレスチェックは初期段階でも十分に使えるものだと思っていますが、今後さらに勤怠のデータと連携したり扱えるアンケートを増やしたりと様々な方面への拡張性を残す形で開発しているのでリリース後の機能拡張にも期待していただけると嬉しいです。
－ ジョブカン労務管理の開発チームは新しく入った方々が即戦力になっている印象があります。何か工夫はされていますか。
Toshiaki
現在では「ドキュメント化」を徹底しています。
代表的なものは以下の３つです。
・開発環境構築のドキュメント化
・運用手順書のメンテナンス
・設計資料のメンテナンス、アーカイブ
環境構築のドキュメント化ですが、具体的にはDocker Composeの設定に全ての情報をまとめるようにしています。
これによりDockerを利用しての環境構築がよりスムーズになり、エンジニアの受け入れ工数削減に繋がりました。
Kazuki
前職と比較して、環境がDocker Composeでまとまってるのは良いと思いましたよ。
こういう仕組みで環境を生成するようになっていると非常に運用しやすいです。
例えば、ソフトの導入手順とかが文書化されているけど、変更があったときにドキュメントの更新がされてないといった現象が減りますね。
Toshiaki
加えて運用手順書のメンテナンスも定期的に行っています。
デプロイや本番環境を触る際はGitHub Wikiの手順が正しいか確かめ、記載がないようなものは新規に追加しました。
Wikiもチームメンバーからレビューを受けたうえで更新し、全員が理解した状態で実行するようにしています。
また設計資料等に関しても、GitHub Wikiに記載し、メンテナンスを徹底した上で、プロジェクト終了後にアーカイブするようにしています。
－ 最後に、労務管理の4周年に向けて、このチームでエンジニアとして挑戦したいことを教えてください。
Daiki
挑戦したいことはたくさんありますね。
企画中の新機能の実装や、数値の分析によるシームレスなカスタマージャーニー設計の構築などはやってみたいと思っています。
直近では開発体制を強化して属人的な領域を無くしていきたいと考えています。
Kazuki
現在開発中の新機能などで、TypeScriptの導入を少しずつ進めています。
TypeScriptは後々メンテナンスがしやすくなるため、導入するメリットは多いと考えています。
こういった取り組みは即座に結果が現れるものではありませんが、継続的に新機能を追加していく上で効いてくると思うので、こちらをサービス全体に反映させていきたいですね。
Wei
労務管理チームに入ってから、ReactやReduxでフロントエンドを書くことから始まり、バックエンドの対応まで色々なことをやらせてもらって良い経験になりました。
今後で言えば、労務管理はまだREST APIを使っています。
その結果、フロンドエンドエンジニアとのコミュニケーションコストも重く、開発のボトルネックになっている部分もあります。
それを踏まえて年末調整機能ではRESTではなく、GraphQLを使ってみたのですが、想定以上に便利だったので今後はGraphQLを労務管理にも展開していきたいですね。
Toshiaki
システムのあり方はエンジニアのみがその責任を負っています。
システムで攻めることができないと、今後多様性を増すであろうビジネス要件に答えることはできなくなっていくと考えています。
現在のチームは、エンジニアのやりたいことと、求められることを噛み合わせて、うまく進むことができていると感じています。
今後もこうした良い部分はさらに伸ばしていきたいですね。
