2008_09_18－故障の原因を探る。

２００８年９月１８日発行

分割ラインです

　《　品質管理編　》

　故障の原因を探る。
　　
　　
　　後の祭りなのかも知れませんが、
　　多くのプロジェクトでは、故障の事象を再度見直し、後工程への反映と
　　対応は行いますが、
　　次プロジェクトへの反映は稀なのです。
　　
　　
　　ＩＴプロジェクトは、同じものをたくさん作る製造業とは異なり、
　　たいていは、１回作成しておしまいになっているのです。
　　
　　故障分析のフィードバックが、ほとんど行われていないのが、
　　ＩＴプロジェクトの大きな特徴ではないでしょうか。
　　
　　
　　プロジェクトに参画する要員も全く同じであることはめずらしく、
　　変ることが当然になっています。
　　このような中で品質の維持・向上を図っていく意識は、
　　プロジェクトリーダーのモチベーションにかかっていると言っても過言では
　　ないでしょう。
　　しかし、多くのプロジェクトリーダーは、長年の向上しないやり方の
　　繰り返しに疲弊し切って
　　　　単に売上と利益の追求の板ばさみになっているのが現実です。
　　
　　
　　
　　
　　そこで少しでも次プロジェクトへ活かせる故障からの工夫は
　　ないものでしょうか？
　　
　　単体試験や結合試験以降の工程で故障の原因を探ってみます。
　　故障といっても、大きく３つに分けて考えてみましょう。
　　
　　
　　３つの中でも多いものを掲げてみました。
　　　　１．設計書の不良
　　　　　　設計書に書いていなかった。記述なし
　　　　　　設計書が間違っていた。　　記述誤り
　　　　　　設計書の記述があいまい。　不明確（曖昧）
　　　　　　ドキュメント修正もれ
　　　　２．設計書の読解能力
　　　　　　仕様の見落としてしまった。
　　　　　　仕様をちゃんと理解しないで製造した
　　　　　　仕様の確認不足により誤って理解
　　　　　　仕様の検討不足で矛盾があった。
　　　　３．ＰＧの不良
　　　　　　新人など知識の習得不足
　　　　　　注意事項の周知不足または無視
　　　　　　標準化の規則破り
　　　　　　修正時のチェック不足で修正モレ
　　　　　　不注意そのもの
　　
　　
　　
　　どのプロジェクトでもたいてい共通していることがあります。
　　スケジュールが遅れていても、このようなことを確実に行うことによって、
　　遅れが取り戻せたり、遅れがこれ以上大きくならないことを防ぎます。
　　
　　
　　
　　設計工程　　　・暗黙の了解に関する辞書を上流工程から作成しておく。
　　　・ユーザー独自表現や用語辞書を上流工程から作成しておく。
　　　・レビュー時にあいまい表現を探し修正する。
　　　・記述モレは暗黙の了解事項や上流工程の設計書の理解不足が原因なので
　　　　辞書を読ませて理解不足を補う。
　　　・修正モレの多くは横展開の確認ミスです。横展開チェックシートを
　　　　作成しましょう。（何箇所修正するのか先に一覧表にするのです）
　　読解能力
　　　・不明な点や疑問点はすぐに聞くことができ、早い回答が得られる体制を
　　　　敷く。放っておかない。ちょっとした疑問でも確認する。
　　　・新たな参画者には、辞書を読ませ理解を早める。
　　　・辞書は常に更新していく。新しい参画者のために作ることは結局、
　　　　　自分の身を助ける。
　　ＰＧ工程
　　　・標準化違反チェックをソースレビュー時に行う。
　　　・新人や新規参画者のＰＧ能力を見極めてフォローやチェック体制を敷く。
　　
　　
　　
　　
　　
　　故障が全くなくなることは、ありませんが、
　　　　　　　単純ミスは、少なくなります。
　　　　そして後工程で余裕が必ず出てきます。