プログラマにも読んでほしい「QC検定にも役立つ！QCべからず集」
https://qiita.com/kaizen_nagoya/items/d8ada7b7fceafe2e5f0e
を書いてみて、気になることがあった。
べからず集を作ってみた。
KPTするべからず
振り返りは、まず自分の頭ですることが大事。
集まって、わいわいがやがやしてなんとかしなくてはいけないのは、
工場のライン生産現場など、すぐに同期を取らないといけない仕事。
仕事に余裕があって、少し間があいてもいい仕事は、すぐにやるより、
一人頭で考えて、優先順位をつけてから、翌日以降にやる方が高価的。
KPTより、わかったこと、わからなかったこと、よかったこと、あらためること
のように、かならず対照の概念を入れるとよい。
KPTにHAZOPを導入してもよい。
なぜなぜ分析するべからず
物事の99%は因果関係分析が不可能だというのが
統計、確率の経験則。
Data Robotというソフトウェアの解析結果を拝見すると、
因果関係ではなく、時間的な経過を評価しているのと同じ計算結果になっている場合がある。
計算できない因果関係を計算できたつもりになるのが危ない。
じゃ、どうやって、再発防止をするのかと聞かれれば、
時間経過をたどって、どこかに変化点があるか、特異点があるかもしれず、
どちらかを探して、そこの条件を少し変えるだけで、
再発防止になる可能性がある。
分析には少し手間をかけるが、
最小の投資で、最大の効果が狙えるかもしれない。
可視化、見える化をするべからず
seeing is believingという言葉を聞いたような気がする。
見えると、信じてしまう。
統計の嘘であっても、視覚化すると騙されてしまうかもしれない。
視覚化しないとすれば、残された道は２つ。
１つは徹底した模擬試験。
さまざまな試験条件を与えて、その試験を達成するかどうか。
もう一つは、聴覚化。
音に変換して、その音の変化で、変化点か特異点をさがせないかという試み。
まだ始めたばかりで、成果がでるかどうかはわからない。
自働化するべからず
自働化ではなく自動化
計算機を使う場合に、自動化をまず達成することに注力するといい。
自動化すれば解決することを、無理に 自働化してもいいことがないかもしれない。
自働化とは
https://www.consultsourcing.jp/5459
動くことを機械化した「ニンベンのない自動化」は、異常が生じても機械は不良品をつくり続けてしまいます。
不良を大量につくらないためには、何か異常があったときは止まるようにしなければなりません。
そこで、動くことを機械化することから、止めることを機械化するという考えが生まれました。
人や職場で培ってきた善し悪しを判断する知恵を機械によるカラクリに置き換えて、装置として組み込み、異常が発生したら自動的に停止するようにします。
このように、人の知恵を盛り込んだ機械化を、「ニンベンのついた自働化」と呼びます。
Test Firstという言葉があるらしい。
まず、試験仕様を決めて、その試験を通るような製品を作る方法である。
最初から試験は組み入れており、不良や異常は作り続けることはない。
上の記述は、機械装置の製造機械だけに限定して設計する人がいたための仕様なのかもしれない。
ソフトウェアシステムでは、最初から試験仕様を決めないと、関数すら作れない。
製造装置を作ってから、試験装置を作るのは無駄。
試験と製造を一体にした設計をすればいい。
設計全体では自働化という発想は回り道だったのかもしれない。
Just in Timeするべからず。
工場火災、地震、サイバー攻撃などで、流れが止まることがあるらしい。
取引先に無理を強いるJITは、公正取引ではない可能性を議論するより、
災害時に弱いかもしれないことを議論するとよいかも。
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.