こんにちは。SmartHRでプロダクトエンジニアをしている@bmf_sanです。
SmartHRは、人事労務領域を中心に複数のプロダクトを展開するマルチプロダクト戦略を推進しています。各プロダクトは独自の価値を提供しながらも、統一的な権限管理でシームレスなユーザー体験を実現しています。これを支えるのが「権限基盤」です。
しかし、プロダクト数の増加とともに権限基盤が開発のボトルネックとなり、新機能のリリースが遅延していました。この課題を根本的に解決するため、私たちはアーキテクチャ戦略を策定し、IAM基盤とアクセス制御基盤の構築に着手しました。
本記事では、権限基盤が直面していた課題、それを解決するアーキテクチャ戦略、そしてその具体的な手段としての新しい権限基盤の設計について紹介します。マルチプロダクト環境の基盤設計や、大規模システムの権限管理に関心のある方の参考になれば幸いです。
価値提供速度の制約という課題
SmartHRのマルチプロダクト戦略では、新規プロダクトの展開スピード向上とプロダクト間連携による付加価値向上が求められています。権限管理はユーザーの運用業務に直結するため、多様なニーズに対応できる柔軟性と、競合優位性を築くための迅速な市場投入が不可欠です。
しかし、現在の権限基盤はこの価値提供速度を最大化できていません。
現在、SmartHRではコアサービス（モノリス）内に実装されたロール機能が、複数プロダクトの権限管理を一手に担っています。ロール機能は「誰が」「どの従業員データに」「どこまでアクセスできるか」を制御する仕組みです。
この中央集権的なアーキテクチャでは、すべての権限機能開発が権限基盤ユニットに集中します。各プロダクトが必要とする権限機能を権限基盤ユニットが一手に引き受けるため、プロダクトチームは自律的に開発できません。プロダクト数の増加に伴い要求が殺到し、権限基盤ユニットの実装能力を超える要求が発生しています。実装に長期間を要するケースもあり、積み残しが生じています。権限基盤ユニット1つのチームの実装能力が、すべてのプロダクトの権限機能開発速度を律速しているため、プロダクトチームが権限機能を必要としても、実装完了まで待機することを余儀なくされ、開発速度が低下しています。
課題が発生する4つの原因
この課題は、現状のアーキテクチャにある以下の4つの原因により引き起こされています。
柔軟性の欠如
既存のロール機能は「従業員データに対する権限制御」という共通要件には対応できますが、プロダクト固有の権限要件には対応できません。これらに対応するには、ロール機能自体を個別に修正する必要があります。開発工数に影響するため、権限基盤ユニットの実装能力を逼迫し、価値提供速度を制約します。
コミュニケーションコストの高さが実装能力を逼迫
プロダクトごとに異なる権限要件を実装するには、権限基盤ユニットとプロダクトチーム間で、要件や仕様について個別に合意形成が必要です。この調整に時間を要し、開発着手までのリードタイムが長期化するため、価値提供速度を制約します。
変更容易性の低さ
ロール機能では、アクセス制御対象のデータ（従業員情報）とアクセス制御のロジックが密結合しています。そのため、1つの変更が複数の機能に影響を及ぼし、変更時の影響範囲が広くなります。また、複数プロダクトで共有される仕組みのため、仕様が複雑化し、認知負荷が高く、属人化が進んでいます。変更に時間を要するため、価値提供速度を制約します。
リリースサイクルの制約
権限機能がコアサービス（モノリス）内部に実装されているため、コアサービスのデプロイサイクルに従う必要があります。権限機能の実装が完了しても、コアサービスのデプロイタイミングまで待つ必要があり、価値提供速度を制約します。
これらの原因は、権限基盤の本質的な難しさを示しています。 tech.smarthr.jp
原因を解消する4つの要求
これらの原因を解消するために、以下の4つの要求を整理しました。
新機能を迅速に追加できること
権限基盤ユニットが個別に修正することなく、各プロダクトが必要とする新機能を素早く追加できる状態を実現します。
自律的に開発できること
各プロダクトチームが権限基盤ユニットへの実装依頼や調整を経ずに、自律的に権限機能を開発できる状態を実現します。
既存機能を容易に変更できること
既存機能の変更時に影響範囲が限定され、複雑性と認知負荷が低く、容易に変更を進められる状態を実現します。
迅速にリリースできること
権限機能の実装が完了したら、コアサービスのデプロイサイクルに依存せず、すぐにリリースできる状態を実現します。
要求から導出した4つの制約
これらの要求から、以下の4つの制約を導出しました。
共通化と分散化の両立
権限基盤全体として、共通化と分散化の両方に対応できるアーキテクチャを実現します。
現状のロール機能は、すべての権限制御を共通化する形で実装されています。しかし、プロダクトごとの多様な要件に対応するには、共通化と分散化の境界を柔軟に設定できる必要があります。この境界についての意思決定を遅延できる設計とし、当初は共通化を継続しつつ、ボトルネックが発生した場合に分散化へ移行可能な柔軟性を確保します。
具体的には、プロダクト間で共通する権限制御（従業員データへのアクセス制御など）は共通基盤が統一的に提供し、プロダクト固有の権限制御ロジックについては各プロダクトチームが自律的に開発・デプロイできるようにします。
プロダクトチームの自律性向上
各プロダクトチームが自律的に権限機能を開発・拡張できるアーキテクチャを実現します。標準的な権限管理は共通基盤の提供するAPIを利用することで実装依頼を減らし、プロダクト固有の権限ロジックはポリシーとして自律的に実装・デプロイできるようにします。権限基盤ユニットは共通基盤の提供に専念し、個別要件への対応を減らします。
これにより、開発の集中を解消し、プロダクト数が増加しても権限基盤ユニットの実装能力が律速要因にならない体制を実現します。
責務の明確な分離
各コンポーネントの責務を明確に分離し、影響範囲を限定できるアーキテクチャを実現します。権限データの管理とアクセス制御の判定を分離し、それぞれが独立した責務を持つようにします。各プロダクトのポリシーは独立して管理され、他のプロダクトへの影響を最小化します。データとロジックを疎結合にし、変更時の影響範囲を限定します。
これにより、複雑性と認知負荷を低減し、既存機能を容易に変更できる保守性の高いアーキテクチャを実現します。
独立したリリースサイクルの確保
権限基盤を独立したサービスとして構築し、コアサービスのデプロイサイクルに依存せず、権限機能を独立してリリースできるアーキテクチャを実現します。
権限基盤の新しいアーキテクチャ戦略
前述した4つの制約を実現する具体的な手段として、私たちは権限基盤をIAM基盤とアクセス制御基盤の2つに分けることにしました。
以下にシステム全体の構成を示します。
C4Context
title 権限基盤 - システムコンテキスト図
Person(role_admin, "ロール管理者", "ロールの作成・割り当てを行うユーザー")
Person(smarthr_user, "SmartHRユーザー", "コアサービスやプロダクトを利用するユーザー")
System(core_service, "コアサービス", "人事労務の基本機能を提供するWebアプリケーション")
System(plus_app, "プロダクト", "勤怠・手続きなどコアサービスと連携する各種機能を提供")
System_Boundary(permission_platform, "権限基盤") {
System(iam_platform, "IAM基盤", "ロール・操作権限の管理を担う独立したサービス")
System(access_control, "アクセス制御基盤", "ポリシー評価によるアクセス制御を提供")
}
Rel(role_admin, iam_platform, "ロール管理・操作権限管理")
Rel(smarthr_user, core_service, "機能利用")
Rel(smarthr_user, plus_app, "機能利用")
Rel(core_service, iam_platform, "権限データ参照")
Rel(core_service, access_control, "アクセス制御要求")
Rel(plus_app, iam_platform, "権限データ参照")
Rel(plus_app, access_control, "アクセス制御要求")
UpdateRelStyle(role_admin, iam_platform, $offsetX="0", $offsetY="-40")
UpdateRelStyle(smarthr_user, core_service, $offsetX="-40", $offsetY="20")
UpdateRelStyle(smarthr_user, plus_app, $offsetX="200", $offsetY="-20")
UpdateRelStyle(core_service, iam_platform, $offsetX="-40", $offsetY="-16")
UpdateRelStyle(plus_app, iam_platform, $offsetX="120", $offsetY="10")
UpdateRelStyle(core_service, access_control, $offsetX="99", $offsetY="-50")
UpdateRelStyle(plus_app, access_control, $offsetX="160", $offsetY="-20")
IAM基盤は、権限データの管理を担当します。IAM（Identity and Access Management）は、「誰が」「何に」「どうアクセスできるか」を管理する仕組みです。IAM基盤は、ロールや権限設定といった権限データを一元管理し、Web UIとAPIを通じてコアサービスやプロダクトに提供します。
アクセス制御基盤は、ポリシー評価による認可判定を担当します。IAM基盤が管理する権限データを評価することで、RBACやACLなど特定の権限モデルに依存しない柔軟なアクセス制御を実現します。プロダクト固有の権限ロジックをポリシーとして記述し、自律的にデプロイできます。
アクセス制御基盤についてこちらの記事も参照してください。 tech.smarthr.jp
この役割分担により、4つの制約を実現します。
まず、共通化と分散化の両立を実現します。IAM基盤がプロダクト間で共通する権限データを統一的に管理し、各プロダクトチームはプロダクト固有の権限ロジックをポリシーとして記述し、自律的に開発・デプロイできます。
次に、プロダクトチームの自律性向上を実現します。管理者はWeb UIからロールの作成や権限設定を行い、各プロダクトはIAM基盤のAPIを通じて権限データを参照できます。標準的な権限管理についての実装依頼が減り、プロダクト固有の権限ロジックはポリシーとしてCI/CD経由で自律的に実装・デプロイできます。
さらに、責務の明確な分離を実現します。IAM基盤は権限データの管理に専念し、アクセス制御基盤はポリシー評価に専念することで、それぞれが独立した責務を持ちます。各プロダクトのポリシーは独立して管理され、他のプロダクトへの影響を最小化します。
最後に、独立したリリースサイクルの確保を実現します。IAM基盤をコアサービスから独立したサービスとして構築することで、コアサービスのデプロイサイクルに依存せず、権限機能を独立してリリースできます。
まとめ
本記事では、SmartHRの権限基盤が直面していた課題、それを解決するために策定したアーキテクチャ戦略、そしてその具体的な手段としてのIAM基盤の設計について紹介しました。
マルチプロダクト戦略の推進に伴い、権限基盤ユニットが開発のボトルネックとなっていました。この課題に対し、私たちは4つの制約（共通化と分散化の両立、プロダクトチームの自律性向上、責務の明確な分離、独立したリリースサイクルの確保）を設定し、目指すべきアーキテクチャの方向性を明確にしました。
IAM基盤の構築は、この戦略を実現しようとする具体的な手段です。集中型から分散型開発フローへの移行により、各プロダクトチームが権限機能を自律的に開発できるようにし、エンドユーザーへの価値提供速度を向上させることを目指しています。
今後も、IAM基盤の構築を進め、その過程で得られた知見を共有していきたいと考えています。
We Are Hiring!
権限基盤ユニットでは、一緒にSmartHRの成長を加速させてくれるプロダクトエンジニアを募集しています。
権限管理、アクセス制御といったドメインを中心に、プロダクト横断で組織やシステムに影響を与える基盤を設計・開発・運用しています。 権限基盤は技術的に難易度が高く、試行錯誤の連続ですが、ソフトウェアエンジニアとして大きなやりがいと成長機会がある環境です。
少しでも興味を持っていただけましたら、ぜひカジュアル面談でお話ししましょう。
