SmartHR で人給基幹プロダクト開発本部のエンジニアリングマネージャーをしている yuzuru です。
この記事では、社内で「人給基幹」と呼んでいる領域が、そもそも何を解こうとしているのか、どこに難しさがあって、いまどんな体制で何に投資しているのかを、一度まとめて書いておきたいと思います。このあと、フロントシステム・人事マスタ・勤怠管理・給与計算の各エリアのマネージャーが、自分の担当領域について順番に書いていくシリーズの1本目です。「SmartHR の人給基幹って、何をやっているところなんだっけ」という方、とくに採用候補として SmartHR を見てくれているエンジニアの方に、少しでも具体的なイメージを持ってもらえたら嬉しいです。 このドメインは、外から見ると「すでにやり方が決まっている業務をシステムに落とすだけ」に見えがちなのですが、いざ中に入ると、制度・例外・時間軸・連携の絡み方がかなり複雑で、そこに SaaS としての体験まで乗ってくるので、わりと骨太だなと感じます。
10分くらいで読める分量を目安にしたので、興味を持ってもらえたら、このあとのエリア別の記事も合わせて読んでもらえると嬉しいです。
筆者プロフィール
yuzuru（秋山 譲）
SmartHR 人給基幹プロダクト開発本部 / Engineering Manager エンジニア歴は約20年。大小様々な企業で EM を務め、2024年12月に SmartHRに入社。 現在は人給基幹全体Directorとして、組織全体の取り組みにも携わっています。
人給基幹が支えている業務
SmartHR が前提にしている社会課題は、人口減少と労働人口の縮小です。企業のバックオフィスは、人手で回すやり方からシステムで支えるやり方へ、もう戻れないところまで来ていると思います。
人給基幹は、そのど真ん中の領域です。具体的に扱っている業務を並べると、
- 従業員情報と組織情報の管理
- 入社・異動・昇降格・退職といった発令
- 勤怠の集計と締め
- 給与計算と支払い
- 各種申請の承認フロー
- 年末調整や社会保険といった帳票
あたりで、どれも「毎月の締め」に直結する業務です。つまり止まると困る業務ですし、法改正が来たから来月から対応します、というわけにもいかない。施行日までに、全顧客に対して当たり前に反映されている必要があります。
この「止められない」という性質が、システムとしての要件をかなりの部分まで決めていると感じます。正確性、監査性、履歴性、可用性、変更容易性。どれか一つでも欠けると、その時点でお客様の業務が止まります。人給基幹は、この水準を当たり前のラインに置いた上で、社会インフラ的な責務を背負っている領域だと思っています。
SmartHR の人給基幹が目指していること
SmartHR は人事労務から始まり、タレントマネジメント、給与、勤怠、周辺プロダクトへと領域を広げてきました。その中で人給基幹は、人と組織に関するデータが最初に集まって、他のプロダクトへ流れていくハブ、という位置づけになっています。
ここで常に意識しているのは、個別プロダクトとしての最適と、人給基幹システム全体としての最適の両立です。単体で便利なだけだとお客様の業務は回らないので、プロダクト間の連携やデータの統合性を踏まえた上で、個別のプロダクトを進化させていく必要があります。
人給基幹はすでに多くのエンタープライズ企業で、毎月の業務の中心として使われています。一つの変更が、顧客企業の給与支払いそのものに影響しうる規模で運用しています。新規プロダクトをゼロから立ち上げるときとは、設計制約がまるで違います。「すでにある整合性」を崩さずに進化させる設計力が、日々試されている感覚があります。
中長期では、SaaS の強みを活かした新しい人給基幹システムを作ろうとしています。既存のオンプレ型を単に置き換えるのではなく、
- 法改正が、施行日までに当たり前に全顧客に反映されている
- 業務に即した形で、プロダクト間をデータが自然に流れる
- 共通モデルの上にデータが集約されていて、活用前提の品質が保たれている
- 連携性と拡張性が高く、標準を保ったまま多様な要件に応えられる
- 「変わり続ける」前提で進化するので、老朽化しにくい
あたりを目指したいと考えています。そしてこれを、既存のオンプレより低い価格帯で提供する。これがもうひとつのテーマです。体力のある大企業にしか届かない品質ではなくて、中小企業まで含めて使える基幹システムを SaaS で作り直す、というところに中長期で投資しています。
なぜ難しいのか ── 制度・時間軸・スキーマ・外部接続
「給与や人事のシステム」と聞くと、法令や業務要件が先にあり、満たすべき処理を正確に実装していく領域だと見られがちです。たしかに、やらなければならないことは多くの場合すでに決まっていて、各社が同じ必須要件に向き合っているようにも見えます。
でも、実際に担当プロダクトを見ていくと、差が生まれる余地はむしろそこに残っていると感じました。同じ制度・同じ業務を扱うからこそ、どこまで迷わず使えるか、AIをどの場面で自然に効かせるか、情報をどう整理して提示するか、アクセシビリティまで含めて誰にとっても扱いやすくできるかが、プロダクトの価値を大きく左右します。
決まった業務をただコードに落とすのではなく、制約の多い領域の中で「どうすれば他社にはない使いやすさを作れるか」を考え続けられる。そこに、この領域の面白さがあると感じています。
制度と例外が重なり続ける
法改正、業界ごとの慣習、会社ごとの就業規則、手当体系、締め日。このあたりが毎年のように動きます。そのうえに、雇用形態、休職、兼務、遡及、差分支給、手作業補正、といった例外が、いくらでも組み合わさってきます。
「4月1日付で休職に入った正社員に、休職中に昇給の遡及適用があって、社会保険の等級変更も重なって……」という話が、ごく日常的に出てきます。こういうものをハードコードではなく仕組みで解けるようにする、というのがこの領域の一つ目の難しさです。
時間軸が複数ある
人給の世界では、「いつ適用されるか（valid time）」と「いつ記録されたか（transaction time）」が普通にズレます。未来日変更（予約）と遡及修正が同じシステムに同居していて、場合によっては同じ従業員のデータに対して同時に走ります。
さらに、「過去のある時点で、この従業員はどう見えていたか」という履歴の視点も重要になってきます。「今の状態」だけを持つデータモデルだと、すぐに破綻する世界です。人事マスタまわりでは、この二つの時間軸を両立させるために、bitemporal なデータモデルを土台にしています。有効日と記録日の両方をキーにして履歴を引ける設計にしておき、予約・遡及・監査といった要求を同じ仕組みで受け止める、というイメージです。どこまでこの仕組みに寄せて、どこは各プロダクト固有の履歴として持つのか。この切り分けは、いまも日々の設計判断の中心にあります。
スキーマが進化し続ける
従業員、組織、雇用、手当。どれも項目が増え続けて、意味も変わり続けていく領域です。新しい手当が生まれ、組織定義が変わり、グループ企業が加わり、入社経路が多様化する。そのたびに、表示・入力・検索・権限・連携のすべてにコストが乗ってきます。
スキーマを柔らかくしすぎると一貫性が壊れて他プロダクトとの連携が崩れるし、硬くしすぎると運用でお客様が困る。どこまで構造化して、どこからユーザー定義に開くか、というラインの引き方は、正直なところ一番難しい部分のひとつです。
外との接続が広い
会計、社労士、勤怠端末、マイナンバー、銀行振込、各社 SaaS、API、CSV。挙げ始めるとキリがないくらい、人給基幹は外の世界とつながっています。それぞれが独自のフォーマットと業務タイミングとバージョン管理を持っている世界です。
全部の連携先に、全部の進化を同じ速度で届ける、というのは現実的ではないので、どの連携をどの優先度で維持・進化させるかを、常に選び続けている状況です。
いま取り組んでいること ── 変更に強い設計と正しさの担保
ここからは、その難しさに対していまどう手を入れているか、の話です。解けるテーマが残っている分だけ、面白さも残っている領域だと感じています。
変更に強い設計へ寄せていく
長年積み上げてきたコアサービスは、制度変更の影響範囲が読みにくくなっている部分が実際にあります。「一見小さな要件のはずが、調べてみると影響先が複数プロダクトに跨っていた」という話も珍しくありません。
ここに対しては、レガシー基盤からの段階的な脱却と、モジュラーモノリス化を進めています。ドメインの境界を定義して、モジュール間の依存方向を静的解析で監視しながら、逸脱を一つずつほどいていく、という地味な進め方です。一気にマイクロサービスに分割するのではなくて、依存を先にほどいてから動かす、という順序を大切にしています。境界の切り方そのものを検証するために、Ruby の動的解析ツールを自作してモジュール境界を探索している話も、テックブログで公開しています。
正しさの担保
給与計算は「1円のズレも許されない」とよく言われます。人給基幹全体でも、計算結果・履歴・監査の説明可能性が、品質の根っこにあります。
「なぜその金額になったのか」を後から完全に再現できること。「いつ、誰が、何を変更したのか」が監査できること。bitemporal な履歴設計と、計算過程のトレーサビリティを、運用コストと見合う形でどこまで作り込むか。ここは一度作って終わり、とはならなくて、継続的に磨き続けている領域です。
体験の一貫性
人給基幹のユーザーは、労務担当者、従業員、管理者、経理、社労士と、立場がかなり違います。それぞれに対して、設定のわかりやすさと、機能の充足性を両立させないといけない、というのがこの領域特有の難しさです。
同じ「申請」でも、従業員から見るとちょっとした変更届に見えて、労務担当から見ると複数プロダクトに波及する重要業務になっている、ということがよくあります。この両面を同じ画面、同じ設定体系の中でどう整理するかは、いまも試行錯誤している最中です。
スケールとパフォーマンス
エンタープライズ企業では、数万人規模の従業員を毎月締める処理が走ります。繁忙期には処理が集中するので、ピーク時の負荷は平時とはまったく別物です。
単にスケールアップで殴るのではなく、ドメインに根ざした指標（締め処理のリードタイム、計算時間、検索応答時間など）を定義して、SLO を設定して、異常を「お客様からの問い合わせで発覚する」前に検知する。そこまで踏み込むフェーズに入っています。
基盤としての拡張性
人給基幹は、他プロダクト、他エリアが依存する土台でもあります。ここを動かすときは、外部への波及を最小化しながら、内部のデータモデルは進化させ続ける、という両立が常に求められます。
安定稼働を保ったまま、中身を漸進的に進化させる。このバランスは個人の技術力だけでは持ちきれなくて、チームとしての意思決定プロセスそのものが問われる部分だと感じています。
どんな体制で取り組んでいるか ── 2つの本部と4つのエリア
人給基幹は、大きく2つの本部で動いています。
人給基幹プロダクト開発本部
ユーザー価値の最大化をミッションに、エンタープライズ企業に選ばれる人給基幹を作っていく本部です。フロントシステム、人事マスタ、勤怠管理、給与計算の4つのエリアに分かれていて、それぞれが自律したチーム群として動きながら、全体としての整合性も意識しています。
各エリアの中はさらに複数のスクラムチームで構成されていて、チーム単位では自律的に動きます。エリアをまたぐ意思決定や、全体の優先順位調整は、エリア EM とエリア PO が連携しながら進めています。
この4エリアに加えて、本部内にはCRE部（Customer Reliability Engineering）も置かれています。お客様からの問い合わせ対応や不具合改修、Customer Observability の整備を横断で担っていて、プロダクトの信頼性を現場目線で日々支えてくれているチームです。
人給基幹プロダクト基盤開発本部 ── 中長期の土台を育てる本部
人給基幹の各プロダクトが共通して依存する「土台」を育てている本部です。先ほどの章で挙げた技術テーマ、bitemporal データモデルの進化、モジュラーモノリス化、業務指標に紐づく SLO・メトリクス設計、そして止められないサービスの裏側での本番データ移行、あたりを、個別プロダクトのロードマップとは独立した時間軸で担います。
本部内にはスケーラビリティエンジニアリングユニットも置かれていて、先ほど触れた SLO・パフォーマンスまわりを中心に、大規模テナントでの処理性能と可観測性を専門に扱っています。基盤本部の取り組みの中でも、特に「お客様の業務をスケール側から止めない」ためのチームです。
プロダクト本部と基盤本部を分けているのは、機能開発と土台の進化とで、時間軸も意思決定の粒度もかなり違うからです。分けておくことで、短期のユーザー価値提供と、中長期の土台作りを、それぞれのリズムで進められる体制にしています。
基盤本部の取り組みは、テックブログでも個別にまとめています。「履歴の適用日を日付化しました」「自作の Ruby の動的解析ツールを使って、モジュラーモノリスの境界を試行錯誤している話」あたりが、具体を知るのにちょうどいい入口だと思います。
チームの動き方
全社的にスクラムを採用していて、人給基幹でも Scrum@Scale で複数チームの協働を運営しています。レビュー、テスト、リリース、モニタリングは各チームが責任を持ちつつ、データモデルや観測性、SLO といった横断テーマは、エリアや本部をまたいだ場で持ち寄って議論しています。
マネージャーとしての正直な感覚を書いておくと、このドメインは「一人の天才が全部を解く」タイプの問題にはなっていません。ドメインに詳しい人、設計に強い人、運用に強い人、CRE としてお客様の声を持ち帰る人。それぞれが専門性を持ち寄って、ようやく前に進むタイプの領域だと思います。入る側から見れば、自分の強みを複数方向から活かしやすい環境なんじゃないか、といまは感じています。
次回以降の予告
1本目としては、いったんここで筆を置きます。2本目以降は、各エリアのマネージャー自身が、自分の担当領域について書いていく予定です。
- 2本目：給与計算
- 3本目：フロントシステム
- 4本目：人事マスタ
- 5本目：勤怠管理
人給基幹は、外から見えているよりもずっと複雑で、その分だけ解きごたえが残っている領域だと思っています。このシリーズを通して、「ここで自分が何を解くのか」が少しでも具体的に想像してもらえたら嬉しいです。
SmartHR では、この領域を一緒に解いていく仲間を募集しています。気になった方は、ぜひカジュアル面談でお話ししましょう。次回以降の記事もお楽しみに。
