品質は作り込むもの

ソフトウェア開発において、ありがちな品質対策の例。

• テスト作業への人員追加
• テスト期間の延長
• テスト体制の見直し

経験的に言って、こんな素性の悪いソフトウェアに関わるとロクな事が無い。根本的な作りが悪いソフトウェアを、いくらテストでフォローしようとしてもそれは無理というものだ。出血が続いているからと言って、傷口に絆創膏を貼り続けても何も解決しない。対処療法が効くのはほんのつかの間に過ぎないし、それでカバーできる範囲は極めて限られている。やるべきなのは出血が続いている根本原因を突き止め、その出血を抑えるための施策を取ることだろう。テストによってマイナス10点がマイナス5点に上がったことを指して「品質が改善した」と主張するのは大きな誤解だし、そもそもいくらテストを続けても決してプラスの点にはなり得ない。スティーブ・マコネル氏がCode Completeの中で言っているように、テストは品質を改善してくれるものではないのだ。

ソフトウェアの品質を上げるのに重要な要因は、開発者の優れたスキルと、それを上手く活用する開発プロセスの組み合わせだと思う。アウトプットに満足な品質を確保できないのなら、それはスキルや開発プロセスに問題があることの証拠だろう。品質は後工程で付け加えるものではないし、付け加えられるものでもない。開発工程の中で作り込むべきものなのだ。技術が充分にあれば障害の発生は幾らでも抑えられるし、足りない部分はプロセスの領域でフォロー可能だ。そんなわけで、最近では開発体制を見れば、その品質がおおよそ見当が付くような気がしている。

テスト自体はソフトウェアの品質を改善しない。テストの結果は品質の指標となるが、それだけのことであり、品質を改善するわけではない。テストの量を増やしてソフトウェアの品質を改善しようとするのは、痩せたくて体重計に乗る回数を増やすようなものだ。体重計に乗る前に何を食べたかによって体重が決まるように、どのソフトウェア開発テクニックを使ったかによってテストで検出されるエラーの数も決まる。痩せないのなら、新しい体重計を買うのではなく、ダイエット方法を変えなければならない。ソフトウェアを改善したいのなら、テストを増やすのではなく、開発作業を改善しなければならない。

CODE COMPLETE 第2版 上 完全なプログラミングを目指して

CODE COMPLETE 第2版 下 完全なプログラミングを目指して