システム開発(アジャイル・スクラム)とか色々

スクラムについてのアウトプットだったり、時々お気に入りのものなど。

アジャイル開発でのメトリクスについて考える

はじめに

大規模のSIだと必ず出てくるメトリック、 現場とはまったく無縁の企画部門から求められる評価指標、組織で働いていると一度は悩むことがあるのではないでしょうか。

最初に断っておきますが、見る人のコンテキストによっては当たり前じゃんくらいの可能性が高いので、期待値低で見ていただけたらと思います。

今回の内容はアジャイルチームを支える会さんの勉強会に出たときの気付きをベースに作成したものです。これはまた別途まとめられたらいいなあ。

なんでメトリックが必要なんだっけ?

なにかを定期的にモニタリングする、これが脳死で目的化されてしまうケースがあるかもしれませんが、よく考えてみるとチームなりプロダクトをより良くするため、現場の自分達が自ずと欲するもの。

最近バグが多いとかなればカバレッジ見たり、なんかオーバーヘッドが多いなと感じたらリリースサイクルを見たりとか、チームやプロダクトを良くしていくための評価指標は定期的にウォッチすべきだし、本来メトリックって目に見えないものを自分達のために見える化させる、そういうもの。

近視眼的なTryがふりかえりで出がちだったりするけど、突き詰めて考えるとこういうことを改善したい!、だったらこういった指標でモニタリングしたいよねっていうチーム作りを目指したい。

上司が求める指標ってなに?

上司が評価指標を求める、結局それは安心が欲しいだけじゃないですか? そんな人はこう一蹴するか、こちらからプル型のまめな報告。スクラムだったらレビューの場に呼ぶのが早い。

面倒くさい人はこれで排除できるとして、いやいや投資の判断基準とかあるわって言われたらそれはプロダクトのビジネス価値やKPIを置けばいいし、このあたりのメトリクスこうあるべきのコンテキストが色々な人と共有できていれば上手くいく気がしてきた。

さいごに

ベロシティをKPIにすべきと報告書に記載するようなコンサルはこの世から滅びればいいなあ。(フィクションです)