「ねらいの品質」と「結果の品質」

品質という定義は、すごく難しいです。

ユーザの要求通りに作ることが品質が高いという人もいれば、ユーザの要求以上のものを作るが品質が高いという人もいる。

一概には言えませんので、そのプロジェクトで品質とは何かをきちんと共通認識することが大事だと思います。

プロジェクトの特徴をしっかりと抑えてマネジメントするということです。

さて、品質には、２つの種類があるのをご存知でしょうか

ひとつは、ねらいの品質と呼ばれる設計品質です。

もうひとつは、結果の品質と呼ばれる製造品質です。

ねらいの品質（設計品質）

ねらいの品質は、設計段階で決まります。

つまり、設計が間違っていれば、絶対に品質の良いシステムは作られないということです。

プロジェクトには、要求変更はつきものですから、途中で設計の一部をやり直すことも頻繁に起こります。

そのときに、変更部分だけをやり直すのではなく、全体設計を見直すことをわすれないでください。

設計品質のチェックポイントには、以下のようなものがあります。

結果の品質は、テストのプロセスで作り上げます。

いきなり全体的な品質を検査（＝テスト）するのではなく、個々の品質を確かめてから全体品質を確認します。

積み木を積み上げるイメージですね。

製造品質で大事なのは、テスト（検査）した結果、不合格になった場合、その不具合原因がどこで入り込んだのかを追及することです。

システム開発のテスト工程は、単体テスト→結合テスト→総合テストなどと進んでいきますが、どのテスト工程で、どんな不具合が発生し、どの工程でその不具合が入り込んだのかを追及します。

例えば、総合テストで発見された不具合の原因を作ったのは、内部設計にあった場合、つまり、設計バグだった場合、ただ単に、バグを修正するのではなく、どうしてバグを作ってしまったのかを追及し、他への影響がないか、この時点でもう一度、全体設計を確認します。

また、よくテストの結果、バグが１件もないと喜んでいるＳＥがいますが、これは喜ぶべきことではなく、心配になる要因です。

テストとは、本番で障害を起こす前に、バグを発見することが目的ですから、テストでバグが発見できなかったということは、テストのやり方に問題があったと考えるべきです。

本当に、バグが１件もなかったのであれば、なぜバグが発生しなかったのかを論理的に考えます。

納得いくデータと考察があれば、バグがなかったことを良しとします。

パッケージ製品をカスタマイズなしで導入したり、簡単なプログラム修正だけのプロジェクトであれば、バグが無いということが考えられますが、ほとんどの場合は、バグが無かったテストなど存在しないと考えるべきだと思います。