2015年5月
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
無料ブログはココログ

« 2013年9月 | トップページ | 2014年6月 »

2013年11月

2013年11月27日 (水)

【定量的管理の疑問点】バグ摘出密度の上下限幅が2倍なのはどうなのか

バグ摘出密度の上下限値が2倍やそれ以上の幅となっている組織は多いと思われるが、これについて違和感を覚えないだろうか。

他の指標、例えば生産性実績を2倍以上の幅で管理されていたらどう思うのであろうか(個人的には別にそれもありと思うだけだが)。

管理するに妥当な範囲とは何か考えもせず適当な実績値持って来て箱ひげの見た目で判断してないだろうか。

そしてこのような大きな幅を持っていることに対して「バグ発生は離散的だし、統計的に十分な数のデータ集まっていないからこの程度のバラツキは許容すべき」とかを何の検証もなく直感で言って終わらせていないだろうか。

いやいや、このような管理はダメだと思われる。
管理というより管理もどき。

バグは離散的データ。だからこそちゃんと考えないと。

2013年11月20日 (水)

【品質保証】「チェックリストに追加します」がダメなわけ

何か問題があってうまい再発防止策がない際の苦肉の策である「チェックリストに追加します」の問題点。

本来チェックリストは行動、結果、成果物が予め定めた事項を満たすことを事後に確認するためのもの。しかし活用開始すれば直ぐ行動者は監査や品証への先回り的にチェックリストを満たすよう行動し始める。

チェックリストの項目いくら増えてもここまでならまだ問題は少ない。
しかし項目多くなるとその内チェックリスト項目を満たせば良いという者が出てくる。それでもまあチェックリストの体はなしているが、更に項目多くなると最後に"本プロジェクトでは対象外"をためらわず乱発するのが出てくる。何のためのチェックリスト。

また項目多いと本来のチェック側もよく分からなくり本来すべきをしなくなったり/できなくなったりする。実質使われないのと一緒の状態。それでも漏れのないフルスペックチェックリスト名の下に続々と項目追加され、一方で運用は破綻する。

最初に戻ると、チェックリストは行動、結果、成果物が予め定めた事項を満たすことを事後に確認するもの。しかしその予め定めた事項は詳細でないといけないのだろうか。チェックリストの使用者はチェック対象の素人なのか。チェックリストはチェックすべき項目全て詳細に網羅すべきものなのか。分野や使用目的によると思う。
チェック者でなく実施者がそれを満たすための用途ならもはやそれをチェックリストと呼ぶ必要はないし、基本的なことならいちいちリスト確認させるというより身につけさせるべき振る舞いである。だからチェックリストは本当に漏れやすい事項についてチェック能力を有するものが分かる程度に簡潔に作成するべきものであり、故に安易に増やし続けることは良くないのである。

« 2013年9月 | トップページ | 2014年6月 »