情報セキュリティ対策/プライバシーマーク取得コンサルティング/ISMS認証取得は、
『Lute株式会社』へ
ご質問・ご相談は、お電話か下記メールで 052-581-1573 .
index
support
pmark_dt
pmark_an
pmark_qa
pmark_iq
isms_an
isms_dt
isms_no
soshiki
koutei
yojitsu
hinshitsu
kyouiku
kyouryoku
user
securityM
profile
policy
seminar001
contact
2008年3月18日発行
《 品質管理編 》
お客様に品質報告をしましょう。(後編)
前回は、記録をつける習慣について書きました。
今回は、そのつけた記録の分析方法です。
まず件数についての分析を行います。
ちゃんと記録がつけてあれば、集計をExcelなどで
集計していきましょう。
1.合計発生件数を日付順に並べていきましょう。
折れ線グラフにしてみましょう。
当然、初めのうちはは急激な発生件数で総件数もうなぎ登り
ですが、だんだん発生件数は収まってくるはずです。
でも収まってこない場合があるのです。原因を考えてみましょう。
・故障の対応を行うとき、横展開(類似)対応を行っていますか?
類似故障対応を行っていないと、試験期間終了までも同じ故障対応
をしなければならなくなり、発生件数は収束しません。
・試験の内容が偏っていませんか?試験内容が一部手薄になっていると
薄い箇所の故障が潜んだままになっているのです。
・本当に品質が悪いと思います。収束していない箇所の設計工程や
製造工程まで振り返って正しく出来上がっているのかを確認しましょう。
本当に悪いのであれば、一旦戻って試験をやり直すべきと考えます。
そこまで悪くないのであれば、後工程の空き時間を利用して強化試験
を行うんです。
強化試験の内容は、これから分析して決めていきましょう。
2.目標となる試験項目数や故障件数目標を予め設定します。
(件数/規模=率に換算します)
この目標値は、会社ごとに固有な値をとっており、過去の実績に実績に
基づいて算出しています。(不明な方は、一度相談願います。)
まず全体の規模から見て、故障発生件数(故障発生率)は目標に対して
実績の故障発生割合を算出します。
また許容範囲を±60%と、かなり幅は広くとっています。これは、
開発方式や言語や難易度も問わないようにしているためです。
逆にこれだけ広く許容範囲を設けているにもかかわらず、大きく外れた
ものは品質に問題ありとする事は、経験上正しいと考えています。
実のところ、目標故障発生件数及び目標に対する許容範囲率の設定に
ついては説得材料となる根拠が乏しいのも事実なんです。
今ままでの実績から難易度を問わず全体平均値としてもとめるしか
できないのが現在の実情です。しかし目標をおいて故障の摘出を図っている
ことは、評価できると考えています。
フォーカスを絞った的確な品質指標値は、存在しないのが実情です。
3.視点を変えて考察をしましょう。
・全体で実績値は、目標値の許容範囲内に収まっていますか?
・人による集計結果の実績値は、目標値の許容範囲内ですか?
・機能別による集計結果の実績値は、目標値の許容範囲内ですか?
・重要なものを個別に捕らえた実績値は、目標値の許容範囲内ですか?
許容範囲内に収まっていない場合。
特定の人であれば、故障内容についてさらに詳しく見てみましょう。
また機能分類や開発方法分類など故障の傾向が分類できるものは
ないか探りましょう。
特定の人や機能や個別のものに故障が偏っている傾向が見られた場合。
次に故障の原因を分析しましょう。
─・─・─・─・─・─・─・─・─・─・─・─・─・─・─・─・─・
昨日配信分の中からのコピーです。
1.故障をつくった工程は、どこですか?
(どこの設計工程?、製造工程?、試験工程内で修正ミス)
2.そもそもどの工程で検出すべき故障内容だったのでしょうか?
3.なぜ、検出できなかったのですか?
試験項目なし、試験忘れ、結果確認ミス、設計から悪かった、
環境等の要因で今検出した、から選んで下さい。
4-1.原因が設計工程にある場合は、
設計書記述ミス、記述モレ、記述内容があいまい、設計書不整合、
設計書修正モレ、規約に違反、設計内容が検討不足
4-2. 原因が製造工程の仕様理解にある場合は、
仕様書の理解不足、仕様書を見落とした、仕様書の確認不足
4-3. 原因が製造工程の製造方法にある場合は、
文法手法の理解不足、連絡不足、規約違反、単なるミス
─・─・─・─・─・─・─・─・─・─・─・─・─・─・─・─・─・
1~4までの集計をしてみましょう。
偏りがあれば、再度確認すべき内容がわかりましたよネ。
例えば、故障の原因を作りこんだ工程が設計工程であれば、
設計を担当者に偏りがないか?機能別偏りなのか?
設計書の記述は問題ないでしょうか?
設計に問題があれば、今まで摘出できなかった理由を調べて
再度見直しを行う必要が出てきます。
結果確認ミスが担当者に偏りがあれば、担当者の試験結果
を再度確認しなければなりません。
一定の難しい機能などに偏りがみられ、設計上問題が無ければ
ミスした内容について再度追加項目の試験を行い補強確認を
しましょう。
このようなことを分析して調査結果をまとめて、強化試験を行えば
より精度の高い品質が確保できます。
これをお客様に報告したら、どのような印象を持たれるでしょうか?
「こんなに故障を出しているのか?」
「もっと試験をする必要があるのでは?」
しかし、報告内容に
フォーカスを絞った強化試験実施の内容と強化試験結果からの
潜在故障の推測状況や設計書見直し実施項目などを詳細に記述している
とどうなるでしょう。
情報がそれだけ詳細に与えられば、逆に安心するのではないでしょうか。
もちろん最初から信用していただけるのは難しいのかも知れません。
しかし、報告内容と実績が伴えば、信頼度は格段に他社を追い抜くでしょう。
お客様を教育していくのも、我々の仕事ではないでしょうか?
品質という情報公開を行いましょう。