技術指標をユーザー体験へとつなげていく、共通ダッシュボードの構築
SLOとプロダクト指標を真に統合するため、川崎氏らが最初に着手したのは、ビジネスKPIの洗い出しと把握であった。エンジニアが事業成長にコミットするには、大上段のミッションから事業・組織ごとに落とし込まれたKPIを正しく意識することが不可欠である。
また、その逆のプロセスとしてエンジニアが見ている技術指標をビジネスKPIに置き換えていくことも重要だ。「お互いの会話が成立する状態を作ることがとても大切で、翻訳してつなげていく役割がエンジニアリングマネージャーには求められています」と川崎氏は語る。具体的には「リクエスト成功率」や「レイテンシー」といった技術目標を、ユーザーの「離脱確率」や「取引完了率」に直接寄与する体験指標へと置き換え、レポートに落とし込んでいった。
この目線合わせを盤石にするため、同社ではPMも日常的に確認する「共通ダッシュボード」を「Grafana」を用いて構築。ダッシュボードの設計においては、エンジニアの要望や難解な技術用語を極力排除し、「ユーザー体験の状態」を視覚的に表示することを徹底した。ドメインごとのSLI可用性や、現在のエラーバジェットが何％残っているのかが一目で判断できる状態を作ったことにより、感覚値ではなく、誰もが同じデータを見てプロダクトの健康状態について会話できるインフラが整った。
予算としてのエラーバジェット運用と、失敗を血肉にするポストモーテム
共通ダッシュボードの導入に続き、川崎氏のチームではエラーバジェットを「技術的な定義」ではなく、「施策を攻めるための予算」として再定義。ユーザーがエラーに連続して遭遇すれば離脱リスクが高まるという前提のもと、リリース可否を判断する基準を設けた。例えば、予算が潤沢にあればデリバリーを最優先してアクセルを踏み、逆にトラブルが相次いで予算が枯渇しかけているならば、一時的に品質向上へとリソースを割く。このように、ユーザー体験をもとにしたリスクマネジメントをロードマップの策定や日々のリバイスに組み込むことで、事業KPIとユーザー体験の双方を天秤にかけたドラスティックな意思決定が可能となった。
また、これらデータ駆動のスキームを支える精神的支柱として、同社では「ポストモーテム」の文化を徹底的に普及させた。「失敗＝悪」と切り捨てる減点主義の文化を脱却し、失敗を次のチャレンジへつなげる組織の経験値へと変換するためだ。インシデント報告の際は「5 Whys」を用いて根本原因を事実ベースで突き詰め、再発防止策を追う仕組みを形骸化させずに回し続けた。失敗を隠すのではなく、職種を問わず全体にフィードバックして血肉化する地道な取り組みが、組織の心理的安全性を底上げしていった。
3つの失敗談から得た教訓、データ至上主義を越えて行き着いた「人と組織の問題」
しかし、これら一連の取り組みは決して順風満帆なものではなかった。川崎氏は実践の中でぶつかった生々しい3つの失敗談を紹介。1つ目は、客観性を求めるあまり陥った「データ至上主義」の罠である。何でもかんでもデータだけで判断しようとした結果、データの見方によって「コト」ではなく「ヒト」に再び目が向いてしまう危機に直面したのだ。「データはあくまで判断材料であって、裁判官ではありません。最終的にはPMとエンジニアがしっかりと意思決定をすることが大事です」と川崎氏は語る。
2つ目の失敗は、SREチームだけで独善的に変革を進めようとし、周囲から浮いてしまったことだ。小さな成功を共有しながら巻き込み、PMを「良い意味での共犯者」として仲間に引き入れるプロセスを最優先すべきだったと振り返る。
そして3つ目は、最初から完璧を求めすぎて大量の指標を追い、組織が疲弊してしまったことである。川崎氏は実体験に基づき、追うべき指標はマジックナンバー「3」程度に絞り、小さく始めて後からスケールさせるのが確実だと身をもって学んだ。これらすべての失敗に共通していたのは、技術の問題ではなく、すべて「考え方や組織の作り方、共通認識の取り方といった、人と組織の問題」だったということである。
