こんにちは、Diverse Developer Blogです。今回は、Diverseの開発組織の生産性と計測結果をどのように活用しているかをご紹介します。

リポジトリごとの開発生産性ダッシュボード

最初に計測中の開発生産性ダッシュボードを公開します。このダッシュボードはGoogleスプレッドシートで作成しており、データは自作したGitコマンドで集計しています。指標や計測の詳細は後述します。

計測対象は、開発が最も盛んで売上の高い弊社のサービス「YYC（https://www.yyc.co.jp）」の3つのリポジトリです。なお、Serverリポジトリは課題解決を優先して実施中なので、ClientやInfraにはない指標を追加しています。

Serverリポジトリ：Perl製のサーバー（API/batchなど）でWebクライアントと管理画面も含む
Clientリポジトリ：Flutter製のiOS/Androidのコード
Infraリポジトリ：AWSのリソースを管理するTerraformのコード

■ Serverリポジトリの開発生産性ダッシュボード

■ Clientリポジトリの開発生産性ダッシュボード

client(iOS, Android)_development_productivity

※ デプロイはAppleやGoogleのコンソールに次回バージョンをアップロードしたタイミング
※ ClientのRevertはデプロイ前のQAで発覚した不具合をrevertするため、本番で発生した変更障害の数と同じではありません

■ Infraリポジトリの開発生産性ダッシュボード

なぜ計測するのか

計測する理由は２つあります。ひとつ目は社内的な理由で「開発組織を改善する手がかり」を見つけることです。

弊社では、改善の第一歩は現状を正確に把握することだと考えています。弊社のサービスは20年以上稼働しており、組織や技術に課題があります。これらの課題をできるだけ正確に把握するために開発生産性の計測を始めました。

ふたつ目は社外的な理由で「エンジニア採用時にイメージしやすい情報を使って開発組織の現状を伝えたい」からです。

弊社の採用ピッチ資料*1は全職種向けの会社紹介になっています。エンジニア採用の面接時は採用ピッチ資料に加えて、利用中の言語やフレームワークの話や、プロダクトのコードやタスクの一部を共有して開発組織の現状を紹介しています。つまり、質的な内容だけで開発組織を説明していました。ここに量的な情報も加えて開発組織をさらにイメージしやすい状態にして採用広報を進めたく、開発生産性の計測を始めました。

デプロイの頻度の計測

開発生産性で有名な指標は「デプロイの頻度」「変更のリードタイム」「変更障害率」「サービス復元時間」の4つです。これらはFour keys*2と呼ばれています。弊社では、計測が簡単で特に重視される「デプロイの頻度」の計測から始めました。

計測はGitで作成したコマンドを各リポジトリで実行して月初にデータを集計しています。デプロイ頻度の計測方法を説明する前に弊社のデプロイフローを説明します。フローは以下のとおりです。

mainブランチからreleaseブランチに向けてPRを作成する
releaseブランチにPRをマージする
CI/CDが本番に変更をデプロイする

つまり、releaseブランチへのPRマージ数が「デプロイの頻度」と同じになります。このマージ数を月間で集計するGitコマンドは以下のとおりです。これで毎月どれだけのデプロイがあったのか数値で把握できます。

# releaseのマージコミット数だけ対象（--since=で対象開始日を指定）
git log --merges --date=format:%Y-%m --pretty=format:'%ad %s' --since="2022-01-01" release \
| awk '{print $1}' \
| sort \
| uniq -c \
| awk '{print $2","$1}' \
| sed 's/^ *\([0-9]*\) /\1,/'

# 実行結果はCSV形式の日付とマージ数となります
2022-01,32
2022-02,27
2022-03,40
<省略>
2023-07,77

d/d/dの計測

次に計測した指標は、d/d/d (deploys/ a day / a developer)です。d/d/dは、1日あたりのデプロイ回数を開発者数で割った数値で0.1以上だと、健全な開発組織と判断する指標*3です。祝日と週末を除いた営業日数を月ごとに算出しておき、現在の開発者数*4と当月のデプロイ数を計測してd/d/dを算出します。

最近はd/d/dを計測する企業も増えましたが、d/d/dを知らないと数値を見ても開発組織の状態をイメージしづらいと思います。そこで弊社では「デプロイ数のデイリー平均（23/01~前月）」も算出して日々の開発をイメージしやすい数値でも表示しています。

Serverは1日3回ほど、Infraは1日0.8回なので2日1度ぐらいの頻度でデプロイすると言えます。一方、審査が発生するClient（iOS,Android）は少し解説が必要です。Clientは7月分の計測終了時点でデプロイ数のデイリー平均が0.27回となっています。

ClientリポジトリはreleasブランチにPRをマージすると、CI/CDでAppleやGoogleのコンソールに次回のバージョンをアップロードします。弊社のiOSとAndroidはこのタイミングをデプロイとカウントします。そして、弊社のスクラムは1スプリントを5日（土日祝日を除く1週間）にしています。つまり、5日に1度はデプロイする頻度（0.27回 x 5日 = 1.35デプロイ/週）だと言えます。

変更障害率とRevert数の計測

Four keysの「変更障害率」はRevertのコミット数を代用して計測しています。コミットメッセージの先頭にRevertやrevertのメッセージが含まれるコミットが対象です。弊社では、デプロイの変更に問題があった場合、 git revert して復旧作業を行います。Revertのコミット数を計測するGitコマンドは以下のとおりです。

# releaseのRevertコミット数だけ対象（--since=で対象開始日を指定）
# 補足: 極稀にRevertを打ち消すRevertコミットがあるため、コミットメッセージでRevertやrevertが重複するコミットはperlワンライナーで対象外にした
git log --grep="Revert\|revert" --date=format:%Y-%m --pretty=format:'%ad %s' --no-merges --since="2022-01-01" release \
| perl -ne 'print if /^(\d{4}-\d{2}) (Revert|revert)/i && (()= ($_ =~ /(Revert|revert)/ig)) < 2;' \
| awk '{print $1}' \
| sort \
| uniq -c \
| awk '{print $2","$1}' \
| sed 's/^ *\([0-9]*\) /\1,/'

# 実行結果はCSV形式の日付とRevertコミット数となります
2022-01,3
2022-02,1
2022-03,5
<省略>
2023-06,2
2023-07,6

提供するサービス内容によって水準は代わりますが、Four keysでは、最も高いパフォーマンスレベルのエリートで変更障害率は15%以下です*5。弊社のServerでは10%台になる時期もありましたが、単体テストの増加やWeb側にe2eテストを導入して改善を試みています。直近数ヶ月はデプロイ頻度が増加しても、変更障害率が10%をこえない状態を維持しています。

なお、Client（iOS, Android）のみ git revert の運用方法が他リポジトリとは異なります。本番リリース前のQAで発覚した不具合に git revert を行うため、本番で発生した変更障害と同じではありません。

廃止/削除のPRマージ率の計測

最後に弊社独自の指標である「廃止/削除のPRマージ率」を説明します。「廃止/削除のPRマージ率」とは、PRタイトルに廃止または削除の文字があるPRをmainブランチにマージした数（廃止/削除PRマージ）を、mainブランチにマージしたPRの数（PRマージ）で割った数値です。

廃止/削除PRマージ ÷ PRマージ = 廃止/削除のPRマージ率

この指標は社内のエンジニアの「廃止や削除のPRでデプロイ数が増加したのであって、ユーザーへの価値提供は増えてないのでは？」という意見から生まれました。不要な機能やコードが減って開発効率が上がるのは、基本的には良いことです。しかし、デプロイの量だけではなく質にも注目すべきと考えて計測を始めました。

Serverのダッシュボードを見ると、23年3月から6月は「廃止/削除のPRマージ率」が20%以上です。これはサービス内で利用するポイントシステムの抜本的な改善に着手したのが原因です。20年以上サービスを運営すると、現在のニーズに合わない機能や古いポイントシステムが残ったりします。そこで機能の廃止やコードの削除を改善と同時に実施しました。そして、7月にポイントシステムの改善がほぼ完了したため、現在の「廃止/削除のPRマージ率」は11%まで低下しました。

このようにポイントシステムの改善という明確な方針があって「廃止/削除のPRマージ率」が上昇するのは妥当な結果です。改善に必要な廃止や削除だったと説明できれば、チーム内の認識のズレが少なくなり、より良い振り返りがチームで行なえます。

「廃止/削除のPRマージ率」はどの程度が適切な数値でしょうか。5%以下だと機能やコードを継ぎ足してばかりな可能性がありそうです。逆に30%以上だと、コードや機能の質に問題があったり、開発環境の改善を優先し過ぎなどの振り返りができそうです。この数値の適切な水準は模索中ですが、計測し続けると見える改善点もあると考えています。