不良はあってはならない=存在しないものだった

私がシステム開発に携わるようになってから30年間の月日が流れました。
その間に品質に対する考え方は随分変わってきました。

私が社会人になった頃は、出荷した製品に不良はあってはならないという考え方が主流でした。
「そんなことは今でも当たり前だ。」と言われてしまうかもしれません。
確かにそうなのですが、昔は非常に硬直的な考え方をしていました。
私の会社がメーカー系で、工場の品質管理のやり方がベースにあったせいで、そういう傾向をより強く感じていたのかもしれません。

不良はあってはならないのだから、不良が起きた時の対処プランを立てようとする品質保証部門や上司から「不良があるかもしれないと思うなら、もっとテストをしっかりとやれ。」と怒られました。
不良を発生させないための冗長構成を考えるのは良いが、システムダウン時の縮退運転や手作業運用などのコンティンジェンシープランを考えるのはけしからんというわけです。
「ソフトウェアの品質を完全に取り除くことはできない」と言って怒られたこともあります。

まるで大日本陸軍のような世界でした。
確かに今よりは、出荷後の不良は少なかったのですが、不良が発生しなかったわけではありません。
でも事故は発生していましたし、公表されずに隠されてしまった不良も多くあったと思います。

Microsoftが不良に対する考え方を変えた

このような考え方が変わったのは、MicrosoftのWindowsが普及した頃からだったと思います。
ダウンサイジングが進み、その基盤としてMicrosoft製品が使われるようになった90年代終盤のことでした。

WindowsNTやSQL Server上で、Visual Basicなどで開発していると、明らかにOSの不具合としか考えられない事象が発生することがよくありました。
そうするとMicrosoftに問い合わせることになるのですが、その答えに驚きました。

Microsoft 「その不良は認識しております。」
私    「そうですか。いつ修正してもらえるのですか。」
Microsoft 「スケジュールは未定です。修正されない可能性もあります。」

何と不良があることは認めるが、修正しないかもしれないと言っているのです。
今では慣れましたが、当時はその答えに大変驚きました。

しかし、上司や品質保証部門もそれを理解し、ようやく不良が発生したときの対処プランをシステムに組み込むことに文句を言わなくなりました。

ただ、ちょっと頭にきたのが、「不良はあってはならない。」と言っていた品質保証部門の人が「不良が一定確率で発生するのは当たり前だから」としたり顔で言ってきたことです。