情報の受け渡しの無駄
明日のファクトリーオートメーションへようこそ。メインパソナリティの高橋です。
クリスです。
クリスさん、よろしくお願いします。
よろしくお願いします。
本日もお便りが来ております。
ラジオネーム、リビーさんよりお便りいただいています。ありがとうございます。
ありがとうございます。
いつも楽しく聞かせていただいています。
最近、ラダーの作成をしていって思ったことなのですが、ラダーの作成をするにあたり、まずやることの一つとして、IOの情報とコメントを電気図面に書かれているとおりに作成する作業があると思うのですが、
この作業に無駄が多いと感じています。
電気設計者がわざわざ特定のフォーマットにCADなどで画球を写してPDFなどで出力し、それを見ながら順番通りに一言一言コメントを同じになるようにという、
例えでいうと、学校の先生が教科書の文言を黒板に丸写しし、それを生徒がノートに丸写するみたいな感覚になります。
そもそもデバイスとコメントのCSVをくれれば、それをこっちでインポートするだけでいいのにと思ってしまいます。
また、CADはCADであった方がいい場面があると思いますが、その場合、IO情報をCSVからCADで自動変換できるようなマクロ的なものがあれば、
一つ一つCADに書き写す手間もなくなるのではと思ってしまいます。
このように設計者間、メカと電気、電気と制御などのコミュニケーションのプロトコルのほとんどがPDFになってしまっていることに関して、
多くの人が相手の考えを理解しやすいメリットがある一方で、そのための手間が多いと感じているのですが、
高橋さん、栗さんはこれについてどう思いますでしょうか。また、ここは他に改善できるのではという思う場面があれば教えていただきたいですということです。
ツールの不備
なるほど。質問ありがとうございます。
これに関しては、たぶん、私の理解が間違っていなければ、
リビさんがCADから、大サンサーの情報から、今言っているのはIOコメントだけですが、
その後、例えばハードウェアコンプレッションとか、色設定とか、
比較的手打ちするのが面倒ではないかということですね。
そういうのが本来はあれば、何か別の集団で、自分なりのエンジニアツールで飛び込めば、
一発で、何でも間違いなしでできるのではないかということですね。
それは確かにそうですけれども、
今、問題は、例えばツールですね。
ほぼSiemensとかを使っているんですけれども、SiemensではObenisというAPIがあるんですよね。
エンジニアツールの中で。
このツールのAPIを経由して、自由的なプロジェクトを作ったりとか、
あとは何かのハードウェアコンプレッションとか、ネットワーク設定する際の各ノードのIPアドレスとか、
あとポトローチとか、あとプログラムとか、さっき言ったIOコメントとか、
全部の自分なりに頑張ってコメントするんですよ、自動で。
なので、そういう自動的なツールというか、今のJXWorksとかにもそういうインターフェースが開いていないことも多いので、
適用的だとしても、ただIOリストとかIOコメントとかだけなので、
そこまでメリットというか、そこまでやらなきゃいけないというゲーム能力が足りないんじゃないかなと思いますね、私の的には。
分業と専門家の不足
ただIOだけ自由的に作ってもそれだけかというレベルで終わっちゃったんじゃないかなと思ったんですね。
どう思いますか?
一言で言うとさ、リビーさんの考えの通り、基本無駄なんですよ、それは。
無駄ですね。
間違いないですね。
やらんでいいことやってるってのは間違いないことで。
ここのやっぱ難しさっていうのは、分業しているっていうことと、
あとはシステム面のサポートをうまく受けられないってこの2つだと思うんです。
そう、まずは分業している、つまり電気設計者と電源設計者は2人いるっていうことですよね。
そうですね、まずシステム面の話をした方がいいと思っていて、要はCADから直接飛べばいいじゃんって話ですよね。
使ってるCADから使ってるエンジニアツールに直接飛べばいいじゃんっていう話じゃないですか、究極的な話をすると。
で、今それを難しくしてる現状っていうのは、まず一つはCADメーカーがちっちゃいこと。各社の。
電気CADを扱ってるメーカーっていうものがすごく力が弱い。
いわゆる電気CADで世界的なシェアのあるメーカーって、今だってeプランとかかなり強いですけど、
eプランが出る前でCADってもう乱立してたんですよね。
電気CADってすごい乱立してて、なんならオートCADで書いてますみたいな。
いわゆる電気CADを専門としている人たちじゃない人たちが電気CADを作っていた時代があります。
これがものすごい乱立していた時代で、PLCメーカーもすごい乱立してた時代がある。
ここで特定のフォーマットプロトコルっていうものが生まれてこなかったっていうのがまず一つです。
昔はいろいろ張ってたから、乱立してるから、そもそも統一はできなくなっちゃったんですね。
できなくなっちゃったっていうよりは、統一をするという動きがまずなかった。
昔のパソコンだとか、今みたいにインターネットが整ってる時代でもなかったですから、
そういうモチベーションがなかったんですよね。
そのままそういうのが行われなかったっていうのがまず前提としてあって、
ただ先ほどリビーさんが言った通り、マクロがあってそれで映せればいいじゃん、ここでっていう話が次出るじゃないですか。
これをやるためのもう一つ難しいところがあって、
これ文行っていうのが出てくるんですよね。
このマクロは誰がやるの?って。
というよりはマクロを作ってこれを使ったら楽になりますっていうのが、
例えばこれって恩恵を受けるのって制御設計者しか受けないんですよね。
このデバイスコメントっていう話をしたときに。
電気設計者は今までの仕事が変わって仕事が増えるだけじゃないですか。
増えただけですね。
こうやったら私の仕事が楽だからこういうフォーマットをお願いしますっていうふうに言うけど、
もらう側は仕事は単純に増えるわけです。
そうだね。
じゃあ文行してる以上、そのお願いが成立しにくいってことですね。
なるほど、確かに。
本当はこれトータルで見たら絶対いいんですよ。
いいことのはずなんです。
最終、トータルで設計のフローで見たときに。
フローで見たときに電気設計者がちょっとコースを増える以上の、
3倍も4倍もコース数が下がるはずなんですよね。
制御設計者は。
そうですね。
そうですよね。
だいたいその後は、
電気設計者がちょっとコース数が増える以上の、
3倍も4倍も工数が下がるはずなんですよね、制御設計者が。
だから全体の設備の工数で見たら、それは下がるはずなんです。
下がる。はい。
でも、全ての業務フローをオーケストレーションできる人材っていうのがいなかった。装置メーカー。
なるほど。
それぞれ機械のプロ、電気のプロ、制御のプロはいるけど、
一人が全部できる人はない。
いないし、装置っていう業務フローの専門家はいなかったわけですね。
装置のフローの専門家っていうのは、これもちょっと教えてもいいですか。
フローの装置の専門家っていうのは、装置を構想の段階から設計、清掃、プログラム、出荷、現時まで全部マークしてデザインできる人っていう。
その工程管理、工程の設計っていうものの専門家がいなかったわけです。
工程の専門家、はい。
例えば、製作装備を作るには、まず構想を設計して、機械を設計して、電気を設計して、制御を設計して、調整して出すんですよね。
はい、そうですね。
この程度の粒度で設計がされていて、もうちょっと踏み込んだところっていうのは、もう専門家にお任せしますって感じなんですよ、実態は。
ああ、なるほど。
だから電気屋さんが、じゃあIOを出してくださいねって、そのIOがその後使われてるかどうかもわかんないし、どこに使われてるかもわかんないんですよね。
それでIOを出しますって、終わり。
うん。で、実際に出してもらって、使わない情報いっぱいありますからね。これは要らない、これは要らないみたいな。
マジで実際に使わない情報も。
うん。
なるほど。
IOもね。
全部無駄ですね、この辺は。
そうそう。
無駄ですね。
無駄かどうか置いといて、それはそういう状況なわけですよ。
うんうんうん。
っていう、なんていうんですか、結局部分最適になりがちなんですよね。
はい。
分業してる以上。で、部分最適になると、そういうマクロを作ろうみたいなことが行われづらくなる。
頼みづらくなるし、やれない可能性が多いんですよね。
そうですね。で、やれてるメーカーっているんですよ、実際。
うんうん。
で、そういう人たちがどういうことになっているかというと、すごく強いトップダウンがある。
あれ?
うん。
もうやってください。
そうそう。
ということで、もうやるしかない。
設計工程の課題
うん。世の中こうだと。いわゆるこうやるんだって言って、部分最適のいわゆる山を飛び越えることができる人たちっていうのは一定数いるんですけど。
なるほど。
うん。ただやっぱり日本の装置メーカーはそもそも小さい。結構規模が小さいっていうのと、その中でそういう力学が働きづらい構成には間違いなくなっているはずです。
なるほど。なるほどね。
うん。で、もともと。
装置メーカーは小さい。
そうそう。で、そもそもそういう着想もなかったわけですよね。全体最適しましょうみたいな。
最適しましょうと。ここでクローズ減らしましょうとか。
そうそう。こうやったら一番最適ですよみたいな。全体で見たらみたいな。そういうそもそも考え自体もなかったわけです。
だってこれって別にアメリカでもなかったですかね?昔まで。
ないんですか?そういう自動で。
だってThe Goalっていう小説知ってます?
知ってます。知ってます。
TOCD論のね。あれが出たの結構最近ですよ。だって。
だってあれ中身はさっき言った話と一緒じゃないですか。部分最適だったら全体的に効率悪いですよっていうのがさっきの話で。
で、それをTOCD論っていうのにうまく解決するっていうのがThe Goalなわけですね。小説の。
これは最近の。
そう。で、The Goalは別にそんなもう100年も200年も経ってるわけじゃないんですよね。まだ。
なるほど。
っていう状況なんですよ。
自動化の必要性
そっかー。アメリカの場合はトップターンだろうか。で、こういうふうになったというか。
別にアメリカもオーションも別にこの辺が綺麗になってるわけではないです。
なっててはないですよね。なっててはない。
もしなってるんだったらそういうシステムとかそういうサービスが出てるはずですね。
そうですね。なるほど。
多少はマシですよ。シーメンスとかロックウェアのものを見ると多少はマシですけど、やっぱり多少はマシレベルじゃないですか。結局人が手で映してる。
まだまだ。ないよりマシ。ないよりいいって感じ。
そうそう。だから別にそれが全て解決してるようなことは世界中どこでもまだないです。
一部の人たちがうまくやってるっていう例はあるけれども。
うんうん。
それが当たり前のように普及してるっていう事実は多分ないと思う。
今どころこの、え、これは欧州もこんな感じですか。欧州でもないよりマシという。
じゃない?
そうか。
だってヨーロッパにPDFの図面一枚もないなんてありえないと思いません?
ないない。絶対ありえない。
でしょ?
うん。
で、これを改善できるのはどうして、まずシステムから改善できるのはどんな面があるか。
リビーさんの聞きたい話はちょっとずれるかもしれないですけど、基本的にはやはり個々の自動化のレベルが足りないんだと思う。
自動化のレベルが足りない?
要は、なんていうか、今工程間の自動化をしようとしてるわけじゃないですか、今。
制御設計者という工程とその間の制御設計者という工程の工程間の自動化をしようとしてるわけですよね、今。
でもその前にまず工程内の自動化の先じゃないですか、どう考えても。
工程の先?
工程内の、要は自分の仕事を自動化するのが先じゃないっていう相手の仕事を自動化するより。
あー、なるほど。
そもそもそこが成り立ってない、成り立ってない、そこがそもそも育ってないのに、あなたの仕事をこうしたら楽になりますよなんて言っても当然響かないわけですね。
事務が示さないといけない。
示さないといけないというか、多分作成パターンとしてはお互いに仕事がかなり自動化されてます。
電気設計者もすごくデジタルになって自動化されてるし、その後ろの制御設計者もデジタルになって自動化されてる。
ただ、お互いの仕事の間っていうのがまだまだ手作業が残ってるよね。
じゃあここってお互いのシステムをよく見たら、こうやったらスルッといくんじゃねみたいな。
うん、なるほど。
だからそうだと思うんですよね。だから今その手作業でめっちゃやってる中に、自動化要素を工程間に入れようとしてるのがやっぱそもそもしんどいんだと思う。
やりやすく見えるけど。
そうそう、自分の工程内のことを全部自動化して上で、じゃあここだったら楽ですよ、お互いに。
なるほどね。
その後はそこで可能性があるんですよね、自動化を。
でもこれやっぱ難しいんですよ、また。
だってお互いが自動化するモチベーションって何?ってなるじゃないですか。
そうだね。
業務間の整合性
しかもここって分業してるってことは会社が割れてる可能性もあるわけですよね。
外駐してる可能性もあるわけじゃん。
多分してるんだよ、このお便りから見ると多分してるんだよ。
多分他の会社がもらってるPDFが詰め…。
そう、同じ会社だったらそんなにちょちょっと言ったら終わるからね。
これCSVでくれるとかね。
CSVがくれないんだよみたいな。
じゃあ他の会社の人たちにお前もっと自動化してるよみたいなのを言うのなんてめっちゃしんどいわけですよ。
しんどい、これはしんどい。
だからやっぱりできるところは多分そういうところで進めるんだと思う。
おのおのの自動化レベルをもう少し上げて、ある程度に達したら肯定感の自動化っていうところに手が出せる。
なるほど、最初は。
めっちゃ楽に見えるんですよ、めっちゃ楽に。
デバイスのコメントをCSVで書いたらインポートできるだけなんて思うじゃないですか。
思うね、言うかなんていうかすごい。
でも場所が悪いんだよ、場所が。
場所が悪いっていうか。
肯定感だからこれって、場所が悪いんですよ。
なるほど。
だから自分の仕事の中でこれCSVで作ればこれインポートできるって最初それ作って終わりじゃないですか。
終わりだよね、終わりだね。
でもこれが人と人のデータの受け足しっていう場所が悪いんだよね。
すぐできそうだけど難しいんですよ。
難しい。
自分でやるのはジムハンジューじゃないし、僕もジムハンジューの持ってないのないし、
これをやると説得するのはかなりちょっとハードル高くなるんですね。
そうなんですよ。
なるほどね。
そうだね、もうそうそう。
分業問題あるし、システム問題あるんですよね、これは。
そうですね。
ここにはかなり個人の仕事のやり方の範疇を超えちゃうわけですね、こういう時って。
自分だけで終われないから、この分野が。
そうですね。
自動化でやろうとしてると。
例えば、これって今1対1で考えてますけど、
例えば電気屋さんにこうやってくださいって言った時に、自分じゃない制御屋さんとも仕事をした時にやり方が変わるわけですよね、その2つで。
あるね、変わります。
毎回説明とか。
そう、めっちゃきついじゃないですか、電気屋さんからしたら。
A社とB社で出発する資料変えなあかん。
そうだね。
しんどいですよね。
で、品スタンプもしにくいですよね。
自分から出すものに対しては時効低間欠で、ちゃんと品質を確保したいはずなのに、やり方がバラバラになって、品質確保の仕組みもうまく作れなくなる。
タンボするんだったら、もうさらにこれを品質のタンボする仕組みは作らなきゃいけないし、コースだけ増やした、これだけ増やして、これを新しい仕様のメリットは全然見えない。
見えないというか、見づらいって言われちゃうんですよね。
そうですね。
で、こういう時は、やれるかやれないかは置いておいて、かなり相手の仕事に入り込まないといけないんですね。
相手の仕事に入り込まないといけない。
要は、ここで制御屋さんから言うことっていうのは、こっちに出すデバイスリストをCSVにしてだけじゃやっぱり弱いんですよ。
弱いね。
だから、もっとこうやったら、そもそもあなたの仕事めっちゃ楽になりませんか?みたいなところに行かないといけない。
これは電儀屋さんって、電儀設計の人に説得しなきゃいけないですよね、これCSVがこうしたら。
そもそもCADを変えた方がいいんじゃないですか?とか。
じゃああなたの仕事半分以上になりますよ、みたいな。
で、そうなった時に、でもこここうしといたら後ろも都合いいんで、こうしといてくださいみたいな。そういう感じですよね、どっちかっていうと。
今どういうこと?こうやったら後ろ方が都合いいからこうやってください。いや、私は関係ないし、そんなこと。
そうですよね。
そうなってますよね、今。
だから、この肯定感ってついでなんですよね、基本的に。ついでなんですよ。
なるほど。
だから、この肯定感だけの着目がすごく簡単に見えるんだけど、実際にはかなりでかい話。
外注の可能性もあるし、でかいというか、だから残念なんですね。
外注じゃなくてもしんどいよ。
しんどい?社内でもしんどい?
設計工程の問題点
しんどい。だってやる理由ないもん。
確かに仕事増やしたけども、やれって言われても困るよ、こっちで。なるほど。
そうですね。
だから例えばお互いに共通の目標があって、お互いにこうやったらそれが達成できますよっていう手が取りやすいから内製はやりやすいだけであって、現状維持だけで言うんだったら内製でもやってくれないと思う。
現状維持で言ったら大切、なるほど。
だから本当に上昇志向のないような会社とかだと相当難しい。
なるほど。
ただ毎日同じことをしていればいいって考えてる人にはやっぱりなかなか響かないと思いますね。
高橋さん今思ったのは、まずこの問題的にはシステム的な問題と分業的な問題があって、
システム的にはまずそもそもこの電気カードプロトコルは乱立、統一してない。
これは電気カードメーカーも少ないし、難しい。
乱立してて当然これ統一できないからどうなるかと。
一方でリビさんのシチュエーション的には、演技設計屋さんと制御設計の人と同じ人じゃない。
もしくはもっと悪い場合では同じ会社ではない。
そういう場合は相手にこれをやりなさいを説得するのは非常に難しい。
なおかつ工程内のことをまずは自動化しておいて、
工程化の自動化を説得するはその後じゃないという話なんですけど、
この説得するのも社内でも社会でもまあまあ難しい。
あんまりエンド力、イノベーション、いいエンド力はない。
わざわざやる、どういうことですよね。
そうですね。難しいというよりは大変やっちゃうんですね。
大変やね。
できないわけじゃない。
大変ですね。
これ聴取志向がないとちょっと守れないかもしれないですね。
また時間の問題だと思います。
自動化の課題
時間の問題というのはこの…
要はそれをやったところが勝つから。
そうだね。それからコースが下げるんですよね。
究極的に反省すると全部なくなる可能性もあるわけじゃないですか。
こういう効率が悪いやり方を続けている方法が全部なくなるってことですか。
電気設計者と制御設計者というもの自体なくなる可能性ってありますしね。
一体化する。
一体化するし、もしかしたら全部機械屋になるかもしれない。
毎年機械屋で全部やっちゃう。
そうなった時に、この会社がどうっていう話よりも、それをやった会社がめっちゃ勝つんだと思います。
コースが下がるから。
めちゃめちゃコースが上がるし、リードタイムも早いし、不具合もないし。
っていうのが世の中では今進んでいるわけですよね。
みんながみんなやってるわけじゃないですよ。
ヨーロッパがアメリカがみんなやってるわけじゃないけど、
一部のいわゆる先駆者たちはもうやってるわけです、それを。
国内もそれだけ。
それとは立ち続けるかもしれないですね。
今はその成果っていうのがそんなに出てない。
たかだか20%とかそういうレベルしか出てないけど、
これが全部自動化になりましたみたいな。
貧血100%ですみたいになった瞬間に、今の10倍とか生産性が出るわけですよね。
そうなったときに。
時間の問題。
勝てないですね。
サービス残業とか。
もう今からやっても。
サービス残業するとか無償労働するとかではもう立ちできなくなっちゃうんで。
だから難しいからやらなくていいっていうことは全然なくて、やんないとダメだけど。
現実は苦しいという。
苦しいっていうことでやって、少しずつ労働を溜めてどのタイミングでいっかなと。
かもしれない。
そうですね。でもやってる人はやってる。
やってる人はやってる。
やってる人はやってる。
やってる人は赤字出しながらやってる。
赤字出しながらやってる。
それが多分返せくるかもしれない。
そうですね。多分どこかでそれが表に出るときは多分来ると思います。
はい。
というお話でした。
なるほど。
なので、基本的にはやったほうがいいです。
ただ大変だけどみんな頑張ろうねっていう話です。
そうですね。頑張ってくださいしか言えないですね。
が、はい。
というわけで、にびさんありがとうございました。これで終了したと思います。
ありがとうございました。
ありがとうございました。
はい。おはようございます。
