DevOps の Four keys の Lead time for changes (=変更のリードタイム)についてのまとめ
DevOps の指標としての 4keys
DevOps のレベルの高さを測る指標として 4keys がよく用いられます。
- (英語)https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance
- (日本語)エリート DevOps チームであることを Four Keys プロジェクトで確認する
その指標とは以下の４つです。
- Deployment Frequency
- Lead Time for Changes
- Change Failure Rate
- Time to Restore Service
今日はその中でも特に２番めの Leed Time for Changes (=変更のリードタイム)について考えたことをまとめます。なぜなら、それ以外の３つの項目は特に曖昧な点もなく計測するものに対する揺らぎがないからです。しかし、変更のリードタイムは違います。
変更のリードタイムの定義
変更のリードタイムの定義は先程あげたサイトには以下のようにあります。
The amount of time it takes a commit to get into production
(commit から本番環境稼働までの所要時間)
これがどうにもよくわかりません。「本番環境稼働まで」というのは明確なのですが、「commit から」というのがどうにも曖昧で、よくわからないのです。なにかの時間を測るには start と end が必要ですが、この start にいくつかの解釈があるのです。以下に例を示します。
変更のリードタイムのスタートの解釈例
- 開発チケットが作られた日時
- 開発着手を示すために最初に空の commit をし、その commit した日時
- 開発チケットが IN PROGRESS 相当のステータスになった日時
- 担当者が実装を完了し PR を出すための commit をした日時
- PR なども終わり、あとは deploy を待つだけの merge commit をした日時
どれも一理ありそうです。
変更のリードタイムのレベル感
ここで一度、変更のリードタイムに求められるレベル感を見てみましょう。
(英語)
(日本語)
余談ですが、日本語サイトのほうは画像をクリックしても拡大画像を閲覧できません＞＜
For the primary application or service you work on, what is your lead time for changes(i.e., how long does it take to go from code committed to code successfully running in production)
Elite: Less than one hour(1時間未満)
High: Between one day and one week (１日〜１週間)
Medium: Between one month and six months (１ヶ月〜６ヶ月)
Low: More than six month (6ヶ月以上)
なんだかますますわからなくなります。そもそも MECE ではないので(例、２週間とかどこになるんだ？)そのことからもこの項目も目安に過ぎないということがわかります。ただ、merge commit 後からリリースまで６ヶ月以上かかるなんてことは想定でもないので、先程の解釈例の 5 は違いそうに思えます。
けれども「大規模かつあまり良くないフローの環境下では、リリースまでに稟議を要したり、ユーザーにサイト停止のアナウンスをしたりなどの時間がかかって６ヶ月以上かかってしまうところもあり、そういうところを Low としているのではないか？」という考察もいただき、5 の可能性を消せなくなりました。また、Elite だと１時間未満ということを改めて考えると、5 以外の解釈は逆に難しいのではないか？という捉え方もありました。
また、この 4keys は開発生産性全体を測る指標ではなく、あくまでも DevOps の指標なのだから、そう考えると 5 が妥当なのではないかと。
その他の考察
Change lead time is measured from the moment the developer starts working on a change to the moment that it shipped to production
https://www.youtube.com/watch?v=-GRta-0M6hQ
この動画では 2. か 3. といっていますね。
同じ出典の blog 記事では
やはり Coding そのものも含めているので 2., 3. ですね。
次にこちら
こちらでは、Lead Time(顧客の要望などがあってからリリースされるまでの時間)、Cycle Time（チームが改善に取り組んでからの時間)、Lead time for changes(コミットされてからリリースされるまで) としっかり定義しています。上の解釈例でいうと、Lead Time に相当するのが 1. Cycle Time に相当するのが 2., 3. そして、Lead time for changes に相当するのは 4. か 5. のようです。記事の後半で、このメトリクスを阻害する要因、改善する手段などがあげられており、それらを読む限りでは 5. に該当するように読めました。
そして同様の解釈をしているのがこちら。
Lead Time, Cycle Time, Lead time for changes について上の記事と全く同じ解釈をしています。これらを見ると、実は Lead time for changes の解釈が曖昧だと思っているのは僕だけで、このようにしっかりした定義があるのではないかと思いはじめました。またこちらは Development の中身も少し詳細が書いてあり、この図の解釈であれば、5. ではなく明確に 4. であることがわかります。
次にこちら
The definition of lead time for change can also vary widely, which often creates confusion within the industry.
おおおｗ やっぱりこの指標は業界内でもしばしば混乱の元になっているといっていますね。少し安心。ですが、このサイトでもしっかりと、Cycle Time と Lead time for changes は区別していました。
最後にこちら、Atlassian
One of the critical DevOps metrics to track is lead time for changes. Not to be confused with cycle time (discussed below), lead time for changes is the length of time between when a code change is committed to the trunk branch and when it is in a deployable state. For example, when code passes all necessary pre-release tests.
め、、、めちゃくちゃ明確！しっかりと、Cycle Time と混同するなってことと、トランクブランチにコミットされてから(つまり merge commit なので上述の 5.)リリースされるまでの時間と明言していました。
(追記 2022/09/29 ここから)
lead time for changes is the length of time between when a code change is committed to the trunk branch and when it is in a deployable state.
なんと、Atlassian は end の定義を自己解釈していました。デプロイ可能な状態になるまで...と。さすがにここは原文でも
The amount of time it takes a commit to get into production
とあるので、恣意的な解釈に思えますが。
(追記 2022/09/29 ここまで)
どうやら、定義としては 4., 5. が本筋のようです。
ちなみに、Yahoo! Japan では 2., 3 の解釈のようです。
Change Lead Time : 開発が始まってから、本番にデプロイされるまでの時間
定義を超えて
さて、ここまで Lead time for changes の定義を考察してきて、なんとなく正しそうなものが見えてきました。守破離の守ということで、まず自分たちの戦闘力を 4keys で計測するには、解釈例の 4., 5. あたりを採用するのが良さそうです。しかし、ここでさらに考えを進めてみたいと思います。私たちはこの指標を計測することで、課題を知り、それを改善することでビジネスの成功を促進したいわけです。となると、それぞれの解釈にはそれぞれ別の意味があることに気がつくと思います。
(解釈例の再掲)
- 開発チケットが作られた日時
- 開発着手を示すために最初に空の commit をし、その commit した日時
- 開発チケットが IN PROGRESS 相当のステータスになった日時
- 担当者が実装を完了し PR を出すための commit をした日時
- PR なども終わり、あとは deploy を待つだけの merge commit をした日時
1.を改善するためにやることはたくさんあります。フォーカスが効かなくなる恐れはありますが、これこそが本質的な顧客価値創出のスピードを表現できているともいえます。総合的価値創出スピードを計測し、それを改善したいと考えるならば、この指標を採用してみるのもありだと思います。個人的にはオススメしませんが。
2., 3. はほとんど同じなのでまとめて説明します。これらを改善するために最も手っ取り早いのは、チケットのひとつひとつのサイズを小さくすることです。粒度を小さくして開発してリリースする。リーンに開発するということを、こう捉え、ついつい粒度の大きい開発にしてしまっているようなチームにおいては、これを指標とすることで、チケットサイズを小さくする力が働き、課題解決に迎えることと思います。
4., 5. を改善するために必要なことは上述のサイトにも多く記載がありますが、自動テスト、コミットを小さく保つ、CI/CD を改善するなどです。これは改善すべきことにフォーカスが効くため運用がしやすいと思いますが、これ単体では改善幅が小さいようにも思います。しかし、あくまでも 4keys の一部として、ほかのメトリクスと組み合わせて改善を進めることが前提であれば、やはりこれが一番しっくりくるのではないでしょうか。
まとめ
これらを踏まえ、本来の意味するところ、それを理解した上で自分たちのチームの何を見たいのか、何を改善したいのかを改めて考えることで、どういうメトリクスを採用すべきかが見えてくると思います。
Discussion
まさに曖昧～と思ったので英語で調べていました。日本語の記事で助かります！
ちょうど社内でリードタイムの定義について議論になったところで、この記事が非常に参考になりました！
のところで、箇条書きの markdown がちょっと崩れているようなので、修正していただけると助かります。
良いまとめありがとうございました。
いえいえ、感想とフィードバックありがとうございます。確かに崩れていたので修正いたしました！
と書きましたが、最近は
Change Failure Rateもかなり揺らぐと思い始めています。主にこのあたりも、組織が何に課題をもっていて、何を改善したいかという目的にそって、ある程度柔軟性のある設計をしていいんだと思っています。みなさんどんな設定をしているのでしょうか。