2009_08_07－設計工程における故障原因「検討不足」。

２００９年８月７日発行

分割ラインです

　《　品質管理編　》
　
　　
　設計工程における故障原因「検討不足」。
　　
　　
　　品質分析の原因欄の中に検討不足というものがあります。
　　
　　なぜ検討不足に至ったのでしょうか。
　　　　・機能の打合せモレ
　　　　　　当初は必要と認識していたが忙しく優先順位が下がり認識が
　　　　　　なくなった。
　　　　・条件の考慮もれ
　　　　　　ディシジョンテーブル表を使用して、全ての条件について検討を
　　　　　　行っていなかった。
　　　　・運用（現場の理解）イメージの理解不足
　　　　　　正しく現場（エンドユーザー）に運用イメージが理解されていない。
　　　　　　説明不足や理解不足が検討の深堀を妨げてしまうのです。
　　　　・詳細箇所は設計者の思い込み
　　　　　　概要までは全員の理解を得ていたが、詳細箇所は設計担当者の思い
　　　　　　込みで仕様が作成されていた。議論されていなかった。
　　
　　
　　設計工程でも検討不足は、製造工程では故障と認識されません。
　　試験工程に入っても当初は検出できません。
　　
　　後半のシステム機能試験や運用試験や性能試験になってようやく検出される
　　やっかいな故障です。
　　また検討不足は、機能の大幅な見直しや追加をしなければならなく、
　　費用も大きくなります。
　　
　　
　　
　　早期発見は、設計工程内で検出するしかありません。
　　　　　　　　製造工程や試験工程の初期では、機能の検討不足故障の検出は
　　　　　　　　行いません。
　　
　　
　　設計工程内では、
　　　　・議事録や懸案事項一覧などの過去分を読み返しましょう。
　　　　　　議事録が詳細に書かれているほど、過去の情景が蘇り、
　　　　　　思い出しやすいものです。
　　　　・運用イメージが正しく相互理解されているかを確認する手段を
　　　　　　複数種類もちましょう。表や文章だけでなく立体モデルや
　　　　　　ストーリーマンガや実物模型なども活用しましょう。
　　　　・ディシジョンテーブルを作成するだけでなく、見直す頻度を多く
　　　　　　しましょう。レビュー時点だけでなく他の機能の打合せなどでも
　　　　　　参照しましょう。関係なくてもモレや不備が見つかることが多い
　　　　　　ものです。
　　　　・設計者の思い込みがはいる時は、検討時間が足りない時、
　　　　　　決定に時間がかかるよ予想される時、面倒だと感じる時です。
　　　　　　進捗が遅れている時ほど、レビュー時に排除するようにしましょう。
　　
　　
　　納期が短いという言い訳では済まされない課題だと考えます。
　　
　　
　　費用負担になると、
　　　　ユーザー検討不足？
　　　　開発側検討不足？　　　　が問題になります。
　　
　　
　　　　小さな資料といえども負担側の判断材料になります。
　　　　相互理解で矛盾が生じない工夫をしましょう。
　　　　　　仕様をビジュアルで見せる工夫も必要ではないでしょうか。