ドメインや仕様が複雑な開発をうまくすすめるためにやったこと

freee人事労務の開発チームで給与計算関連の機能開発を行っているbanaと申します。最近はポケモンスリープに睡眠を支配されています。

freee人事労務の給与計算チームでは、先日入退社月の日割り計算の機能をリリースしました。この機能開発は自分が経験した中では比較的ドメインや仕様が難しい開発で、学びが多くあったため、プロジェクトを前に進めるためにやったことをこの記事にまとめたいと思います。

1つでも役に立つことがあれば、また、深いドメイン理解が求められるアプリケーション開発の大変さと面白さを少しでも感じていただければ幸いです。

前提

入退社月の日割り計算とは

今回記事で取り上げる内容が伝わりやすくなるよう、簡単に入退社月の日割り計算について説明します。

例えば、給与の締め日が月末（=給与計算期間が月初から月末）の会社に入社するときの基本給について考えます。従業員は月給制とします。

1日に入社した場合、欠勤があるケースなどを除けば全額支給されると思いますが、月の途中、15日入社の場合はどうでしょう？

このようなケースでは、合理的な方法で給与を日割りすることができます。これが入退社月の日割り計算です。

月の途中で入社した場合に支給を日割りするイメージ

なぜ複雑さに向き合う必要があるのか

まず、人事労務や給与計算は制度や仕組みが難しいため、当然それをアプリケーションに落とし込む際にもその複雑さに向き合う必要があります。

加えて、今回の開発で扱う日割り計算は、法律上1つのやり方に定まっているわけではなく、合理的な範囲で企業が裁量をもって決めることができます。運用上様々なパターンがありえ、それらが法令上決められているわけではないので、いつもにもまして仕様の言語化が必要でした。

ここからは実際にやったことをいくつか取り上げます。

コアとなる定義や不確実性の高い箇所を中心に早めに議論した

プロジェクトを進めるにあたって、実装上重要になる定義や計算式、不確実性の高そうな箇所をプロジェクト序盤で把握することを心がけ、時間をとって議論しました。

これによって未定義の計算式や考慮漏れパターンに気づくことができました。あまりにも工数がかかりそうなケースは事前にスコープから外す議論をすることができました。

例えば、日割り計算対象となる条件の1つに途中入社であることが挙げられていました。「途中入社である」というのは、一見仕様としてはっきりしていそうに思えるのですが、実装に入っていくフェーズにおいては実は曖昧です。

これを実装できるくらいに明確にしていきましょう。

ぱっと思いつくのは「入社して最初の給与計算期間 かつ 給与計算期間内の初日 < 入社日」でしょうか。私ははじめこれを思いつきました。なお、給与計算期間とは給与締め日が月末の場合、月初〜月末のことです。

では、給与計算期間の初日が所定休日だった場合はどうなるでしょう？

休日の直後に入社しているなら、日割りしないという判断が一般的に思えます。定義を「入社して最初の給与計算期間 かつ 給与計算期間内の最初の所定労働日 < 入社日」にする必要がありそうです。

それでは、給与計算期間内の全てが所定休日だった場合は？

「そんなことあるの？」と思われるかもしれませんが、設定上可能ですし、実務上も労働形態が変形労働制などのケースで起こり得ます。

上記は一例ですが、このように具体例を出しながら定義を明らかにしていく上で、実は定義が曖昧であることが判明することが複数回ありました。

そうはいっても、あらゆることを最初に詳細まで議論するのは現実的に無理があります。

コアとなる定義についてはじっくり時間をとって議論しましたが、全てに対して時間をかけるのではなく、時間をかけるべきところを見極めメリハリをつけて取り組んだこともよかったと思います。

仕様を図解しながら共有した

自分の所属チームには週に1日オフィス出社推奨日があります。その出社日を有効活用して、ホワイトボードに図を書きながら話すことで、メンバー内のドメインや仕様の理解を深められました。

一例として、給与計算の締め日支払日のパターンごとに、図を書き、今回実装したい日割り計算のロジックを検証しました。

議論に使った図の一例

図解しながら理解を深めることによって、特定の設定の場合に本質的に実現不可能なパターンがあることなどに気づき、プロダクトマネージャ（以下PM）と仕様やスコープについて早めに議論することもできました。

タスクの依存関係を可視化した

仕様の整理が進みある程度開発内容の見通しがついた段階で、大まかなタスク依存関係を図にしました。

実際に作成したタスク依存関係図のイメージ

可視化することで、どの領域に優先的に着手すればよいか、複数人で開発を進める上でどこがボトルネックになりやすいかをチーム内で共通認識を持って進めやすくなったように思います。

また、プロジェクトに途中参加したメンバーからすると、全体像と今ざっくりどこまで終わっているかなどが把握しやすくなる効果もあったようです。

クイックにコミュニケーションすることを心がけた

本プロジェクトでは、エンジニア間ではもちろん、PM・プロダクトデザイナー（以下PD）・QA・エンジニア間でも、比較的円滑かつスピーディーにコミュニケーションがとれました。

PMやPDと距離が近いことで、ミーティングの場をまたずにその場（SlackやGoogleMeet）で仕様確認や方針決めができました。手を不必要に止めることなく開発を進められたと思います。

テストが始まるより前の実装段階で、QAから「このケースではどうなるのか」といった質問をしてもらったおかげで、考慮漏れにも気づくことができました。

これはドメインが複雑な開発に限らないとは思いますが、事前に全てを見通すことは不可能なので、開発者が問題に気づいた段階で、その問題が開発のボトルネックにならないよう素早く解消できるツールや文化は重要であると思います。

おわりに

ドメインに深く立ち入る開発は、ときに（いつも？）大変さが伴いますが、その分やりがいと面白さがあると強く思います。この記事が、複雑なドメインに向き合っている方や、そのような開発に興味を持っている方の一助になれば幸いです。