アジャイル開発におけるメトリックを考える その②
はじめに
開発生産性は高いのか、コストはどうなんだとか、投資判断をするにあたって必要という主張は理解できるんですが、報告するためのメトリックという意味のなさに辟易し、いろんなところで相談していたのが結構前のはなし。
ちょっと前に受けたScrum@Scaleのトレーニングでは、S@Sの概念的なところもそうですが、どういった指標を取る？というところにかなりフォーカスしていて、やっぱり自分たちの健康度を測ったり、改善するためにもメトリック大事だよねを再認識できました。
というところで、そのあたりちゃんと考えていこうっていうメモです。
共通認識として持っておきたいこと
一言で言ってしまえば、ryuzeeさんのブログの一文で終了してしまうんですが、
スプリントの中ではチームは自己組織的に仕事をしているべきであり、外部から監視目的でメトリクスを取ることはありません（そういう用途で使ってはダメです）。 あくまでもチームが自分達自身がうまく製品を届けるため、そして改善のためにメトリクスを使うことになります。
というのが真理。
外部からの監視がなぜダメなのか、言語化した法則がいくつかあります。
そして、測定基準のもう一つの弊害「測定基準の改ざん」問題である。この問題を端的に表している法則がある。一つは「キャンベルの法則」と呼ばれ、「定量的な社会指標が社会的意思決定に使われれば使われるほど、汚職の圧力にさらされやすくなり、本来監視するはずの社会プロセスを捻じ曲げ、腐敗させやすくなる」というものである。もう少し直接的なのは「管理のために用いられる測定はすべて、信頼できない」という身も蓋もない「グッドハートの法則」というものもある。ようは「測定基準は改ざんされやすい」のである。
この記事にもあるケルヴィンの「測れないものは改善できない」は前提にあるとして、キャンベルの法則やグッドハートの法則というものを理解したうえでチームが改善のための指標を追うってことをマネジメントや他のレイヤーに理解してもらわないといけないですよね。
チームとしては、包み隠さない心理的安全性といった土台が必要。
最近はアウトカムで〜という話もよく聞きますし、誤解はなくなりつつあるのかとは思いますが、指標による安心をくれ的な風潮は変えていかないといけないです。
アジャイル開発における指標
あくまでも前述を理解したうえでという話になると思いますが、こんなものもあるよっていうのを調べてみました。
ボリュームあって全体的に学ぶところは多いのですが、「ソースコード変更とテストの継続的な実施」というのが面白いなと思ったのが楽天さんの資料。
www.slideshare.net
コミット数とコミットサイズを複合的に見たり、日次でコミット数や検出バグ数を見たりとか。
スプリントの終わりにまとめてテストしているミニWF化とか、レビュアーがやりやすい環境かとかわかりそう。コミットとかあまりフォーカスして見たことなかった。
他にもコンテキストも記録するというやり方も大事だなあと思った。
コンテキスト（文脈）も記録すること。 コンテキストのないデータは、ノイズ以外の何物でもないことがわかるかもしれない。 例: 動けるチームメンバーの数、スプリント中でのインシデントの激しさ
スクラムチームの成熟度は弊チームでもたまにやるのですが、結構抽象度が高く体力使うので、スプリント毎とかに測るなら、スクラムチェックリストやSpotifyのAgile Metricsとか良さそう。
スクラムチェックリストは日本語訳がありましたが、言語の壁をつないでくれる方は本当感謝しかないですね。
英語で検索するとscrum orgのサイトとかで色々とディスカッションされてますね、色々掘っていきたい。
雑なまとめ
記事を読みながら（あと携わっている開発を思い出しながら）メトリックと何が測れるのかをざっと考えてみました。
前述の通り、大事なのはこれだけを追うというよりは、複合的に見たり、そのときのコンテキストを把握したうえで活用すること。既に使ってるものもありますが、チームに合ったものを色々試していきたい所存。
開発者にフォーカスしたもの
スプリントバックログのDoneまでの時間
⇒スウォームできているか
INVESTのSとなっているかベロシティ
⇒技術的負債の蓄積
プロセスの改善度合い
チームの成長コミット数とコミットサイズ
⇒レビューのしやすさ
レビューの時間短縮日次のバグ検出数
⇒ミニWF化の懸念（後半にバグが出まくっている的な意味）バグ修正日数
⇒スプリントのスラック
スプリントの品質
サバイバルモード化
プロダクトにフォーカスしたもの
アウトカムや事業的な意味で考えるとたくさんありますが、自分が書くとお粗末になってしまいそうなので1つだけ。
- サイクルタイムと問い合わせ発生率（バグ的な意味）
⇒リリースのオーバーヘッド
プロダクトの品質
顧客へ届けた価値
自動化
チームにフォーカスしたもの
おわりに
まとめ疲れてしまったんですが、サービスのダウンタイムとかコールセンターの入電率とか結構思いつくものたくさんあるなあ、、
誰かとディスカッションしたい。
