@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- PR -

もっといい品質管理手法のアイデアありませんか?

投稿者投稿内容
ららら
会議室デビュー日: 2003/01/27
投稿数: 3
投稿日時: 2005-02-15 13:00
バグ摘出件数って必ずしも品質の指標にはならないと思いますが。

◇日本人担当者(参照元記事URL参照)
「当初のテスト実施計画では、システム規模○○に対してチェックリストを△△件、バグ摘出目標値が××件だった。ところが貴社のテスト実施報告によると、実際には約束したバグ摘出目標値より少ない。潜在バグがあるはずだ。いったいどういうことだ。その根拠を説明せよ」

私はこの場面の中国側リーダとちょうど同じ状況になったことがあります。
どうやらコーディング経験の無いプロマネ(真似)が増えているらしく、
単体テスト前のチェックはコンパイルしかしてはいけないらしい。
それで品質管理になるのでしょうか。

この品質管理手法が必ずしも悪いと言いませんが、前提条件があります。
1, コーディング開始前にチェックリストを作成してあること。
2, チェックリストはプログラマとは別の人間(仕様を熟知している)が作ること。

また、バグ摘出目標値の算定基準がたいていの場合イイカゲン。

もっといい品質管理のアイデアがある!という方、是非教えてください。
_________________
はゆる
ぬし
会議室デビュー日: 2004/02/16
投稿数: 1008
お住まい・勤務地: 首都圏をウロウロと
投稿日時: 2005-02-15 13:27
こんにちは。

ええと、アイデアではないのですが…

引用:

らららさんの書き込み (2005-02-15 13:00) より:
〜してはいけないらしい


憶測で作業しているのがいけないのではないでしょうか。
顧客が求めているのは、何でしょう? 基準(手順)などをしっかり確認されましたか?

私には、参照元記事にある

引用:

「計画と実態が異なる」という話は、「いった、いわない」の議論と同様に頻繁にお目にかかります。


と大差ないように見えるのですが。
_________________
はゆる
Smile, Smiles make me happy.
ぐるみん
会議室デビュー日: 2005/02/12
投稿数: 12
投稿日時: 2005-02-15 20:42
「きちっと運用されていないから手法自体が正しくない」と言っているような気がしますが・・・
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2005-02-15 23:56
参照記事から品質を考えるのは無理がありませんか?
オフショアが題材だから「お前ら気おつけろよ!」って
いう意味で捉えれば良いレベルだと思うんですけど。

例えば、記事内容では「日本の品質意識を理解してもらうには」とありますが、
私達ってそんなに品質意識がありますかね?

日本人は他人に対し極度な品質レベルを要求する割に、
いざ自分が検証する立場になると非常にいい加減で
実務レベルで品質に厳しい目を持って対応されているのは
職人気質な方や非常に高いプライドを持って仕事をされる方ですね。

つまり、日本の品質というのは品質管理や品質手法ではなく
現場の人間で成り立っているのでは無いでしょうか?

また客観的に考えて検証という行為は、検証対象物の性質を網羅的に
理解し論理的に品質保証する手段を組み立てれる能力が必要な訳ですから
確りとした設計能力と知識が必要となる訳です。

もしかすると分析能力を凌ぐ難しさかもしれません。

検証がいかに高度な能力が必要であるか、そういう認識が出来ていない時点で
品質意識ってあるんですかね?と疑問に思います。

アイデアの方ですが、って事で
まず私達が品質意識を持つ事から始める必要があるのでは無いでしょうか?


_________________
OFF企画中ご意見募集

[ メッセージ編集済み 編集者: はにまる 編集日時 2005-02-15 23:57 ]
ぽんす
ぬし
会議室デビュー日: 2003/05/21
投稿数: 1023
投稿日時: 2005-02-16 01:15
いや、その、...
参照元の記事ではこの品質管理の手法を主題にしていないのに対して、
いまこのスレッドの話題はそれを主題に持ってきていると思うんですが...
その話をすればよいのでわ?
私は素人なので分からんですが。

・・・が、素人考えながら、そのプロマネ氏はバグが減っていってる
報告書を作ることだけに興味があるんじゃないの?とか思ってしまいます。
というと言い過ぎですかね。どこかで評価基準を叩き込まれたんでしょうし。

セミプロのプログラマとしては、デバッグとテストは別だよなあ、
なんてことを思ったりもします。

それにしても、あまりうまい手がないからこそ4、50年にわたってみんなが
苦労し続けている問題なわけで、簡単に解決できるとはちょっと思えない
ですが。

[ メッセージ編集済み 編集者: ぽんす 編集日時 2005-02-16 01:16 ]
はゆる
ぬし
会議室デビュー日: 2004/02/16
投稿数: 1008
お住まい・勤務地: 首都圏をウロウロと
投稿日時: 2005-02-16 11:11
引用:

ぐるみんさんの書き込み (2005-02-15 20:42) より:
「きちっと運用されていないから手法自体が正しくない」と言っているような気がしますが・・・


私は 「運用できなかった自分(たち)は、棚に上げてて大丈夫?」 が引っかかったのですが。
ららら さんが現在どういったお立場なのかは、文面から窺えませんでしたし、当時の顧客が、数字にだけ執着していたのか、要求レベルが高かったのかも分かりませんでした。
# いずれにせよ、受注する側としては頭の痛い話なのですが…
「その根拠を説明せよ」 と言われ(たのかな?)、その後どういう経緯を辿ったのかは、お聞きしたいところです。

品質管理と一口に言っても、とても範囲が広いものだと思います。
単体テストに主眼を置いていらっしゃるようですので、まずはチェックリストについて調べられてはどうでしょうか。
こちらのスレが参考になりそうです。

 ・ テスト項目数
_________________
はゆる
Smile, Smiles make me happy.
ぽんす
ぬし
会議室デビュー日: 2003/05/21
投稿数: 1023
投稿日時: 2005-02-16 13:12
引用:

はゆるさんの書き込み (2005-02-16 11:11) より:
単体テストに主眼を置いていらっしゃるようですので、まずはチェックリストについて調べられてはどうでしょうか。


そーゆー話だったのかな?
私は「根本的に考え方がまずいんじゃない?」とゆー話かと思ったんですが。

たとえば、全ての分岐を実行してチェックすればわりと良い品質になりそうな
気がします(それでもレースコンディションは発見できませんが)が、
現実的なコストでは無理なわけで。
じゃあ全ての行を実行しよう、とか、それもできなければドンブリ勘定で
何件テストする、とかになるわけですよね。
で、そのドンブリ勘定だけでは不安だから、バグの件数を眺めて残りのバグの
数を想像する、というまた別のドンブリ勘定をやってみる、と。
で、そのときの「数え方がまずいんじゃない?」ってのがいまの話だった
んじゃないかなあ、と思ったですが。
はゆる
ぬし
会議室デビュー日: 2004/02/16
投稿数: 1008
お住まい・勤務地: 首都圏をウロウロと
投稿日時: 2005-02-16 13:39
引用:

ぽんすさんの書き込み (2005-02-16 13:12) より:
私は「根本的に考え方がまずいんじゃない?」とゆー話かと思ったんですが。


その辺りもひっくるめて、よく分からなかったので、あちこちのスレにリンクしているスレを紹介してみたのですが
もう少し的を絞れば、色々な意見を聞けそうな気がするんですけどね (^^;

# 簡単に解決できることではないとは、私も思います…
_________________
はゆる
Smile, Smiles make me happy.

スキルアップ/キャリアアップ(JOB@IT)