テストと品質
「検査（テスト）の強化が、品質改善の最善策とは見なされない」と、PMBOKでは解説されています。
なぜでしょうか？
テストは、品質を保証する行為です。
このテストをやったから、このパターンにおいては想定通りの動きをします、ということを保証しています。
品質を高くすると言って、とにかくテストパターンを増やしまくる策をとると、
同じようなテストを繰り返して、コストがかかる割には効果は薄く、
しかも実施していないパターンについては保証されないまま、ということになります。
動かすとすぐバグが見つかるようなプログラムに対して、手厚いテストを行っても、
手間ばかりかかり、結局はバグが残存してしまう、というのは容易に想像がつくと思います。
元々の品質がしょぼいと、いくら直しても、大した品質にはなりません。
そのため、品質を高くしたいのであれば、ものづくりの段階で対策を打っておくべきです。
こんな風に設計や製造をする、こんなレビューをする、といった、「計画によって」求められる品質を達成すべきです。
例えば…
・設計者に対し、事前にシステムの要求事項の説明をしておく
→要求を汲んで設計を実施することにより、要求の認識違いなどを防ぐ
・プログラマに対し、以前の開発で発生した製造バグの内容の展開をする
・開発中において発生したバグの展開を行う
→同じようなバグを作りこまないようにする
・レビューの際に、要求事項や議事録などを参照し、要求を満たしているかを確認する
→要求の実装漏れがないようにする
・あとはよくある、レビュー時間の目標値、設計・製造バグ数の目標値を定めること など。
ものづくりのフェーズに、重要なリソースや、多くの時間をつぎ込むことも大事と思います。
プロジェクトが炎上するのは、テストフェーズになってからが多いです。
ものづくりのフェーズをやっつけで何とか終わらせ、あとはテストで確認しよう、と考えているプロジェクトはとても危険です。
ものづくりの段階で、いかに品質の高いものを作るか、を意識して進めることが重要です。
その方がコストもかからず、結果的にプロジェクトを成功に導く可能性が高い、と考えます。
作りこみ時の品質を高めるには？についてはこの本。
