完璧を求めない意思決定-アクセス制御基盤における制約との向き合い方

アーキテクチャConference2025の【公募セッション】アーキテクチャの選択 ー ＜悩んだこと・変えたこと＞での登壇資料です。
https://architecture-con.findy-tools.io/2025?m=2025/session/mdl/vQ5YaPtw

テックブログのリンクは以下です。
https://tech.smarthr.jp/entry/2025/11/14/121715

Transcript

1. © SmartHR, Inc. 完璧を求めない意思決定 アクセス制御基盤における制約との向き合い⽅ ⽵内 健太 / X @bmf_san SmartHR プロダクト基盤開発本部 権限基盤ユニット 2025/11/20 アーキテクチャConference 2025
2. 本⽇お話すること • マルチプロダクトSaaSで⽣じた権限管理のボトルネック • 理想的な解決策と、それを阻む3つの制約 • 制約を受け⼊れたポリシーベースアーキテクチャの選択 • 完璧を求めない意思決定と制約との向き合い⽅ 2
3. マルチプロダクトSaaSで ⽣じた権限管理のボトルネック
4. SmartHRのマルチプロダクト戦略 • SmartHRは⼈事労務を中⼼としたマルチプロ ダクトSaaS • 各プロダクトで「誰がどのデータにアクセス できるか」の制御が必要 • 権限基盤はロールベースのアクセス制御を担う 4
5. 権限基盤のミッション • 開発効率 • 統⼀的なユーザー体験 • セキュリティ 5
6. 浮上した課題 ⸺ 開発効率の低下 • 問題 ◦ プロダクト数の増加に伴い、権限機能の要求が集中 • 結果 ◦ 権限基盤チームがボトルネックに • 影響 ◦ プロダクトチームの開発を妨げてしまう 6
7. 改善前のアーキテクチャ（中央集権型） 7
8. 改善前のアーキテクチャ（中央集権型） 8 • 責務の密結合 • 開発負荷の集中 • プロダクト固有要件への対応困難
9. 理想的な解決策と それを阻む3つの制約
10. 理想的な解決策を描く • 理想的なアプローチ ◦ 新しいロール管理基盤を構築 ◦ ロール管理とアクセス制御を完全に分離 ◦ 各プロダクトが独⾃のポリシーを持つ ◦ プロダクトチームが完全に⾃律的に開発 10
11. しかし、現実には制約がある • UIの変更制限 ◦ データモデル変更によりUI影響は不可避 • 短期での価値提供 ◦ 理想的アプローチの機会コストが⼤きすぎる • 段階的移⾏ ◦ ユーザー体験への影響を⼩さく検証したい 11
12. 制約を受け⼊れた ポリシーベースアーキテクチャ の選択
13. 完璧 vs 現実 制約を「障害」と⾒るか、 「設計のパラメータ」と⾒るか？ • 完璧を追求すると‧‧ ◦ 制約は「障害」 • 現実的な価値を追求すると‧‧ ◦ 制約は「設計のパラメータ」 13
14. ポリシーベースアーキテクチャの採⽤ • 現実的なアプローチ ◦ 既存UIを維持したまま、ポリシー層だけ追加 ◦ 段階的な責務分離 ◦ ボトルネックの緩和 ◦ 将来への選択肢を残す 14
15. 改善後のアーキテクチャ（ポリシーベース） 15
16. 改善後のアーキテクチャ（ポリシーベース） 16 • コアサービス ◦ ロール管理 + データ取得 • アクセス制御基盤 ◦ ポリシー評価のみ
17. OPA（Open Policy Agent）の採⽤ • OPAを選んだ理由 ◦ CNCF Graduated Project ◦ 豊富な実績とエコシステム ◦ ⾼パフォーマンス‧⽔平スケーラビリティ 17
18. OPA（Open Policy Agent）の採⽤ • OPAを選んだ理由 ◦ CNCF Graduated Project ◦ 豊富な実績とエコシステム ◦ ⾼パフォーマンス‧⽔平スケーラビリティ 18 # 例: 管理者は全従業員にアクセス可能 allow { input.user.roles[_] == "admin" input.resource.type == "employee" }
19. ⽬指す3つの価値 • ボトルネックの緩和 ◦ アクセス制御ロジックの責務を切り出し • 学習機会の確保 ◦ 実運⽤を通じたベストプラクティスの蓄積 • 将来への選択肢の確保 ◦ 意思決定を遅延させ、柔軟性を保つ 19
20. 意思決定の遅延 今決めるべきこと • ポリシーベースアーキテ クチャの採⽤ • ボトルネック緩和という 喫緊の課題への対応 将来に委ねること • 新しいロール管理基盤へ の移⾏ • 完全な責務分離 • ポリシーの分散管理 20
21. 完璧を求めない意思決定と 制約との向き合い⽅
22. まとめ • 制約を明確に定義する ◦ 何を制約とするか、何に挑戦するか • 制約を設計のパラメータとして受け⼊れる ◦ 障害ではなく、設計の前提条件 • 意思決定を遅延させる ◦ 今必要な価値を提供し、将来の選択肢を狭めない 22
23. ブログ 完璧を求めない意思決定 ⸺ アクセス制御基盤における制約との 向き合い⽅ https://tech.smarthr.jp/entry/2025/11/14/121715 23
24. © SmartHR, Inc. © SmartHR, Inc. We are hiring ! https://hello-world.smarthro.co.jp/
25. ご清聴 ありがとうございました！ 25