SmartHRに入社してからの3年間を振り返る
December 24, 2022
この記事はSmartHR Advent Calender 2022 24 日目です。
はじめに
こんにちは、ばーちー(@hypermkt)です。 2020 年 1 月に SmartHR に入社して約 3 年がたちました。2023 年 1 月より新しいチームへ異動することとなり、ちょうどよい機会なので入社してからの 3 年間をざっくり振り返りたいと思います。
3 年間年末調整機能の開発をしていました
年末調整とは「所得税の過不足を調整する手続き」のことです。SmartHR の年末調整機能では人事労務担当者と従業員向けに年末機能を提供しています。年末調整機能の開発プロジェクトは年単位となるため、2020 年版、2021 年版、そして 2022 年版の年末調整を開発してきました。
今でこそ年末調整について大凡把握はできていますが、入社前は控除の意味すら理解していませんでした…。 全くドメイン知識がない状態でも PdM やドメインエキスパートにより情報をインプットする場が設けられており、しっかりと理解した状態で開発に臨むことができ、とても助かりました。
一番思い入れのある開発は「キハイショ」です
キハイショとは「給与所得者の基礎控除申告書 兼 配偶者控除等申告 兼 所得金額調整控除申告書」のことを言います。
…
な、なんだそれは..?! と思われるかもしれませんが、こちらの書類のことです。
社内ではこの書類の右上にある「基・配・所」から「キハイショ」と呼ばれています。
この書類は 2020 年の税制改正に伴って誕生しました。
特徴的なのは「給与所得者の基礎控除申告書(ピンク枠)」と「給与所得者の配偶者控除等申告(青枠)」と「所得金額調整控除申告書(緑枠)」という３つの書類が一つに合体した書類となっています。分かりづらいので色分けすると以下のようになっています。
この書類は自身の給与収入・所得額をピンク枠に、配偶者の給与収入・所得額を青枠に、給与収入が 850 万円を超える場合で特定の要件を満たす場合は緑枠に扶養家族情報を記載する書類です。
この書類を PDF 出力する機能開発を担当しました。弊社プロダクトの PDF 出力には Thinreports を使用しており、これを利用することで簡単に PDF 作成が可能となります。ざっくりとした利用イメージとしては出力したい項目ごとにメソッドを用意して、画面上の指定の場所で該当のメソッドを呼ぶ設定をする感じです。
年末調整書類の難しいところは項目の出力条件の複雑性です。上部にある「あなたの氏名」や「あなたの住所」であればデータベースから取得した値をそのまま出力するだけで簡単ですが、真ん中から下部にある申告書部は特定条件の時のみチェックを入れたり、値の出力をするので複雑度が増します。
例えば所得金額調整控除申告書の「☆ 扶養親族等」に該当する扶養親族を出力するには
以下の条件判定を行い、2, 3 のいずれかを選定して出力する必要があります。出力パターン・条件が多数あるため、テストケースも網羅的に実装する必要があります。
出典: No.2676 年末調整で所得金額調整控除の適用を受けるとき｜国税庁
初めて見たときは「なんだこれは…」となりましたが、書類の仕様を把握するにつれて実装も徐々に楽しくなり、完成形の PDF を出力できたときは達成感に満たされたことを覚えています。
MTG ファシリテーションは会議設計が重要
SmartHR ではすべてのチームでスクラム開発をしています。スクラム開発にはリファイメント、レトロスペクティブ、プランニングなど様々な MTG が行われます。スクラム開発以外でもチームやタスクの方針など様々な MTG が行われます。
MTG で共通しているのはメンバーとの議論で、意見を発散させ 1 つの終着点に収束させることです。MTG におけるファシリテーターの役目は MTG を円滑に進行させることです。
いざ自分が MTG のファシリテーションを担当すると、うまく意見の発散や収束ができず苦労することが多かったです。自分は MTG の中における同期的な議論の理解や瞬発力のある会話が苦手であることに気付かされました。
そこでファシリテーションが得意なチーフ（チームのプレイヤー兼エンジニアマネージャーの役割）に相談し、ファシリテーショは会議設計が重要であることを教えてもらいました。
具体的な方法については、去年のアドベントカレンダー記事としてこちら「ファシリテーションでスクラム開発の改善に取り組んだ話」にまとめてありますのでご覧ください。
苦手なものを今すぐ得意に転換することはできなくても、しっかりと準備をすることで MTG ファシリテーションに恐れることなく立ち向かえるようになりました。 今でも苦手なのは変わりないですが、心持ちは全然違います。この「MTG ファシリテーションは会議設計が重要」であることを知れたのはとても大きかったです。
パフォーマンス改善は奥が深い
2022 年はパフォーマンス改善に注力し、上期は負荷試験を、下期は継続的なパフォーマンス監視と改善に取り組みました。
パフォーマンス課題の検知については New Relic などのパフォーマンス監視ツールを利用すれば発見は難しくありません。問題は検知したパフォーマンス課題の解決方法を見つけることです。
パフォーマンス課題は、様々な条件が組み合わさって「遅い」という結果が生まれます。
- アプリケーションサーバーまたはデータベースサーバーのインフラスペック
- データベースの特性
- データベースのパラメーター設定
- データベースのインデックス設定
- データ量
- アプリケーション実装
- SQL
- テーブル設計
など様々な要素が絡み合っています。パフォーマンス改善ではどのレイヤーにボトルネックがあるかを特定し、解決方法を編みだす必要があります。
しかし、いざ着手してみるとこれが難しい!!なかなかすぐに答えが見つけられず何日も悩んだことが何度もありました。 こういった難題に取り組むときのコツとしては、すぐにチームメンバーやパフォーマンス改善が得意な強いエンジニア相談することです。 チームメンバーの力や知見を借りることで、どうにか解決方法を見つけてきました。パフォーマンス改善を通じて学んだことは以下の通りです。
様々なパフォーマンス課題に取り組んで学んだことは以下のとおりです。
速い・遅い ORM の特徴を知ること
例えば以下のように 生 SQL では速いですが Active Record の where メソッドに巨大な配列を渡すを遅い場合があります。何も知らないと便利と思って実装してしまいそうなので、ORM の特徴や知見を貯めていく必要があることを知りました。
※ ちなみに以下の PR は後日 revert されており、現在もこの課題は残ったままと思われます。
速い・遅い SQL の特徴を知ること
発行される SQL の JOIN するテーブル数が多かったり、一回で大量のデータを取得しようとすると遅くなることがあります。 遅くなる SQL の特徴と取得対象のテーブルのデータ数なども考慮しながら SQL を組む必要があります。 この辺については以下書籍がとても参考になりました。
ORM から発行される SQL を知ること
発行される SQL がイメージできないと、発行される SQL に問題がないのか判断できません。 ただ ORM が複雑に絡み合ってくると想像もできなくなってくるので、必要に応じて SQL 出力して SQL の実行確認をするのが良さそうです。
多角的な観点で課題を見ること
冒頭でパフォーマンス課題は様々な要素が絡み合っていると説明した通り、どのレイヤーで影響しているのか多角的に見ていく必要があります。局所的に課題を見るとハマりがちです。
おわりに
入社して 3 年間をざっくり振り返りました。苦労したことも多かったですが学びも得ており成長に繋げられたと思います。何より開発を通じて利用しているユーザーの皆さんに価値を提供できていると実感できているのが一番のやりがいです。来月からは本体チームとなりますが、年末調整開発で得た知見と経験を活かしていきたいと思います。