ギルドでパフォーマンス監視体制を整えた話

こんにちは！atama plusのhikarinです。

Webサービスにおいて、パフォーマンスは非常に重要です。2017年と2018年のGoogleの調査（出典）によると、ページ表示速度が1秒から3秒になると直帰率が32%増加し、6秒になると106%増加すると報告されています。このように、ページの読み込み速度が遅れるだけでユーザーが離脱するリスクが高まるのです。
また、パフォーマンスと言えば、最近ではService Level Objective（SLO）とService Level Indicator（SLI）をSREで決めて運用している組織が増えています。これにより、サービスの信頼性とユーザー体験を高める努力がなされています。

本記事では、組織全体でパフォーマンス課題に向き合うための体制づくりについて紹介します。

atama plusが抱えていた問題：パフォーマンス課題に組織全体で取り組めない

atama plusには数十人規模の開発者が在籍しており、開発組織のエリアと各チームの役割が整理されています。エリアとは、atama plusにおける部門のような組織階層でありその下にチームが所属します。
例えば、社内のプロダクトを開発するソフトウェア開発者にソフトウェアプラットフォームを提供し、アプリケーションやサービスのニーズに応えるSoftware Platformチームや、プロダクトの基盤の維持運用を担うSREは、プラットフォームエリアに所属しています。一方で、サービスの機能開発を行っているのはプロダクトエリアに所属するチームであり、これらのエリアは分かれています。機能のパフォーマンス改善を実施する際は、主にプロダクトチームのリソースが必要となります。
atama plusではエリアごとにPO（Product Owner）やAO（Area Owner）がおり、リソースの配分には担当Ownerの承認が必要です。プラットフォームエリアのチームが機能パフォーマンスの課題を発見しても、プロダクトチームのリソースを確保するにはプロダクトエリアの責任者との合意が必要であり、大きなハードルとなっていました。さらに、塾で多く利用いただいているatama＋は、一般的なWebサービスと比較してパフォーマンス自体によるユーザー離脱への影響が小さいため、他の開発施策と比較して高い優先度をつけることが難しい（=パフォーマンス改善のためのリソースを確保することが難しい）状態が定常化していました。

開発組織全体を巻き込むために

ギルド発足

かつて、プラットフォームエリアに所属する複数のチームがパフォーマンス監視体制の構築を試みましたが、前述した課題によりエリア間を超えた巻き込みが実現されず、断念を重ねてきました。そこで過去の学びを活かし、チーム単位ではなく、アーキテクチャチームとプロダクトチームを巻き込んだ開発チーム横断の組織で課題に取り組むべく、パフォーマンスギルドが発足しました。ギルドにはDevだけでなく、QAメンバーも加わりました。

atama plusにおけるギルドとは、特定技術領域や、エンジニアが関係する特定テーマについて、そのテーマに興味関心のある有志がチーム横断で集まる組織体です。より具体的な内容はこちらの記事をご覧ください。

ギルドの活動

開発組織全体を巻き込んでパフォーマンス改善を進めるために、以下の課題を挙げ、少数のグループに分かれて取り組みました。

• ナレッジ整理
• ユーザー価値との関連性の訴求
• 監視方法の拡充

当初の想定では、具体的なパフォーマンス目標と運用ルールをギルドから提示することで開発組織全体を巻き込むことを目指していました。しかし、その方法には以下の2つの課題がありました。

1. 納得度のあるパフォーマンス目標を様々な機能に対して一律または個別に定義することが難しい
2. プロダクトチームが負担に感じると活動が持続されない

そこで、プロダクトチームに主体的に取り組んでもらう方法として、以下の方針に切り替えました。

1. すべての機能の監視を分担するのではなく、プロダクトチームがオーナーシップを持っているユーザーにとって重要な機能から監視を開始する（量を絞ることにより負荷を軽減する）
   • サービス提供に必須レベルでの監視はSREが行う
2. パフォーマンス目標は各チームで決める（主体性を持って取り組んでもらう）
3. 実際のパフォーマンス改善活動は後回しにする（まずは仕組みの定着を主眼とする）

ギルドはこれらをサポートするために、監視環境の作り方、閾値の決め方（目安）、そして閾値超えを検出したときの運用フローを整備し、プロダクトチームへの普及活動を行いました。

普及活動の具体例

普及活動はスモールステップで慎重に進めました。パフォーマンスの監視と改善プロセスを以前から回していたAlgorithmチームのプロセスを参考にし、無理のないプロセスを策定しました。また、先行してプロダクトチームのうちひとつに対してワークショップを実施し、ギルドの提示する仕組みが受け入れられるか検証しました。
ワークショップのゴールは以下の3点です。

• 各プロダクトチームが気軽にダッシュボードを作れる状態になっていること
• 作ったダッシュボードを職種関係なく眺められる状態になっていること
• 閾値抵触があった場合の運用フローの認識が揃っていること

ワークショップは、各チームに対して以下の流れで行われました。

1. ワークショップ開催前までに、各チームが担当する機能の内、利用頻度が高い機能を決める
2. ワークショップ当日は、Datadogを使ってギルドと一緒にパフォーマンスを監視するダッシュボードを作成する
3. ダッシュボードの監視頻度をギルドと相談しながら決める
4. 実際にダッシュボードを監視してみる
5. 一時的にわざと閾値超過が起こるような閾値を設定し、閾値超過時の運用フローをなぞってみる
6. ラップアップ

ワークショップ後の参加者の感想としては、「実際に行動するまでのハードルが下がるので参加できてとてもよかったです」「他の方に設定してもらうのではなく、自分たちでどの画面の機能を計測したいか話し合える良い機会になったと思いました」「チームでパフォーマンスの継続監視をする動きにつながるというワクワクを感じました」といった声が上がりました。

ワークショップの様子

全体展開へ

ワークショップの結果を経て、いよいよプロダクトチーム全体への展開ステップです。ユーザー価値との関連性の訴求（アプリの応答待ち時間が生徒の学習時間に対してどれくらい影響を与えているか）や、プロダクトチームへの負荷がどれくらいであれば許容されるかをプラットフォームエリアのAOに壁打ちして調整した効果もあり、プロダクトエリアのAO/POからもスムーズに承認を得ることができました。そして、チームごとにワークショップを行い、パフォーマンス監視体制の構築が実現されました。
プロダクトチーム主体で重要機能の監視をしてもらうようにしたこと、またリソース配分の意思決定をするPO/AOにも合意を取ったことにより、実際にプロダクトチームでパフォーマンス課題のチケットが切られて取り組まれるようになってきています。過去にパフォーマンス監視体制を整えようと試みたプラットフォームエリアのメンバーも、この実現に非常に喜んでいます。

学び

1. 枠組みを作ることも大事だが、必要なステークホルダーの巻き込みを先にしたほうが良い
   • 数値の設定を先にやろうとして決めきれず、浸透させられずに頓挫するケースが多かったです。チームレベルでのオーナーシップと自治が可能な体制の構築が大事です。
2. スモールステップ：SLO策定より先にプロセスの定着にフォーカス
   • まずは仕組みを定着させ、その後で具体的な目標設定をすることで、スムーズに進めることができました。
3. パイロットチームがあると進みやすい
   • Algorithmチームでの知見や、ワークショップを先行実施したチームの協力が全体展開をスムーズにしてくれました。

終わりに

このように、パフォーマンス監視体制を整えることで、組織全体が一丸となって品質向上に取り組むスタートを切ることができました。今後も継続的に改善を行い、生徒が熱狂する学びを提供するために努力していきます！