アジャイル開発と品質管理の関係

「アジャイル開発はMTTRを重視している」指摘を受けたのでメモ。

【元ネタ】
MSDN：可用性の概要

平均故障間隔 - Wikipedia

平均修復時間 - Wikipedia

ソフトウェアやハードウェアの信頼性や可用性に関する用語として、MTBF・MTBR・稼働率などがある。

MTBF＝稼働時間/稼動回数
MTBR＝修理時間/故障回数

稼働率＝MTBF/MTBF+MTBR
故障率＝1/MTBF

MTTRは可用性、MTBFは信頼性・障害密度に密接に関係するのは周知の通り。

MTBFが大きいほど信頼性は高いが、ソフトウェアのMTBFは格段に小さいように思う。
SRATS:Software Reliability Assessment Tool on Spreadsheet Softwareのサンプルでも、MTBFはわずか16時間に過ぎない。
つまり、16時間後には必ず障害(バグ)が出る。

しかし、MTTRが「0」に近ければ、信頼性が低くても稼働率は100％に近くなる。
つまり、バグ修正工数が少ないほど、ユーザ側から見るとシステムはずっと稼動しているように見える。

アジャイル開発で、「開発の一番重要なファクターは時間である。平均バグ修正時間をみれば品質がわかる」という話を聞いた。
つまり、アジャイル開発ではMTTRを重視している、と。
確かにそうだろうと思う。

リファクタリング、テスト自動化、継続的インテグレーション等のプラクティスは、保守性を高めてソースを修正しやすくすることにつながる。
つまり、バグ修正工数と言うMTTRを短くすることにも注力していると言っていい。

Googleでも、サーバーは故障するものであり冗長化することに力点を置いているという話もある。
極論な話だが、HDDが1時間に1回壊れたとしても、予備のHDDにすぐに取替えできるならば、問題ないという考え。
つまり、MTBFが小さくてもMTTRがほぼ0ならば、実際のシステムの利便性は問題ない。

システム開発でもそうだ。
度重なる機能改善やバグ修正があったとしても、修正工数を小さくできる余裕があるならば、自信を持ってプログラミングできる。
つまり、保守性が高く、可読性の高いシステムならば、どんどん機能改善できる余裕が出てくる。
すなわち、アジャイル開発と相性がいい。

プログラミングの保守性を高くする為のノウハウがGoFのデザインパターンでもある。
マネジメントのノウハウとしては、イテレーションという単位にシステム開発を分割して、スコープを制御する事によって、システムの安全性と継続性を重視する選択肢も取れる。

アジャイル開発と品質管理の関係についても色々考えてみたい。