データで見るアジャイル開発：リードタイムとデプロイ頻度の計測（2024 Advent Calendar 23日目）

公開日: 2024/12/23@Panda_Program

この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の23日目の記事です。このアドベントカレンダーは「ある機能開発チームでスクラム, XP, DevOps を一度に実践したら真のアジャイル開発ができた」という内容です。執筆者は全てプログラミングをするパンダです。

開発の指標とその計測方法

本記事では2022年4月から6月末までに自分たちのチームで計測した開発の指標とその集計方法を紹介します。

なぜ計測するのか: 「推測より計測」

パフォーマンス改善の金言に「推測より計測」という言葉があります。これは「何となくここが遅いという理由で、当てずっぽうにチューニングをするのは良くない。計測をしてボトルネックを特定し、そのボトルネック改善にリソースを投下せよ」という意味です。

ソフトウェア開発のパフォーマンス向上も同様です。なんとなくこれが遅い原因だろうと推測するのではいけません。私たちにはLeanとDevOpsの科学という書籍から得た知見があります。Four Keysを改善すればチームのパフォーマンスが上がるのです。

何を計測するのか: Four Keys

今回チームで作成した機能は新機能だったため、リリース時にはまだ使われていませんでした。このため、DevOpsのFour Keys のうち変更のリードタイムとデプロイ頻度を計測の対象としました。

変更のリードタイムについては、featureブランチの全プルリクエストのファーストコミットの日時とそれをマージした日時を取得します。このデータを元に最大、最小、平均日数などを計算して分析材料とします。

デプロイ頻度はdevelopmentブランチのプルリクエストをmasterブランチにマージした日時を取得して計算しました。

どのように計測したか: GitHub API を活用

データ取得のためにGraphQLのGitHub APIを使いました。データの対象期間は2022年4月から6月です。

クエリを書くに当たり、同じようなことをされている方のブログやGraphQL公式ドキュメント、GitHubのリファレンスを参照しました。

発行したクエリは以下です。このクエリは、あるレポジトリで指定されたラベルが付与されたプルリクエストのタイトル、最初のコミットの日時、プルリクエストがマージされた時間、コメント数を取得するものです。これは2024年現在でもGitHubのGraphQL Explorerから利用できる有効なクエリです。

query ($owner: String!, $repo: String!, $prCount: Int!, $label: String!) {
  repository(owner: $owner, name: $repo) {
    name
    pullRequests(
      first: $prCount
      labels: [$label]
      states: [MERGED]
      orderBy: {direction: ASC, field: UPDATED_AT}
    ) {
      nodes {
        ... on PullRequest {
          title
          mergedAt
          commits(first: 1) {
            nodes {
              commit {
                committedDate
              }
            }
          }
          comments {
            totalCount
          }
        }
      }
    }
  }
}

クエリの変数（Query Variables）は以下です。prCount（プルリクエストの個数）は自由に書き換えてください。

{ "owner": "xxx", "repo": "some-repository", "label": "some-label", "prCount": 10 }

このクエリを実行すると以下のような結果が返ってきます。

{
  "data": {
    "repository": {
      "name": "some-repository",
      "pullRequests": {
        "nodes": [
          {
            "title": "PR title 1",
            "mergedAt": "2022-04-07T05:09:23Z",
            "commits": {
              "nodes": [
                {
                  "commit": {
                    "committedDate": "2022-04-05T05:59:08Z"
                  }
                }
              ]
            },
            "comments": {
              "totalCount": 0
            }
          },
          {
            "title": "PR title 2",
            "mergedAt": "2022-04-08T06:27:30Z",
            "commits": {
              "nodes": [
                {
                  "commit": {
                    "committedDate": "2022-04-06T13:52:29Z"
                  }
                }
              ]
            },
            "comments": {
              "totalCount": 0
            }
          },
          {
            "title": "PR title 3",
            "mergedAt": "2022-04-08T06:31:28Z",
            "commits": {
              "nodes": [
                {
                  "commit": {
                    "committedDate": "2022-04-05T14:17:21Z"
                  }
                }
              ]
            },
            "comments": {
              "totalCount": 1
            }
          }
        ]
      }
    }
  }
}

指標を可視化する

データが揃ったので可視化をします。JSONデータを整形するスクリプトを書いてCSVファイルに出力し、Google SpreadSheetに読み込ませてグラフを作成しました。

集計した項目には以下のようなものがあります。

1日のデプロイ回数（デプロイの頻度）
ファーストコミットからdevマージまでの平均時間（変更のリードタイム）
1日のデプロイ平均回数
PRごとのコメント数平均

変更のリードタイムは以下の表を元にグラフを作りました。土日などの休日の日数を引くために元データをさらに加工して計算しました。

1日のデプロイ回数はシンプルなデータから取得できました。

これらを元に作成したのが以下のグラフです。これらのグラフの分析は2日目の記事で紹介しているためここでは省略します。

1日に1度はデプロイしようという目標も開発の中盤と後半でほぼ達成できました。

これらのデータとグラフを社内で共有すると好評を得られ、マネージャーがこの次の開発から毎スプリントごとに指標を自動集計してスプレッドシートに反映させるスクリプトを作成していました。チームを超えて後につながるトライができたこと、指標が改善していくのとチームメンバーが自分たちの開発スタイルに自信を持ち始めるタイミングが重なっていたことから、今後も計測する価値のある指標だと実感しました。

次回は成功だけじゃない自分たちの開発の後日談を紹介します。

Happy Coding 🎉