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            
無料ブログはココログ

« 【共通フレーム2007】共同レビューに関する3つの説明 | トップページ | 【共通フレーム2007】予定の節目で、定期的なレビューとは »

2008年10月29日 (水)

【定量的品質予測のススメ】無理に指標を定める価値

P26「2.3.7 モデル利用上の注意点 (1)管理限界の設定」において、「もし十分な蓄積データがない場合は」として、2番目に「②既存の品質管理ツールで設定されている値を用いる」とある。

無理にツールを使うメリット・デメリットを書かずに、あっさり「既存の品質管理ツールで設定されている値を用いる」と書いて良いのだろうか。

P20「コラム モデル化時の注意点」の「ソフトウェア開発では複数の要因(特に人的要因)が大きく影響するため、測定値に大きなバラツキが出る(すなわち分布の山がなだらかな)傾向が有り、しかも正規分布にならない場合が多い。したがって、実際の現場では管理限界±3σでは範囲が広過ぎて利用できないことが多い」という記述がある同じ書籍の中で「もし十分な蓄積データがない場合は」「既存の品質管理ツールで設定されている値を用いる」などと、どうして簡単に奨められるのであろう。

「十分な蓄積データがない場合」には無理に管理限界を設定する必要が無いと言う判断もあると思うのだが。

しかし、本書は違う。
何が何でも管理限界を設定しなければならないと考えているようだ。

「もし十分な蓄積データがない場合」としての3番目に「③品質管理担当者やプロジェクト管理者の経験から暫定値を設定する等の方法でとりあえずの値を設定し、組織内のデータの蓄積と共に値を修正することが現実的であろう」と書かれている。

「とりあえずの値」を設定することのメリットよりデメリットの方が多いと言うことは考えられないのであろうか。

とりあえずやってみる。
これが「定量的品質予測のススメ」のスタンスである。

先に引用したP20のコラムを考えれば、「とりあえずの値を設定し、組織内のデータの蓄積と共に値を修正」しようとしたら、値が発散しすぎて何がなんだか分からなくなったというケースが出てきそうに思われる。

そして、ここが一番重要なのであるが、それが分かるまでの間、その「とりあえずの値」に基づいて実際のプロジェクトが管理されることになるのだが、このことに何の益があるのであろうか。

「値が発散しすぎて何がなんだか分からなくなった」と分かるまでは、「とりあえずの値」をモノサシに管理限界を超えた場合に是正措置を検討することは意味のあることなのであろうか。

ソフトウェア開発プロジェクトは、管理限界の精緻な設定を目標にしているのではない。
開発すべきソフトウェア作成を計画通り・要求通りに完了させることである。

「とりあえず定めた管理限界の値ではあるが、プロジェクトにおいて管理限界を少しでも超えた場合は、必ず対策を取ってください」ということのメリットを正当に説明できない管理限界は、いらない。

無理に指標を定める価値は何であろう。

品質だとなんとなくイメージできないかもしれない。では、利益指標を考えてみればよい。
業界の売上高対比平均営業利益率は何パーセントだから当社もそれを採用するので、これを下回る場合は必ず対策を取ってくださいということに違和感はないか。

「目標」「目安」に使うには良いかもしれない。しかし、管理限界のような「管理指標」として使う場合は、よくその値の精度を考慮して用いなければならない。

« 【共通フレーム2007】共同レビューに関する3つの説明 | トップページ | 【共通フレーム2007】予定の節目で、定期的なレビューとは »

定量的品質予測のススメ」カテゴリの記事

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/1048600/24606125

この記事へのトラックバック一覧です: 【定量的品質予測のススメ】無理に指標を定める価値:

« 【共通フレーム2007】共同レビューに関する3つの説明 | トップページ | 【共通フレーム2007】予定の節目で、定期的なレビューとは »