開発生産性分析を試みた経緯

現在、エニグモでは開発組織体制の変更、メンバー増強など様々な組織強化を目指した動きが加速してきています。ただ、そのような施策が開発組織のパフォーマンスを向上させているのか定量的な指標で測ることができませんでした。また、開発組織としては、開発を通して一定のスピードでユーザーに十分な価値を届ける責任を負っているものの、開発スピードを測る良い方法がありませんでした。このように組織パフォーマンス向上施策の結果を確認するため、開発組織としての開発スピードを図るために開発生産性分析の取り組みが始まりました。

また、この取り組みは開発生産性に興味がある有志のメンバーが集まり進めていきました。

指標選定

分析する指標としては、Googleが提案しているFour Keysを参考にしました。 Four Keysを参考にした理由は以下になります。

開発スピードを測る指標が含まれている。
自分達で計測、分析の基盤を整えられそう。
一般的な指標である。

そして、指標の中で速度に関わる指標であり、計測が容易そうな変更のリードタイムとデプロイ頻度を計測することが決まりました。デプロイ頻度に関しては、営業日や開発メンバーの増減による影響を少なくするために、 @hiroki_daichiさんが紹介されていたd/d/dというやり方で 1日あたりの1開発者あたりのデプロイ回数を計算することにしました。

また、現在BUYMAは基幹システムと複数のマイクロサービスで構成されていますが、どの開発チームも修正することが多い基幹システムにおけるこれらの指標を計測していくことになりました。

各指標の定義

前提として、BUYMAの基幹システムはGitlabをホスティングサービスとして利用しています。本番環境へのデプロイは内製アプリケーションを通して行われ、開発者が各々デプロイ依頼を作成します。本番環境へのデプロイプロセスは1日3回実行されるため、各開発者は作成した依頼をそのどれかのプロセスに乗せて本番化します。

Four Keysを参考にしつつ、このようなBUYMAの特徴を考慮して各指標の定義をチームで相談して決めました。

その上でリードタイムは以下の定義で計算しています。

MR内の最初のコミットからそのMRが本番環境に反映されるまでの時間

各開発者によって開発手法は異なるため最初のコミットタイミングが微妙にずれる可能性はありますが、 開発 -> レビュー -> QA -> デプロイという一連の開発プロセスを計測できるためこのような定義にしました。

d/d/dに関しては、デプロイ回数/営業日/開発者数となっていて、それぞれ以下のような定義になっています。

デプロイ回数: 本番化された本番化依頼の数

BUYMAの本番化の特徴として、1デプロイに複数の修正が含まれるためその一つ一つの修正を個別に数えたかったためこのような定義にしました。

営業日: 土日祝日を抜いた平日

営業日は特に一般的に使われているものです。

開発者数: マージされたMRに参加したユニークGitLabユーザー数

エンジニアリング部門に属していても「基幹システムに関わっていない人は含めたくない」、「過去の特定期間の開発者数も出したい」など考慮する点が多く難しかったのですが、「MRに関わった人数は開発に関わる人数と等しいだろう」という考えのもとチームで相談してこのような定義になりました。

データ収集、可視化の仕組み

次に、指標の計測と可視化の仕組みについて説明します。

Airflowにワークフローを構築して、MRに関わる情報をGitLabのAPIから収集しBigQueryに格納しています。デプロイに関する情報は内製本番化アプリケーションが利用しているデータベースに永続化されているため、BigQueryに連携してGitLabの情報とJOINできるようにしました。可視化に関しては、BigQuery上のレコードをSQLで加工してLookerのダッシュボードを使うことで実現しています。

リードタイムに必要なデータ収集

リードタイムを計測するために以下のGitLab APIを利用しています。基本的にはAPIのレスポンスから日次の差分データを取得して、そのままBigQueryのテーブルに保存しています。

List all projects API

GitLabのプロジェクトのマスターデータを収集するために利用しています。収集したデータはLookerで可視化する際にプロジェクト名を表示するなどに利用しています。

List group merge requests API

MRデータを収集するために利用しています。マージ済みMRの情報のみ必要なのでAPIパラメータを使ってマージ済みMRの情報のみ収集しています。

Get single merge request commits API

MRに紐づくコミットの情報を収集するために利用しています。ここで取得したデータを利用してMRに紐づく最初のコミットを特定して、リードタイムを計算します。

d/d/d に必要なデータ収集

リードタイムを計測するために以下のGitLab APIを利用しています。こちらも日次の差分データをそのままBigQueryのテーブルに保存しています。

List a Project’s visible events API

GitLabのイベント情報を収集するために利用しています。マージされたMRに参加したユニークGitLabユーザー数を計算する際にここで収集したデータを利用しています。

可視化について

先述したように可視化にはLookerのダッシュボードを利用しています。 LookMLでSQLを組み立てて指標を計算しています。エニグモではBUYMAをメインの機能で分割して開発チームを組織していて、それらをドメインチームと呼んでいます。指標の監視や分析は各ドメインチームにやってもらっているため各ドメインチーム毎にダッシュボードを作成しています。

運用について

指標の監視や分析は、細かいやり方を指定せずにドメインチームに依頼しています。例えば私が所属しているチームでは毎週の振り返り時にリードタイムとd/d/dを確認して、何か問題があれば改善案を考えるという運用をしています。また、開発生産性指標の計測にあたり、開発者にMRへのラベル付与を依頼しました。MRに付与されたラベル情報をもとにドメインチーム毎のリードタイムを計測しています。

今後の課題

今後の課題としては以下になります。

BUYMA基幹システム以外でまだデータ収集できていないマイクロサービスがあるため正確に開発組織全体の生産性を測れていない。
要件定義、仕様決定などのディスカバリーフェーズにかかっている時間を図れていない。
変更障害率、サービス復元時間など安定性の指標を図れてない。
- 現状だとリードタイムやd/d/dが向上した際に、それが障害発生による細かい修正が増えたのが原因なのかわからない。