思いこみ不良について

voxy3170さん苦労されているようですね。
私の想像ですので、違っていたらすいません。
御社の作業工程では
『責任の所在が明確になっていない』のではと思います。
作業者が『思い込みによる作業です』と原因を挙げていることから、
作業者の工程に対する責任感が感じられません。
どのような理由であれ、担当する工程からでた不良の責任は
担当者にあるという教育が必要ではないでしょうか？
その上で、原因を防ぐ対策も作業者が検討できるような体制が
とれれば次第によくなっていくと思います。
品質は『システムによる側面』と『人の教育による側面』があると
私は考えています。
仮に100%不良を防ぐ工程を構築しても、作業者がその工程通りに
作業を行わなかったら、不良は発生してしまいます。
仮に100%不良を出さない作業者がいても、その人がいなければ、
製品の供給ができません。
工程改善には多大な苦労がいりますが、それをやっていかないと
今の時代会社が傾きますよ。
がんばってください！！

思いこみを避けるには、思いこまないようにすればいいです。
要するに記憶することをやめるということです。
記憶していないのでデータをみながら作業しなければなりませんが。
記憶しなければならないときは、思いこみ間違いが起きるので
３回確認します。

誤記は起きるものなので確認します。
どのような誤記が起きるか記憶します。起きうる誤記を知っていると
誤記が起きにくいです。時々テストをして起きうる誤記を知っている限り
書いてもらいます。多く書けた人のスキル評価を上げます。

図面の読み間違いもよく起きます。どのような読み間違いが起きるのか
知っていると起きにくいです。新人さんがたぶんこのような読み間違いを
しているだろうなと思って見に行くと、予想通りやっていることがありま
す。

voxy3170様こんにちは
思い込みの問題は、私どもの会社でも今大きな問題になっています
そもそも人間は、完璧では、無いので必ずミスをします。
私どもでもまずは作業者確認後→第三者チェック（確認）をしていますが
その後→また第三者チェックを入れてダブル確認をしています
なぜこんなに確認ばかりあるかと言うと思われますが作業者確認後→第三者チェックここのチェックで確認したものがもれて不良になっているのが現状です。
これでもれて不良になっています
そのため今度はシステム的に機械を導入して形状異常確認できるものを入れました。
なぜ入れたのかと言うと確認作業者がストレスでとうとう病気になってしまいました。
人間はストレスをためると集中能力が落ちてしまうからです
以前JRの事故もある様に人間に無理な罰側を与えるとまたその罰則が怖くて
ミスをかくそうとして事故をしてしまうのと同じです。
そこら辺をよく考えてシステム的に改善をしなと思い込みミスは少なくなりませんと私は、考えています
あまり参考にはなりませんが。なるべく人間で確認。確認でなくそうとしないほうが良いと思います。

みなさん仰られておりますが、大切なのは「確認作業」ですね。
この確認作業は絶対に自分以外の人間に任せるべきだと私は思います。

脳ミソのメモリーにデータが残っているので
自分の目では何回確認しても見つからないものです。
頭まっさらな状態の人に考えながら確認してもらうのが良いですね。

お礼

2005/11/15 19:20

有り難う御座います。
因みに、確認作業を翌日にしてもやはり頭に残っていて、間違いは見つからない事が多いです。

質問者

「思い込みによる作業です」
非常に難しい問題です


本人はOKだと思い込んでいるので、検出をするのは、非常に難しいです

一番重要なのは、思い込まないようにするのが、重要だと考えられますが
これは、非常に難しい
疑えば、すべて疑うことも可能です

基本的にポカ避けよけというものを使うと非常に効果的です

不良は、人間の手によりはじくのではなく
機械に乗らないようにする、
自動的にはじかれるようにする、

など、基本的に人間が、思い込んでいても、NGだと検出できるようにすると非常に効果的です

つづく

つづき

前回は人による判断を避ける方法を書きました
人は間違いを起こすので機械などで、検出しようと言う方法です



依然使った物は、デバッグ（不具合が発見されていて、修正済みのはずなので、）バッグの必要がないという方法で不具合をなくすという方法です

プログラムの世界の考え方でオブジェクト指向と呼ばれています
先ほど書きましたが

依然使った物は、デバッグされているはずなので、
それを流用すれば、新しく、作ったところと、
その周辺だけをデバッグすれば、良いはずです
こうすることによりチェック項目を少なくして、ミスを減らすという考え方です




こうかくと主題である思い込み不良が発生するのでは？と思われますが
初期条件にデバッグはされていると言う点で違います

もちろん、前回デバッグされていない場合、死にますが…


オブジェクト指向と言う手法は、とても優れていて、設計、開発にも流量することが出来る考え方だと思いますが

難解であり、プログラマーの世界でもこれをりかいしているひとが少ないです


まだまだ続く

前回は、プログラムの世界の考え方である、オブジェクト指向という手法を用いて、以前使った技術の流用という手法を書きました

究極の思い込みですが、きちんとやれば、いろいろ良いことが起こるので
興味がある人は、オブジェクト指向の本を買ってみると良いでしょう
私はこの技術をプログラムだけでなく、他のことにも応用しようと
１７～８年説明してますが、大体理解できない人が多いほど、難解です



今回は、ある意味究極な手法です
不具合は、発生します、いくら対策をかけても発生するものです



始めの投稿は、不具合の検出する方法です
２番目の投稿は、不具合を発生させない（にくく）する方法です



今回のは、発生してしまった場合の方法です


不具合は、発生するものです、そして、チェック体制を万全にしても抜けていくものです


では、発生する前提で物を作ってみたら同でしょう
発生したらメッセージを発するとか
発生した場合、発生した部位だけ、取り替えるとか


あたりまえのようなことですが、実は大切なことです
そして、余り考えられていないのです


ISOで言うところの、FMEA（潜在的故障モードの影響解析）がそれにあたります

事前に発生しうる、不具合を考えておき、前もって対策を考えておく

ホリエモンが言うところの"想定の範囲内”がこれにあたります



また、こういう考え方もあります、不具合が発生しそうなところがあれば、
その部分を簡単に隔離（簡単に変更が可能）なように作る
これは、オブジェクト指向の中の一つのアイテムですが
不具合が発生した場合その部分だけ変更できるように作っておけば、不具合が発生した場合、その部分だけの変更でよいという考え方です

かんたんにいうとトカゲの尻尾きりですね


もう少しつづく

長くなりましたが

日本人はチェック表が好きです
不具合が発生したら、すぐにチェック表を作成したがります

ISOなど取得している企業に限って、その傾向が強いです
ISOには、チェック表を義務づけているわけではないのだが

しかも、チェック表なぞ、何の役にも立ちません
チェック表をつけて不良がとまった事例は、私の経験する限り、皆無です

確かに少し意識はあがりますが、書類が増えるだけ…orz




もう一つすきなのが、2重チェックです
これも大好きです
しかしながら不具合はとまりません、多少の効果はありますが
そのうち３重チェックや４重チェックしなくては…となります



前に書いた事例は、チェック表を作らず、二重チェックもさせず
不具合を少なくさせる方法です

１００％なくなりませんが、致命的な欠陥をなくすのが、目的です


文面が長くなりましたが…



そのうち、思いのたけをじぶんのHPにでもかこうかしら･･･

お礼

2005/11/15 19:18

有り難う御座います。
弊社は、機械に乗ってはじくのが難しい品物が多く、現状は人の目で確かめている事が殆どですが、いずれ機械ではじく手法を考える必要が有ると思います

質問者