@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
もっといい品質管理手法のアイデアありませんか?
1|2|3
次のページへ»
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-02-15 13:00
バグ摘出件数って必ずしも品質の指標にはならないと思いますが。
◇日本人担当者(参照元記事URL参照) 「当初のテスト実施計画では、システム規模○○に対してチェックリストを△△件、バグ摘出目標値が××件だった。ところが貴社のテスト実施報告によると、実際には約束したバグ摘出目標値より少ない。潜在バグがあるはずだ。いったいどういうことだ。その根拠を説明せよ」 私はこの場面の中国側リーダとちょうど同じ状況になったことがあります。 どうやらコーディング経験の無いプロマネ(真似)が増えているらしく、 単体テスト前のチェックはコンパイルしかしてはいけないらしい。 それで品質管理になるのでしょうか。 この品質管理手法が必ずしも悪いと言いませんが、前提条件があります。 1, コーディング開始前にチェックリストを作成してあること。 2, チェックリストはプログラマとは別の人間(仕様を熟知している)が作ること。 また、バグ摘出目標値の算定基準がたいていの場合イイカゲン。 もっといい品質管理のアイデアがある!という方、是非教えてください。 _________________ | ||||||||
|
投稿日時: 2005-02-15 13:27
こんにちは。
ええと、アイデアではないのですが…
憶測で作業しているのがいけないのではないでしょうか。 顧客が求めているのは、何でしょう? 基準(手順)などをしっかり確認されましたか? 私には、参照元記事にある
と大差ないように見えるのですが。 _________________ はゆる Smile, Smiles make me happy. | ||||||||
|
投稿日時: 2005-02-15 20:42
「きちっと運用されていないから手法自体が正しくない」と言っているような気がしますが・・・
| ||||||||
|
投稿日時: 2005-02-15 23:56
参照記事から品質を考えるのは無理がありませんか?
オフショアが題材だから「お前ら気おつけろよ!」って いう意味で捉えれば良いレベルだと思うんですけど。 例えば、記事内容では「日本の品質意識を理解してもらうには」とありますが、 私達ってそんなに品質意識がありますかね? 日本人は他人に対し極度な品質レベルを要求する割に、 いざ自分が検証する立場になると非常にいい加減で 実務レベルで品質に厳しい目を持って対応されているのは 職人気質な方や非常に高いプライドを持って仕事をされる方ですね。 つまり、日本の品質というのは品質管理や品質手法ではなく 現場の人間で成り立っているのでは無いでしょうか? また客観的に考えて検証という行為は、検証対象物の性質を網羅的に 理解し論理的に品質保証する手段を組み立てれる能力が必要な訳ですから 確りとした設計能力と知識が必要となる訳です。 もしかすると分析能力を凌ぐ難しさかもしれません。 検証がいかに高度な能力が必要であるか、そういう認識が出来ていない時点で 品質意識ってあるんですかね?と疑問に思います。 アイデアの方ですが、って事で まず私達が品質意識を持つ事から始める必要があるのでは無いでしょうか? _________________ OFF企画中ご意見募集 [ メッセージ編集済み 編集者: はにまる 編集日時 2005-02-15 23:57 ] | ||||||||
|
投稿日時: 2005-02-16 01:15
いや、その、...
参照元の記事ではこの品質管理の手法を主題にしていないのに対して、 いまこのスレッドの話題はそれを主題に持ってきていると思うんですが... その話をすればよいのでわ? 私は素人なので分からんですが。 ・・・が、素人考えながら、そのプロマネ氏はバグが減っていってる 報告書を作ることだけに興味があるんじゃないの?とか思ってしまいます。 というと言い過ぎですかね。どこかで評価基準を叩き込まれたんでしょうし。 セミプロのプログラマとしては、デバッグとテストは別だよなあ、 なんてことを思ったりもします。 それにしても、あまりうまい手がないからこそ4、50年にわたってみんなが 苦労し続けている問題なわけで、簡単に解決できるとはちょっと思えない ですが。 [ メッセージ編集済み 編集者: ぽんす 編集日時 2005-02-16 01:16 ] | ||||||||
|
投稿日時: 2005-02-16 11:11
私は 「運用できなかった自分(たち)は、棚に上げてて大丈夫?」 が引っかかったのですが。 ららら さんが現在どういったお立場なのかは、文面から窺えませんでしたし、当時の顧客が、数字にだけ執着していたのか、要求レベルが高かったのかも分かりませんでした。 # いずれにせよ、受注する側としては頭の痛い話なのですが… 「その根拠を説明せよ」 と言われ(たのかな?)、その後どういう経緯を辿ったのかは、お聞きしたいところです。 品質管理と一口に言っても、とても範囲が広いものだと思います。 単体テストに主眼を置いていらっしゃるようですので、まずはチェックリストについて調べられてはどうでしょうか。 こちらのスレが参考になりそうです。 ・ テスト項目数 _________________ はゆる Smile, Smiles make me happy. | ||||||||
|
投稿日時: 2005-02-16 13:12
そーゆー話だったのかな? 私は「根本的に考え方がまずいんじゃない?」とゆー話かと思ったんですが。 たとえば、全ての分岐を実行してチェックすればわりと良い品質になりそうな 気がします(それでもレースコンディションは発見できませんが)が、 現実的なコストでは無理なわけで。 じゃあ全ての行を実行しよう、とか、それもできなければドンブリ勘定で 何件テストする、とかになるわけですよね。 で、そのドンブリ勘定だけでは不安だから、バグの件数を眺めて残りのバグの 数を想像する、というまた別のドンブリ勘定をやってみる、と。 で、そのときの「数え方がまずいんじゃない?」ってのがいまの話だった んじゃないかなあ、と思ったですが。 | ||||||||
|
投稿日時: 2005-02-16 13:39
その辺りもひっくるめて、よく分からなかったので、あちこちのスレにリンクしているスレを紹介してみたのですが ![]() もう少し的を絞れば、色々な意見を聞けそうな気がするんですけどね (^^; # 簡単に解決できることではないとは、私も思います… _________________ はゆる Smile, Smiles make me happy. |
1|2|3
次のページへ»