【考察】Fourkeys の『変更のリードタイム』には、設計や開発の時間を含めないのでは？という話

株式会社ウェイブのSREシラトです！
数ヶ月前から、弊社のAnimeFestaチームで FourKeys の測定を開始いたしました！

Fourkeys において、変更のリードタイムの定義は

• コードのコミットから本番稼働までの所要時間

とされていますが、、、

＿人人人人人人人人人人人人人人＿
＞ コードのコミットって何？？ ＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣

何を差しているのかモヤモヤしておりましたが、
自分なりに納得のできる定義ができたので、共有いたします！

結論

GitHub Flow をベースにすると

• プルリクエストのコードレビューが完了し、masterブランチにマージされた時間

を変更のリードタイムの始点としました！

結論に至るまでの軌跡

まずは、書籍：Lean と DevOps の科学 の内容を見返してみました。
二章に記載されていた、変更のリードタイムの定義を要約すると以下の通りです。

リードタイムは大きく、以下の２つに分類される

1. 製品の設計と開発 の時間
   • 所要時間の測定をいつ始めるべきかが明確になっていない
   • 結果の変動が大きい
2. 製品のデリバリ（ビルド、テスト、デプロイ） の時間
   • 測定が比較的容易
   • 結果の変動が小さい

本調査研究では、「製品デリバリのリードタイム」を「コードのコミットから本番稼働までの所要時間」とした

以上のことから、製品のデリバリの時間、つまり、ビルド、テスト、デプロイの時間 が変更のリードタイム測定対象であると読み取れます。
本番環境へのデプロイは、CI/CDが導入されており、迅速かつ安定的にデプロイできることが求められている、ということですね。

割とあっさり、答えに辿り着いたのですが、ここで疑問点が出てきました。
「設計や開発の時間は測定しなくていいだと？！？！？！」
他にも疑問点が出てきましたが、自分なりに納得できるまで考察しました！

疑問点

1. 設計や開発の時間は、変更のリードタイムに含めなくていいのか？

一番腑に落ちた理由が、

• 設計や開発のリードタイムが短くなると、デプロイ頻度が向上する

と思ったからです。
「そりゃ、そうだろ！！」とツッコまないでください😇

また、現実問題として、開発途中にミーティングが発生すると、
リードタイムに含める？除く？などの判断コストが発生します。
測定が比較的容易、という理由にもめっちゃ納得しました。

2. なぜ、『コードのコミットから』と表現されているのか？

個人的な解釈のため、仮説となります。
ケイパビリティにトランクベース開発が含まれていることから

• トランクベース開発を想定していた

と思いました。
すべてのブランチ戦略を考慮して、変更のリードタイムを一言で表現することはできないと思います。
あまり深掘りするところでもないので、「もしかすると、こんな背景があったのかなー」と勝手に解釈しました。

3. 手動での確認作業があるとリードタイムが安定しないのでは？

弊社では、主に GitHub Flow が採用されており、
masterブランチへマージ → ステージング環境デプロイ → 本番環境デプロイ
の順番にデプロイフローが流れていきます。

ステージング環境では、デザイン崩れなど含めた手動での確認作業を行うため、
何らかの理由で時間が安定しない可能性があります。

しかし、製品のデリバリは、迅速かつ安定的にであること が求められているため、
ステージング環境の動作確認は可能な限り自動化することが、理想だと考えております。
また、ユーザーへの価値提供が遅れていること に変わりがないことや、
改善点を見つけ出すヒントにしたいと考え、あえて測定対象に含めてみました。

おわりに

Fourkeysの定義や疑問点について考察してみました！
次回は、FourKeysの可視化方法や実際の活用方法などをご紹介できればと考えております！

宣伝

ウェイブでは、電子コミックやアニメ配信などのエンタメコンテンツを自社開発で運営しております。
一緒に働くメンバーを募集中ですので、興味ある方、是非、以下のリンクにアクセスをお願いいたします！

https://hrmos.co/pages/wwwave