品質管理の重要性
明日のファクトリーオートメーションへようこそ、メインパーソリエンティの高橋です。
クリスです。
よろしくお願いします。
アコキチサ技術者からのお便りです。いつも読んでくださいます。
設備の搬入から立ち上げを早くするために何か工夫していますか?と、高橋さん。
そうですね。
何と言うか、身も蓋もないことを言うんですけど、今から。
結局、品質良かったら早く立ち上がるじゃないですか。
すごい極端に考えられるそうですね。立ち上げで言うと、ソフトだけではない。
ソフトもハードもですけど。
まず設計が正しくて、正しい設計通り製造されていれば、いわゆるノータイムで立ち上がるはずですよね、基本的には。
そうですね。
ソフトも制御も多分そうだと思うんですよ。
なので、基本的には何で長引くのかとか、何で上手くいかないのかっていうと、一言で言うと品質が悪いから。
設計の品質が悪いから。
そうですね。設計、製造、組み付け、いろいろありますけど、各プロセスがありますけど、企画をして構想して設計して製造して組み付けて調整するっていう各プロセスありますけど、
これそれぞれの品質が積み重なって一番最後の調整の品質になってると思うんですけど。
なので、基本的にはこれをどれだけ良くするかだと思います。
当然調整の時にいろんなテクニックはあるんですけど、うまくやるような。
ただやっぱりそれは対処療法でしかないので、本質的な対策じゃないなと思ってて。
基本的には各自の設計フェーズ、製造フェーズっていうところを、僕らは自己定観決って言うんですけど、
自分のやってたところをいかに品質を保証して良くするか出すか。
なるほど。設計側でちゃんと設計思想、正しい設計思想を議論してこれを持って設計して、
製造側もちゃんと新しいもの、品質の良いものを部品とか全部作って、
現場に着いたら新しく組み立てて、目の通りに組み立てて、そういうことですよね。
どこのステップをずれちゃっても、結局最後の調整がどんだけテクニックあっても、そこまで早くならないってことですよね。
これの大事なのは、人がちゃんとやればうまくいくっていう考え方を知っていることだと思います。
難しいですね。人がちゃんとやればうまく。
要は、これはミスったのは僕がちゃんと見なかったからですとか、そういう話は一切抜きにしていかないと多分これはなくならないだろうな。
私がちゃんと見てないから。
設計情報の必要性
そうですね。じゃあ例えばクリスさんがタイプミスを一文字タイプミスとするじゃないですか。
例えばプログラムを作っていって0って書くところを1って書いちゃったと。
なんで間違えたんですかっていう話ですよね。
私反応してないから。
っていうともう何の解決もしないので。
おかげするかですね。
そうですね。で、それをいわゆる絶対にそれを再発しないようにするにはどうしたらいいか。
なるほど。これまた生産の技術の話がすごくつながりますね。
そうですね。で、結局的には例えばですけど、クリスさんがキーボードを打たなきゃそれは発生しないわけですよね。
そうですね。
0を1に間違えて申し訳ございません。
そうですね。
だから基本的にはそれは、例えばどこかの図面からそれを見てクリスさんが手打ちをしているんだったら、図面から直接それがインポートされるような仕組みにしたらそれはなくなるじゃないですか。
打ち間違えて。少なくともその部分に関しては。
ということを繰り返すんですよ、基本的に。多分それしかないと思ってます。
どんどん上に逆らわれるんですよね。例えば図面を、この図面に基づいている人が書き間違えたら、もちろんこれを基づいて生成されたコードを間違えたので、どんどん何で図面が間違えているかを追っていくという感じですよね。どんどん間違えたところを追っていくというイメージ。
間違えたところを追っていくもそうですし、最終的に何て言うんですか。これはソフトの話になりますけど、自動コーディング、自動コーディング、自動コーディングって話をしていったときに、一番最終的には設備設計に必要な情報って何なんですかねっていう話を考えるってことに行き着くんですよ、大体。
設備とって必要な情報は何なんですか。
例えば、設備設計の基本的な流れを言うと、まず一番最初に構想を立てている人、多くは機械設計者ですけど、この機械はこういうふうに動きますっていう動作線図を出してくるわけですね、一番最初に。
そうですね。
すごいラフな動作線図を出してくるわけですよね。
それに電気設計者がそれをこういうふうに肉付けして、次にプログラムを書くときにこれが足りないね、これが足りないねっていう肉付けをしてっていう。
どんどん情報が足されていってるわけですよ。
そういう流れですよね。
そうですね。
これをどんどん無くしていきましょうって話をしたときに、今一番先頭でやってる動作線図の情報だけじゃ到底設備はできないですよね。
情報が荒すぎて。
そこにはインターロックが書かれてるのかって書かれてないし、異常は全て書かれてるのか書かれてないし。
要はそれだけの情報じゃ設備はできないわけですよ。
そうでしょうね。
でも後ろの工程をどんどん無くしていったら、最終的には一番最初のその状態で書かないといけない情報って何なんでしたっけって話になる。
設備は何が必要ですかという。
そこには生産設備に必要な設計情報っていうのは何かっていうのと、それはどう体系立てて存在しているのかっていうことを考えないといけない。
ごめんなさい、もう一回最後のあれ言葉。
ものを体系立てて、その必要な情報を体系立てて整理する必要があるっていうことですね。
なるほど。これは社内の標準、ガイドラインというか標準があるんですね、各社自分とかで。本数字は絶対こんなものが。
そうですね。各社はもうないですよ。基本的にはないです。
仕様書という言い方ですか。仕様書というわけではない。
仕様書とか全然足りないですよね。やっぱりそれはあらあらの情報で、足りないところは人が保管してるんですよ、基本的には。
そうですよね。
デジタルツインと効率化
そういうことを論理づけてルール化して、いかにそれを短縮化していくかってこと、効率化していくかってこと。
効率化を進めていったときに最後に残る必要最低限の情報は何か。
最低限抑えなきゃいけないことを何ですかと。
それを見つけることがおそらく今のデジタルツインやDXって呼ばれてるものの生産設備設計の最終形になるんだと思います。
今までの設備の情報線も上がってるから、逆に言うと。この中に最大公約数、絶対どこに出てくるんですね。
情報は上がってないです。今は何も情報は残ってないですよ。
なるほど。
設計した情報っていうのはどこにも残ってないんですよ。
今あるのはカードしてる設備だけですよね。
だから今残ってるのは一番最後にこういうものを作りましたっていう最終的なアウトプットが残ってるだけで。
それがどういう考えで作られてるとか。
どうしてこんなアウトプットが出なきゃいけないのかわからない。
それが統一的な考え方で作られたんじゃなくて、なんとなくこうしましたみたいなものがたくさん含まれてる。
昔はこうやってるからとか。
そうですね。前回当初ですとかそうですね。
そういうものが入ってると絶対に効率化っていうのはできないんです。
なるほど。
だから最終的な効率化をして自動的な設計だとか自動的なものをやるっていうのはすべて意味が必要なんですね。決めることに。
このルールはこれだからこれですよということを全部わからないと。
そうです。
自動設計は自動設計するのは無理がまだ遠いんじゃないと思いますか。
かなり難しい。だから今いろんなオートコーディングやそういうものがうまくいかないのはそこが曖昧だからなんだと思います。
でもこういうところはドイツとかなんか結構なんかいいものはそうですけど、ハロバとかなんかないですかこういう設計。
ドイツは全くないです。
みんな困ってますね今でも。
困ってるというか要は無理なんですよね。
例えばシーメンスがそれを決めきるなんて無理なんですよ。
なんでかっていうと一番末端の最終的にできるアウトプットは無限にあるからです。
装置も最終的にできるものは無限だからこの中でああそういうこと?
だから今例えば1000個のメーカーが作ったものを集めてその中から最小勾配数を見つけ出しましょうって言ってもあまりにも違いすぎて出せないんですよねそれが。
なるほど。
なので例えば大体こうやったらうまくいきますみたいな大まかなものだけ作って残りのところは人がフィッティングしていくっていうのが今の主流ですよね。
でもこれ大体できたところ少ないんですよね。
そうですね。
ただその先に行こうとするとやっぱりそこにはさらなる設計情報への踏み込みっていうのが多分必要になるんだと思います。
でもこれどうやって返すかなんか設計するときに残る残る何か残らなきゃいけないんですよねつまり。
そうですねだからそれを考えないといけないってことですね。
じゃあクリスさんが例えばこの以上を出しますって言ったときにそれ何で出すんですかっていう話でこういう理由ですってどういうときにやらないんですかって。
難しいねこれそう言われると。
絶対そうじゃないですかクリスさんトレー付けといた方がいいから付けときましたみたいな話いっぱいあると思うんですよ。
ありますあります。
じゃあそのとりあえずの基準って何みたいな。
昔1年も1回出てからあやあらもたさん作りましたよ私が。
そうですよね。
なんで作らないんですか難易度困るからでもでもって感じですよね。
あったねありましたね一体でも言われました。
そうそうだからそういういい加減なことを機械的に処理させるのは難しいんですよね。
難しい。
だからその今でも人間は得意なんですよそういういい加減なこと。
確かにいい加減なこと得意。
とりあえず付けておきます昔はこうだからとか。
そうそうだから人間はそういうそれをうまくやる能力があるんですけどでも人間のやり方だと進出的に限界があるんです。
なるほどなるほど。
だって今僕らフがいっぱい出してるわけですかねそのやり方で。
そしてこれも効率は悪いんですよね結局。
いらないものはたまってたまってていらないものがわからないものはたまってるんですよね。
そうですね。
たまっていく。
っていうところがやっぱり課題でだから僕らの今やってるやり方をどう機械的に処理できるように変えていくのかっていうことと。
当然それにはその今いい加減な方法で僕らやってるからそのまあいい加減な方でやってるわけじゃないけど。
ある種の大枠なやり方でやってるからそれに紐づいたハードウェア構成も当然なってるし制作する機械の作り方にもなってる。
なるほどですね。
なのでこれに手を入れていこうとすると結構大がかりな作業になるんですけど。
多分この先行くにはそういうことやらないといけないんだろうなっていうふうに個人的には思ってますね。
そうですね。
これが難しいというかどうやってこの町長をもらえばいいかですよね。
どう収集してどういう形で収集してとか。
そうですね。
それがまあ今多分各社がやりたいこと。
やりたいこととてもどうやるのかまだ妄作してる。
そうですね。
この間我々話したベッコフのフレームワークだって多分そういうことをやりたいんだと思うよな最終的には。
そうですね。
だからこうやったら設計できるんですよっていう道筋。
結構ちゃんとしたフレームワークは多分組みたいんですよみんな。
このフレームワークがあれば大体できることも決まってるし、決まったところは全部トリコを使ってということですよね。
そういうフレームワークっていうのはプラットフォームだとか基盤系のシステムっていうのが確実に不可欠なので、
フレームワークの重要性
そのフレームワークを作ったところが次のPLCの大きなシェアを総取りしていくんじゃないかって僕は思います。
今こういうフレームワークは一生懸命作ってるところは将来多分シェア通る可能性があるんですよね。
一生懸命。
そうですね。それは完成すれば。
なるほど。
なるほど。
どうなんだろうな。
国産のPLCでも一応作ってますもんね。
自分らのフレームワークでいう言い方から。
ライブラリー?
ライブラリー?
そうですね。ただ、こういうこと言うとあんまり聞こえが良くないかもしれないですけど、ほぼないに等しいと思ってます。
ないっていうのは?
いわゆる個別機能のライブラリーに留まってるってところですね。
例えばMQTTための通信ためのライブラリー、これをためのライブラリー、これを一つの枠として留まってない枠でいうか。
そうですね。じゃあそれをあるサイクルを作るためにはどういうふうにすればいいんですかっていうのは何も決まってない。
じゃあ自分で頑張ってやってくださいって。
そうですね。だいたいこういう感じで組み合わせたらいいんちゃいますか?みたいな、そういう感じですよね。
なるほど、なるほど。
だからあまり制約を課すつもりがないんだと思います。
制約をかけるのは難しくないですか?
いや難しい。難しいかみんなやらないんですよ。
ちゃんと考えないとどこを制約かければいいのかわからないじゃないですか。
そうです。だから制約をかけるって間違うとものすごく機能を損なうんですよね。使い勝手とか。
バグも出るし。
いわゆるは自分でやればいいんですよ。
リスクが高い、拡張性が高いとかそういう話はいいことに一見いいことに聞こえるんですけど、
逆にいろんな速さとかそういうものを失っていく。便利さっていうものを失っていく。
なるほど。
要はできないことがいっぱいあってもそれが使わなくていいことなんだったらできないことが。
これは多分世の中の人はめちゃめちゃ便利に感じると思います。覚えることが少ないから。
なるほど。そうですよね。
この間、ぺこぷさんとかが作ったフレームワークも、この間ちょっと試したんですよ、サーボーのSTPフレームワーク。
まあまあ簡単でしたね、あれ作るの。本当にさらにファンションブロック、MCパワーとか全部禁止する必要なくなったんですよ。
そうですね。
MCパワーとか全部なくて、それは便利だなと思って。
そうですよね。でも確実に自由度は減ってるんですよ、たぶん。
減ってますよ。すごい減ったんですけど、だいたいハミ当たるかなと思ったんですよ、使い方とか。
そうですね。でも8割9割できるんだったらいいよねっていう。
っていうですね、要は便利っていうのはなんかやらないってことなんで基本的に。
でもやらないっていうのはめっちゃリスクなんですよね。すぐ不満につながるから。
っていうところに日本のメーカーがどこまで踏み込むかっていうのがこれからちょっと見ていきたいなと思ってるところですね。
なるほど、なるほど。
僕は頑張ってほしいなと思ってます。
頑張ってください、本当に。
偉そうなこと言いましたけどね、ちょっと。
それは大事ですよ、大事ですよ。
僕の意見です。
人生初めのPUCもあんまりですから、頑張ってください、本当に皆さん。
そうなんですよね。だから一気にやれることが増えたらみんな嬉しそうに聞こえるんだけど、実はあんまり嬉しくない。
人もいる。拾った方が嬉しくない側面もあるってことですね。
その自由度が高いと言われても嫌なんですね。
日本の生産現場への適用
そういう場合もあるんですよね。
なるほど。
変なこともなるし、変な動作もなるし、そういう場合もあるんですよね。
そうですね。
例えばノードレッドなんてめちゃめちゃ簡単じゃないですか、作るのって。
簡単ですね、はい。
でもあれで生産性ビット作るのちょっと難しいですよね。
使うほど持ってないですね。
生産性ビットの面で見ると足りないことがあるんですよ。
となったらその途端にめっちゃ不便に感じるんですよね、僕らって。
不便に感じたことあるんですね、私も。
だからちょっとプロタイプ作るのはいいんだけど、実際に使うと夢を追うとかあるんですね。
そうですね。
だからそれが制約することの難しさなんだと思います。
ノードレッド制約されてないんですよね、一応。
そうですね。
これ最初の話に戻りますけど、
じゃあどういうことを制約してどういうことを制約しなくていいかってどうやって考えたらいいんですかねっていうポジションに立ち替えると、
生産性ビットに必要な能力と構造っていうのは本質的には何なのかっていうことを知らなきゃいけない。
これは、これ分かる?
PUCメーカーの中でそこまで分かる人がなかなかない。
分からないですよ、分からないですよ。
そうですね。
これをやっぱりやるのって、現場を知ってる人じゃないとやっぱりやれないんですよね。
そうですね。
生産性ビット作ったことがない人がやっぱりこれはやることはできない。
これやる人はその破壊してメーカーの中に入るかどうかはもう判断が別ですよね。
っていうのがやっぱり本質的な難しさだと思います。
なるほど。
だから設備をしい尽くして、これはいらない、これはいるっていうことを言えるかどうかっていう。
この設備は大丈夫ですけど、こちらではやっぱりいらないものもいるっていうこともあるしね。
そうですね。
あるから。
あるんですね。
いると思います。
だからそれはどうしていくかですね、それを。
なるほど。
もしかしたら自動車用パッケージ、家電用パッケージ、プラント用パッケージみたいになっていく可能性もありますし。
業界とは別れるんですね。
要はパックエムルとかそうですよね、基本的に。
そうですね。
食品業界に限定したフレームワークという形で抑えてるわけじゃないですか。
こういうフレームワークですよね、なるほど。
っていうのがここ1年、2年ぐらいでなんとなく僕はそういう感じに思えてきた感じですね。
僕たちがやるべきは多分そういうことなんだろうなって。
フレームワークを。
フレームワークを用意作る。
力を作るために力を作るんですね。
筋のいいフレームワークを作る。
そうですね。
そうだね。
もっと言うと、日本国に適応したそういうのを作る。
そうだね。ヨーロッパのものばかり使うじゃなくて、日本の生産現場に青のフレームワークを作らなきゃいけないんですよね。
そうですね。
だからさっきも言った通り、ヨーロッパの人とかアメリカの人が考えたフレームワークって、日本が使うとおそらくこれが足りない、あれが足りないって絶対になると思うんですよ。
そもそもこれはアメリカの現場とかヨーロッパの現場のために作ったものですよね。
そうですね。
だからやっぱりそこに乗り切るっていうのは一つの恐怖があって。
要は日本に合わないものとアメリカに合ったもので戦ったら、同じものを使ってアメリカが勝っちゃうわけですからね。
となった時に、それを使って差別化して日本が勝つって言えばなかなか難しいので、やっぱり日本国内でそういう活動を多分しないといけないんじゃないかなって思ってます。
メーカーだけじゃありえないかもしれないですね、これ。
でもどうだろうな、これ。メーカーとエンドユーザー。
多分合併とかタッグ組まないと無理だと思いますね。
多分一緒にやらないとお互いも作る気にならないですよね、どっちか一方だけ作るには。
そうですね。ただ何て言うんですか、絶対にそのPLCを使わないといけないわけではないですけどね。
日本版フレームワークさえできればいいんで、じゃあ例えばベックフのツインキャットの上に日本版フレームワークを走らせましょうっていうのも全然成立はするわけです。
このフレームワークの定義はどうすればいいんですよね。日本に会うゲームまで会うフレームワークの定義は誰がやる、やりましょうみたいな感じですよね。
そうですね。ただじゃあベックフを使った日本版フレームワークを作りましょうっていう時に、当然日本のPLCメーカーそんなの載ってこないわけじゃないですか、絶対。
設備立ち上げの改善策
載ってこないですよね。
っていうと、そもそもそういうこと自体が破綻する可能性がありますよね。
となったらじゃあ国産メーカーでもうまくやれるような仕組みの上でそういうフレームワークを作りましょうっていうのが現実的なラインじゃないかっていう。
版社とご参加とかでちょっと一緒にやりましょうみたいな感じですよね。
そうですね。僕がISCを推進する理由はもうそこなんですよね。
皆さん同じものを作れる。
そうですね。
同じのレシピで、ガイドラインでものを作れるから。
そうですね。
同じガイドラインだったらフレームワークの共産者、日本のUSCメーカーも同じフレームワークだけでも作れるんじゃないかという話ですよね。
そうですね。だからこのISCの企画のここまで引き上げたもののカードウェアを出せば、このフレームワークはとりあえず使えるから、そうすればあなたのところもやっていけるよっていう風にするのが一番妥協的なラインなんじゃないか。
なるほど。
っていうのが今なんとなく思ってることかなっていう。
そうですね。
ちょっとなんか偉い話飛んだ気がするんですけど、設備搬入から立ち上げを早くするために何か工夫してますかって聞かれて、なんか全然関係ない話してる。
すごい、フレームワークられましたね。
でも我々の興味範囲はここだから、そこに行っちゃうのもしょうがないんですけど。
基本常にISCとかフレームワーク見てますからね。
そうですね。
そこで情報収集してますし。
でもなんというか、これじゃないですってなった時に何ですかっていうのがいまいち答えられないんですよね。
そうですよね。最初は答えかかるんですけど、どんだけやってもこれも現場でテクニックしかないので。
根本的な高さで特に根本的な高さを直さないと、あれだけ早くなっても1、2日くらいだけじゃないかなって思ったんですね。
そうですよね。
どんだけ早くても。
根本的に直せるんだったら、高さでやったところ設計の思想とか、あれ全部よくするんだったら、
分からんけどな、本当にブータンの時間、マッツの時間とか直す時間がいるんだったらこっちの方がいいんじゃないかなと思ったんですね。
なので誰かがそういうのをちゃんと開発して、本を書くって感じですかね。書籍を出して。
高橋さんに目線向いてますよ、今。
高橋さん。
じゃあ私とクリスさんで書籍出しますか、そういう。頑張って開発して。
そうですね。フェーマーク、プレイマークを。
頑張ればできるもんですけどね、日本は。日本は頑張ればできると思いますよ、フェーマークくらいは。
いや、やれるんじゃないかな。
もう全然、やろうができるもんですけど、日本のメーカーって優秀ですから。
そうですね。僕その業務的に生産設備をずっとやってますけど、僕の感覚、生産設備そんな難しくないんで、構造的には。
やることもある程度枠があるんですよね、こういうやり方なんか。
そうですね。
ひまりというか。
そうですね。各社は各社のやり方がありますけど、それが捨てられへんかっていうと、捨てられへんことはないと思います。
なんですか、ちょっとこの辺わからないですけど。
設備の立ち上げを早くする方法
例えばですけど、今このやり方であったら不具合絶対浮きませんっていうものを出されたときに、それを拒否する理由ってあんまりないんですよね。
そうね、喜んで浮けますよね。喜んでやりますよね。
そうそう、例えば現場の使い方がちょっと違うとか、覚えなさなあかんとかいろいろありますけど、でも不具合ゼロになって立ち上げ時間ゼロになるんだったら、たぶんみんなやりますよ。
やりますよね。やります。
だってものすごく効果が大きいの、それが。
そうですね。
なるほど。
これはなんなんですかということか、みんな追求しなきゃいけないんですよね。
そうですね。でもただ今やっぱりそれはほんまなんですか、ほんまにそうなるんですかっていう疑問が湧くのもそうだし、見えてない不具合とか見えてないデメリットはないんですかっていう話も当然あるので。
はい。
それはその実績とか何かいろいろなもので証明していく必要はあるんでしょうけど、ただそれがすべて見えたときにはみんな喜んでやると思いますけどね。
そうですね。やらないと何も始まらないからね、こういうのは。
やって焦げてる感じですよね、焦げて。
そうですね。
あ、これダメ、ダメとかもう一回やり直すとかね。
そうですね。
それを実現する手段は別にフレームワークとか意思じゃないかもしれないけど、もしかしたら。
ただ今のところその辺を抜いたときに何かいい手段とかいい方向性があるのかっていうと、世の中には出てないんじゃないかなっていうのは思いますね。
なるほど、なるほど。
面白い話題ですね、どうやって装置を早く立ち上げるからこのフレームワークとか設計の話をどうやって。
そうですね。
まあ、こういうのはぶっ飛んだ考えをしたほうがいいと思います。
そうですね、そもそもこれ早くするのはコンボ的にどうすればいいのか。
そうですね。
何で遅いの、そもそも何で遅いんですかって考えなきゃいけないですよね。
そうですね、例えば不具合を10%減らしますっていう考え方だと、やっぱり今の延長線上を修正するっていう考え方になっちゃうんで。
でもこれをゼロにしますとかそういう話にすると、今のやり方じゃ絶対できないんで、別の考え方をせないといけないんで。
こういうときは一旦とんでもないこと言い出すっていうのが大事な気がしますね。
目標設定の重要性
面白いですねこれ、10%減るんだったら別に修正でも多分済ませる話ですけど、完全にゼロするんだったらこのやり方はちょっと無理ですという。
面白いですねこれ。
そうですね。
確かに。
なんか僕の好きなラジオで、ポッドキャストで氷商売ラジオっていうのがあるんですよ。
氷商売っていうのは薄利多倍ってクリスさん分かります?
分かりません。
薄利益でいっぱい売るって書いて薄利多倍なんですけど。
それは反対ですね。
厚い利益で少なく売るっていうのが氷商売っていう。
それをやる、それをどういうふうにできたらできますかっていうポッドキャストとかあるんですけど、僕これ好きでずっと聞いてるんですけど。
そこで言われた結構印象的な言葉があって。
例えばあなたの商品が100万円の価格で売ってますと。
これを120万円で売ってくださいねって言ったら、あなたは今売ってるお客さんのところに行くでしょうと。
今買ってくれてる人にどうやったら20万円だけ買ってくれますかって行くでしょうと。
でもこれが10億円で売ってこいって言われたら、もうあなたはそのお客さんのところに絶対行かないです。
10億円買ってくれるお客さんのところに新しく行きます。
絶対そうだね。
確かに。
これはだから、結構チャレンジが飛んだことをやるには、今のやり方の延長線上とかそういうところじゃ絶対達成できないっていうことか。
ちょっと書いておきますよ。
ちょっと書いておきます、メモで。
面白い、確かに。
悪魔のものをもとで120万円で売るんだったら、今の現存のところでもいけるかもしれないですけど。
今の100倍と200倍以上売るんだったら、別のところ、新しいやり方じゃないともう無理ですって言うんですよね。
そうですね、そうなるとそもそも論を考えないとやっぱりやれないんで。
やっぱりそういう結構飛んだ目標とかぶっ飛んだ目標を一回立ててみる。
もしくはその過程を置いてみるっていうのは、こういう物事を考える上ではそれなりに大事なこと。
ちょっとメモしておきましたね、これちょっと。
明堅メモ帳の中でちょっと松井大介氏がした。
そうですね、僕なんかこの考え方が一番やっぱりトヨタに入って一番学んだことかなって思いますね。
さっき言ったこのぶっ飛んだこと。
僕らはあるべき姿って言うんですけど、それを。
なるほど、なるほど。
ちょっと勉強になりました、これちょっと。
これ後の番組教えてください。
送っておきます。
後教えてください。
ちょっと面白い言い回しに似てるなと思ってます。
皆さんも郡商売ラジオ面白いんで聞いてください。
商売、はい。
郡商売、ありがとうございます。
というわけで、最初のタイトル忘れましたけど。
搬入した時にいかに早く立ち上げるかっていう話から、設備品質をどう上げるかっていう、特に僕らのソフトウェアの話を今日はしました。
皆さんもぜひ一度考えて県外のシミュレーションを見るいい機会にしていただけると嬉しいですということで、このラジオは終了したいと思います。
ありがとうございました。
ありがとうございました。
