未知の障害より既知の障害に対処する

経験則に基づく話。ソフトウェアの品質評価を行う際には、全く未知の障害を見つけ出そうとはかない努力をするよりも、既知の障害に基づく評価を行う方が、費用対効果が高くて効果的ではないかと思う。新規の開発対象や言語、開発環境、ドメインを対象にしたシステムでは、どのような観点で評価を行ったら良いのか、幾ら仕様書やドキュメント類が揃っていてもなかなか分からないことが多い。ソフトウェアテストの教科書通りに従っても、現実にはなかなか思うようにならないのだ。

ところが、以前に似たような開発をしたことがあるとか、対象ドメインの知識を持ち合わせている、古いシステムのことを理解している、開発者のスキルレベルをよく知っている、となると評価は俄然やりやすくなる。なんせ何が弱点であり、どのような評価方法を用いれば良いのか分かっているのなら、まずはそのウイークポイントから確認するのが有効なのだ。わざわざ小難しい評価を行う前に、ピンポイントの簡単な評価を行うだけで、直ぐに問題が見つかったりする。

特に役立つのが昔の障害管理レポートやチケット類で、これらのデータが一通り揃っていると、簡単に分析するだけで、評価を行う際の作戦が立てやすくなり、作業の見通しがずっと良くなることが多い。きれい事しか書かれていない仕様書類よりも、障害報告の方がずっと生臭い情報が載っており、プロジェクトの実状を知るためにも良い題材だったりする。

障害は偏在する。決して満遍なく存在するものではないのだ。そして、その障害は繰り返し発生する。下記はその一例。

Aさんが、あるバグが作ってしまう。

再発防止策として、Aさんはチェックリストを作って個人的に活用する。

しばらくして、別のBさんが同じバグを作ってしまう。

Aさんの作ったチェックリストをチーム内に展開して再発防止を図る。

しばらくして、新しく入ったCさんが同じバグを作ってしまう。

新しく加わったメンバにも、既知の事例とチェックリストを展開するルールを設ける。

しばらくして、Aさんが同じバグを作ってしまう。

昔作ったバグを忘れており、チェックリストでの確認がいい加減だった。

人は過ちを繰り返す。ミスをすること自体は仕方ないし、避けられないはずだが（例：タイプミスをしない人はいない）、その為の対策はいくらでも可能なはずだ（だからこそ、スペルチェック機能が有る）。全く未知の障害なら見つけ出すのも大変で、原因を突き止めたり対策を施すのも手間がかかるが、既知の障害なら、その辺の作業は難しくないし、短時間で片付けることも容易だ。

何よりも、全く新しいタイプの障害が見つかって「こんな問題が発生するのか」と発見が有るのなら技術的にも興味深いものの、既知の障害が再発すると、そのガッカリ感（精神的ダメージ）はかなり大きい（でしょ？）。そんな虚しさから逃れるためにも、再発防止の観点は必要だし、効率的に片付ける方策も不可欠だと思っている。