mofmofでは最近、「LeanとDevOpsの科学」という本の輪読会を行っています。 この本の輪読会は定期的に開催し、順次後ろの章についてもログを投稿する予定です。
前回は1章を読みました。記事はこちら「なぜケイパビリティに着目するのか。LeanとDevOpsの科学を読んだ記録（1章）」
従来の測定手法の問題点とは
従来は以下のような方法で測定していた。
- 書いたコードの量
- ベロシティ
- リソース利用率
それぞれ問題があった。
書いたコード量を測定することの問題点
巨大化したソフトウェアを生み、保守と変更のコスト増を招く
ベロシティを測定することの問題点
- チームの状況はチームごとで違うため、単純にベロシティ比較はできない
- ベロシティのため見積もりを水増ししたり、無理にストーリーを終わらせたりする
- 水増しはあまり経験したことはないが、ストーリーの完了条件を重視し、そこに合致する最低限で終わらせがちという話が出た（保守性、変更可能性の高いコードにするためには、ストーリーの完了条件を決める時点で良いコードを意識しておく必要がある）
リソース利用率を測定することの問題点
- リソースが空いているときに常に何か作業をアサインするような状態を目指してしまう
- それによって、改善や予想外の作業は入れづらくなるという話
じゃあ望ましい尺度は?
- デリバリのリードタイム
- デプロイの頻度
- サービス復旧の所要時間
- 変更失敗率
これらを測定して改善していくことが望ましい。 調査の結果、パフォーマンスの高い組織は、開発スピードを上げると品質も上がっている。 また、この尺度を改善することで、組織全体のパフォーマンス（収益性、市場占有率、生産性）もあがるとのこと。万能感
実際に行った議論
- 受託開発で行うハードルはありそう
- 開発チームだけで改善できる数値もあるので、適宜どちらに働きかけるか判断できるようモニタリングするのが良さそう
- 受託開発でやってるとこあるんかな?
- デプロイ頻度はなぜデプロイ?リリースではダメ?
- 変更失敗率も含有するためだと思われる。リリースだと失敗した（切り戻した）リリースを扱いづらそう。
- とりあえずtexta.fm聞いておくと役に立ちそう
- ハイパフォーマーとローパフォーマーについては開発環境やチーム状況等に大きな差がありそうなのでなんとなくイメージが湧くけど、ミディアムパフォーマーとの違いが何なのかかがポイントになりそう
- リードタイムは、何をした時点から、何ができた時点までを測定するのかなど、指標の定義は組織毎に多少のカスタマイズをして決める必要がありそう
- まずはGoogleのfourkeysを参考にすると良さそう
