Zero Bug tolerance (既知のバグをゼロにしてデリバリーする)

いつだったか、たぶん今年だけど、Zero Bug tolerance (既知のバグをゼロにしてデリバリーする) の話によしおかさんから「それは現実的じゃない。」という指摘を頂いた。確かに昔はやってなくてアジャイルとか CI/CD とかで変わってきたところだと思う。

むかし、半年以上のスパンで出すときは、リリース時にQAで見つかったものに重要度/緊急度の分析をして対応決める(トリアージ)が普通だった。深刻じゃないバグは注意書きしたりした。一定以上、深刻なのは小さく再リリース(HotFix)したり。なのでリリース後は結構忙しかったり。

あ、HotFixっていうのもマイクロソフトが自動アップデートするようになったWindowsの方のXPあたりから聞くようになった単語ですね(個人的にはそうだけどもっと前からあったのかもしれない)。

継続的デリバリーの世界では毎日潰してく。品質が上がったというよりマインドの問題っぽい気がする。扱うシステムの粒度が違ったり、リリースの頻度も違うんだろうけど、基本的なパスのエンドツーエンドテストを毎日やるようにしたりとかかなぁ。

で、同じようにQAしたらそれなりに発見されるんだろうけど、問題はクラウドというオープン系では2週間も状況を固定してテストしたりできないってことかな。(だから、品質の"判定"を会議でやるのはもう無理だと思う。)

あ、昔は完全な動作確認環境も作れなかったりした。ハードウェアがあってドライバ違いで出るやつとか。プリンタ機種依存問題とか辛かったな。仮想化とクラウドでずいぶんやりやすくなった、というのはある。

なんでこんな話を再考してるのかっていうと、Hunter の Chris Lucian がモブ始めて一年半バグが出なかったので、信頼を得て次のステップに進めた話をしてて、そうそううまくいかないプロダクトはバグ対応に自分たちが潰されちゃうんだよね、って思い出したことによる。

アンクルボブのClean Code の世界。これもアジャイルやってる人はみんな知ってると思うけど、意外と知られてなかったりするのかもしれない。きれい(Clean)といっても美意識の問題じゃないのです。ビジネス直結の話。

いまどき、リリース前のQAでボコボコ基本的な指摘が見つかるようなブロダクトに近づきたくないですよね。