SmartHR SaaS管理ユニットがモジュラーモノリスからマイクロサービスへ移行した理由と手順

記事のサマリー（TL;DR）

• SmartHR SaaS管理ユニットは2023年10月にメタップスクラウドの事業譲渡を受け、情シス領域へ参入。モジュラーモノリスで約半年で IdP 機能をリリース
• 可用性・パフォーマンス・開発体験の3課題が表面化し、Packwerkによる依存整理→HTTP通信への置き換え→リポジトリ分離の段階的移行を実施中
• 移行後の CI は30分超→約1分、従業員50,000件のクエリは13.7秒→3.07秒（4.46倍高速化）、従業員データテーブルの行サイズは約71%削減

kintone・Salesforce など社内 SaaS 管理基盤を持つ日本の情シス組織が注目すべき点

SmartHR が今回公開したアーキテクチャ移行の事例は、IdP（シングルサインオン）や SaaS アカウント管理という、多くの日本企業の情シス部門が抱える機能領域そのものを対象にしています。

従業員データを起点に外部 SaaS のアカウントを可視化・プロビジョニングするという設計は、kintone や Salesforce、SmartHR、freee など複数の SaaS を併用している日本企業において現実的なニーズです。一方で、こうしたシステムは「既存モノリスに相乗りして素早く立ち上げる」か「最初からマイクロサービスで設計する」かというアーキテクチャ選択を迫られがちです。今回の事例は、その二択を「順序の問題」として捉え直した好例です。

特に注目したいのは、可用性の独立性です。年末調整など労務機能のメンテナンス窓口と IdP のログイン経路が同一プロセスにある状態は、SaaS 管理機能を内製している組織でも発生しやすい構造です。Rails ベースの業務システムに管理 UI を追加している構成では、同様のリスクを抱えている場合があります。

詳細

SmartHR が情シス領域に進出した背景

SmartHR は人事労務領域にとどまらず、情報システム部門向けのサービスにも取り組んでいます。この動きは、2023年10月にメタップス社から「メタップスクラウド」の事業譲渡を受けたことがきっかけです。

SmartHR には入退社・異動・所属・役職などの従業員データが集積されており、このデータを活用することで外部 SaaS へのシングルサインオンや SaaS アカウント管理の効率化が図れます。具体的には、以下の2つの機能を開発しています。

• IdP（Identity Provider）機能：SmartHR を起点に外部 SaaS へログインできる
• ID 管理機能：SmartHR 上の従業員データをもとに、外部 SaaS のアカウントを可視化・作成・削除できる

立ち上げにモジュラーモノリスを選んだ理由

SaaS 管理ユニットは、情シス領域の立ち上げ時に SmartHR の基本機能のモノリス内にモジュールを作る形で開発を始めました。モジュラーモノリスを選んだ主な理由は以下のとおりです。

• インフラを一から用意しなくてよい：既存の認証・権限・デプロイ基盤をそのまま利用できた
• 従業員データの扱いやすさ：同一データベース上で Active Record 経由で従業員データにアクセスでき、SSO 対象従業員の絞り込みや SaaS アカウントの可視化を容易に実現できた

この判断により、IdP 機能は約半年でリリースすることに成功しています。

モジュラーモノリスで表面化した3つの課題

プロダクトが成長するにつれ、モノリスに相乗りしていることによる課題が明確になってきました。

課題1：可用性

情シス向け IdP 機能は、従業員が日々の業務で外部 SaaS にアクセスするためのログイン経路そのものです。しかし、年末調整のような労務機能のメンテナンスや基本機能内の別プロダクトの障害が発生すると、IdP 機能や ID 管理機能も停止してしまう構造になっていました。

課題2：パフォーマンス

SmartHR の従業員データは過去・現在・未来の状態を扱うために Bitemporal Data Model を採用しています。これは履歴データを正確に扱える一方で、関連テーブルやカラムが多くなりやすい構造です。

SaaS 管理ユニットの機能では従業員データを参照しながら外部アカウントと突き合わせる処理が多く、情シス領域からは不要なテーブルやカラムが存在しても、基本機能側のデータ構造に乗っている以上は整理しにくい状態でした。ユースケースに合わせてインデックスを追加したくても、情シス領域の都合だけで基本機能側のテーブルにインデックスを増やす判断は難しく、扱う従業員数が増えるほど問題が大きくなっていきました。

課題3：開発体験

大きなモノリスの中で開発しているため、CI に30分以上かかることがありました。デプロイは1日1回で、ステージング環境への反映にも時間がかかります。ローカル開発でも rails s の起動に時間がかかり、フロントエンドから API を呼び出すだけで数秒待つ場面もありました。

SaaS 管理ユニットでは AI も活用しながら一人ひとりがフィーチャーを担当して進める開発体制をとっています。「小さく直してすぐ確かめたい」場面が多い中で、CI や起動の待ち時間の積み重ねは開発のモメンタムを損ないます。

マイクロサービスへの段階的移行：3ステップ

SaaS 管理ユニットは現在、一気に切り離すのではなく「依存関係をほどきながら段階的に独立性を高める」アプローチでマイクロサービスへの移行を進めています。

ステップ1：Packwerkで依存を可視化する

最初のステップでは Packwerk を使って基本機能への依存を整理しました。従業員マスタなど基本機能側のデータに直接触れていた箇所を、Public API を介したメソッド呼び出しへ寄せていきます。

この段階の成果は「切り離す前に境界を見えるようにできたこと」です。どこが基本機能に依存しているか、どの呼び出しをサービス間インターフェイスとして扱うべきかをコード上で確認しやすくなりました。

ステップ2：依存を HTTP 通信に置き換える

次に、Packwerk で整理した依存を HTTP 通信に置き換えました。同じモノリス内のメソッド呼び出しではなく、サービス間通信に近い形で境界を扱えるようにします。

まだ同じモノリス内にコードがある状態で「切り離した後のインターフェイスを先に育てられた」ことが大きかったとチームは振り返っています。通信の失敗やレスポンスの扱いを含めて、サービス間通信の形に慣れる期間として機能しました。

ステップ3：リポジトリの分離（現在進行中）

現在は IdP 機能・ID 管理機能のコードベースを基本機能から切り出し、インフラも新たに用意して分離した段階にいます。

API の移行では既存 API を一度に置き換えるのではなく、ストラングラーパターンを使って段階的に移行しています。既存の経路を残したまま新しいサービス側へ処理を少しずつ移し、VPC 内の HTTP 通信を通じて必要なデータにアクセスする構成へ変えています。新旧 API が共存する期間には**腐敗防止層（Anti-Corruption Layer）**を設けて差分を吸収しながら進めています。

今後の予定：データベースの移行

次のフェーズとして、データベースの移行も予定されています。基本機能側の従業員データを直接参照するのではなく、バッチや Worker によるデータ同期を通じて SaaS 管理ユニット側のサービスが必要なデータを保持できるようにします。これにより可用性とパフォーマンスの面でも独立性を高めることを目指しています。

移行によって得られた効果

移行はまだ完了していませんが、すでに以下の改善が確認されています。

デプロイ頻度：1日1回という制限から解放され、対象サービスの都合でいつでもリリースできるようになりました。

CI 時間：モノリス全体の CI で30分以上かかっていたものが、移行後のサービスでは約1分で完了するようになりました。

ローカル開発：rails s の起動が速くなり、画面を開いて API の挙動を確認するまでの待ち時間が大幅に短縮されました。

新技術の導入しやすさ：リポジトリを分けたことで RubyDex・Sorbet・Caddy などの新しい開発基盤ツールを対象サービスに閉じた形で導入・運用できるようになりました。

パフォーマンス（移行途中の暫定値）：

また、従業員データテーブルの行サイズを約71%削減できたとのことです。必要なデータをサービス側の用途に合わせて持つことで、複雑な履歴データへの都度アクセスを減らせています。

モジュラーモノリスで始めたから移行できた

SmartHR エンジニアの nori 氏は、この経験から「モジュラーモノリスで始めることとマイクロサービスへ移行することは対立する選択肢ではない」と述べています。

最初から別サービスとして作っていたら、インフラやデータ連携の準備に時間がかかり、IdP 機能を半年でリリースするのは難しかったはずです。一方で、モノリスの中でもモジュールとして境界を切っていたことで、後から責務の境界を判断しやすい状態を作れていました。

Packwerkを導入していたことで、普段の開発でもモジュール間・サービス間の依存を意識しやすくなり、移行を進める場面でも「このメソッドは情シスモジュールからしか呼ばれていない」「ここは基本機能に依存している」といった判断を素早く下せました。

まとめ

モジュラーモノリスは立ち上げのための現実的な選択肢であり、境界を意識して作ることでマイクロサービスへ移行するための足場にもなります。今回の移行から得られた学びは「最初から完成形のアーキテクチャを選ぶよりも、その時点で価値を届けやすい形を選びつつ後で変えられる余地を残しておくことの大切さ」であると総括されています。