トラブルは続くだろう

昨日、FBのあるグループ(名前が長い)で教えてもらったところ、MQTTとWebアプリのFlaskを1つのプログラムにするのはあまりやらない事で途中にデータベースを入れて分けるのが普通だとのこと。

なのでMQTTの受信→データベース書き込みとWebアプリ←データベース読み出しと2つに分けてやってみている。まあ、MQTTは簡単だったけれどそこで受信したデータをデータベースに書き込むのは面倒で、あまり例が無かったけれども英語のサイトにあったので何とか出来そうな気がして来た。Flaskがデータベースから読み出すのも全然わからなかったが何となく出来そうだ。データベースのコマンドはこれはコメントなのか？と言う位人間の言葉みたいになっていて、これが逆に頭を混乱させる。

何にしろやればできるはずなんだが、いろいろなフレームワークが一緒になると頭の切り替えが大変だ。



話は変わるが、また今朝も生産管理のKがボヤいてた。変な事が多いらしい。

その変な事、マイナートラブルなのだけれど良い事ではない。関係する部署Aはその元を作った部署Bがミスしたと言う。自分たちがそれをチェックする機会が複数回ありながら止める事ができなかったと言うのは棚上げ。本音は知らないが。部署Bは部署Aが見てくれるからとか平気で言う。アホな！...どっちも。


工場でよくやるのが、ミスが発生したらミスのあった行程の後で検査を入れると言うような事。これやってると工場にやたら検査する行程が多くなってロスが大きくなる。時間も人件費も。ただ、それだけならまだマシで、もっと根本的にダメになってしまう事もある。


これは人間の性質によるもので、1つの仕事を1人でやる場合と2人でやる場合、そしてもっと多くの人数を割り当てる場合でどれが一番出来高が上がるかと言うあれ。2人で2倍には絶対ならない。5人で5倍は絶対無理。複数で同じ事をやると手待ちが増えると言うのもあるが、各人のパフォーマンスがガタガタと落ちてしまう。

検査も同じで複数段の検査はやればやるほど検査にならなくなる。1人でチェック表でも持たせてやる方がかなりマシ。作業員が見て、近くに検査員がいて、後工程でも検査があったりすると絶対全部スルーする場合が出てくる。

と言うわけで、朝、Kがボヤいていた時にちょうど部署Bのマネージャーが入って来たので気を付けた方が良いよと優しく言ってやったが、「部署Aが見ていてくれるから」などとバカな事を言う。もう、その意識がそのままトラブルにつながっているとわからないのか！ まだまだ続く？