アジャイル開発のキーメトリクス

先日JaSST新潟にて、t_wadaさんの講演を聴きました。資料は↓なので、ぜひご興味ある方はご覧ください。

この中でとってもいいな、と思ったのがこの記事のタイトルにもなっている、「4つのキーメトリクス」です。それは、

・リードタイム
・デプロイ頻度
・MTTR（平均修復時間）
・変更失敗率

です。アジャイル開発の時代になって、いかに早くユーザに価値を提供するか、そしてユーザが不便を感じたらいかに迅速にそれを解消できるか、が勝負であるためこのメトリクスはとてもしっくりきます。

なお、講演の際には、この4つが相対的に重要になってはいるが、昔から使われているメトリクス（例えばMTBF）が大事ではなくなったということではない、と強調されていました。そこは誤解なきよう。

リスクの種類の話

で、この話を受けてちょっと考えました。

各種製品におけるソフトウェアの占める価値の割合が増えてきていて、故障が起きてもすぐに直せば許されるように変わってきている。また、逆にポジティブな方向でユーザの嗜好や世の中の流行りが変わったらそれにすぐ対応するとユーザに評価されるようになってきている。

（負の）リスクには、「起きないようにする」という対策と「起きてから対処する」という対策があります。（厳密にはもうちょっと細かいものがありますがここでは割愛します）

4つのメトリクスが評価しているのは、後者の「起きてから対処」がどれだけうまくできたか、なのかなと思いました。

でも、そもそも起きてはいけないこともあるわけです。最近だと銀行口座への不正アクセスだったり、個人情報流出系だったりの、「一発アウト系」の問題です。それらは、「起きてから対処」では遅いわけです。起きてしまったらもうサービスが継続できないですから。（そういうサービス、思い浮かびますよね）

なので、絶対に起きてはいけない事象に対しては「起きないようにする」ための対策を打っておき、それ以外の事象はあきらめるという戦略になると思われます。まさにリスクベースドテスト、です。

では、4つのメトリクスだけで十分なのか

ちょっと話が逸れましたが、最初のメトリクスの話に戻すと、「起きてから対処」の良さを測るために4つのメトリクスを使い、「起きないようする」の良さを測るためにクラシックなメトリクスを使うのが良いのでは、と思っています。

これまでは「起きないようにする」側のメトリクスがほとんどだったのに対し、「起きてから対処」側が重要性を増す、という意味では組み合わせて使ってもt_wadaさんの意図からはずれないと考えています。