品質の分析 -1-（技術的原因）

ＱＭ（品質管理）だけでなく、ＱＡ（品質保証）であっても、一般的に結果に対する「品質」と言うものは必ずと言っていいほど分析をします。するはずです。たぶん。する…よね？

少なくとも、私は必ず行います。
なぜなら、評価しないことには、

ＱＭの場合
　「今後のプロジェクトで、再発を防止するために」

ＱＡの場合
　「現在起きている問題傾向を把握することによって、
　　他に見逃している不良や欠陥がが無いことを確認するために」

と言った観点で、見直しや再計画に活かさなければ、品質に携わることを主担当として遂行するための責任を全うできないからです。もし、していないＱＭやＱＡがいたら、たぶん責任を果たしていないと思います。

たとえば、ソフトウェア開発において…そうですね、プログラミング工程の中で発生した不良、欠陥の発生傾向が次のようであったとしましょう。

「技術的原因」は「どんな不良だったのか？」をあらわすものであり、「動機的原因」は「なぜ不良を作りこんだのか？」を示すものだと考えてください。

３つ目の表「作り込み工程」は、不良／欠陥を分析した際に、「どの工程で作りこまれた不良だったのか？」を示すものです。個人的には、「どこで作ったか？」ではなく、「どこで発見するべき不良だったか？」を示す方がより正確に分析できるのですが、まぁ、工程ごとに分析していれば自ずとわかってくることなので、どちらでも良しとしましょう。

みなさんはこの内容から、どのような分析を行うでしょうか。