システム開発部SREチーム、マネージャーのm-nemotoです。
2021/08からチームのマネージャーとなり、約1年が経ちました。
前任者が築いてくれた基盤や制度を引き継ぎつつ、一方ではチームの課題にゼロから向き合った1年でした。
本記事では、これまでのチームの課題と、これからチームが何を目指していくかをご紹介できたらと思います。
これまでのチームの課題
これまでのSREチームでは、SREメンバーがプロジェクトの一つを担当し、インフラの構築〜運用を実施する、という業務内容でした。よくある「インフラ色が強い」SREチームだったと思います。
当然といえば当然なのですが、インフラチームとして活動することで「インフラ技術がサイロ化してしまう」という課題が生じました。DevOpsを実現するためのSREチームがDevOpsを阻害する、という中々クリティカルな課題でした…。
それだけではなく、SREメンバーが特定のプロジェクトを担当することで、トラック係数の問題、実施した改善事項を他プロジェクトに展開できない (しづらい)、DevOpsの成熟度がチームによってまばら、といった課題も発生しました。
上記の問題を解決するためには「チームの目標を見直した方がいいのでは」という結論に至り、私たちはチームの目標とミッションを再検討しました。
チームの目標とミッション
検討に使用した資料や書籍、ウェビナーの一部をご紹介します。
(いずれも素晴らしい資料でチームの成長に欠かせないものでした。資料を公開してくださった著者、関係者の方々にこの場を借りてお礼申し上げます！)
- How Google SRE And Developers Collaborate
- DevOps vs. SRE vs. Platform Engineering? The gaps might be smaller than you think
- AWS Well-Architected Framework
- The DevOps ハンドブック 理論・原則・実践のすべて
- チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計
- SRE Next
- Forkwell公式 ITエンジニアのキャリアと学び
上記の資料を元に (ときにチームで輪読会を実施) 検討を続け、チームの目標を「DeveloperExperienceを最大化することでプロジェクトに貢献する」としました。また、ミッションを以下に絞りました。
◇ Platform SRE
開発チームが利用するインフラ環境を構築し、積極的にインフラの標準化を図ります。
標準化によって、実装コストの削減、改善事項の横展開、オンボーディングコストの削減などを改善します。
また、標準化したプラットフォームをSREチームの成果物として扱い、利用者に迅速なフィードバックを行います。
◇ DevOps (Embedded SRE)
SREメンバーが開発チームに参加し、DevOpsに基づいた改善を行います。
具体的には、DORA Metrics、バリューストリーミングマップを可視化し、開発チームのDevOpsパフォーマンスを測定します。
測定結果からボトルネックを把握した後は、チームの垣根を超えて、改善活動を行います。
行った改善活動はPlatform SREで巻き取り、組織全体への適用を検討します。
◇ ツール管理
Platform SREのミッションと重なるところはあるのですが、開発部で使う共通ツールの管理をSREで担当します。
クラウド管理や自動化などの改善を行い、運用コストを削減します。
今後
目標をチームメンバー全員で検討したため、目標設定が決まるや否やすぐにアクションに繋げることができました。
現在、Platform SREでは標準となるアーキテクチャの検討とIaCのコーディングルールなどの整備を行っています。DevOpsに関しては早速開発チームに参加し、DevOps関連のメトリクスを可視化できるよう準備中です。
実施したタスクについては本ブログで発信していけたらと思います。
最後に
これまでインフラ色が強かったSREチームですが、これからはSREの本来の目的に立ち返りDevOpsの推進と部全体の最適化を行うチームになりたいと思っています。
目標の変更は、開発部メンバーの協力なしでは設定できない目標でした。
負荷になってしまうところもあったかもしれませんが、快諾してくださった開発部メンバーには頭が上がりません。
そんな素敵なメンバーと一緒に仕事をしたいという方がいましたら是非募集要項をご覧ください！
