この記事は何？
自部門でのAWS SSOを導入するにあたって、チームや部門を超えての取り組みを行ったのでその振り返りをまとめています。
※振り返りを主題としており、AWS SSOの設計や実装については触れていません。
あなたは誰？
株式会社グロービスのデジタルプラットフォーム部門（以下、GDP）でSite Reliability Engineerをしており、AWS,K8s(EKS)周りを中心に扱っています。クラウドインフラ分野を主軸と置きつつ、プロダクト開発チームと一緒に運用・監視の改善やインフラリソースへの扱いに対する心理的ハードルを下げる取り組みをしています。
何をしたの？
私が所属するGDPでのAWSユーザー管理運用においてAWS SSOを導入し、全社共通のIDaaSであるOneLoginと連携しました。
※開発チームへの影響などを鑑みて、正確にはまだSRE内での試運転中のため部門内のエンジニア全員が利用できる状態ではありません（小声）。
背景として、GDP管轄のプロダクトに関連するAWSアカウント自体はSREが管理していますが、OneLogin自体の管理や入社・退職などに伴う社員のアカウント管理フローはGDP内のIS（Information System、一般的に情シスと言われる分野の業務を担当）チームや会社全体のIS部門が担当しています。そのためAWS SSOを導入するにあたっては、ユーザーアカウント管理に関わる業務フローを理解し、関係者の合意の上でフローを変更する必要があります。
今回の取組には2部署3チーム(うち1チームはSRE)に関わっていただきました。実施した事項についてはざっくり以下です。
- AWS SSO導入方法の案まとめ
- 導入のHowとしてどのような実装・運用案があるか
- それぞれの案に対するメリット・デメリットはなにか
- ユーザーアカウント管理に関連する既存の業務フローの理解
- どの部署・どのチームがいつ何をトリガーとして何を実施しているか
- 今回の対応に伴う業務フロー変更の落とし所の合意
- 既存の業務フローにマッチするAWS SSO導入案を決める
- 今回の対応に伴ってどの部署・どのチームがいつどんなケースで何を行うか
- 導入に向けて実施することの整理と実施
- どの部署・どのチームがどのタイムラインで何を実施していくか
学んだこと
全体像の把握を通して共通認識を構築する
複数部署・チームに影響のある取り組みについては、特定の部署・チームの都合に合わせた個別最適ではなく全体としてより良い形に落とし込むための視点が重要です。
SREにだけ最適化されたオレオレ運用フローを組んだところで、他部署・チームにしわ寄せが及んで手間が増えてしまっては全体としての嬉しさは減ります（なんなら、組織全体としては「元の運用フローのほうが遥かに良かった」となりかねません...）。
今回の取組においてAWS SSO導入についての具体的なHowの部分については、SRE内でAWS SSO運用経験のある同僚がいてくださることや、クラスメソッドなどの良質な技術ブログが存在するためほとんど心配ありませんでした。
一方で既存のユーザーアカウント管理の流れや、OneLoginのRole管理粒度・作成フロー、OneLoginユーザーとOneLogin Roleとのひも付きタイミングなどについての理解が重要でした。
そこで既存のユーザーアカウント管理の業務フロー図を各部署・チームからいただき、それを元にして今回の対応に伴う追加の影響箇所・事項を加筆しました。
また変更に伴う影響範囲の全体像について各部署・チーム間で共通認識を持ったうえで取り組むことで、組織全体としてのより良い運用の姿が見えてきました。全体像について関係者全員が共通認識を持つことの重要性を改めて実感しました。
相手の関心事を理解する
ある業務フローについて、そのフローの中のどの観点にフォーカスしたいか・するべきかは部署・チームによって異なります。
例えば今回の件では、SREとしてはOneLoginからSCIMプロビジョニングされるところ以降について最も関心がありますが、ユーザーアカウント管理をしていただいている部署・チームは入社・退職などを含むユーザーアカウントのライフサイクル全体に対して関心があります。
部署・チームによって関心事が異なる中で物事を進めていくには、（自分の関心事について考えることはもちろんとして）相手の関心事についても理解し、どうすると全体としてより良くなるかを一緒に考えていくことが重要であると感じました。前述の通り全体像の把握と共通認識の構築が大事になりますが、その根底として相手の領域についても知ろうとする姿勢が大事であると思いました。
関係者内でのお互いの関心事について理解を深めることで、自身の領域についても相手の事情を考慮した上でのより良い運用が見えてきて、それが結果として組織全体の最適化に繋がっていくのではないかと思いました。
小さく始める
複数の組織に影響がある物事を進めていくにあたって、最初から完全な世界を達成しようとすると途方もない労力がかかると感じました。
例えば今回の件については、より本質的にはOneLoginを利用したSSOログインを部門内の標準としてAWSを含めた各種SaaSに展開していくことが組織全体として重要な事項になってきます。
これを一度に達成するにはあまりにもスコープが大きいため、 GDP内のAWSユーザー管理運用をAWS SSOに統一すること を目先の目標としつつ、更にその前段のステップとして（開発チームに横展開できるフローの大枠を抑えつつも） SRE内で利用できるフローを確立すること でした。
現状と最終ゴールを抑えてステップを踏んで一歩ずつあるべき姿に進んでいくことで、PDCAサイクルを小さく回して次ステップへの改善に活かせ、また達成感も得られやすいと感じました。
また影響を受ける部署・チームでも段取りが必要になるため、組織全体として負荷や混乱を招かない形で進めていけることもメリットだと感じました。
まとめ
大きな組織では関わる部署やチームが多く、特にID管理・認証認可・クラウドインフラの分野における取り組みが及ぼす影響が非常に大きいです。
そんな中で全体像を把握してお互いの見る世界を理解したうえで一歩ずつ進めていくことで、少しずつ理想の状態に近づいていくのだと感じました。
これからも一歩ずつ着実に進んでいければと思います。
Discussion