＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
もっといい品質管理手法のアイデアありませんか？
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2005-02-16 20:55
これに対する答えなら、簡単でしょ。当初の計画からのずれと、そのずれによる補正値を求めればいいのです。 いい加減だと思うなら、なぜいい加減だと思うのかを説明し、今の数値が妥当である根拠を説明すればいいでしょう。 例えば、今私がいるところでは、コード量が何ステップ（ステップに意味があるか、という問題もあるのですが、それは置いておいて）だろうと、最低バグ発見件数が１件となっています。しかし、１００ステップほどのコード、しかも３割はコメントや自動生成されるコードで、１件もバグがある方が品質的に問題でしょう。ですから、「対象ステップ数が極小であるため、問題なしと判断する」としています。 また、.NET Frameworkを使用していますが、DataSetを作成すると裏で大量の（そして半分は使わない）コードを吐き出します。レビューにはこのステップ数も含めますが、設定のミスをコードのバグとしてカウントするかどうかは微妙な判断だと思います。 同じように、画面設計でも、１つのコントロールを置くのに数ステップのコードが生成されるでしょう。コントロールを置く位置を間違えた、色指定を間違えたといったミスを、コードのバグとカウントするのか、微妙な問題ではないでしょうか。 あるいは、ステップ数からレビューにかける時間の上限も決められています。ところが、この時間をほぼ必ずオーバーする。何となれば、この基準は実際に行った時間を元に算出されており、今使っているレビュー時間は実際に行った時間×人数で求めているため、必ずオーバーするようになっています。 基準：５人で１時間→１時間 実際：５人で１時間→５時間 IDEが発達して、エディタだけでゴリゴリ書いていた時代の基準は適用できなくなってきています。もちろん、そのことを最初に指摘できなかったのはミスですが、単に「いい加減な基準」というのではなく、これこれの理由で、今の件数が妥当である／品質的に問題はない、と説明できないでしょうか。 あるいは、「いい加減な基準」と思っても、そのいい加減さを理論立てて指摘できないのなら、「いい加減」と判断する基準も「いい加減な基準」ではないでしょうか。 参照元記事の例では、中国側の言い分通りですね。テストしながらコーディングしているので、コーディング後のテストにバグが少ないのは当たり前。コーディング中のバグは、コーディング中であるが故にバグではない。日本側が、そういう開発スタイルを受け入れられるかどうか、品質とは別の問題であると思います。 もっとも、テストケースの品質検証を行う必要があると思いますが。 _________________ | ||||
|
投稿日時: 2005-02-16 21:25
この品質管理手法に意味があるのかどうかは甚だ疑問です。が、上記の主張はまったくもって筋の通ったものだと考えます。約束しているわけですから。もし、バグ摘出目標など品質管理に寄与しないのだと考えているのであれば、はじめから、そう述べて「目標値」など約束しなければいいのです。 約束した値を達成できなかった以上、その根拠を求めらて当然。その段になって、「品質管理手法自体に問題がある。」などと言い出すほうがおかしい。 | ||||
|
投稿日時: 2005-02-16 23:01
レスありがとうございます。 顧客がISO9001認証を受けていたりすると、どうしても数字を求められますよね。 この手の手法は統計学的なものなので、目標値も統計学的に定められていなければならないはずですが、実際にそのようにしている企業なんてどれぐらいあるのかな、と疑問に感じています。 よく「ISO9001なんかやっても工数が増えるだけで何にもいいことがない」という意見を耳にしますが、ISO9001はあくまで管理のフレームワークに過ぎないので、それに則って品質管理を行ったからと言って品質が良好だなんていう証明にはならないはずなんですけど。 | ||||
|
投稿日時: 2005-02-16 23:24
ぐるみんさんのおっしゃるとおり、ISOは品質が良好なことの証明ではなく、品質管理を行っていることの証明ではないでしょうか？ ソフトウェアも「ソースを見れば分かります」「動かしてみれば分かります」ではなく、JISマークのような誰にでも分かる指標が必要なんですよね。 作るほうは鬼のように面倒くさいんですけど･･････。 テストとドキュメント作成の自動化が待たれるところです。 | ||||
|
投稿日時: 2005-02-17 03:36
スレッド立てた張本人です。
いろいろなご意見ありがとうございます。 誰もまだ答えを出したことがない、簡単なことではない、というご意見が一番納得できました。できれば"ベストプラクティス"と呼べるようなものを教えていただきたかったのです。 私の意見と既出のご意見と混ぜますが、 ・バグ摘出件数の目標値には根拠がない。 補正すればよい、というご意見もいただきましたが、 目標値を変えることはできないのです。 なぜなら、”孫請けだから交渉の余地がないし、数字は変えられない"のです。 また、その条件を約束したのなら当然だ、というご意見はもっともですが、 現場が約束したわけではなく、目標値はお空から降ってくる ・数値による品質管理(と呼ばれるもの)は品質を管理する目的よりも、 品質管理がされていることを証明するための道具に過ぎない。 目標値を超せば品質が悪いと、少なければテストが足りないと揚げ足を取られる。 結局のところ、数値はごまかさざるをえない。 問題となるのはこのときで、開発者が自分で納得いくまで裏でデバッグできる 余裕があるか、書類上の単体テストまでで強制的に提出されるか。 のどちらかです。 また下請けの立場から言わせてもらいますと、 ・品質管理に五月蝿い元請会社は納期、コストにもうるさい。(要はケチ) ところが、下請けが納期までに十分な品質が出せなくても 更に上のエンドユーザとなる発注元には、できました、 といって平気で提出して押し切る。 場面を何度も見てきました。 結局のところ、 ◆◆◆品質管理者の権力 ＜＜＜ プロジェクト管理者もしくはその上位者の権力◆◆◆ という政治的というか構造的な問題が解決できない永遠の課題かもしれません。 しかし、改めて、 ■ユーザ、元請、下請が納得できる品質管理フレームワークのようなもの。 を理論よりも実践で行おうとしている方が少なくともこの世のどこかに いらっしゃると思いますので、そこをほんの少しでいいですから教えてください。 もしくは本で出版して、布教してください。 Jittaさんのご意見 >>> あるいは、「いい加減な基準」と思っても、そのいい加減さを理論立てて指摘できないのなら、「いい加減」と判断する基準も「いい加減な基準」ではないでしょうか。 私の至らない部分はご指摘のとおり、ここにあります。反省しきりです。 [ メッセージ編集済み 編集者: ららら 編集日時 2005-02-17 03:38 ] | ||||
|
投稿日時: 2005-02-17 12:44
？
やり方を聞いて布教しようとしても、失敗で終わるんじゃないですかねぇ。 品質管理というよりは、交渉術とかの方が役に立つかもしれません。 _________________ はゆる Smile, Smiles make me happy. | ||||
|
投稿日時: 2005-02-17 21:03
まず、自分の会社に対して、自社における品質目標値を作成することをお勧めします。もちろん、CMMIのレベル認定や、ISOの認定が受けられればなおいいのですが、過去のプロジェクトを統計処理してもいいでしょう。ISOやCMMIでは、下請けからの成果物についても管理対象ですから、下請けに基準がなければ自分たちの基準を押しつけることになります。 もちろん、“現場が約束”するわけではないので、営業とも連携する必要があります。 品質が管理されていることを証明する、もっともです。ですが、管理されていることが証明されているからこそ、品質は管理されているのではないですか？ また、ISOでは、そういった基準値は都度都度見直していくことが絶対ですから、現状からかけ離れているなら見直しを…孫請けだから要求できないのね。う〜ん、それも営業との掛け合いですね。自社での品質基準値が求まっていれば、営業に対して、「この範囲に収まっていればよし。外れていれば自社の実績より、この範囲でお願いしたいと掛け合ってくれ」とお願いできるのではないでしょうか。ただし、前提として、自社での基準が必要ですが。 なんにしても、終わってから「意味がない」といっても、ただの言い訳です。本当に意味がないと思うなら、始まる前に言っておくべきでしょう。 _________________ | ||||
|
投稿日時: 2005-02-17 23:36
加納といいます。
王道としては「自分の会社」が約束するよりも、まさに「現場」が約束することでしょうか。 もちろんWBS等でしっかりと成果物の規模を計ることも含めて、ですが。 ここで重要なのは本当に開発するプロジェクトの人たちが納得した見積もり をその当人たちが作成して顧客に提出することです。 もちろん、営業が出したのとは違うでしょうが、とりあえずそれは気にしない ことにすれば。「提出」自体は意外とできるものだと思いますが。認められるかは ともかく。 顧客が認めようが認めまいが、プロジェクト内で開発する人の行った見積もりが 一番正しいわけです。よって、その見積もりに「なる」わけですから、その線で 交渉すれば何とかなる可能性はゼロではないと思います。 この件で言うなら、例えば1ks当たり20件摘出すると決めたなら、(数字は適当) その件数を摘出するべく、いろいろ工夫をするはずです。しなかったら開発の 怠慢でしょう。その工夫を顧客に話せば理解してくれると思います。 通常、テストのほとんどは「視点」を変えることと同じですから、いろいろ な視点で「システム」を見てテストをするはずです。 だから、その視点の仕様における網羅性などを話せば分かってくれると思います。 もし、理解されないなら、単に開発能力が足りないのでは。。。 [ メッセージ編集済み 編集者: 加納正和 編集日時 2005-02-17 23:41 ] | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.