はじめまして。HRMOS労務給与プロダクト部でエンジニアをしているgenと申します。 2022年4月に株式会社ビズリーチに中途入社して以降「HRMOS労務給与」の開発を行ってます。 給与計算システムの開発には広範な給与計算業務の知識が必要であり、定期的な法改正への対応も求められますが、前職では食品卸のお客様に対して業務システムの開発を行っており、入社時点では給与計算の知識を全く持っていませんでした。
労務給与プロダクト部では、エンジニアは必ずしも給与計算業務に精通しているわけではないという前提の上で「業務知識の深い理解」や「法律で明記されていない細部の明確化」ができるようになるために「業務スペシャリスト」と協力して開発を進めています。
この記事では、業務知識を持たない私のようなエンジニアでも法的要件があるプロダクト開発ができるようになる開発業務プロセスについて、給与計算システムの月額変更届の機能実装を例にご紹介します。
難しさはどこにあるのか
個人的に、給与計算システムの難しさは以下の要因にあると考えてます。
- 複雑な法的要件
- 定期的に改正される法的要件
- 会社ごとに異なる独自の規定
今回例に挙げる月額変更届は制度自体が複雑なので1つ目の複雑な法的要件に該当します。
更に、今後改正される可能性もゼロではないので、その場合には2つ目の定期的に改正される法的要件に該当する可能性もあります。
月額変更届(随時改定)について
複雑さを感じ取っていただくために、ここで月額変更届の制度を紹介します。※斜め読みで大丈夫です。
月額変更届とは、被保険者の標準報酬月額が変わる際の手続きに使用します。 標準報酬月額に応じて被保険者の健康保険料・厚生年金保険料が決まります。
月額変更届は以下3つの条件に該当した場合、速やかに年金事務所や健康保険組合に提出する必要があります1
- 昇給または降給等により固定的賃金に変動があった。
- 変動月からの3ヶ月間に支給された報酬（残業手当等の非固定的賃金を含む）の平均月額に該当する標準報酬月額とこれまでの標準報酬月額との間に2等級以上の差が生じた。
- 3ヶ月とも支払基礎日数が17日（特定適用事業所に勤務する短時間労働者は11日）以上である。
明記されていない細部を網羅するための感覚
さらに、法律や制度の説明に記載されない細部までの明確化が求められることも開発の難しさとして捉えています。
具体的には、月額変更届の説明の昇給または降給等により固定的賃金に変動があった。という記載について、システム化するにあたり曖昧な部分を厳密にする必要があります。
昇給または降給等とは、「等」と記載されているが、厳密なスコープはあるのか固定的賃金はどのような性質のデータか変動があったの具体的な判定方法は
例として支給項目の一つである「通勤手当」を上記の説明に照らし合わせて考えてみると、以下のように厳密に定義できます。
- 通勤手当は大きく「通勤定期代」と「出勤日数に応じて都度支給する手当」の2種類に分類できる
- 通勤定期代について
- 固定的賃金の一つとして扱う
- 支給単位（3ヶ月定期→6ヶ月定期）の変更も、月額変更届の対象になり得る
- 月によって支給の有無が変わるので支給額そのものを使用することができない
- 支給単位で按分した1ヶ月あたりの金額「社保対象通勤費」を計算し、それが前月分と比較して差があれば変動した判定にする
- 出勤日数に応じて都度支給する手当について
- 固定的賃金ではない
説明には記載されていない、労務給与領域特有の業務感覚が身についてなければ、通勤手当一つとっても仕様への落とし込みに時間を要したり、ぬけもれが発生しかねません。
この感覚は書籍を読む等だけでは身につけることができず、エンジニアが開発する際に苦労する点だと思います。
「業務スペシャリスト」との共創
私たち労務給与プロダクト部では、そういった課題に対応するため業務スペシャリストがプロダクト組織内に所属し、エンジニアとともに複雑な機能開発の課題を乗り越え、共にプロダクト開発を進めています。
業務スペシャリストとは、人事・労務・給与といったバックオフィス業務に精通しているメンバーで、一般的にはドメインエキスパートと呼ばれるような人たちです。
社会保険労務士の資格を持ち、実務経験が豊富で、システムに必要な機能の精査や法令に準拠した要件定義のみならず、実際のシステム操作に関する実務担当者目線からのアドバイスもしてくれます。
エンジニアと共にプロダクト開発を進めていると言っても過言ではありません。
同じ組織内に業務スペシャリストがおり、物理的な距離も大変近いので、エンジニアは開発プロセスの中でいつでも業務スペシャリストに業務に関する相談ができます。
また、主に設計のフェーズにおいて業務スペシャリストと協働しながらプロセスを進めます。
エンジニアと業務スペシャリストの関わり方
ここからは、開発プロセスの中でエンジニアと業務スペシャリストの具体的な関わり方をご紹介します
業務シナリオ/要求の共有
まずは開発予定の機能について、業務スペシャリストから業務の概要と、プロダクトオーナー（以下、PO）から要求の共有が行われます。
例えば、日本年金機構が記載しているこれらの条件について
（1）昇給または降給等により固定的賃金に変動があった。
（2）変動月からの3ヶ月間に支給された報酬（残業手当等の非固定的賃金を含む）の平均月額に該当する標準報酬月額とこれまでの標準報酬月額との間に2等級以上の差が生じた。
上記の文章から業務スペシャリストが以下のようにまとめて、システム開発に必要な情報を説明してくれます。
- 月額変更届の計算には、変更前の情報として4ヶ月前の給与データが必要
- HRMOS CORE（同シリーズで提供中の従業員データベース）の情報を参照する場合は〇〇時点の情報を取得する
要件の調整
エンジニアは共有された業務シナリオ、要求についての疑問点を解消し、調整や提案を通して要件に落とし込みます。 業務スペシャリストにも相談しながら、最終的にはPOと制約や開発スコープの合意を取ります。
「システム上で月額変更届対象外となった社員を手動で対象者にする」という機能の外部設計では、以下の様なやり取りを行い仕様を決めていきました。 当時のメモをそのまま掲載します。
対象外社員の扱い、どうする？
■開発側の想定内容
・給与データ確定時に月変対象者の抽出を行い、この画面ではあらかじめ抽出していた（指定された改定年月に該当する）月変対象者を表示するだけ。■課題
・開発側の想定に沿った場合、対象外社員が一覧表示されなくなるが、業務上特に支障はないか？■業務スペシャリストへのヒアリング結果
Q.対象外社員も表示したい理由は？
・どうしてもシステム上で自動判定できない月変対象者が出てくる。
・その人たちを本当に月変対象者にしなくて良いかの確認だったり、データを修正して月変対象にしたりしたいため、対象外社員も月変対象にできる仕組みが必要。
・そのため、一覧で対象外社員の人たちも表示され、データが確認できた方が良い。Q.システム上で自動判定できなそう（自分で対象にしないといけなそう）な社員はあらかじめ目処がついているもの？
・ある程度は給与計算時点で分かっている。
・そのため、システム外で怪しい人たちのリストは作るはず。■検討内容
・対象外社員も一覧表示するとなると、何千人もこの画面に表示されることになる。
・あらかじめある程度自動判定に引っかからない怪しい人がわかっていることが前提なのであれば、対象外社員を手動で一覧に追加できる機能があれば問題ないのでは。
・仮に対象外社員を一覧表示したとしても、「何千人と表示されている中から事前にリストアップされている怪しい人リストの社員を検索してデータ修正する労力」と、「対象外社員から怪しい人を自分で選択して一覧に表示し、データを修正する労力」は変わらない気がする。
・なので対象社員だけ表示される。手動で対象外社員を追加できる。で良いのではと思っている。
・そもそもどのぐらい自動判定で抽出できないものなのか…？イレギュラーケース？イレギュラーケースならなおさらそんなに対象社員はいないはずなので手で追加できれば良い気がする。■POレビュー結果
・1stでは一旦手動で対象外社員を手動で一覧に追加できる、に留める。
外部設計/内部設計
外部設計/内部設計では、業務スペシャリストが仕様書を作成したり、エンジニアの設計物に対してレビューを加えたりします。
特に日付や年齢に関する境界値は、多くが日本語で表現されていることもあり、システム化する際に非常に間違えやすい点だと感じております。 認識のズレを起こさないように、エンジニアが境界値に関する仕様を作成した後は業務スペシャリストにレビューを依頼します。
月額変更届の対象者かどうかを判定する処理の設計では、以下の条件分岐の定義を業務スペシャリストと一緒に作成しました。
また、業務スペシャリストでも判断がつかないような内容については、税務署や社労士事務所等に問い合わせも行います。
まとめ
この記事では給与計算業務の中でも複雑性が高いとされる月額変更届のリリースを例に、労務給与プロダクト部のエンジニアと業務スペシャリストの共創の様子を紹介しました。
法的要件があり複雑性が高いプロダクト開発で、エンジニアと業務スペシャリストが組織内で協力をし合い専門知識を得ながら成長し、価値を生み出している様子を感じ取っていただければ幸いです。
開発以前はエンジニアはこの月額変更届業務の存在自体ほとんど知らない状態でしたが、業務スペシャリストと協力し、業務知識と法令の仕様を理解しながら開発を進めることができました。 独学でも労務給与領域の業務を学習することは可能ですが、専門家である業務スペシャリストにまず見てもらうことができるので、安心感を持ってプロダクト開発ができました。 また、同じ組織内に所属していることで素早くフィードバックループを回すことができるので、プロダクトが少しずつでも着実に成長していることを実感しました。
HRMOS労務給与はまだ開発途上の製品であり、製品とともに開発プロセスも少しずつ見直しを行っています。 これからも業務スペシャリストと協力して難しく複雑な課題に取り組み続けていきます。
