コンテンツに移動
DevOps & SRE

博報堂テクノロジーズによる SRE の活⽤とその変⾰的影響

2024年9月4日
鈴木 幹昌

株式会社博報堂テクノロジーズ, マネジメントセンターインフラ開発一部 CCoE チームリーダー

近藤 卓未

株式会社博報堂テクノロジーズ, マネジメントセンターインフラ開発一部 CCoE チーム Tech リード

Join us for Gemini at Work

Learn how Gemini can help your business at our digital event

Register

※この投稿は米国時間 2024 年 8 月 13 日に、Google Cloud blog に投稿されたものの抄訳です。

株式会社博報堂テクノロジーズは、マーケティング × テクノロジーの⼒で、社会と⽣活者に新しい価値や体験を提供するために、博報堂DYグループのテクノロジー戦略会社として、開発体制を集結し、体制強化・進化を⽬的として設⽴されました。

我々博報堂テクノロジーズのインフラ部隊は、博報堂DYグループのビジネスを構成する各種サービスが稼働するパブリック クラウドを安定的に運営し、パブリック クラウドの知⾒提供や運⽤⽀援を⾏う横断的組織です。

クラウド、インフラ領域のプロフェッショナルであること、オーナーシップを発揮すること(⾼い当事者意識を持っていること)、新しい価値の創出に果敢にチャレンジすることをバリューに、⽇々エンジニアリング活動に取り組んでいます。

背景と課題

インフラチームでは、社内の組織やサービスごとに存在するアプリケーションのインフラや、共通利⽤インフラの開発・運⽤を担当しています。当チームは、プラットフォーム エンジニアリング & SRE の思想に基づいた活動を⾏っています。これまでも SRE の要素を各⾃が部分的に取り⼊れており、ポストモーテムの実施やオブザーバビリティの仕組みの構築などを推進してきました。しかしながらチームには主に 2 つの課題がありました。

  • インフラ システムの規模拡⼤に伴い、急速にチームの⼈員が増えました。さまざまなバックグラウンドを持つメンバーが新たに参画したことにより、やるべきことを明確化・共通化し、チームとして現状の把握と⽬指すべきゴールの⽬線を合わせることが必要でした。

  • アプリチームとは、主にチケットベースでコミュニケーションを取っています。⼈員の拡⼤だけでなく、テレワーク中⼼の業務体制も導⼊しているため、お互いをあまり知らない状況が⽣じています。⼩さな認識のズレが⼤きなひずみに発展する可能性がありました。

システムや組織が拡⼤していく中で、インフラチーム内でのメンバー間ならびにアプリチームとの共通認識および協⼒関係の強化が、私たちのビジネスとしての持続的な成⻑に必要なコア要素であると考えました。

そこで、SRE のマインドセットをインフラとアプリの両⽅のメンバーで理解し、共通の認識に基づいたカルチャーを醸成するきっかけとすることが、上記の課題を解決するための不可⽋な要素であると考えました。そのため、Google Cloud Consulting が提供する SRE の最初のステップである「SRE Core」プログラムを利⽤することにしました。

変化

まず「SRE Core」プログラムを通して、今まで接点が薄かったアプリチームとインフラチームのコミュニケーションを活性化できました。具体的な例として、本プログラムに取り組むにあたって必要な情報をインフラ メンバーのみでは収集・把握することが難しい部分があり、アプリチームとの協⼒が不可⽋でした。

SRE の指標の⼀つである CUJ は、アプリのビジネス要件や実利⽤者の⾏動を元に設定しますが、通常、このような内容はビジネスサイドとコミュニケーションを取る機会が多いアプリチームが握っています。今回、CUJ 制定・SLI/SLO 設定(エラー バジェットを含む)・リスク分析設定と SRE に必要な設計をアプリチームとともに作り上げていきました。この共同作業と共通認識の醸成が起点となり、アプリチームのみで実施していたスプリント ミーティングにインフラ メンバーも参加するなど、よりコラボレーティブな協業関係がプログラム終了後も続いています。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Hakuhodo_-_Next_Tokyo.max-2200x2200.png

またインフラチームとしては、SRE の活動がいつ・なぜ必要かを体系的に学習でき、部分的に実施していた SRE の取り組みを振り返り、強化することができました。例えば、ポストモーテムの⽬的について、障害の再発防⽌のみではなく⾃⾝と他者の違いから新たな気付きを学習する点である、などを改めて学びました。ポストモーテムの⽬的を正しく学ぶことで、実施の際に気をつけるべきマインドセットや、⾏動に結びつける仕組みをチーム内でアップデートしました。ポストモーテムの実施をプロセス化し、アクション アイテムのチケット作成を明確化し、さらにはこれまで内部で閉じていたポストモーテムの議事もアプリ側へ公開するなど、すぐに反映・実現できる改善活動を実践しています。

また、オブザーバビリティの重要性についても再認識し、現在の仕組みの再確認や改善を継続して⾏い、定期的なミーティングでインフラ・アプリがともに指標を確認し、アプリケーションのパフォーマンスの維持と潜在的なトラブルの予防に役⽴てています。このように、これまでの部分的な SRE 活動の取り組みをさらに⼀段⾼いレベルで実践し、個別の取り組みが線でつながったことにより、インフラチームとしてはより信頼が得られる組織の活動サイクルを回せるようになりました。

未来に向けて

今回「SRE Core」プログラムで経験を得たことにより、インフラチームはアプリケーションおよびビジネスとのコラボレーション領域を広げていき、プロアクティブな活動を増やしていきたいと考えています。現状は⼀部のアプリとのコラボレーションからのスタートですが、これを⼀つの成功事例として同様の活動を横展開していきたいと考えています。その際に重要な点として、アプリごとに携わるメンバーやビジネス パートナー、環境やカルチャーなどが異なるため、それぞれの状況に適応した SRE 活動が必要である、ということです。SRE 活動⾃体が⽬的ではなく、アプリやビジネスの⽬標に寄り添うための活動要素の一つが SRE であるという認識のもと、当プログラムで学習した内容を調和させながら適⽤したいと考えています。また、当社では、組織横断的な活動を⽬的とした CCoE チームがあります。CCoE では全社へ情報展開ができるポータルサイトや開発者同⼠がつながるコミュニティを運営しており、今回学習した内容を発信予定です。さらに CCoE としては社内での活動の成熟に伴い、社外へも情報発信していきたいと考えています。このような取り組みを通して、⼼理的安全性に配慮した議論や⾏動が、CCoE やインフラの組織を超えて社内メンバー同⼠で⾏われることを期待し活動を続けたいと考えています。

補⾜: ⼼理的安全性について

当社では経験年数が二極化し多様な観点を持つ⽅が在籍している都合上、パフォーマンス発揮のため⼼理的安全性への配慮は必要不可⽋だと考えています。⼼理的安全性が確保されていない状況、例えば「悪い知らせ」を持参した担当者こそが責任を問われるケースでは、「当たり障りのない報告」に終始し本質的な議論へ発展しません。このようなトラブルには、経験豊富な社員のみ知っている暗黙的に実施すべき作業が抜けており聞くのが怖い、などの⼼理的な障壁により⽣じるものもあります。

⼼理的安全性が確保された状況では、⼈へフォーカスしない、つまり問題の原因はシステムだと考え、問題⾃体を機会と捉えます。例えば、⼿動作業ミスに関するトラブルは、⼿動であること⾃体が問題だと考えたり、過去に類似事例がないシステム障害が発⽣した際は、新たな知⾒獲得の機会と考えたりするでしょう。こういった発想の転換を⾏うことで、恐怖⼼が⼼理的なバックグラウンドとならず、バイアスなく議論・作業を⾏うことができます。これにより、経験年数を問わず⼀⼈⼀⼈がパフォーマンスを⼗分に発揮することが可能です。ただし、特定の⼈だけが思って成り⽴つものではなく、⽴場・役職を問わず、チームや組織全体として根気強く認識することで効果を発揮できるものだと考えています。

投稿先