メトリクスを共有するためのダッシュボードを新たに構築
まず1つ目の施策として、開発生産性・メトリクスの基準を開発組織全体で統一した。一口に「開発生産性が高い・低い」と言っても、その基準が明確に定義されていないとそれぞれの主観に基づき評価・判断するしかなく、SREと開発者のように立場が異なる者同士では、正確なコミュニケーションがなかなか成立しない。この課題を解決するために導入したのが前出のFour Keysメトリクスであり、先ほど挙げた4つの指標を「共通言語」としてSREと開発者とが互いに正確なコミュニケーションを取れるようにした。
この施策を推進するために新たに構築したのが、これら4つの指標をSREと開発者とで共有するためのダッシュボードの仕組みだ。指標のデータを収集・可視化するための仕組みは以前からあったものの、手動でスプレッドシートを更新する運用となっており、データの量や正確性、タイムリー性に問題があったため、開発者に浸透しなかった。そこでこれをシステム化し、自動的にメトリクスを収集・集計・可視化する仕組みを新たに構築することにした。
具体的にはGitHubからリードタイムとデプロイ頻度に関するデータを、そしてスプレッドシートの帳票からMTTRと変更障害率のデータを自動的に収集し、既に社内で展開していたGoogle Workspaceのスプレッドシートアプリ上で集計した。その内容をGoogle Looker Studioを使って自動的にダッシュボード化し、ビジュアルな形式で誰もが一目で指標値をタイムリーに把握できる仕組みを新たに構築した。
これら一連の仕組みを実現するに当たっては、「全自動」「リアルタイム性」「変更容易性」という点にこだわった。
「メトリクスの集計作業自体が負担にならないよう全自動化すること、そして開発者が見たい時にいつでも正確な情報が参照できるリアルタイム性の実現を必須要件に挙げていました。また組織体制やプロセスが変わるとメトリクスの計測方法も変わるため、変更を容易にしておくことも重要でした。その点Google Looker Studioのようにノーコードでダッシュボードを開発できる仕組みは、私たちのニーズに合致していました」（川津氏）
SREと開発を横断する協働チームを新たに創設
2つ目の施策としては、改善活動を「皆の目標」とするようにした。開発チームにとってはサービスデリバリやインシデント対応が主たるミッションであるため、生産性の改善活動はどうしても後回しになりがちだ。そこでSREチームとの温度差を解消し、改善活動をSREと開発者双方にとって共通の目標とするために、SREチームと開発チームを横断するチームを新設した。
各開発チームから協力者を募り、SREチームのメンバーとともに改善活動のための明確なチーム・役割・責務を定義した。ここで最も重要視したのが、「改善をボランティア活動にしない」ことだった。
「ボランティアではなく、正式な仕事としてアサインすることで、開発者も日々の開発の仕事と並行して改善活動に堂々と関われるようになります」（川津氏）
また「Embedded SRE」と呼ばれる取り組みも新たに始めた。これはSREのメンバーが開発チームの中に直接入って、1カ月なり2カ月の間実際にチームの一員として働くことで、そのチームの中に潜む品質や生産性にまつわる潜在的な課題を掘り出すという取り組みだ。
同社のクラウドサービスで一時期変更障害率が高まったときがあり、なかなか原因がつかめずにいたが、このEmbedded SREの手法を取り入れてSREのメンバーが一定期間開発チームに入り込んで一緒に働いてみたところ、隠れた原因をあぶり出して無事対処できた。
