　製品が完成するまでに報告される不具合数は、製品仕様しだいで大きく異なる。開発者の技術力にも左右される。製品の作りや機能が複雑になれば、製品でできることが増える。できることが増えれば、それらすべてを正常に動かさなければならない。必然、不具合報告の数は増えていく。

　開発者の意図どおりに正しく動いているからこそ、不具合になる場合だってある。仕様設計自体がよろしくないから、設計どおりの正常動作がよろしくないのだ。疑問を感じるかもしれないが、この場面では正しい動作を「不具合である」と報告する。

　製品が完成するまでの不具合報告件数は、数百、一千で済めばかなり少ない。仕様設計がよほど手堅いのか、開発者の技術力が相当に優秀なのか、いずれにしても不具合が少ないのはよろこばしい。しかし、そうそううまくいかないのが、モノづくりである。

　不具合報告が数千にのぼるのは当然で、一万を超えても驚くほどではない。ひとりの品質管理メンバーが1日3件の不具合を報告したとする。チームが10名であれば、1日の不具合報告は30件だ。ひと月20営業日と考えれば、月の報告数は600件に達する。もちろんこれは単純計算でしかない。だが、さほど現実からかけはなれた数字ではないだろう。

　数字は実にわかりやすい。自分がどれだけの成果をあげたのか、嘘も偽りもなく示してくれる。誰の目から見ても明らかだ。ここで肝心なのは、数の内訳だ。

　ある日、Aさんは1件、Bさんは10件の不具合を報告したとする。ふたりの数字の差は10倍もある。優劣を比べられても不思議はない。あなたが評価者ならば、ふたりの仕事ぶりをどう評価するだろうか。もし数字のみで判断するのであれば、Aさんは低評価、Bさんは高評価となるはずだ。10倍の差は無視できない。ここで、数の内訳を思い出してほしい。Aさんが報告した1件は、製品動作の根幹部分にかかわる重大な不具合だった。Bさんが報告した10件は、仕様書への質問だけだった。ふたりに対する優劣の考えかたはきっと変わるだろう。

　不具合報告の数が多いことを、成果として誇らしく思う気持ちはよくわかる。だが、忘れてはならない。数字には量と質、どちらにも意味があるのだ。数字にこだわらず、品質管理が求める本質を見失わないでいてほしい。