【定量的品質予測のススメ】測定単位を細かくすれば詳細な品質管理・分析を行うことができるのか

Ｐ11｢2.2.1　測定単位(品質管理単位)｣において「測定単位を細かくして品質データ(欠陥数等)を測定することにより、詳細な品質管理、分析を行うことができる」と書かれている。
本当にそうだろうか。

例えば、プログラムソースの「測定単位を細かくして」１論理ステップ毎の欠陥を測定することに何か意味があるのであろうか。
それは極端な話、といわれるかもしれないが、では、「測定単位を細かくして」の細かくする最小単位は何であろう。

詳細な品質管理、分析を行いたいからと何でも「測定単位を細かく」すればよいわけではない。
測りたいものの特性に応じた測定単位で測ることが重要なのである。

これに対しては「細かく測るからこそ、その結果を見てどの単位で測ればよいかが見えてくる」と言うことも出来よう。

本書は、P6で｢開発途中の品質は、その組織において経験的に測り得た何種類かの品質関連指標を測定して評価されることが常であり」と書かれているように、まず、とにかくデータを集めてそれから品質指標を考えようというスタンスのようである。
だから「測定単位を細かくして品質データ(欠陥数等)を測定することにより、詳細な品質管理、分析を行うことができる」という発想が生まれてくるのであろうが、指標に対する仮説を立て、測定し、仮説の妥当性を確認してから指標として採用することも良い方法であると思われる。

尚、Ｐ67に、事例として、「テスト密度や欠陥密度の達成率の例が挙げられており、
　　　テスト密度の達成率　：　１３６．３％
　　　欠陥密度の達成率　　：　１７７．８％
とされている。
そして目標ガイドとして、テスト密度８０．０～１００．０、欠陥密度９．０～１２．０と書かれている。

確かに、有効桁数４桁でテスト密度・欠陥密度の達成率を評価できる組織であれば、「測定単位を細かくして品質データ(欠陥数等)を測定することにより、詳細な品質管理、分析を行うことができる」ということも理解できるが、「定量的品質予測のススメ」という書籍名で本書を手に取った組織にはそれは無理であろう。

しかし、この例で出された組織において、テスト密度７９．９０、欠陥密度１２．１５であった場合どう評価するのであろうか。興味深い。
また、前回のプロジェクトで、テスト密度８５．１０、欠陥密度９．５２であったものが、今回のプロジェクトでテスト密度８５．２２、欠陥密度９．５０になったら、改善されたと言うのであろうか。

何でも細かく測定するのが良いというのであれば、ソフトウェア開発の品質レベルに重要な位置を占める開発者のプログラミング時間の測定も、「設計書を読む時間」「どうプログラミングするか考える時間」「実際にキーボードを叩く時間」「書いたコードを読み返す時間」「コンパイルしている時間」等の単位で、かつ各時間を秒単位で、測定したらよいのではないだろうか(冗談で書いています)。

「測定単位を細かくして品質データ(欠陥数等)を測定することにより、詳細な品質管理、分析を行うことができる」という記述は本当は何を言いたいのかもう少し詳細に記述されるべきであろう。