システム開発では、納期内にシステムを完成させることはもちろん、顧客の要求を満たす品質を実現することも非常に重要である。ただ、品質という言葉は非常に曖昧であるため、本当に良い品質を実現できているかを定性的に判断するのは難しい。そんな背景もあり、現場ではしばしば品質基準というものが定められ、定量的に品質の良さを保証することが多い。
少し具体的に説明すると、このくらいの規模のシステムを作ったら、このくらいの試験項目を実施すれば良いだろう（＝試験密度）、あるいはこのくらいのバグが検出されるだろう（＝バグ密度）、というものを試験の前に定めておき、実際に試験実施中もしくは完了時点で、その基準値の許容範囲内に収まっていれば高い品質が満たされている、という考え方である。
ただし、実際にはいくら沢山試験をしたからといって、全く見当はずれな試験ばかり実施していれば品質は保証できないし、いくら沢山バグを見つけたからといって、十分に網羅性の高い試験を実施できたことを必ずしも意味しない。つまりは、品質基準を満たしているから品質が良い、とは言い切れないのだ。
さらに言えば、この品質基準というものの信憑性も非常に怪しい。品質基準となる数値をどうやって決めるのか？を何度か研修で学んだことがあるが、ほとんどの場合が「過去の類似プロジェクトの数値を参考に決める」というものだった。
つまり、過去に類似のプロジェクトが存在しないような新規開発の場合はそもそも定めることが不可能、というわけである。また、多くの場合、プロジェクト完了時に大した反省も行われないため、過去のプロジェクトで定めていた品質基準が妥当であったかどうかの考察はなされていない。間違った品質基準をひたすら使いまわしているのではないか？という疑問が残る。
こんなわけで、品質基準に頼りすぎるのは危険な行為であるわけだが、システム開発において（特に業務要件の）品質を担保することは非常に難しいため、こういった手法を取らざるを得ない部分がある。現場レベルでも、なんとなく類似の試験項目を追加してもあんまり効果的ではないだろうな、という予想は抱きつつも、上に言われるがまま、強化試験という名の無意味な試験をしてしまうこともある。
なぜこんなことになってしまうのか。私がSIerに入って感じたのは、システム開発の試験が、品質を保証することよりも、可監査性を満たすところに重きを置いてしまっているからだ。
要するに、実際にシステムの品質が良いこと以上に、システムの品質が良いと皆に思ってもらえることを重視しているのである。成果よりも努力を重視する日本にはありがちな考え方の典型例だ。
とは言え確かに、可監査性というものも重要である。
「バグのないシステムを完成させました！あとは使って下さい！」と言われても、お客さんは納得できないし、障害発生などのリスクを考えると、商用環境に導入できないはずだ。
それよりは、「これだけの試験を実施しました。これだけのバグを検出できました。従来の品質基準値がこのぐらいだったので、今回は前回以上の十分な品質が確保できています。なので、安心して使って下さい。」と言われた方がはるかに説得力があり、誰が聞いても納得しやすい。
ただ、そこに重きを置き過ぎて、実態が伴わなくなってしまっているのはどうなのだろうか。顧客への説明責任も大切だが、根本のシステムの品質を上げるために時間を使ってはどうだろう。
