障害発生時の類似見直し

色々なプロジェクトチームがさまざまな持論を展開していることでしょう。

今回は、この記事から「類似見直し」だけに焦点をあてて、さらに深掘りしていきたいと思います。

あまりマネジメントが上手くないプロジェクトであれば『とにかく不具合が発生したら一律全て類似見直し』とすることでしょう。昔は"三倍返し"とか"十倍返し"なんて言葉で、とにかく思考停止して「1匹いたら3匹(10匹)いるから、見つけるまで見直しを止めるな」なんて悪習を徹底させる大手SIer企業もありましたが、その名残かもしれませんね。

ちょっと捻ったプロジェクトでは『不具合発生時の原因（分類？）によって類似見直しの有無』を決定するかもしれません。あるいは定量的品質管理によって『偏りが大きい不具合原因』や『バグ密度などの基準を上回った機能』に絞り込んで類似見直しをしていることでしょう。

ですが、そのどれを見ても私は品質保証の観点から私はあまり推奨したくありません。

たとえば、よくありそうな定量的品質管理を例に挙げると

　「偏りが大きい不具合原因」
　「バグ密度などの基準を上回った機能」

だけに絞り込んで類似見直しをしたとしましょう。もちろん見直しをする価値は高いと思いますし、"優先度"という観点からは文句なく正解だと思います。ですが、定量的品質管理の落とし穴は「優先度の高いもの」すなわち「基準を超えたもの」「著しく偏ったもの」以外はすべて問題がないと勝手に判断してしまうことです。

不具合は一つひとつ分析してみなければ、その内容から類似見直しが必要かどうかは判断できません。しかし、定量的品質管理においては「基準を超えたもの」「著しく偏ったもの」以外は雑魚と思い込んでしまって、切り捨てようとしてしまうため、それのみで品質を測ろうとすると100%の保証ができなくなってしまう点に弱みがあります。

もちろん、障害管理で一つひとつの不具合に対する詳細な検討ができていれば別ですが、そうしていればむしろその時点ですべて解決してしまうので定量的品質管理の出番は必要なくなってしまいます。

結果、

障害管理をしっかりすれば定量的品質管理は活きる。
でも、障害管理をしっかりすれば定量的品質管理そのものが必要なくなる。

ということになってしまうわけです。それでも完全に不要だとは思っていません。もちろん意味はあると思います。特にお客さま等への報告に用いるとそれなりに説得力が出ますので、コミュニケーションツールとしては良いかもしれません。

ですが、こと「品質」専用として扱うのであれば、"保証（100%、best）"ではなく"向上（～99%、more better）"にしか使えない…と思っておいた方がいいでしょう。

少し脱線してしまいましたが、「であれば類似見直しの要否や範囲というものは如何にして判断すべきか？」という話になります。

そこで私は障害管理における「時間軸」を用いるべきだと考えるわけです。

そもそもテスト工程自体にはあまり不具合というものはありません。

あるとしたらそれは

　・テストケース漏れ
　・オペレーションミス
　・データミス

の３点です。ですが、１つめの「テストケース漏れ」を除けばどれも大した問題ではありません。製品やサービスの品質自体に問題があったわけではないので、適切な方法やデータで再実施すればいいだけです。

問題は「テストケース」が漏れた場合です。
この不具合はその工程の質そのものが問われます。そこで保証しきるはずの品質が保証しきれていなかったということですから、信用問題にも関わります。

もし、テストケースがそのテスト工程で求められているすべてのパターンを網羅していれば、基本的にその工程で発見されるべき不具合はすべて検知されるはずです。

テストの質が高いか低いかは主にこの観点で語られるべきなのです。