はじめに

こんにちは。リンクアンドモチベーションでエンジニアをやっている伊藤です。
私のチームではプロダクト開発の生産性指標としてFour keys metrics¹を利用しております。
今回はそのFour keys metricsを自前でダッシュボードにしてみたのでそちらをご紹介できればと思います。

どうしてやったのか

私はアプリケーション開発以外にも開発生産性向上をもっていたのですが、Four keys metricsの測定が手動で振り返りのたびに計算するといった運用になっていました。
そのため振り返り時以外には集計されず、エンジニアメンバーの意識も向きづらい状況でした。
これは自分自身も感じており、「なんとなくよくないかも」くらいの感覚しか持てず、改善のためのアクションやその振り返りがしづらい状況でした。
そのため、「集計の手間を減らすこと」「みんなが見たいと思えるようなものにすること」をゴールにFour keys metricsダッシュボードの構築を行いました。

どんなことをしたか

全体的な方針

最終イメージとしては Google Cloud ブログ「エリート DevOps チームであることを Four Keys プロジェクトで確認する²」のダッシュボードをイメージしました。

(「エリート DevOps チームであることを Four Keys プロジェクトで確認する³」より引用)

私たちのチームでも、Four keysが一目で分かることように1ページに現在のFour keysの状況をまとめ、また各項目をドリルダウンできるようにより細かい情報をそれぞれの指標ごとに1ページにまとめています。

※中央の「High」「High-mid」などはこちらにあるDevOps Research and Assesment (DORA) 開発組織のパフォーマンスに関する指標をもとに分類したときの評価をもとに、Mediumをより細く「High-mid」「Low-mid」のように分類を追加したものです。Mediumをさらに分割した背景は、目標を達成可能性の高い基準で設定できるようにするためです。

構成としては至ってシンプルで、全て一度 Google Sheetsに集約し、そこからGoogle SheetsのLooker Studio Connectorを利用して接続しています。⁴

本当はBigQueryに集約してから接続したかったのですが、

BigQueryの習熟度が低いこと
綺麗にダッシュボードにまとめる前に慣れたGoogle Sheets上で簡単な分析をしたかったこと

を理由にGoogle Sheets上に一度集約する構成にしました。

また各指標はDevOps Research and Assessment（DORA）の提唱した指標を基に自分たちの状況と照らし合わせて指標の取得方法を工夫しております。

各指標の詳細な取得方法やどんなドリルダウンを行っているかは次項目で一つ一つご紹介できればと思います。

変更のリードタイム

「commit から本番環境稼働までの所要時間」⁵

私のチームでは「開発メインブランチにマージされた日時からGithub Pull Requestの含まれる最初のcommit日時を引いた経過時間」をカウントしています。

上記指標とした背景としては、

開発のフェーズ的にデプロイ頻度は意図的に落とすこともあるので分離したい
開発メインブランチへのマージ時間を短縮することでコンフリクトの発生予防などが期待できる

などです。

変更のリードタイムに関しては弊社のアドベントカレンダーにまとめているのでそちらもぜひご覧ください。

qiita.com

デプロイの頻度

「組織による正常な本番環境へのリリースの頻度。」⁶

私のチームでは「チームがアプリケーションのソースコードの変更を含む何回デプロイ作業を実施したか」をカウントしています。

上記指標とした背景としては、

複数のリポジトリにまたがるサービスだがデプロイ作業は同時に行うので、これは1としてカウントしたい
Feature Flagsのデプロイ作業もあるが、これはカウントしたくない

などです。

私のチームではデプロイの管理に Jira Service Managementを利用しているため、このタスクの成功数をデプロイ数として取得しています。

Jira Service Management → Google Sheets へのデータ連携は Jira Cloud for Sheetsを利用しています。

主に下記の情報をGoogle Sheetsに連携した上で可視化しています。

成功したデプロイの数
直近のデプロイステータスと担当者
1回あたりのデプロイにかかっている時間

(デプロイ作業にかかる時間が増加傾向にあるので、分析して対策しようと思います)

サービス復元時間 (MTTR)

「組織が本番環境での障害から回復するのにかかる時間」⁷

私のチームでは「障害が確認されたから、暫定的対応 (一次課題解決)までの時間」をカウントしています。

上記指標とした背景としては、

サービス特性上、顧客の課題解決がなされれば回復したと言える
課題解決の暫定対応の手法にはhotfixのリリースだけではなく、パッチあてなども含まれる

などです。

私のチームではインシデントの管理にもデプロイと同様に Jira Service Managementを利用しているため、インシデント対応のなかで「発生時刻」と「暫定対応完了時刻」を記入してもらうようにしています。

Jira Service Management → Google Sheets へのデータ連携も同様に Jira Cloud for Sheetsを利用しています。

主に下記の情報をGoogle Sheetsに連携した上で可視化しています。

インシデント発生時刻
暫定対応時刻
混入日時
インシデントレベル (重要度や緊急度をもとに策定)

変更障害率

「デプロイが原因で本番環境で障害が発生する割合（%）」⁸

私のチームでもこの指標に関しては解釈の余地があまりないため、「単位期間あたりのインシデント発生数 / デプロイ数」として算出しています。

算出は「デプロイの頻度」と「サービス復元時間 (MTTR)」で既に取得した、インシデントの混入日時とデプロイ数をもとに行っています。

ただ、Looker Studio上でデータ統合を行う場合、計算フィールドが使いまわせず不便だったので、Google Sheets上であらかじめjoinしたものをデータソースとして利用しています。

support.google.com

やってみてどうか

現在はチームメンバーに全て公開しながら、リーダー陣で定期的に振り返りと改善アクションの策定を実施しております。
以前と比較すると、手動での集計作業をせずとも結果を確認できるようになったことで、気軽に指標と向き合えていると感じています。
チームメンバーにスクショとか送ると、「もっとやってきましょ〜」みたいな改善に向けた声をもらいやすくなったのも、可視化の影響かなと思うので、引き続きeliteな開発チーム目指して改善していきたいなと思います。