巻頭言：Four keysの"Change lead time"をちょっと深堀る

著者：しょっさん
目次

ありがたいことに第２号も発刊できました。ご協力いただけました皆様にここで感謝申し上げます。

今回の巻頭言は、Four keysの"Change lead time"についてちょっと深堀りしてみた話を書いていきます。

Four keysとは

“State of DevOps Report"という、毎年DORA(Devops Research And Assessment)社によって発刊されている、DevOpsに関わるエンジニアのアンケートを元に統計を取り、考察・研究されたレポートがあります。
Four keysはその2014年度に発刊されたレポートで発表され、「ITパフォーマンスを測る指標」というものでした。（ITパフォーマンスってザックリした言葉ですね）

そんなFour keysは以下の4つの指標で構成されています。

  • Deployment frequency（デプロイ頻度）
  • Lead time for changes（変更リードタイム）
  • Time to restore service（サービス復旧時間）
  • Change failure rate（変更失敗率）

これらを計測することで、DORAが提唱する"技術ケイパビリティ"を測ることができ、その結果が組織パフォーマンスやWell-being（個人の幸福、仕事の満足度）にも影響を与えているとされています。

DORAがこれらを"DORA Core Model"として定義しており、公式サイトにて詳しい説明がされていますので、興味のある方はそちらをご覧ください。

DORA Core Model

そんなFour keysの中でも、今回は"Change lead time"についてちょっぴり深堀りしてみたいと思います。

Change lead timeのfirst commitって？

Change lead timeの定義を調べてみるとこう書かれています。

How long does it take to go from code committed to code successfully running in production?
（コードがコミットされてから、本番稼動するまでにどれくらいの時間がかかりますか？）

ということで、Change lead timeはコードがコミットされてから本番稼動するまでの時間を指します。
では、ここで書かれている “code committed” とは一体何を指しているのでしょうか？

first commit?

さて、ここでインターネットで検索すると、 “first commit” という言葉がよく出てきます。最初のコミットをChange lead timeのスタート地点として考えているパターンですね。
ふむふむと思いましたが、「ん？LeanとDevOpsの科学を読んでもそんなこと書いてないぞ？」と疑問が湧いてきました。

では、書籍とは別にもう一つ論拠となるソースを増やしてみようと、DORAが提供していたFour keysのリポジトリをあたってみることにしました。ここのメトリクスに関するドキュメントもさらってみましょう。

メトリクスの計算方法が書いてありますが、ここを読むと 「deploymentのデプロイ日時からにdeploymentに紐付くchange（≒ commit）の作成日時の差分日時」 がChange lead timeとして計測されていることがわかります。
なるほどなるほど、ということはfeature branchのfirst commitをChange lead timeのスタート地点として考えればいいのか〜-

とはなりません。

何故かというと、DORA Core Modelに立ち返るとDORAは「トランクベース開発」を技術ケイパビリティの一つにも据えていることからもわかるように、 feature branchを使わない開発を推奨 しています。つまり、feature branchのfirst commitをChange lead timeのスタート地点として考えるのは、DORAの提唱する方法とは異なるというわけです。
先程のリポジトリのREADMEを読むと、トランクベース開発前提で書かれているということがわかります。

つまりはfeature branchのような機能単位でのコミットをChange lead timeのスタート地点として考えるのは、ちょっと意味合いが違いそうですね。

この考え方を補強するために色々と調べてみると、GitLabのやり方はこれと同じということがわかります。

とはいえ、トランクベース開発をしていない場合はどこを計測の開始点とすればいいのでしょうか？
答えは非常に明確で、 trunk branch（≒ main branch）にマージされた時点 をChange lead timeのスタート地点とすればいいのです。なので、 feature branchがtrunk branchにマージされた時点 をChange lead timeのスタート地点として考えるのが良さそうです。
先述のGitLabのドキュメントにも、GitHubで言うPull Requestのマージボタンを押したタイミングをスタート地点としていることからも、この考え方が正しいと言えるでしょう。

ここまで考えていたことを日本語で明確に書かれていた記事がzennにありましたので、こちらも読まれるとよいと思います。

あと、日本だと広木 大地さんも同様の指摘を行ってらっしゃいました。（簡潔でわかりやすい）

まとめ

ということで、Four keysのChange lead timeについてちょっと深堀りしてみました。深堀りしてみたものの、それでは 「これが正解なのでこれに従ってね！」 というのは少し暴論で、現場によって事情は異なるため自分たちの現場に合ったChange lead timeのスタート地点を見つけることが大事だと思います。
ただ、原義としてDORAの提唱するトランクベース開発を前提としていることを踏まえると、feature branchのfirst commitをChange lead timeのスタート地点として考えるのは適切ではないということがわかりました。

こういった元々はどういった定義だったのか？を深堀りするのは、思想を知るためにも非常に有意義なので、皆さんも「あれ？なんか引っかかる」と思ったことは、頻出する情報に飛び付かずに調べてみるのをオススメします。

以上、ちょびっと深堀ってみた話でした！間違いやご指摘があれば、ぜひ教えてください！🙇

それでは、また次号でお会いしましょう！