2024年 継続して取り組んではいないが3ヶ月ほど

freee人事労務の給与計算ロジックはwriter instanceへの負荷が高く、従業員数の大きい事業所が全従業員の給与計算を一度に実行するとdbのCPU負荷が高まりシステム障害のリスクを抱えていた。 RDSのLocal Write Forwardingという機能を使い、readerにtransactionを貼り、その中のwriteのqueryのみwriterに転送するという対応をし、CPU負荷を抑える取り組みをした

• 給与チーム
• 品質チーム
• DBREチーム

• RDSの対応: DBREチーム
• 本番適用前の検証: 品質チーム、給与チーム

まだ枯れていない技術をfreee人事労務というプロダクトのコアの価値である給与計算機能に導入するため、結果整合を確かめる検証期間を設けた。 具体的にはLocal Write Forwardingを有効にした計算と無効にした計算を一回の処理の中で直列で実行し、結果に差分があるかを確認した。 差分があった場合にはその時間帯のユーザーの操作ログを確認し、発生するべくして発生した差分なのかを確認した。 これを行うことで新たな技術も安心して本番で動かすことができ、CPU負荷の軽減につながった。

詳細は記事に書いています。

• freee人事労務の給与計算ロジックにLocal Write Forwardingを導入した話

2023年 6ヶ月ほど

人事労務ソフトの給与計算機能を担当するチームに所属している時のプロジェクト。 既存の通勤手当機能は全ての従業員が一つの通勤手当を持つという仕様だったが、バスと電車を利用して通勤しているなどのケースで通勤手当を複数持てるようにしてほしいという要望があり、 人事労務ソフトを検討する際の失注要因になりうるため対応することにした

• eng 3人
• PM 1人
• QA 1人

実装

• Reactを使ったfrontの実装
• Ruby on Railsを使ったbackendの実装 リリース調整

複数化するにあたって一番難しかったのが、複数定期を持っているパターンの給与計算だった。 ユーザーにヒアリングをする中で、電車とバスを使っていて、さらにそれぞれの定期の更新タイミングが異なるケースもあることがわかり、複数の更新タイミングの異なる定期を付与できるようにした。

公共交通機関を利用した場合、通勤手当は月15万円が上限である。 https://www.nta.go.jp/users/gensen/tsukin/index2.htm

一般的に定期券は3ヶ月と6ヶ月があり、会社が従業員に対して3ヶ月分または6ヶ月分の定期代を、特定の月の給与にまとめて支払うことが多い。 この時、たとえば6ヶ月分で18万円の定期代を支給した際に15万円の枠からはみ出た3万円が課税対象になるかというとそうはならず、按分し1ヶ月3万円の通勤手当の非課税枠を消費した扱いになる。 また定期券は払い戻しが可能なため、定期の有効期限内で払い戻しをすると払い戻し時点以降は通勤手当の非課税枠の消費はなかったことになる。

なので、毎月の給与計算を行う際に、過去の支給実績、払い戻し実績を考慮した現在の非課税枠を考える必要がある。 このロジックがとても複雑で、実現がかなり困難だった。

対応としてはチームのエンジニア全員でホワイトボードを使い、想定されるケースに対してそれぞれ

• この月はいくらの非課税通勤手当、課税通勤手当が支給されることが期待されるか
• その導出の過程はどのような式になっているのか
• 実装に落とし込む場合どのようなコードになるか というのを話合いながら愚直に設計していった。

実際の実装は1人のengがメインで担当してくれたが、内容があまりに複雑になってしまったのでチーム全員でコードを処理順に読んでいく勉強会を開催し、メインで実装したeng以外でも保守ができる状況を作った。

2023年 3ヶ月ほど

人事労務ソフトの給与計算機能を担当するチームに所属している時のプロジェクト。 ソフト上から役員/役員以外の雇用形態の設定はできるが、役員報酬を設定することはできず、ユーザーは代替手段として基本給の付与を利用することが多かった。 しかし役員報酬と基本給というものは本来別物なので分けて設定できるのが望ましく、また従業員兼務役員という雇用形態では役員報酬と基本給それぞれ発生するので理想的な状態ではなかった。 それを解消するためのプロジェクトを設計から実装までリードした。

• eng 3人
• PM 1人
• QA 1人

Design Doc作成 (設計) 実装

• Reactを使ったfrontの実装
• Ruby on Railsを使ったbackendの実装 リリース調整

雇用形態と役員報酬金額は密接に関係するデータだが、既存機能の事情で同じテーブルに持つことができず別テーブルでの管理となった。 それぞれのデータは過去、未来時点での履歴をもつことができるためその整合性を保つための設計に苦労した。 ex. 2019年4月では雇用形態: 役員、役員報酬 50000円、2020年4月には雇用形態: 役員以外、暗黙的に役員報酬は0円、2025年1月からは雇用形態: 役員、役員報酬100000円の予定、などのデータを全て持っておく必要がある。

結果DB上で整合性は取らず、アプリケーション上でDBから取得したデータを確認してデータを上書きする対応を入れた。 雇用形態に応じて役員報酬の金額が変わるというのはドメインの都合のため、ロジックをValue Objectに閉じ込めるた。そのおかげでアプリケーション上はdbの不整合を意識することなく利用でき、また将来的に新たに参照箇所が増えた場合もdbの不整合が漏れ出す恐れを小さくすることができた。

2021年 半年ほど

自分のチームではPublic API開発と、Public APIを利用し第三者が作成したアプリを公開できるアプリストアの運用をしていた。 公開アプリ促進のために、自社プロダクトの経費精算の申請、承認をトリガーとしたWebhook通知機能の開発を行なった。

• eng 5人
  • チームにはengが5人いたが、インフラを触れるのが社員2人のみで、もう1人は別のプロジェクトを進めていたのでインフラに関しては1人で開発を進めた。
• PM 1人
• QA 1人

Design Doc作成 (設計) 実装

• AWS Lambda, SQS, SNSを利用したWebhook基盤の構築
• railsを利用した、経費精算のステータス変更をトリガーとしてWebhook基盤へ通知する機能の実装
• reactを利用した、Webhook設定画面の実装

Webhook機能自体会社として初めて実装する機能だったので、インフラ構成から複数の案を出しSREチームに相談しながら構築を進めた。 結果的に今後Webhookをトリガーするイベントや通知対象が増えたときにも対応できる、パフォーマンスが十分という理由からSNS, SQS, Lambdaを採用した。 また、自社のサーバーからユーザーが設定した任意のURLにリクエストを送るため、セキュリティには注意を払った。 セキュリティチームのレビューを受けた上で、LambdaをVPC内に配置し、routing tableにも制限をすることで安全性を高めた