「LeanとDevOpsの科学」の「リードタイム」を正しく理解する
「LeanとDevOpsの科学」 という本がある。 この本では、「Four Keys」と呼ばれている1、ソフトウェアデリバリのパフォーマンスを計測する指標が紹介されている。
- デリバリのリードタイム
- デプロイの頻度
- サービス復旧の所要時間
- 変更失敗率
以上の4つである（ここでは本の中の用語のまま載せさせてもらった）。 この中の 「デリバリのリードタイム」 は何なのかを説明したいと思う。
デリバリのリードタイムとは
「機能の開発が完了2してから、本番環境にデプロイされるまでにかかる時間」 のことである。
文字通り「デリバリ」のリードタイムのことだ。 このリードタイムは、例えば「手動」テストをしていたり、「手動」デプロイをしていたりすると、長くなる。 だから、テストはなるべく自動化しなさいよ、デプロイも手動でやってないでボタン一発でできるようにしなさいよ、そうしないとパフォーマンス低いよ、となるわけである。
「開発にかかった時間」は含めない。
「開発にかかった時間」を計測しない理由
本のp.21に以下のように書かれている。
製品や機能の設計と検証の所要時間に関しては、多くの場合、所要時間の計測をいつ始めるべきかが明確ではない上に、変動が非常に大きいという問題がある。
言っていることはもっともだ。
「所要時間の計測をいつ始めるべきかが明確ではない」 は大いに共感できる。
単純に考えるとコミット日時なんかは思いつくが、それだけだと実際にコミットするまでの「どうやって実装しようかなぁ」と考えていた時間が入っていないけどそれっておかしくない？と思う。
また、「どういう機能にすべきか」と機能要件を検討している時間も入れた方がいいのではという意見もあると思うし、もっと言えば顧客から要望の電話が来た時から計測すべきなんじゃないか、という意見もありうるだろう。
「変動が非常に大きい」 も共感できる。
コーディングにかかる時間は開発しようとしている機能の難易度にもよるし、開発者自身のスキルにも左右されるしで、そんなものを測ったところで意味がなさそうなことは容易に想像がつく。
それを含めてしまうと、めちゃくちゃ簡単なアプリ（例えばシンプルなToDoリストアプリとか）を作っているチームはエリートになりやすいと思われるが、だからと言ってそれを担当しているチームが優秀だ、とは言えないだろう。
すべての機能の開発難易度が同じなら、コーディング時間を計測することでエンジニアの優秀さを計測できるかもしれないが、そんなことは現実的にあり得ない。
「LeanとDevOpsの科学」は「2,000社を超える多くの会社・チームを調査して得られたデータを分析したら、こういうケイパビリティを持ったチームがソフトウェアデリバリのパフォーマンスが高いことが分かった。
そしてそれらのケイパビリティはすべての会社・チームで実践できる」ということを説いている本だ。なので、そのチームが開発しているソフトウェアの難易度や、チームに所属しているエンジニアが優秀かどうかが大きく影響するような指標では意味がない。
「優秀なエンジニアを雇って簡単なソフトウェアを開発しましょう。そうすればパフォーマンスが上がります」では、はぁそうですかとしかならない。
だから、パフォーマンスの計測に「開発にかかった時間」を含めないのである。
「開発にかかった時間」を計測しても意味がないのか
流石にそこまでは思わない。
たとえばGitHub CopilotなどのAIを導入したら、どのくらい時間が短縮できたのかは知りたいだろう。 その辺りの指標として役に立つかもしれない。
ただ上述したように、開発対象のソフトウェア機能の難易度や、エンジニアのスキルに左右される部分も大きい。 ここをきちんと理解しておかないと、とんでもない評価を下される可能性がある。
リードタイムの解釈を勘違いしている人が多いのはなぜか
これはDORAが悪いと思う。
Four Keysってよく聞くけどなんだろう。Four Keysで開発生産性3が計測できるらしい。Four KeysはGoogleのDORAが提唱してるらしい。じゃあ「Four Keys」を正しく理解したいなら本家だろう、ということで見つかるのは本家っぽいオーラを出している 「エリート DevOps チームであることを Four Keys プロジェクトで確認する」 だ。ここには以下のように書いてある。
変更のリードタイム - commit から本番環境稼働までの所要時間
commitから？commitってなに？どれのこと？となるのは間違いない。私もなった。
よく分からないのでこれの解釈をインターネットで検索する。 するとFour Keysを解説している記事の中でも「commitとはいつのことなのか」の解釈がバラバラである。具体的に言っていない記事も多い。
また、「First commit」というワード4もよく出てくる。 このワードのせいで、「最初のコミットから、デプロイまでの時間」と勘違いしているような記事が散見される。
DORAはトランクベース開発を前提としている。 なので、コードへ行ったコミットはすべてデプロイフローが走り、ユニットテストや自動受け入れテストをパスすればデプロイされる。 これが前提となっているので、「コミットから本番環境稼働までの所要時間」という説明になるのだ。
ところが、featureブランチを切ってPull Requestを作り何日もかけてコミットを積み重ねレビューを受けてマージして、初めてデプロイフローが走るような状況で開発していると、そんなことはまったく想像が付かない。
このすれ違いが、誤ったリードタイムの解釈が広がってしまった原因だろう。
まとめ
「LeanとDevOpsの科学」 で紹介されている、開発組織のソフトウェアデリバリのパフォーマンスを計測する4つの指標のうちの、「デリバリのリードタイム」について説明した。
「デリバリのリードタイム」とは、「機能の開発が完了してから、本番環境にデプロイされるまでにかかる時間」のことを指す。「開発にかかった時間」は含めない。
「Four Keys」は「ソフトウェアデリバリのパフォーマンス」を計測するための指標であるということを、忘れないようにしよう。