読者です 読者をやめる 読者になる 読者になる

バグは測定できないから管理もできない

計算機

測定できないものは管理できない

あるいは,

You can't manage what you can't measure.

あるいは

If you can't measure something, you can't manage it.

調べたけど出典がよく分からなかった.おそらくドラッカーかデミングの引用だと思われる.『まどマギ』のキュゥべえも似たようなことを言った.

観測さえできれば干渉できる。干渉できるなら、制御もできる。

これでいうとソフトウェアはどうだろう?見つかっていない障害を観測することはできない.当然,数を測ることもできない.

原理的には,バグは管理も制御もできない.

ドラッカーはそんなものには責任を追わなくてもいいと言っている.*1

社会的な責任を引き受け、問題の解決に乗り出す前に、マネジメントたる者は、問題のどの部分を自らの強みに合ったものにすることができるかを検討しなければならない。測定可能な目標で表せる分野があるかを考えなければならない。

もしそのような分野があるならば、自らの社会的責任として、さらに検討してよい。しかし、そのような分野がないならば、問題がいかに重要であって緊急を要するとしても責任を負うことは抵抗しなければならない。

そのようなものを引き受けても、社会に害をなし、自らに害をなすだけである。成果をあげることはできず、したがって責任をもつことはできない。

そんなわけにはいかないから,ソフトウェア開発者は観測できないものを測定するべく頭を捻ってきた.

測定というと客観性が必要だ.

ソフトウェアテスト293の鉄則

ソフトウェアテスト293の鉄則

によるとアメリカではプログラマとテスタは別の職種だそうだ.客観性という意味では,この2つが分かれていた方が正しい測定に近づく.自分でテストしたら,バグが多過ぎたらなかったことにするし,少な過ぎたらでっちあげる.別に悪いことでない.

でも,プログラマとテスタが分かれているのは,そんな理由ではなくて,文化の違いだろう.なんでもするけど何にもできない人を作るのが日本で,なんかだけできてなんかだけする人を作るのがアメリカ的だ.

客観的でなくても,経験則的にこのへんが怪しいとか分かるものだ.経験則は馬鹿にできない.この経験則を体系化できればすげえよな.