00:02
こんばんは、2024年6月25日の夜です。
夜といっても、正確にはもう26時26日になってしまっていますが、
今日は会社の合宿で来ているホテルの部屋からお送りしております。
昨日のことは、正直、今ベロベロに酔っ払っているので
覚えていないです。ですので、今日来るときの話をしようと思います。
今日、この会場に来るまで、電車が1時間ぐらいと、
そこからマイクロバスで20分ぐらいだったんですが、
電車の中では本を読んでいました。
その本は、ソフトウェアアーキテクチャメトリックスという
モライリーさんから出版されている本です。
これは、私の知人、友人でもある島田さんが翻訳をされているので、
発売日に買ったんですが、つんどく状態にしてしまっていたので、
改めて思うことがあり、読んでいます。
この中で、私が1つ誤解していたかもしれなくて、
帰ったら確認しようと思っていることが1つあります。
それは、DEENとDevOpsの科学という本で、
ソフトウェア開発組織の生産性を測る指標として、
4つのメトリックスが提示されて、今はそれを見ている人とか、
もう少し新しい、別のメトリックスが最近はあったりするんですが、
そういう何らかの指標をとって、ソフトウェアの開発組織の生産性を
測ろうというか、改善していこうという試みがされていて、
私たちもそれをしているわけですが、その中の1つのメトリックス、
変更のリードタイムと呼ばれているものが、
自分が思っていたものともしかしたら違うかもというのが書かれていたので、
それを確認したいと思っています。
変更のリードタイムという名前だけ聞くと、
いわゆるリーン開発の文脈で、
サイクルタイムとかリードタイムという要求が作られ始めたか、
もしくは思いついてからお客さんの手元に届くまでの時間を
リードタイムとかサイクルタイムというふうに定義して、
それを計測するという枠組みがあって、
それと同じものだと、
思っていたのですが、
この本では、
Fortisの変更のリードタイムは、
それではないですよというふうに書かれていて、
そうだったっけと思って、ちょっと心配になっています。
この本で書かれている変更のリードタイムの定義は、
03:02
開発者が完成させたコードや設定の変更が、
パイプラインを通って端に到達するまでにかかる時間と書かれています。
要はデプロイにかかる時間とかテストにかかる時間みたいな、
そういうところを計測してくださいと言っているんですよね。
これは完全に私、
リーンの文脈のリードタイムのことだと思って、
そのつもりで計測をしたり人と話していたので、
ひょっとしてめちゃくちゃ間違っていたかと思って、
今、夜も眠れない状況です。
嘘です。もう寝ます。
というわけで、
ここの会場に来るまでの電車の中で読んだ本で、
もしかしたら間違って覚えていたものがあるかもしれないので、
帰ったらすぐに確認したいという話をしました。
それではまた明日会いましょう。バイバイ。
