Four Keysの導入による生産性と品質と品質の向上について

こんにちは、エンジニアの安達です。

今回は弊社における生産性と品質の可視化と改善の取り組みについて、お話ししようと思います。

Four Keysとは

開発の生産性と品質の可視化にあたり、Four Keysという指標を導入しました。Four KeysとはGoogleが提唱しているソフトウェア開発チームのパフォーマンスを示す4つの指標です。以下の指標を測定し、継続的に改善を繰り返すことで、ビジネス成果を大幅に向上させることができます。

・デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度
・変更のリードタイム - commit から本番環境稼働までの所要時間
・変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%）
・サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間

参考：

エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud 公式ブログ

なぜFour Keysを導入したのか

これまで、弊社のエンジニア組織には定量的な目標やゴールがなかったため、組織としての方向性や成長を可視化することが難しいという課題が挙げられていました。そこで、エンジニア全員で話し合いを重ねた結果、Four Keysを導入し生産性や品質を改善していくことでイケてる組織になるのでは？という仮説が立ち、導入が決定しました。

どうやって計測しているのか

弊社ではGitHub、AWS、Redashを活用し、以下のようにFour Keysの計測・可視化をしています。

主な使用技術は以下の通りです。

・GitHub...GraphQL APIでPull Requestごとのコミット日時、レビュー日時、マージ日時等を取得します。

・AWS CodePipeline...パイプラインのイベントログからデプロイされた日時を取得します。

・AWS Lambda + API Gateway...各種データソース（GitHub・CodePipeline）とRedashを繋ぐ役割を担い、データソースを集計した結果をAPIとして返却します。

・Redash...LambdaのAPIからデータを取得し、グラフとして可視化します。

計測・可視化の仕組みを全て自社で構築しているため、「変更のリードタイムの算出時に祝日は含めないようにしたい」「2日以上レビューされなかったPull Requestの割合を算出したい」といった細かい要望にも対応しながら、日々仕組みをアップデートしています。

どのように運用しているのか

以下のように2週間・4半期ごとにエンジニア全員で数値を確認し、ネクストアクションを策定・実行しています。

2週間ごと

各項目の数値を確認し、数値を改善するための小粒度のアクションを策定して実行しています。

アクションの例：

・一定期間レビューされてないPull RequestをSlackに通知することで、レビューの待ち時間を改善する。
・リリース待ちのPull RequestをSlackに通知することで、デプロイの頻度を改善する。

四半期ごと

各項目の数値に加え、四半期で発生した障害の振り返りも行い、中粒度のアクションを策定して実行しています。

アクションの例：

・ステージング環境のE2Eテストを充実させることで、リリース前に重要な機能のデグレを検知できるようにする。

・（ユーザーへの影響はない）軽微なエラーログを解消することで、重大なエラー数の急増から障害発生を素早く検知できるようにする。

どのような効果があったのか

変更のリードタイムの改善

Four Keysの導入以前は、変更のリードタイムを短くするという意識が浸透していなかったため、大きなPull Requestを作成してしまいレビューがなかなか進まないことが日常的に発生していました。Four Keysの導入後は小さいPull Requestを作って素早くレビュー・マージする意識が強くなり、最初のコミット〜マージまでの平均日数が5営業日から1営業日まで短縮されました。私個人としても、素早くレビュー頂いて素早くリリースするようになったため、開発が進めやすくなっていることを実感しています。