「品質」を超えろ

中学生の頃からプログラムを書いているけど、学校を卒業して、コの業界に入って驚いたことが多々ある。
そのひとつが「ソフトウェアの品質」という言葉。会社で最初に教わったのは、バグや不具合が少ない（バグや不具合を充分に取り除いた）ソフトウェアが品質の高いソフトウェアであるということ....。これはある程度は当たっていると思う。特に最初から仕様がかっちり決まっている受託開発であれば、これで良いだろう。でも品質ってなんだろう？ 例えば「このキーボードは品質が良い」というと「このキーボードは不具合が無い」だけではなく「このキーボードは高級感があって打ちやすくて...所有して満足に値するものだ」となるのではないだろうか。「所有する喜び」や「使う喜び」等の度合いがより高いものが「品質が高い」というのだと思う。ソフトウェアの場合、当然バグの多少も含まれるが、「そのソフトウェアがどれだけ有益か」「使う人がどれだけ満足するか」「それを使うことでどれだけ幸せな気分になるのか」などという要素が、品質に入るべきだと思う。定量化は難しいが。

大量生産される製品の製造過程で不良率をコントロールする「品質管理」という言葉が昔からある。ソフトウェアにおける「品質」も、このあたりからきているのだろうか。ソフトウェアの開発行為を工業製品の製造行程にマップしようという試みが昔から行われているけど、ソフトウェアは大量生産される工業製品とは違う。むしろ一個一個手作りの世界だ。携帯電話に搭載され何十万台もの端末にコピーされるようなソフトでさえ、品質が確定するのはたった１コピーのソフトウェアが完成した時点だ。そのような世界で生み出されるものの「バグの多少のみ」に「品質」という言葉をマップするのに今でも違和感がある。
現状では、どんなに使い勝手の悪く殆ど何もできない糞ソフトでも、バグが無い（仕様書と動作が合致している）のであれば、出荷時点で「品質に問題は無いソフトウェア」ということなのだ。バグ・不具合・仕様書不一致の多少だけで品質を語るという段階を超えていく必要があると思う。