この記事は何？
この記事は GLOBIS Advent Calendar 2024 22日目の記事です。
グロービスのSREチームでは、SRE・クラウドインフラ領域についての知見共有や技術移譲のために、プロダクト開発チームとのモブプログラミングを活発に実施しています。本記事ではモブプログラミングの取り組みについて紹介します。
あなたは誰？
株式会社グロービスのデジタルプラットフォーム部門（以下、GDP）でSite Reliability Engineerをしており、AWS,K8s(EKS)周りを中心に扱っています。クラウドインフラ分野を主軸と置きつつ、プロダクト開発チームと一緒に運用・監視の改善やインフラリソースへの扱いに対する心理的ハードルを下げる取り組みをしています。
https://speakerdeck.com/globis_gdp/globis-sre-team-is-hiring
前提
プロダクト開発チームとSREの立ち位置
SREは各プロダクト開発チームから独立した1つのチームとして事業部内に存在しており、一方でプロダクト開発チームは複数存在しています。SREチームだけですべてのプロダクトの信頼性向上を担うことは現実的ではないため、各プロダクト開発チームに対してイネイブリング活動を行っています。
GDP SREの役割
SREの役割は 各プロダクト開発チームが、自律的にプロダクトの開発生産性向上や信頼性の維持といった活動を実施できる環境づくり を行うことです。SREの領域は広範囲に及ぶため、PlatformとCollaborationという2つのユニットに分かれて活動しており、本記事では主にCollaborationユニット（以下、Collaboration SRE）の活動を取り上げます。
Collaboration SREの活動骨子となるVision/Valueについては以下の記事を参照ください。
SREとモブプログラミング
プロダクト開発チームが効率的に開発・運用を行えるよう、Collaboration SREはプロダクト開発チームの状況に適した仕組みや知見の共有を行っています。具体的な取り組みとして、プロダクト開発チームとのモブプログラミングを通じて、クラウドインフラや監視などに対する機能追加・改修を実施しています。
目的
すべての取り組みは、冒頭で述べた各プロダクト開発チームが、自律的にプロダクトの開発生産性向上や信頼性の維持といった活動を実施できる環境づくりという目標達成に向けられています。
モブプログラミングを通じて、プロダクト開発チームは自身のプロダクト運用に必要な対応を自律的かつ自発的に実施できるようになります。これにより、SREがボトルネックとなることなく、組織全体がより効率的にプロダクト信頼性向上に取り組むことができます。
さらに、モブプログラミングを通じてチーム間の関係性を深めることで、運用改善や機能開発についてプロダクト開発チームがSREと早期段階から協力しやすい雰囲気作りにも繋がります。
どんなことをしているか
Collaboration SREがプロダクト開発チームと一緒に実施していることは主に以下です。モブプログラミング（プロダクト開発チームから依頼を頂いたり、SREから提案したりとどちらのケースもあります）が中心ではありますが、プロダクト開発チームが効率的にプロダクト運用を実施できるようにするためのサポート的な施策も実施しています。
- モブプログラミング系
- Kubernetes関連のリソース追加・編集
- AWS関連のリソース追加・編集
- Datadog監視の追加・修正
- 障害・不具合と思われる事象についてプロダクト開発チームと一緒にライブ調査会
- プロダクトのクラウドインフラ関連（AWS, Kubernetes, Argo CDなどの関係性など）の知見共有会
モブプログラミングの形式としてはドライバー（プロダクト開発チームから一人）とナビゲーター（Collaboration SREから一人）とガヤ（その場に参加している人）に分かれて実施します。モブプログラミングの形式やお作法そのものは今回の本質ではないため、あくまでも知見共有や技術移譲を目的として、みんなでワイワイやろうという雰囲気で実施しました。
心がけていること
プロダクト開発チームの心理的ハードルを下げる
誰しも、普段扱い慣れない分野のコードを変更することには大きな心理的ハードルがあります。たとえその分野のコードに対する編集権限や解説ドキュメントが整備されていても、プロダクト開発チームとしては「これで本当に正しいのだろうか？」「そもそもアプローチは適切なのか？」といった不安を感じます。
逆に一度でも実際に手を動かす経験をすることで払拭される不安要素は大きいため、最初の一歩に対する心理的ハードルを下げることが重要であると考えています。そのためにモブプログラミングを通して一緒に手を動かすことで全体の雰囲気を感じてもらっています。
チームを越えての取り組みはどうしても気を使うケースが多いため、できる限りフットワーク軽く とりあえず一緒にやってみよう！ というノリを大切にしています。
(例1)
(例2)
また、仕組み・原理をガチガチに則るのではなく、あくまでも雰囲気を掴む第一歩としています。余談・雑談を含めつつ、
((私が雰囲気でKustomize書いてる事がバレたときのリアクション))
構成全体の共通認識を作る
信頼性の高いプロダクト運用を実現するには、コードの修正箇所を把握するだけでは十分ではありません。プロダクトが稼働するエコシステムの全体構成を理解することで、障害対応をより効率的に行えるようになったり、今後の運用効率化のためのヒントも得られます。
プロダクト開発チームとSREの双方がシステム全体の構成や処理の流れを把握することで、より効果的な協業へと繋がります。
Collaboration SREがモブプログラミングをする際には、修正するコードの箇所や書き方（例：TerraformやKustomizeの書き方）に始終するのではなく、プロダクトを支えるクラウドインフラがどのように動いているのかについても説明をします。
例えばKubernetesマニフェストに関連するモブプログラミングを実施する際には、コードの書き方に加えてAWS・Kubernetes・GitHubの関係性についての知見共有会を行いました。
後から見返せるようにNotionで簡単なドキュメントを作成し、クラウドインフラ全体の構成図を超ざっくり図解しました。なんとなくでも良いので全体の流れをイメージできると、どこに対して変更が必要であるか、不具合がどこに起因しているか、などに結びつけられるため今後の運用で効果を発揮します。
感想
プロダクト開発チームとのモブプログラミングを通して、単なるコーディングの知見共有に留まらず、プロダクトを動かすクラウドインフラ全般についての共通認識の構築に効果的であると感じました。
また一緒にワイワイと時間を共有することでチーム間の関係性がより強固なものになったと感じます。この取り組みを通して今後も継続してチームを越えた連携が取れていくのではないかと思います。一度でも一緒に協業することを通して得られる安心感（相手を知っているという安心感？）は非常に大きいと思いました。
月に一度開催される事業部の全体会で、プロダクト開発チームがモブプログラミングの取り組みについて発表してくださいました。プロダクト開発チームが自律的・主体的にプロダクトを改善することで、組織全体の運用水準とケーパビリティが向上し、非常に良い方向に進んでいると感じています。
積極的に協力してくれるプロダクト開発チームに感謝するとともに、今後も組織全体の運用改善に取り組みたいです。
Discussion