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