はじめに
ユニークビジョン株式会社 では品質向上の取り組みの一つとして、リードタイムの計測と改善を行うことになりました。その理由と、どのように計測するのかを本記事にまとめます。
Four Keys
Four Keys とは、DORA (DevOps Research and Assessment = DevOpsの調査と評価)
によって選定された下記の 4 つのメトリクスです。
-
リードタイム
- 開発着手してから本番環境にデプロイされるまでの平均時間
-
デプロイ頻度
- 一定の期間内に何回本番環境にデプロイしたか
-
MTTR
- インシデント発生から復旧までの平均時間
-
変更失敗率
- 本番環境での即時の対応を必要とするデプロイの失敗の割合
Lean と DevOps の科学によると、これらの 4 つの指標は 収益性、市場占有率 と正の相関関係にあります。
すなわち、これらの指標を計測し、改善していくことで、組織のパフォーマンス向上が期待できるということです。
なぜ我々はリードタイムを短縮したいのか
テストやリリースの自動化を促進する
リードタイムを 1 日以下にしようとすると、テストやリリースのプロセスを自動化せざるを得ません。
自動化が進むと、開発速度が速くなり、ヒューマンエラーも減ります。
現在ユニークビジョンのテストは手動で行うことが前提となっており、改善すべき課題の１つであると捉えています。
細かくリリースしたほうが価値が高い
複数の機能をまとめて少ない回数でリリースしたときと、機能単位で細かくたくさんリリースしたときを比較してみます。
トータルで同じ工数の機能をリリースしても、リリースが細かい方が、価値 × 時間 の値が大きくなります。
実際に、一部のプロダクトで複数の機能をまとめて開発しているときに、案件対応で開発がストップしてしまい、すでに開発が終わっている機能も数カ月間リリースできない、という事態が発生していました。
素早くフィードバックを得られる
リードタイムが短いということはつまり、開発 → リリース → フィードバック → 改善 のサイクルが早いということです。
昨今の市場は目まぐるしく変化しています(ex. Twitter)。 細かくリリースして細かく軌道修正していくことで市場の変化に強いプロダクトを作ることができます。
採用するリードタイムの定義
リードタイムの終了時刻の定義は「その機能が本番環境で使えるようになった時間」という明確な定義がありますが、開始時刻に関しては複数の定義が混在しています。
下記の記事が非常によくまとまっていました。
リードタイム開始の定義
| No | 計測開始の起点 | メリット | デメリット |
|---|---|---|---|
| 1 | Issue が作られた日時 | ・課題の発生から解決までの時間を計測できる。 | ・すごく古い Issue に対応すると一気にリードタイムが長くなってしまう。 |
| 2 | Issue に着手した時間 | ・開発工程を最初から最後まで含んだ時間を計測できる | |
| 3 | 最初のコミットの日時 | ・集計のための担当者が行う追加の作業がない。 | ・「最初のコミット」が遅いとリードタイムが短く計測されてしまう。 |
| 4 | 担当者が実装を完了し PR を出した日時 | ・開発時間が含まれないので、Issue の粒度が大きくなりすぎてしまう可能性がある。 | |
| 5 | PR なども終わり deploy を待つだけの merge commit をした日時 | ・DevOps の改善の中心をテスト、デリバリーとしている場合には有効。 | ・デプロイにかかる時間だけしか計測できない |
どれを採用するか
我々は下記の理由から 2. Issue に着手した時間 を採用したいと考えました。
- 4, 5 では、Issue の粒度が大きくなりすぎてしまう可能性がある。
- 開発フェーズも含んでいる 1, 2, 3 での計測のほうが、開発を短い時間で終わらせよう。という気持ちになれる。
- 1 だとすごく古い Issue に対応すると一気にリードタイムが長くなってしまう。
- 3 の場合、「最初のコミット」が遅いとリードタイムが短く計測されてしまう。
どうやって計測するか
Issue に着手した時間を計測方法は、下記の２つが候補に挙がりました。
- 空のコミットを打つ方法
- ラベルを変更する方法
1 だと空コミットの手間が増えて開発体験を落とすと考えました。
これまでの開発フローをほとんど変えることなく計測可能な 2 を採用することとしました。
実際の運用方法
手順
- Issue に着手し始めたときに Issue に
着手中相当のラベルを貼ります。 - Issue が完了して、本番環境にデプロイされたことが確認されたら Issue をクローズします。
※ユニークビジョンでは Gitlab でリポジトリや Issue を管理しているので、ラベルが貼られた時間やクローズされた時間を Gitlab API 経由で取得して集計することができます。
救済措置
開発着手時にラベルを貼り忘れた場合、start at 2022-11-29 15:00 のように特定のフォーマットで時刻を記入します。
その時刻を優先的に開発着手時間として計測します。
対象外ラベルについて
一つの Issue をタスク単位の Issue に分割する場合は、親 Issue のみのリードタイムを計測します。
理由は、分割された Issue のほうが平均のリードタイムが短く計測されてしまうためです。
そのため、分割後の Issue には計測対象外ラベルを付けて、計測から除外する運用にすることとしました。
議論
ここまでの内容を、社内のエンジニア全員と議論したところ、下記のような意見がでました。
- より一般的に使われている定義は 4 ではないか。だとすれば 4 を採用したほうが、他社と比較できるメリットがあるのではないか。
- よりストイックな改善をするには、1 の定義を採用すべきではないか。
- 1-5 のすべての値を取ることで、どこがボトルネックになっているかが分かるのではないか。
- 計測する値を一つに絞る必要はないのではないか。
これらの意見を受け、2 の定義のリードタイムを中心に見つつも、他の定義のリードタイムも観測、公開していく、という方針に切り替えました。
実際に集計してみた
2 以外の定義のリードタイムについて、取り急ぎ集計してみました。（2 も集計出来たら追記します！）
※縦軸の単位は日
分かったこと
- どの定義でも増減の傾向は同じ
- 3, 4, 5 のリードタイムはほぼ同じ
- 巨大な棚卸しがなかった直近 3 カ月だけで見ると 3, 4, 5 のリードタイムは約 20 日
- 古い Issue を棚卸ししてクローズした 5 月と 9 月に数値が大きくなってしまっている
次のアクション
放置された古い Issue がリードタイム計測に大きく影響を与えてしまうので下記のような対策が必要そうです。
- そもそも Issue を放置しない
- まとめて古い Issue をクローズするときは計測対象外ラベルを貼って計測対象外にする
- 何らかの基準を設けて古い Issue をフィルタリングする
現在の 3, 4, 5 のリードタイムは約 20 日なので、これを下回るように意識して開発を進めていく必要があります。弊社で実施している OKR の目標として設定するのも良いかもしれません。
まとめ
リードタイムと一口に言ってもたくさんの定義があることが分かりました。どの定義もメリットとデメリットがあるので、それぞれを理解した上で、抱えている課題に最も効果的なものを選定しましょう。
また、社内での議論を経て、メトリクス一つにも多様な意見や見方があるということを実感しました。メトリクスを改善するにあたっては、メンバー間で「なぜそのメトリクスを計測するのか」という共通認識を揃えることが重要だと思うので、このような機会を設けたのは非常に良かったなと思っています。
まだ、ようやく計測ができるようになったばかりです。今後、実際にリードタイムを改善することが重要です。ユニークビジョンでのエンジニアの皆さん、一緒に改善していきましょう！