権限基盤アーキテクチャチームの挑戦 —— Policy-as-Codeで実現するアクセス制御

こんにちは。SmartHRでプロダクトエンジニアをしている @bmf_san です。

SmartHRでは、2025年に権限基盤ユニット内に「アーキテクチャチーム」を新たに立ち上げました。このチームは、SmartHRがマルチプロダクト戦略を実現し、すべてのプロダクトが安全かつ自律的に価値を届けられる環境を構築するために重要な役割を持ちます。

この記事では、SmartHRのマルチプロダクト戦略を支える権限基盤の課題解決に向けて新設されたアーキテクチャチームの組成背景、私たちのミッション、Policy-as-Code（権限設定をコードとして管理する手法）を中核とした現在の取り組みとその挑戦について紹介します。

SmartHRの成長に伴う権限管理の複雑化

SmartHRは、人事・労務管理のクラウドサービスとして多くの企業に利用されています。近年、私たちはマルチプロダクト戦略を推進し、人事・労務領域の様々な課題を解決する複数のプロダクトを展開しています。しかし、この成長に伴い、一つの大きな技術的課題が浮上してきました。それが「権限管理の複雑化」です。

従来、各プロダクトが独自に権限機能を実装していた結果、権限ロジックの重複、プロダクト間での仕様の不整合、開発・運用コストの増大といった問題が顕在化しました。

この問題構造を図示すると、以下のような状況が見えてきます。

---
title: 従来の権限管理における問題構造
---
graph TD
    A[プロダクトA] --> D[独自権限実装A]
    B[プロダクトB] --> E[独自権限実装B]
    C[プロダクトC] --> F[独自権限実装C]

    D --> G[権限ロジック重複]
    E --> H[仕様不整合]
    F --> I[運用コスト増大]

    G --> J["同じ従業員データに対して<br/>異なる権限設定"]
    H --> J
    I --> J

    style G fill:#ffcccc
    style H fill:#ffcccc
    style I fill:#ffcccc
    style J fill:#ffe6e6

図では、プロダクトA、B、Cがそれぞれ独自の権限実装を持ち、それが権限ロジックの重複、仕様の不整合、運用コストの増大という問題を引き起こし、最終的に同じ従業員データに対して異なる権限設定が生まれる構造を表現しています。

「この従業員データを誰が見ることができるのか？」「この操作を実行する権限があるのか？」といった基本的な問いに対する答えが、プロダクトごとに異なる実装で管理されている状況でした。

課題解決に向けた権限基盤のグランドデザイン策定

これらの課題を根本的に解決するため、私たちは「権限基盤のグランドデザイン」を策定し、中長期的なアーキテクチャ戦略を明確にしました。このグランドデザインでは、単なる技術的な改善にとどまらず、組織全体の権限管理のあり方を見直し、5年後、10年後を見据えた持続可能なアーキテクチャの方向性を描きました。

グランドデザインの策定過程では、各プロダクトチームへのヒアリング、既存システムの詳細な分析、技術調査を実施し、SmartHRにとって最適な権限基盤のあり方を検討しました。その結果、Policy-as-Codeを中核とした新しいアーキテクチャと、段階的な移行戦略が明確になりました。

グランドデザインで描いた新しいアーキテクチャの全体像を図示すると、以下のような構成になります。

---
title: Policy-as-Codeアーキテクチャの全体構成
---
graph LR
    A[各プロダクト] --> B[権限基盤API]
    B --> C[ポリシーエンジン]
    C --> D[宣言的ポリシー]
    D --> E[Git管理]
    E --> F[CI/CD<br/>テスト・デプロイ]
    F --> C

    G[ビジネスルール変更] --> D
    H[レビュープロセス] --> E

    style C fill:#e1f5fe
    style D fill:#f3e5f5
    style F fill:#e8f5e8

この図は、各プロダクトが権限基盤APIを通じてポリシーエンジンにアクセスし、宣言的ポリシーがGit管理され、CI/CDパイプラインでテスト・デプロイされる流れを示しています。ビジネスルールの変更は宣言的ポリシーに反映され、レビュープロセスを経てGit管理されます。

このアーキテクチャの中核となるのが「ポリシーエンジン」です。ポリシーエンジンとは、権限設定を宣言的に記述・実行するエンジンのことで、各プロダクトからの権限チェック要求を受けて、宣言的に定義されたポリシーに基づいて判定を行います。

戦略実現のためのアーキテクチャチーム組成

権限基盤は、各プロダクトが安全にデータや機能を連携するための土台となります。また、それだけでなく、権限基盤は各プロダクトの開発効率を高める役割も持ちます。

共通利用する権限機能を基盤化することで、各プロダクトは複雑な権限ロジックを個別に実装する必要がなくなり、それぞれの領域の開発に集中できます。そうすることで、新規プロダクトの高速な立ち上げや日々の開発効率の向上も期待できますし、権限基盤の統一化により、一貫した権限管理を全プロダクトで実現できるようになります。

これらの開発は、これまでも継続的に取り組んできました。内部的には将来プラットフォーム化することを見込んでアーキテクチャを設計してきており、各プロダクトの権限機能も一定の共通化を進めてきました。

しかし、領域を超えてプロダクトを提供して初めて学習できた課題や、実際の運用によって学習できた課題も多くあり、課題は山積みです。

それらの課題を解決し、マルチプロダクト戦略の実現に向けて強い権限基盤を作っていくため、グランドデザインで描いた戦略を実現する専門性と責任を持つチームとして、権限基盤ユニット内に独立した「アーキテクチャチーム」を新たに組成しました。

新たに組成されたアーキテクチャチームが何を目指し、どのような価値観で活動しているのか、ミッション・ビジョン・バリューを順に紹介します。

ミッション

権限基盤のボトルネックを"緩和"し、ポリシーベースのアクセス制御を組織に定着させることで、すべてのプロダクトが安全かつ自律的に価値を届けられるようにする

私たちが特に重視しているのが「緩和」という表現です。これは、権限基盤の課題を一度に完全解決することは現実的ではなく、段階的な改善を通じて着実に価値を提供していくという考え方を表しています。

ビジョン

マルチプロダクト戦略を支える、高可用・高性能なアクセス制御基盤を実現する

SmartHRが複数のプロダクトを展開する中で、権限基盤は単一障害点となってはいけません。高可用性を保ちながら、高速な権限チェックを実現することで、ユーザー体験を損なうことなく、安定した権限管理を提供します。

バリュー

アーキテクチャチームが大切にしているバリューは、次の5つです。

Policy-as-Code First

ポリシーはコードとして管理し、レビュー・テスト・CI/CDを通じて品質とスピードを両立する

従来の権限管理では、複雑なビジネスルールがアプリケーションコード内に散在し、変更時の影響範囲が把握困難でした。発足したアーキテクチャチームでは、権限ルールを宣言的なポリシーコードとして管理し、通常のソフトウェア開発と同様の品質管理プロセスを適用することを重視しています。

Decoupling & Enablement

責務分離によるボトルネックの削減と同時に、各プロダクトが自律的に権限機能を実装できるよう支援する

権限基盤チームが全ての権限実装を担当するのではなく、各プロダクトチームが自律的に権限機能を開発できるよう、SDK、ドキュメント、ベストプラクティスを提供する方針を大切にしています。これにより、開発速度の向上と責任の明確化を両立することを目指しています。

Pragmatic Incrementalism

完全解決ではなく段階的緩和を選択し、リスクを抑えつつ短サイクルで価値を届ける

理想的なアーキテクチャを一度に実現するのではなく、現実的な制約の中で最大の価値を生み出すアプローチを重視しています。小さな改善を積み重ね、フィードバックを得ながら次の改善につなげる文化を大切にしていきます。

Reliability & Security by Design

セキュリティと可用性は後付けせず、設計段階から織り込み、SLO達成を最優先事項とする

権限基盤は、全てのプロダクトが依存する重要なインフラです。チーム発足時から、設計段階からセキュリティと可用性を考慮し、明確なSLO（Service Level Objective）を設定して、その達成を最優先に開発・運用を行うことを大切にしています。

Open Communication

インセプションデッキなどのドキュメントを常に最新に保ち、ステークホルダーと透明かつ迅速な対話を実践する

技術的な意思決定の背景や進捗状況を、ステークホルダーと積極的に共有することを重視しています。インセプションデッキ、ADR（Architecture Decision Records）、定期的な報告会を通じて、透明性の高いコミュニケーションを心がけていきます。

アーキテクチャチームの現在の取り組み

グランドデザインで描いた戦略を具体的な実装に落とし込むため、現在私たちは以下の取り組みを重点的に進めています。

Design Doc策定フェーズ（現在）

技術的な意思決定についてはADRを作成し、その決定事項を踏まえてDesign Docの策定を進めています。ポリシーエンジンの技術選定、データモデル設計、API設計など、新しい権限基盤の核となる部分について、まずADRで技術選択の背景と根拠を明確にした上で、詳細設計をDesign Docに落とし込んでいます。

今後のロードマップ

Design Doc完成後は、ざっくりとしたスケジュールイメージとして、以下のようなステップで段階的に進めていく想定です。

---
title: 権限基盤開発のロードマップ
---
timeline
    Phase1 : Design Doc策定
           : ポリシーエンジン技術選定
           : データモデル設計

    Phase2 : スケルトン開発
           : 技術的実現可能性検証
           : 基本アーキテクチャ実装

    Phase3 : 本格開発フェーズ
               : 段階的機能追加
               : リリース可能バージョン構築

    Phase4 : 移行計画策定・実施
            : 段階的移行
            : 本格運用開始

このタイムラインは4つのフェーズで構成されています。Phase1ではDesign Doc策定とポリシーエンジンの技術選定、データモデル設計を行い、Phase2でスケルトン開発と技術検証、Phase3で本格的な開発と機能追加、Phase4で移行計画の策定と実施、本格運用開始という流れになっています。

これらの計画は大まかな方向性を示すものであり、各ステップでのフィードバックや状況変化に応じて柔軟に調整していく予定です。