- 2019年4月 freee株式会社 入社
- 2020年1月 Public APIチームに異動
- 2021年1月 同チームでマネージャーを兼任
- 2022年7月 freee人事労務の給与チームに異動
- 2023年1月 同チームでマネージャーを兼任
- 2023年7月 Bundle開発チームマネージャーを兼任
- 2024年7月 freee人事労務人事給与領域の開発責任者
担当プロダクトのRDSへのLocal Write Forwarding導入
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負荷の軽減につながった。
詳細は記事に書いています。
通勤手当の複数化対応
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の不整合が漏れ出す恐れを小さくすることができた。
Webhook機能開発
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にも制限をすることで安全性を高めた
■ 2024年7月 ～ 現在 **所属部署・役職: freee人事労務の給与・労務領域の開発責任者・マネージャー。Bundle by freeeの開発責任者・マネージャー 担当業務: 給与・労務機能開発チーム（5チーム）およびSaaSアカウント管理サービス開発チーム（1チーム）の計6チーム（エンジニア合計約20名）を統括。うち3チームは担当マネージャーを通じた間接マネジメント。
- プロダクトオーナーと共に、中長期（半年～1年）のプロダクトロードマップ策定に参画し、技術的実現性と事業目標達成の両立を追求。
- ロードマップ実現に向けたエンジニア組織戦略の立案・実行。
- チーム構成の最適化、メンバーのスキルセットやキャリア志向を考慮した異動配置。
- リーダー候補の発掘・育成を意識したアサインメントと支援。
- エンジニア採用活動を主導（採用要件定義、媒体選定・スカウト、書類選考、面接、オファー面談まで一貫して担当）。
- 担当マネージャーとの週次1on1、及び担当チームメンバーとの月次1on1を通じて、各チームの状況把握と課題解決を支援。
- 複数チームのプロジェクト進捗状況を定期的にモニタリングし、組織全体の生産性向上と目標達成を推進。
■ 2023年7月 ～ 2024年6月 **所属部署・役職: Bundle by freee開発チームのマネージャー 担当業務: M&Aにより統合したSaaSアカウント管理サービス開発チーム（エンジニア7名：社員4名、業務委託3名、PdM1名）のマネジメントを担当。
- チーム立ち上げとプロセス最適化:
- M&A直後のチームにおいて、メンバーとの積極的なコミュニケーション（1on1、食事会等）を通じて相互理解を深め、円滑な組織統合に貢献。
- プロダクトのフェーズ（スピード重視）とメンバーの特性（元CTOの高い技術力）を考慮し、開発プロセス（レビューフロー）を最適化。開発スピードの低下を防ぎ、迅速な価値提供を維持。
- メンバー育成と権限移譲:
- 社員エンジニア3名に対し、プロジェクトリードの役割を段階的に委任。
- 初期は設計・要件定義ミーティングに同席しサポート、徐々に自律性を促し、メンバーの成長とチームのスケールに貢献。1on1でのフィードバックを通じて成長を支援。
- チーム連携強化:
- 業務委託メンバーを含めた全員との定期的な1on1やチームイベントを実施し、雇用形態に関わらず一体感のあるチームを構築。
- コミュニケーション効率向上のため、週20時間程度の契約だった業務委託メンバーを、フルタイムで働ける業務委託エンジニアに変更。
■ 2023年1月 ～ 2024年6月 所属部署・役職: freee人事労務給与計算チームマネージャー 担当業務: 給与計算機能開発チーム（エンジニア3名、QA1名、PdM1名）のマネジメントを担当（ピープルマネジメント対象はエンジニア3名）。
- チームビルディング:
- 多様なバックグラウンドを持つメンバー（社歴、専門性、チーム参加時期）で構成されるチームにおいて、四半期ごとのオフサイトを企画・実施。相互理解促進やWorking Agreement策定を通じて、心理的安全性の高い協働体制を構築。
- 複雑なプロジェクトの遂行:
- 法制度対応（通勤手当複数化、定額減税）など、要求仕様が複雑なプロジェクトをリード。
- PdMや外部専門家（社労士）と連携し、要件の正確性を担保。
- （特にアピールしたいエピソード例） 通勤手当複数化における複雑な計算ロジックに対し、チーム全員での設計セッションを主導。ホワイトボードを用いて全ケースを洗い出し、実装方針を決定。実装後もチームでのコードレビュー会を実施し、属人化を防ぎ保守性を向上させた。
- 法制度対応（通勤手当複数化、定額減税）など、要求仕様が複雑なプロジェクトをリード。
- ピープルマネジメント:
- 週次1on1によるメンバーとの対話を通じて、進捗確認、課題解決、キャリア相談を実施。
- メンバーの意向とキャリアパスを踏まえた目標設定、および挑戦的なタスクのアサインメントにより、メンバーの成長を支援。
- 成果（Pull Request数・内容、プロジェクト貢献等）に基づいた客観的な評価を実施。
- Ruby, Ruby on Rails
- React, TypeScript
- AWS