専用機の設計課題
TomoyaTakahashi
明日のファクトリーオートメーションにようこそ、メインパーソナリティの高橋です。
クリス
クリスです。
TomoyaTakahashi
はい、よろしくお願いします。
クリス
よろしくお願いします。
TomoyaTakahashi
ラジオネーム、しらたけさんからお便りです。ありがとうございます。
クリス
ありがとうございます。
TomoyaTakahashi
高橋さん、クリスさん、お疲れさまです。
専用機の図面やデータの管理について質問です。
私の会社では、客先のワーク、ライン使用に応じて装置を専用設計するいわゆる専用機というものをやっています。
専用機は一品一用というのが建前ですが、現実はこれまでにない新しい装置というのは珍しく、
似ている装置の図面をコピーして変えるところだけ変えるというパターンがほとんどです。
メカ図面の場合、完全同一仕様であっても、全体組図は製版ごとにコピーして新しい図面版を割り振りますが、
ユニット組図や部品図は可能な陰で流用します。
これにより、図面が無秩序に増えるのを防ぎつつ、
もともと同じ仕様の装置でも改造による合期間での仕様が異なってくるという状況にも対応しています。
ただし、実際は理想通りにいかないことも多いですが、
一方、電気設計になるとコイル取り、設定のリファレンス情報などページ間の相互依存関係が強く、
図面が一本の巻物のようになり、一部分流用や共通化がなかなかうまくいきません。
何かうまい方法はないでしょうか。
長文失礼しました。よろしくお願いします。ということです。
電気設計の流用と共通化
TomoyaTakahashi
どうですか、クリスさん。
クリス
制御器。制御器は、ちょっと待ってくださいね。
TomoyaTakahashi
まず質問は分かりました?
クリス
どうやって電気設計の方に流用か共通化にいい方法がないかというのが一番メインの質問ですね。
電気設計のほうは見たての図面とかも流用して、コピーがなくなって完成したんですけど、
電気設計のほうがそういうのはうまくいってないという人がほとんど多いんですね。
TomoyaTakahashi
そうですね。どうしたらいいですか。
クリス
そもそもこの予想と予想関係、コイルと接点とリファレンス情報などのページ感が、
ちょっと待ってくださいね。
何が置き換えなくなっていくんですか。ちょっと待ってくださいね。
電気設計になるとコイルと接点のリファレンス情報などのページ感の一本の巻物になる。
これ巻物でいうことは、コイルと接点がひも付いてて、
これ予想関係、すみませんちょっとわからないです。
コイルの接点のリファレンス情報などのページ感の予想、
予想関係が強い、それで巻物になる。
TomoyaTakahashi
これで巻物なんですかね、そもそも。巻物になる。
変わりましょうか。
クリス
すみません。
TomoyaTakahashi
言われていることとしては、要はコイルと接点があちこちに飛んでるんだと思いますね。
例えばコンベアがあって、何かはハンドがあってっていうもので、
コンベアっていうものをコピーしてきたときに、ラダーズとして。
クリス
その中には、例えばハンドの中のいろんな接点がもうすぐにめちゃめちゃ入ってる。
TomoyaTakahashi
そこに結局依存関係があるよっていう。
クリス
これ電気設計なんですよ。これプログラムの話?
TomoyaTakahashi
プログラムの話をしていると思います、これはね。
クリス
これ電気設計、これプログラムの話か。
TomoyaTakahashi
電気設計っていうのは、板の設計からプログラム調整まで指すことが多いです。
生産済みの世界で。
クリス
なるほど。
最近電気設計、西洋設計みたいなパターン分けてて、
電気設計はプログラムまで作るっていう話ですよね。
TomoyaTakahashi
全部プログラムで作りますよ。結局呼び名が違うだけですからね、そんな。
クリス
なるほど、なるほど。
これをまずはライプ…
この状態が昔ソフトウェア設計のときはあったんですけど、
ソフトウェアコイルと接点がリモついていることをラインかなと思ったんですね、今まで作ったことが。
TomoyaTakahashi
それはどうやったらなるんでしょう。
クリス
アドレスがやってまず、アドレスやってないですよ、プログラムの中で。
全部アドレスやってない。
TomoyaTakahashi
別にアドレスでやっても同じじゃないですか、管理さえできればそれって。
クリス
そうですね、これ管理の問題か。でも管理ができてないからですよね。
TomoyaTakahashi
どういう管理をすればこれができるようになるのかっていうことを多分質問されてるんだと思います。
クリス
そうですね、ソフトウェア設計の側では、私できることは大体ファンクションブロックとか、
あとはダブルローティーンとかちょっとうまく分けて、
自分が変更するところを一番最小限にするのが自分のやり方かなと思ったんですね。
TomoyaTakahashi
それってどう分けるんですか。
クリス
例えばロボット、もちろんコマが分かる。
例えば1個のライン、DR、組み立て機の中で、
例えばボシリンがあって、ロボットがあって、あとはいくつかの小さなパーツがあるんだとして、
最初に私がやることは、ステーションが分けていくんですね。
例えばロボットが真ん中にあって、搬送はステーション1個で、小さく組み立て1個でステーション3つがあって、
その中でシリンダー3つ、シリンダー3つとか、
あとは搬送だったらロボシリン1個、上にシリンダー、またチャックを見たらシリンダー1個みたいな感じで全部小さく分けておいて、
それでシリンダーのファンクションブロック、共通部分のロジックだけ作って、
それでまず基本部分作ったんですね。
その後はアドレスだけ振って、有力度出力アドレスだけ振って、それで水道部分ほぼ終わったんですね。
最後に自動、もう一応同じじゃないですか、やっていくこと。
いつもこうやって分けているかなと思っているんですね。
TomoyaTakahashi
流用が効く原理がどういうことかっていう話ですよね。
クリス
そうですね、流用がどうする。
TomoyaTakahashi
なぜ流用が効くのか、なぜ流用が効かないのかっていうところを多分述べないといけないんじゃないかなと思います。
クリス
なぜ流用が効かない、それでもなぜ流用が効かなくなるということですよね。
TomoyaTakahashi
なぜ流用が効かなくなる?なぜ流用が効かなくなるというのは?
だってファンクションブロックなんか作り方は無限にあるわけですから、流用が効かないファンクションブロックの作り方なんて無限にあるわけじゃないですか。
クリス
例えば中に飲むの外アドレス使ったりとか。
そうだし、例えばロボスリンダーに2つ制御するので1個のファンクションブロックなんか作ったらもう流用効かないじゃないですか。
なるほどね、なるほど。
TomoyaTakahashi
例えばロボットの先にハンドが入っているファンクションブロックを作りましたっていうと、
クリス
ロボットの流用したけどハンドが変わったらもうできないわけですね、それ。
TomoyaTakahashi
ハンドが違うものが入っていると。
ライブラリの管理と流用性
クリス
例えばね。
なるほど、なるほど。
そういう時は作り方の問題ですね。
そうですね。
TomoyaTakahashi
道具まで細く、ロボットだけは1個ブロックで、ハンドは別にみんなで一緒に。
それを多分言語化しないといけないわけですね。
クリさんが今僕がこういうのはどうですかって言った時に、そりゃこうしたらいいんだよっていうことを多分今言ってくれたと思うんですけど、
じゃあそれを設計論に落とした時どうなるかっていう話なんだと思いますよね。
なるほどね。
どういう方針でライブラリを作ればいいのかっていう。
それはどういう理屈なのかっていうことなんだと思います。
クリス
一番小さいパーツから全部やるから。
TomoyaTakahashi
小さいパーツから。
じゃあなんで一番小さいパーツからやるんですか。
クリス
簡単、作り方簡単ですよね。
TomoyaTakahashi
でかいやつ作ると変更する時もいかないし。
それは多分違うんですよ。
多分それは違ってて、一番小さいところから作ってるのは一番買えなくていいから作ってるんだと思います。
買えなくていいから作ってる。
例えばロボシリンダーっていうものに対してロボシリンダーを制御するライブラリを作るじゃないですか。
作ります。
クリス
これは何に紐づいてるかってロボシリンダーに紐づいてるわけですよね。
ロボシリンダーが何か仕様が変わりますかって変わらないじゃないですか。
TomoyaTakahashi
ロボシリンダーはロボシリンダーで、その仕様も機能も変わらないですよね。
それは製品だから。
クリス
一回作ったらもう終わりという。
TomoyaTakahashi
そう。だからじゃあ次ロボシリンダーを使いますっていうものをした時にそのライブラリはそのまま引っ張ってこれるわけです。
何も変わらないからその対象が。
クリス
なるほどね。
TomoyaTakahashi
でもこれじゃあ装置になったら装置の仕様が死ぬほど変わるわけですよ。
装置でかい単位で見たらね。
ロボシリンダーが5個が6個になりました。
ロボシリンダーがエレシンダーになりました。
こんなこといっぱいあるわけじゃないですか。
クリス
ありますね。
TomoyaTakahashi
だからライブラリの対象の先が変わるかどうかっていうのがまず大事なんですよ。
その流用性っていうものを考えたとき。
クリス
例えばちょっと変わってもライブラリまだ使えるかどうか。
TomoyaTakahashi
そうですね。ハードウェア変わるというかそれに紐づいた何かそれを対象として何か。
例えば今回作るライブラリっていうのはじゃあロボシリンダーを1個扱うライブラリを作ります。
それはロボシリンダーを使っている限りはそれはずっと流用できるわけですね。
何も変わらないから。ロボシリンダーの仕様は何も変わらないから。
ここまでいいですか。ここまでいいですよね。
じゃあ次ですよ。
じゃあまず一番変わらない最小単位っていうのはアクチュエーターとかセンサーの製品単位ってことになりますよね。
クリス
そうですね。
TomoyaTakahashi
いわゆる機械に紐づくわけです。一番最初は。機械の要素に紐づくわけです。
サーボモーターだったらサーボモーターのライブラリ。
エアシリンダーだったらエアシリンダーのライブラリ。
近接センサーだったら近接センサーのライブラリ。レーザーセンサーだったらレーザーセンサーのライブラリ。
クリス
ありますね。
TomoyaTakahashi
これはその要素レーザーセンサーを使いますっていうことに紐づいてるんで、
クリス
次の説明レーザーセンサーを使うんであれば100%流用ができます。
そうですね。同じ製品だから。同じ製品ですよね。
TomoyaTakahashi
じゃあこの最小単位っていうのは作っておけば100%流用が効きますよねっていうのがまず一番最初の出発点。
クリス
もう一回言っていいですか。最後の場。もう一回言っていいですか。
TomoyaTakahashi
100%流用が効きます。その製品を使う限り。製品というかその部品を使う限りね。
クリス
そうですね。
TomoyaTakahashi
で、その次はそのアクチュエーターに紐づくものっていうのは変わってきますよね。
例えばじゃあサーボモーターを使います。じゃあその先の減速比は何なんですか。回転なんですか。リードレ。ボールネジなんですか。
クリス
リードレですか。はい。
TomoyaTakahashi
っていうものが変わってくるじゃないですか。
クリス
変わってますね。はい。
TomoyaTakahashi
じゃあこれによってライブラリが流用できるか流用できないかっていうのはちょっと変わるわけですよね。
クリス
具体的に考えたら変わるんですよね。
TomoyaTakahashi
変わりますよね。少なくともパラメーターから何から何までコピーしてきても使えないわけじゃないですか。その先が変わってる可能性があるから。
クリス
変わらないですね。はい。
TomoyaTakahashi
っていうところを考えていく。じゃあそのさっきの何も変えなくていいところと今回変えないといけないところっていうのを考え方がどう違うんですかっていうことですよ。
クリス
変えなくてもいいと。あ。
変えなきゃいけないことをどうやって切り分けるか。
TomoyaTakahashi
切り分けるか。で、それをどういうふうに考えるかですよね。
クリス
なるほど。
なるほどね。
TomoyaTakahashi
で、それはその時に大事なことっていうのは、
なんて言えばいいのかな。
クリス
どこまでを変えなくてよくて、どこを変えるべきなのかっていう設計をすること。
変えなくてもいい。
TomoyaTakahashi
変えなくてもいい。何を変えなくてよくて、何を変えるのかっていうライブラリーとしてね。
クリス
なるほど。はい。
TomoyaTakahashi
例えばじゃあどういう話をするかっていうと、じゃあさっきのサーボモーターの話しますね。
サーボモーターっていうものの制御自体は一緒です。
でもその先に付いてる機構が違うと。
クリス
そうですね。はい。
TomoyaTakahashi
ボールネジかもしれないし、ローラーかもしれないし。
クリス
はい。
TomoyaTakahashi
ですよね。
ライブラリーの基本的な設計
クリス
はい。
TomoyaTakahashi
これを最初から、じゃあこの3パターンがありますっていうふうなライブラリーにするのか。
クリス
そうだね。それともパラメータで。
TomoyaTakahashi
それか、これはもうボールネジ用で1個作って、ローラー用で1個作ってみたいな感じにするのかみたいな。
クリス
なるほど。
TomoyaTakahashi
要はその。
クリス
サーボモーターじゃなくてサーボモーターの付いてるローラー。
TomoyaTakahashi
まで含めてライブラリーにしちゃうかっていうね、そういう考え方もあるわけですよ。
クリス
なるほど。
で、それをどう組み合わせるかっていうのが次なわけですよね。
そうですね。
TomoyaTakahashi
なのでその考え方っていうのをしっかりと決めていかないと、この2つがもう考え方混ざったしでも流用なんか効かないわけですよ。
クリス
このファンクションブロックがサーボモーターでOK、でもこのファンクションブロックはもうローラーになってる。
ローラーなくても、このローラーファンクション関係で言えばサーボの西洋のロジックも入ってる。
TomoyaTakahashi
そうですね。
クリス
そう言い合わせちゃうんですよね。
流用性の理解
TomoyaTakahashi
っていうのがまず一番下のそのアクチュエーターとかセンサーとかその最小端のライブラリーの決め方ですよね。
これは非常に流用率が高く設計できるはずです。どっちにしても。
クリス
そうですね。
TomoyaTakahashi
そんな種類があるわけじゃないですからね、作って終わりだと。
クリス
そうですね。
で、たぶん今回質問されてるというのはここから先がたぶん難しいんだと思うんですよ。
TomoyaTakahashi
高谷さん、ローラー機構ができたらどうするの?とかリニアルの設計はどうするの?とかみたいな。
っていうよりは、ここから先は同じになることが基本的にないからですね。
クリス
はい。
要はそのいろんなコイルであったりだとかそのいろんなものがいろんなところから飛んでくるわけです。
そうですね。
機械動きが変わる。
違うから、当然この辺のロジックも全部違うんですね。いろいろ物をどうやって動くのか。
TomoyaTakahashi
例えばそのじゃあモーターが2つありますっていうことだけって言っても、モーターをどういう順番で動かすんですかっていうのは全く同じではならないわけですね。
例えばAを動かしてBだけどBを動かしてAの可能性もあるわけです。上のシーケンス回路としては。
この時点でここをまるまるコピペするのは無理なんです。仕様が違うからね。
クリス
この最小限どこまでいるわけですよね。
TomoyaTakahashi
そうですね。
クリス
ロジックがAモーターを動かしてBモーターを動かしてライブラリーを作ったら流用性が非常に効きにくい場合があるんですよね。
TomoyaTakahashi
ここのためのものを作っちゃったみたいな。
そうですね。だからAとかBっていうこの順番までライブラリーの中に含めちゃうともう流用が効かなくなるわけです。それを変えないといけないから。
じゃあどこを変えてどこを変えないかっていう線引きが大事なんですね。
クリス
どこまでライブラリー化すべきか。
TomoyaTakahashi
そうですね。この中で重要なのは何を変えないといけないのかっていうのが正しくわかることなんですよ。
クリス
何を変えなきゃいけないのか。
TomoyaTakahashi
要は例えばクリスさんがあるライブラリーを作ったとするじゃないですか。
作りますね。
それをコピーしましたと。別の設備を作るときに。
それが例えばある場所が1点流用できなくて。
っていうことがわかってたらそこを直すだけですよね。
クリス
そうですね。
TomoyaTakahashi
コピーしてきてそれが何を変えたら正しく動くのかっていうことがわかってれば直すだけなんですよそれは。
確かに。
クリス
だから要は完全にコピーしてそれが保証されてることが重要なんじゃなくてどうやったら動くかっていうことがわかってることが重要なんですここで言うと。
一番やること少なくて簡単に早く動くのは最終ゴールですね。
TomoyaTakahashi
それはどこかって。
これが中のロジックをきちんと考えられてるライブラリーっていうのはそもそもコピー&ペース1個は噛み合わなかったら何で噛み合わないかってのがわかんないってことなんですね。
クリス
もう一回やってみて下さい。
TomoyaTakahashi
要は例えば100行のコードがあったとするじゃないですか。
この100行をコピーしましたと。
でも仕様がちょっと違うからこの100行のコードは思った通り動きませんでしたってなるじゃないですか。
クリス
よくありますね。
TomoyaTakahashi
この時にこれは全部使えないってなるのか、どこか1行変えたら使えるってなるのかっていうのがあらかじめわかってれば別にそれは流用したってほぼ言えることじゃないですか。
クリス
なるほどなるほど。
でもこれだけのメーカー席の話言っておきますね。
リテルストージの図面をコピーして変えるべきここだけ変えるというパターンほとんどですけどソフトウェアもそうですよねソフトウェアも。
TomoyaTakahashi
それを試行錯誤的にやるのは流用したとは言えないってことです。
流用とは言えない。
クリス
クリスさんがじゃあこのライブラリをコピーしてきてこのライブラリでこの装置を作りますって言った時にもう書く前にこれを変えればいいってわかってるっていうのがライブラリの重要なところなんですよ。
書く前にこれを変えればいい。書く前にこれを変えればいいっていうのは。
もう一回やってみて下さいちょっと取るの難しい。
TomoyaTakahashi
100行をコピーしてこれで動きますかっていうことがその時点でクリスさんがまず判断できるかっていうのが一つですよね。
そうですね。
で多分できないですってなった時に。
どこ変えればいいのかっていうことですね。
どこを変えればいいっていうのがわかっててその変え方も正しくわかってればそれは別に問題ないわけですよ。
クリス
問題ないですよね。
TomoyaTakahashi
でそれは100行のうち99行が書かなくてくそも流用できるんだったら流用率99%じゃないですか。
標準化の重要性
クリス
そうだねはい。
TomoyaTakahashi
でもその1行がどこにあるかわからずに試行錯誤的にやったらもうその時間だけどんどん過ぎていくわけですよね。
クリス
そうだね。
TomoyaTakahashi
じゃあその1行がわかるってのはどういうことですかっていう。
クリス
どう表現するかどう表現?表現するかっていうか。
TomoyaTakahashi
でその1行を見つけるのは設計者の能力なのかっていう話なんですよ。
クリス
なるほど。
なるほどね。
TomoyaTakahashi
だからあらかじめこういう場合にはこういうとこに変えればいいですよっていうことであらかじめ決まっていればそこを変えるだけじゃないですか。
クリス
そうだねよく考えたらそうですよね。
TomoyaTakahashi
でそれがその論理的に導き出せるかっていうことだ。
いわゆるその仕組みなんですよね。
クリス
はい。
TomoyaTakahashi
アーキテクチャーなわけです。
プラットフォームというべきかもしれませんけど。
クリス
はい。
うん。
あーなるほど。
もう変えるべきか。
どういうこの1行をどうやって説明、見つけるか。
TomoyaTakahashi
そうですね。
クリス
でこの今の動く。
TomoyaTakahashi
僕はちょっとこれきちんと正直声で説明するのすごい難しいなと思ってるんで。
多分聞いてる人結構チンポンカップンなのかもしれないと思ってますけど。
はい。
うん。
クリス
うん。
なるほど。
TomoyaTakahashi
要はそのなんて言うんですかね。
流用性の高いプログラムを作るってのはどういうことかっていうと。
絶対これは変えなくていいっていう部分をどうやって保証するかなんです。
クリス
どうやって保証するか。
うん。
どこまで、この装置、この僕のロジーここまでだったら、このライブラリーはそのまま流用できるということを明確に説明できるかどうかっていうこと?
TomoyaTakahashi
説明できるかどうかっていうか、それをドキュメントに決めれるかどうか。
クリス
ドキュメントで落とし込んだというか、説明してたかどうかですね。
TomoyaTakahashi
そうですね。はい。
クリス
あーなるほど。
前も言ってたことあったんで、言ってましたね、このコードのドキュメント化はどうするか。
TomoyaTakahashi
はい。で、例えば、じゃあこういうものを作りたいですよっていうときに、
じゃあライブラリーこれとこれとこれがあるねっていうときにそれを引っ張ってきたときに、
その何パーセントのところまではこれで確定するのかっていうことが、その時点で決まってるのが最良ってことです。
クリス
ってことは最初にこのライブで作った人は、そもそもドキュメントがないと、そもそもライブで流用できるかどうかわからないってことですよね。
今よく考えるとすごい根本的な問題ですよね。
TomoyaTakahashi
そりゃそうです。ライブラリーっていうのは自分が頭の中にあるものを適当に引っ張ってくることではないですよね。
クリス
そうですね。なので、そもそもこの3ドキュメント説明できない限りは、その流用が共通か無理って言うんですよね、ライブラリー的には。
TomoyaTakahashi
そうです。
クリス
ここが最初の一歩目、入り口ですか、一歩目。
TomoyaTakahashi
一歩目っていうよりは、そもそも全体をデザインされてないと無理だっていうことだと思いますね。
クリス
全体的にデザインしないと無理。
全体的にデザインしないと無理。
なるほどね、なるほど。
TomoyaTakahashi
要は、なんていうのかな、ちょっと難しいんですけど、生産設備というものがどういう情報で構成されているかっていうことを構造的にまず分解する必要がある。
クリス
そう、要は構造的に分解する?
分解する。
TomoyaTakahashi
分解する。
クリス
これは例えば一つ、機構的に機能で分解するか。
ロボットが真ん中にあって、大量送るところのワンパーツの機能があって、
このロボットは一つのペケンペースという機能があって、また次のコンベアが次のステーションに流し込む、こういう機能を分けるという理解でいいですか、どういう言い方でもいいですか。
TomoyaTakahashi
それをもっと細かくですね。だってピックアンドプレイスってピックアンドプレイスじゃないじゃないですか、実際の機能としては。
クリス
そうですね。
TomoyaTakahashi
実際にはどこかの誰かがピックアンドプレイスしなさいっていう指示を出してるわけですよね。
クリス
そうですね。
TomoyaTakahashi
その指示を出せるかどうかっていう判断もその中に入ってるわけですよね。
クリス
はい。
TomoyaTakahashi
ピックアンドプレイスの指示を出します。その指示が出していいかどうかインターロックの判断があります。実際に指示をします。
指示をしたらそれを各アクチュエーターに送信するコマンドに変換するやつがいて、で実際に動くわけですよね。
そうですね。
だからピックアンドプレイスの部品って言いながら実際にこれだけのプロセスを踏んでるわけです、実際のプログラムは。
クリス
なるほど。
TomoyaTakahashi
じゃあさっきそのもうちょっと細かいこと言うと、じゃあインターロックを判断するっていうインターロックを判断する材料はどっから来てるのって。その条件って誰が出してるの。
クリス
なるほど。
TomoyaTakahashi
っていう情報の流れをまず明確にしないと、ここはそのままコピーしても大丈夫ですっていう場所がわからない。
クリス
なるほどね。コピーする場所はわからない。
TomoyaTakahashi
わからない。
クリス
どこまで、ああなるほどね。明確しないと。はいはい。
深いねこの話。はいどうぞどうぞ。
TomoyaTakahashi
でさっきのアクチュエーターの話に乗ると、アクチュエーターのところはほとんど100%流用できますよねって話をしたじゃないですか。
クリス
しましたね、はい。
TomoyaTakahashi
でそれが装置になったら、もうそんな100%は絶対無理なわけですよね。
クリス
無理なんですね。絶対地が可変な部分が出てくるんでしょうね。
でその中で、じゃあAという装置とBという装置で流用部がある程度あったとしたら、その中で100%流用できるところはどこなのかっていうところが最初から分かっている状況っていうのがこのアーキテクチャを作るっていうことだと思います。
標準文言い方がちょっと変ですね。
TomoyaTakahashi
そうですね。
その中で絶対変わらないものは何ですかっていう。
でその絶対変わらないものを最大化するような作り方ってどうですかっていう。
クリス
ちょっと待ってくださいね。
装置の中に絶対変わらないものは何ですか、この絶対に変わらないものを最大化してプログラムのライブラリとして落とし込むのは何ですかという。
どうすればいいんですかという。
TomoyaTakahashi
そうですね、はい。
絶対に変わらないところを作るやり方っていうのは何ですか。
流用性の原則
TomoyaTakahashi
例えばですけど、エリシンダーの図面を書きましたっていうのがあるとするじゃないですか。
その中のコイルを全部ベタ書きで書いたって言ったら、もうそれは使えないわけですよ。
クリス
使えないね。
TomoyaTakahashi
でもこれが例えばアドレス、インデックスレジスタで関節指定されてたら、そこのパラメータを変えれば使えるわけですよね。
クリス
インデックスだけずらせば、インデックスだけ変えれば全部使える。
あるいはもう流用できるっていうことですよね。
TomoyaTakahashi
そうですね。
で、これをもっと便利にしたのがローカル変数なわけですけど。
うんうん。
クリス
だからさかんさん最初に言ったのは別に変数プログラムでも何でもじゃなくてやり方が一緒ですね。
そうですね。
大事なのは変数とかやり方じゃなくて、変わらない部分は何ですかと言ってたんですね。
TomoyaTakahashi
それを決めていくっていうところですよね。
クリス
これ決めてから変数とデバイスやっても同じですよということですよね。
TomoyaTakahashi
そうですね。めんどくささは全然違うんで、やり方は自由に選ぶ必要がありますけど。
クリス
はい。
TomoyaTakahashi
で、それを外目から見て確定させること。
いわゆる設計前にどれだけ流用が効くかってことが、プログラムを一行も書かずに分かっていることをどういうふうに持っていくか。
クリス
ちょっと待って、もう一回やってもいいですか。
TomoyaTakahashi
要はプログラムを一行も書かずに、こうすればプログラムの何パーセントができますか、保証できますかっていうことをどういうふうに組み立てるかなんですよね。
設計の最適化
TomoyaTakahashi
で、これはこの機能は絶対変わらないとか、ここはこう組み立てれば変わるかもしれないけどロジカルで確定するとか。
そういうことを最大化するように、そっちのプログラムの構造や書き方っていうものを規定するっていうことだと思うんですよね。
クリス
はい。なるほど。
言葉にできないんだよな。
TomoyaTakahashi
ホワイトボードが今すごく欲しいです。
クリス
そうですね、なんかフワッとしてた感じですね。
分かるような分かんないような。
不平なものを書いて、全部取り出して、パワレムを全部取り出して、そこをライブレーカーでも何でもいろいろとして、それで最小限の部分。
これを案外違うんだったらどこに変えるのかを明確にする。それが第一歩。
TomoyaTakahashi
究極的な方針で言うと、変えなくていいところは全部コピーしてきて、変えないといけないところをいかに早く設計できるかっていうやり方を決めるんです、最終的には。
クリス
一番早くプログラムを作る方法。そういうプログラムを作る方法がやはり共通が最大ってことですよね。最大の。これですよね。
TomoyaTakahashi
理想なのは一行も書かないことなんで、まるっとコピーして終了ですっていうのが理想ですけど、実際はそうはならないわけですよね。
クリス
そうならないほうがいいですね。
TomoyaTakahashi
じゃあどういう方針をとるかって言うと、90%をコピーしてきて10%を死ぬほど手で頑張りますみたいなことがいいのか、70%をコピーしてきて残りの30%をすごく効率的にプログラミングするっていうのが早いのかっていう話です。
クリス
これ別に考え方の問題ですよね。やる人、どっちも会社の。そうですね。
電気石器屋の人の考え方ですね。
TomoyaTakahashi
それはどっちがいいかっていうのは、別に90%コピーしたほうが早く終わるとは限らないんですよね。残りの10%が超複雑になっちゃうと。
クリス
なるほど。
TomoyaTakahashi
っていうところのバランスを決めながら、生産すべりのアーキテクチャを設計していく。
クリス
ということですね。
TomoyaTakahashi
設計するっていうのは、その装置一つを設計するんじゃなくて、その会社の仕事のやり方を設計するっていうこと。
クリス
会社の仕事のやり方。
いわゆるそもそも、え?
そもそもね、会社の仕事の設計。
つまり。
TomoyaTakahashi
プログラムを作るっていうのはこういうことだよっていう。
これはAという説明のBという説明のCという説明のある程度やり方は一緒で、
それはこういうやり方をすると非常に効率的で、
そのやり方っていうのはライブラリーみたいな材料の話もあれば、ライブラリーの組み合わせ方の話もあれば。
クリス
そういうのが全部会社の仕事。
TomoyaTakahashi
そうですね。
クリス
やり方の決めり方ですよね、決めり方の方ですよね。
なるほど。
ぱっとせんもん。
正直伝えられてるような気があんまりしないですけど。
そうですね。
一番理解できたのは、もう一回聞くんですけど、高瀬さんの話。
買わないものだけ採材を聞いたして、
それで残りの何パーセント買わなきゃいけないのは明確にする。
それが一歩だけしか私も理解できなかったんですけど。
なるほど。
難しい。
TomoyaTakahashi
買えないでいいところを。
クリス
最大化する。
TomoyaTakahashi
最大化するっていうのと、買えないでいいっていうのをはっきりさせるっていうことなんです。
ドキュメント化ってか、論理的にここは買えないでいいでしょっていうライブラリーの作り方をするってことです。
クリス
なるほど。
作り方とかいろいろ絡んじゃうんですよね、これも。
なるほどね。
TomoyaTakahashi
だからよくあるのは、買えないでいいっていうのは、
2つの説を見比べて、ここが買えないでいいよねっていうのを見つけることだと思ってる人たくさんいるんですよ。
クリス
よくあるね。
AラインとBラインの比べて、ここだな、買えなきゃいけないのは。
TomoyaTakahashi
ここだなって、ここは使えるなって。
初めて作るものが決まって、見比べて調べるっていうのを共通からって思ってる人たちが結構いたりするんですけど、
現実にはそうじゃなくて、もうこのAという設備ができていたら、
このAという設備の中で流用できる部分ってもうその人に決まってるっていうのが理想なんです。
クリス
あ、でもこの定義席からの部分のチームの中で、この部分は絶対買えないよねということも認識。
TomoyaTakahashi
そう。
クリス
一生しないとダメですよね。
TomoyaTakahashi
そう、だからAっていう設備があったらもう食べれる部分はここだけですっていうのが最初から決まってるんです。
クリス
ここは触るな、ここは絶対触らないで。
決めないといけない。
TomoyaTakahashi
ここ以外はもう食えません、もう買えないといけないですってはっきりしてるんですよね。
じゃあBという設備を作るときには、じゃあ食える部分からどこを持っていきますかっていう議論なんですよ。
クリス
それもソフトステッキだけの話じゃないですよね。
もうその後もうこの会社、このやり方OKかどうかとかいろいろ絡んじゃうんですよね。
TomoyaTakahashi
そうですね、まあその機械設計だとか、そのバンの設計だとかも当然絡むんですけど、実際にはそういうことなんです。
AとBっていうのが初めに出てきてから、それを見てると流用できる部分っていうのはごちゃごちゃになる。
そうじゃなくて、Aっていうものを作ったときにもう食える部分が最初から決まってるよっていうのがモジュール化なんですね。
クリス
触っていい、触ってダメってところがちゃんとピンポイントしてくるんですね。
TomoyaTakahashi
で、そこが分かればじゃあ食えないところをどういうふうに早く作るかっていう議論に次になっていくわけです。
クリス
食えないところをどうやって作るか。
リファレンスの重要性
TomoyaTakahashi
要は流用できないって決まってるところがあるわけですよね。
クリス
流用ところはどうするんですか。
それをいかに簡単にやるか。
TomoyaTakahashi
問題はここですよね。流用できる部分はそこまで見るよりは流用できない部分をいかにも早く終わらせるか。
で、それは一番よくあるのは型を決めるってことですね。
クリス
型?
TomoyaTakahashi
型。要はこういうやり方をしていけばやれるよって。
例えばシーケンス回路でその状態遷移の書き方はこうだよみたいな。
これは仕様がこうなってたらだいたいこんな感じで書くんだよって。
クリス
絶対変えないでね、ここ。もう決まりだから。変えるならそうで頑張って。このブロック以外のところで頑張ってって言ってるんですよ。
これ自分だけじゃできないですね、一人で。
定義席の全部も話さないといけないですね。
明らかにここで1個変えればいいのに、
ここでロジック1個変えればいいのに、1個の回路を変えれば返すっていうものなのに、
これまた、いや違いますよ、ここで書いちゃダメですよ、言えるかどうかですよね。
違いますよ、ここで書いちゃダメだから絶対書いちゃダメ。
そうですね、そういうことなんだと思いますね。
TomoyaTakahashi
そういうことなんだと思いますね、僕の設計論はそうです。
だから間違ってるんですよね、AとBっていうのがあって、
このAとBでミクロマンやったらこれ30%いけるね、でもAとCでミクロマンやったらこれ50%いけるねみたいな、そんな議論が発生するからまずおかしい。
クリス
待て待てね、今ライブラリーあって、このライブラリーが当時Aだったら30%を利用できる、
TomoyaTakahashi
そういうBだったら50%、そういうCだったら60%、これライブラリー自体はおかしい。
クリス
同じだったら絶対変わらない部分だから、この部分だけは多分どのところでも100%を利用できる。
TomoyaTakahashi
そうですね、当然新規ライブラリー作らなあかんとかそういうのはありますけど。
クリス
でもあそこの部分普遍だったらもうでも変えなきゃいけないってことは、
TomoyaTakahashi
このライブラリーあっては失敗しちゃったっていうのはいかがですか?
そうですね、究極的には設備Aから設備Bに利用するんじゃなくて、
ライブラリー群っていうライブラリーのパッケージがあって、
その中から設備の70%は構成されますよっていうのが理想なんです。
クリス
例えばロボットのライブラリーだけ、シリンダー、単砲、ABもあるとか、あとサーボも2つ。
あの辺はみなさん今使っているものの一番ローレベルはいかがですか?
コンボ連動のライブラリーも絶対変えない部分を作らないといけないですよね。
TomoyaTakahashi
そうですね、だからどっかの設備が流用してくるっていう考え方がまずちょっとあんまりやってはいけない。
クリス
そうなるともうこの設備ためのものになっちゃうんですね、これも。
TomoyaTakahashi
そうですね、だから作るべきはそのライブラリー群、ライブラリーパッケージっていうものを最初に定義するっていうのが大事で。
クリス
参考ありますか?
TomoyaTakahashi
そうですね。
クリス
参考あります?
TomoyaTakahashi
参考って何ですか?
クリス
はい、どうぞどうぞ。
ん?
どうぞ、先に言ってください。
はい。
TomoyaTakahashi
ライブラリーパッケージっていうのがその大事なわけですね。
そこにあるものから流用してくるっていうことで、いわゆるリファレンスを作れってことだ、最初に。
クリス
リファレンス。
TomoyaTakahashi
要はそのよくある間違いが、設備をいっぱい作っていったらライブラリーが増えていきますよねっていうのは圧倒的な間違いで。
クリス
逆に言うとライブラリーはこれしかないから、どこの装置でも同じものを使ってますよ、逆ですよね。
TomoyaTakahashi
そうですね、だからリファレンスを作るのが先なんですよ、リファレンスを増やすのが先なんですよね。
で、そのある設備を作っていくとリファレンスを作る優先度っていうのはあると思います。
この設備あるからこのリファレンス先に作りましょうみたいなのはあります。
その結果使ってる設備が増えていくっていうのはそうだけど、実際にはリファレンスを充実させるっていうのが重要なんですね。
クリス
なるほど、なるほど。
理解できました、高谷さんということは。
これなんか参考できるものないんですかね、メーカーで。
こういうものの、そういう最小型のものだけがライブラリーとかなんかありますか、あるという。
ちょっと嬉しいですね、こういう。
こういう困ってるのたくさんいますよね。
TomoyaTakahashi
参考になるのは、例えばパックMLみたいなものは、一番下のライブラリ群じゃないですけど、一番上の形は決まってるわけですよね。
クリス
そうですね、逆に一番上で決まってて、下は全部これ順々してですよね。
TomoyaTakahashi
あれももう型が決まってるわけですよ、リファレンスっていうものは決まってるわけですよね、最初に。
クリス
うんうんうん、なるほど。
なんかいい例あるかなと思ったんですね。
TomoyaTakahashi
ないよ。
クリス
でもさっき高谷さんのアイディア聞いたら、一個ちょっとLG、何だっけ、Siemensね。
Siemensのライブラリの活用
TomoyaTakahashi
Siemensツールないで開けないから無理ですね、あれ。
まあでもSiemensも一つそうですね、だからSiemensってファンクションブロックを作ってめっちゃ配るじゃないですか。
あれもリファレンスを充実させてるわけですよ。
そうですね。
そっから選んで使えっていうことを言ってるわけですね、彼らは。
クリス
ここで一個ライブ、ちょうど開いたので、
皆さん、ディスコードでいろいろリンクを貼るんですけど、SiemensではLGF、Library of General Functions、
いろいろ信号の生成とか、あと時間とかタイマーとか全部の標準ライブラリを、
ローレベルのコンボネントとかのライブラリ提供されてるんですね。
あれを使えばとりあえず、この辺は絶対動作保証できるというライブラリがたくさん出てるんですよ。
こういうところSiemens開けない、ソフト開けないとちょっと微妙ですけど、
まあそういう結構いいライブラリであるんですね。
これプラス画面とか、画面も一緒にテンプレートで。
こういうテンプレートでプラスこのライブラリもワンセットみたいな感じとかもあるし、
結構参考はあるんですけど、難しいですね、Siemensをずるい開けないと。
流用性の課題
TomoyaTakahashi
実際にはそれプラスもうちょっと上のレイヤーも固めていくっていう形に。
そうですね。
これは多分各ユーザーがやってくるんでしょうけど。
クリス
そうですね。
TomoyaTakahashi
実際にはそういうやり方をしていくと、さっき質問で来てたようなコイルとかリファレンスがあっちゃこっちゃいって、
全然利用できませんみたいなことには多分ならない。
クリス
ならないですよね、なるほど。
TomoyaTakahashi
少なくともこの部分はできる、この部分はできる、みたいなものが多分60%、70%できるようになると思います。
クリス
そこですね、何ができる、何ができないとかはっきりしてないから余計にもちゃくちゃになっちゃう感じですよね、今は。
TomoyaTakahashi
そうですね。
だから実際にじゃあどういうとこが利用できないんですかって話になったときに、
一般的なシーケンスの部分とインターロックの部分ですよ。
ここはもう全然利用ができない部分になりますね。
クリス
そうで、これが機械装置で変わるから。
でも普通の、例えばこのコマンド来たら、やっぱりね、シリンダーここまでセンサーできるまではずっとスロックするとか、
あとこの時間内にセンサースロックし続けて、この時間内、またセンサー見えなかったらアラームとか、
その時にスロック切るとか、そういうのが全部共通ですよね、その部分は大体。
TomoyaTakahashi
正直その辺はちょっと難しいと。
クリス
難しいか、この辺難しいか。
TomoyaTakahashi
なぜかというと、2つ以上のものを組み合わせたものっていうのは、1個変わるともうそこ変わっちゃうじゃないですか。
クリス
それもちょっともうちょっと細かく切らなきゃいけないですね。
TomoyaTakahashi
例えばコンベアを動かして在下センサーを叩かなかったら異常にしますっていうのは、
その在下センサーがあるかもわからないわけですよね、流用先に。
クリス
そうですね。
TomoyaTakahashi
でもそのコンベアが動くっていうところはわかるわけですよ、インバータがあるとか。
クリス
そうか。
TomoyaTakahashi
だから自分単体で、いわゆるアクチュエーター単体で評価できるものっていうのはほとんどいける。
そうですね。
だから指示もいけるし、こういう指示を出したら静点しますっていうのもできるし、
インバータからこういう異常が返ってきたら異常にしますっていうのもできるわけですよね。
できる。
だから単体で判断できるものっていうのは、大体80%から90%ぐらい流用できます。
流用と言うと。
これを組み合わせて異常にする。
例えば指示を出したときに、1秒間このセンサー叩かなかったら異常にしますみたいなのはしにくい。
クリス
この辺は多分下辺の部分ですね。
ある意味多分この使い方、この変なこの、オンラインだったらそもそもこの機構は違うとか。
だったら多分この部分もう使えなくなっちゃうんですね、ライブで言っちゃったら。
TomoyaTakahashi
そうですね。その場合は機構の標準化っていうのをする必要があります。
クリス
この辺またベーカンの話変わっちゃうんですね。
そうですね。
TomoyaTakahashi
この辺を共通しましょうと。
だから例えばコンベアを動いたときに在庫センサー絶対つけましょうみたいな機械設計のルールっていうのがこれ出てくるわけですよ、次。
でもそこまでやれば流用ができるわけですね。
ライブラリ化っていうのができるわけです。
クリス
僕はこの話、電源設計だけやるのがちょっと無理、時が来るんですね。
電源設計とメガ設計を同時に一緒に話さないとダメですね。
TomoyaTakahashi
最初からやる必要ないと思いますけどね。
クリス
ある程度。
TomoyaTakahashi
だってまずソフトの60%は多分個別機器のプログラムが占めてるはずです、全体を並べたときに。
クリス
そうですね。
TomoyaTakahashi
じゃあ自分たちだけやっても60%は流用化なわけですよ。
クリス
それでも十分かなと思います。
TomoyaTakahashi
十分でかいですよね。
クリス
そうですね、1000V1以外作るよりは60%。60%はもう動作放送付きのプログラムあったらこれは楽だな、そうですね。
そうですね。
なるほど。
TomoyaTakahashi
まずはそこからだと思いますね。
クリス
60%を狙いましょうというんですよね。
TomoyaTakahashi
狙いましょうっていうか、そこからやりましょうだと思いますね。
クリス
そうですね。
最初スタートポイントで60%、70%くらいの放送付きの開発的なプログラムがライブラリ化をしましょうというんですよね。
TomoyaTakahashi
そうですね。
そこから先は組み合わせの話になるんで、その組み合わせが全く同じ組み合わせに関しては流用できるわけですから、
じゃあそれは全く同じ組み合わせがどういう頻度で出てくるのかどうかって話になるじゃないですか。
それがじゃあこれとこのセンスとは絶対80%くらいの確率で使うからライブラリ準備しておきましょうみたいな話に次がなっていくわけですね。
クリス
なるほど。その後に判断しちゃうんですよね。
じゃあこの組み合わせだって絶対来るからそれをまたライブで作って、
標準化による効率化
クリス
これはもう多分専用のステンを聞いたから別にあんまりないから、
まだやらなくてもいいってことですよね。
TomoyaTakahashi
やらなくてもいいよねとか。
こういう機構にするときは絶対こういう構成にしてくれたら品質補償できるから絶対これ調整楽になるよとか、
そういうお互いの旨味を提示しながらそこの標準っていうのは決めていくわけですね。
これをよくある間違いとは言わないですけど、失敗する傾向っていうのはこのユニットを標準化しますって最初にやっちゃうこと。
クリス
ユニット?
TomoyaTakahashi
絶対このユニットですみたいな。機械絶対同じですみたいな。
だからこれの整備は全部同じですって最初に外だけ決めちゃうっていうのが結構失敗の元だと思いますね。
クリス
キーパーのスケールが大きすぎるってこと?大きすぎるってこと?でかすぎるってこと?
TomoyaTakahashi
別にメカ変わらないんだったらいいんですけど、絶対変わるんですよ。
クリス
変わらないことはないんですよね。
TomoyaTakahashi
で、その時にさっき言ったアクチュエーターの構造化とかができてなかったら全部やり直しになります。
クリス
だからだかすさんが言ったのは一番小さいからコンポーネントからやりましょうって言うんですよね。
TomoyaTakahashi
コンポーネントをちゃんとやってたらコンポーネント変わったとこだけ変えればいいんです。
クリス
コンプネント変えただけでデータ信号同じだから、上のロジックも同じだけどコンプネント変えただけでコンプネント変えればいいと。
そうすると変更する分も最小限になるんですよね。
TomoyaTakahashi
そうですね。で、これをやるにはそのユニットの中があるルールに従って書かれてないといけないんです。
クリス
もう一回言ってもいいですか?
TomoyaTakahashi
ある決められたルールで書かれていないとこれが分からないんです。
これがこう変わったらここに影響がありますねっていうことを分かるためには、そのユニットの中がどういうロジックでどういうルールで書かれているかっていうのが非常に重要になる。
クリス
なるほど。どういうロジックでどういうルールで書かれるか第一。しかもね。
TomoyaTakahashi
で、これで最初の僕の論に戻ると、生産設備の構造化した設計をしないとまずダメだよっていうのはこういうことなんですね。
クリス
設備の構造化を設計しないとダメ。
TomoyaTakahashi
要はどういうルールでその設備は作られているんですか?どういうルールでその設備のプログラムは作られているんですか?
クリス
そこからですね。
TomoyaTakahashi
それはあなたの思いつきで決めてませんか?その場のっていう。
クリス
なるほど。
TomoyaTakahashi
で、思いつきで決めてるところっていうのは何かが狂ったときに全部お釈迦になるよって。
クリス
高田さんすごい色々経験がありそうな感じしてますね。すごいずっと聞いてるときに。
TomoyaTakahashi
いや、まあ僕はだからこういうなんていうんですかね。
仕事?
仕事をしてるから。
クリス
なんか苦しい思いがあったなと感じましたね。
高田さん、まあ仕事の話じゃちゃうんですけど、ずっとこの辺の仕事を順次したいんですね。
この構造化とかライブラリ化とかの仕事を順次したいんですね。
TomoyaTakahashi
僕は標準化っていう仕事をしてるんで基本的には。
クリス
だからこういう設計論、厳しいというかちゃんと考える。
どうだったら失敗するっていうのも分かるんですね。
だから。
経験済み。
TomoyaTakahashi
標準化の仕事の一番難しいところっていうのは確定させることなんですよ。
言ったことありますかね、その。
クリス
買わないことは見極めるか。
いいんじゃないですか。
TomoyaTakahashi
っていうよりはその。
クリス
頑張る調子が。
TomoyaTakahashi
あなたの仕事は何時間で終わりますよねっていうことを、
あらかじめ分かる状態にすることなんです、我々の標準化の仕事っていうのは。
クリス
だって待って、あなたの仕事は何時間で終わりますかということを明確にする。
TomoyaTakahashi
例えば全く何もライブラリーがない状態で仕事をして100時間の仕事があったとするじゃないですか。
その仕事に対して着手する前に、あなたの仕事は50時間で終わりますよねっていうことを言えるようにするっていうのが標準化の仕事なんです。
クリス
なるほど、つまり一人の時間を。
TomoyaTakahashi
なるほど。
じゃあ50時間であなたは終わりますよって言ったらなんでなんですかっていう話ですね。
で、さっきのやる設備の参考図面を探してきて、それのいちいちこれはどれくらい流用できそうかみたいな判断してると、
それはもうやってみて何時間だったっていう結果でしかないんですよ。
クリス
やってから何時間ですね。
TomoyaTakahashi
それだと見積もりが安くならないですよね。
クリス
ならないよね。
TomoyaTakahashi
だって一番最初最悪100時間かかるかもしれないんだから100時間分の見積もり出すじゃないですか、普通に考えたら。
クリス
そうですね。
TomoyaTakahashi
だから見積もり時点で50%の値段でもらうためには50%やるためにロジックをその時点で抑えておかないといけないんです。
クリス
なるほど。
TomoyaTakahashi
じゃあまだ手もつけてない相手の仕事をお前はこの時間でできるだろうっていうロジックを作らないといけないんです、標準化っていうのは。
クリス
一人の仕事の量を見積もり、あれでも見積もりできるようにする。
時間やらなきゃいけないのか、ある程度把握できる標準化の最終の一つの仕事ですよね。
TomoyaTakahashi
だから一番最初にこのやり方でこれだけやったら設備の50%の部分はあなたの仕事はほとんどしなくていいです。
じゃあ残りの50%に対してだけ見積もりしてくださいっていうことです。
クリス
これは標準化のゴールですね。あるいはゴール一つですね。
そうですね。
なるほど。これじゃあ見積もりのレターとか全部使っちゃうんですよね、最初的には。お金使っちゃうんですよね。
TomoyaTakahashi
そうです。こうなったときに再利用っていうのはたまたま再利用できたっていうことじゃ全然ダメなんですよね。
クリス
じゃあ次ちょっと変わったらなんで前回の50%なんで、今回の70%なんの?っていう。
あれだとだいぶ答えになっちゃうんですよね。
PLCの標準化とその目的
クリス
標準化できてないねということ、標準化。
TomoyaTakahashi
そのときにこの50%のこの部分は今回適用できないから今回30%だよねっていうのは見積もり時に分かっていればそれはそれでいいわけです。
クリス
なるほど。でもこれ分かる人で。
そうだね。
なんか面白いですね、これ。確かに標準化そもそも目的が何ですかということですね、最終的には。やっぱりお金ですね、最終的には。
お金です。
TomoyaTakahashi
お金だね。
お金と品質のお金ですね。
クリス
そうですね、お金の品質ですね。
TomoyaTakahashi
要は決められたタイミングで決められた量だけ決められたところにお客さんに決められたお金コストで届けるっていうことをやるにはどうするかっていう話ですよ。
クリス
なるほど。
品質、お金。
なるほど、大変勉強になった。
これはちょっとまたいさな繰り返しで聞いてみようかしちょっとすごい話ですね、これ。大変勉強になりましたよ、これ。
TomoyaTakahashi
これは今ソフトの話をしましたけど、これは電気ハードもそうだし機械設計も同じなんですよね。
クリス
下辺のところどこが、上辺のところどこのか。
そうですね。
これ組み合わせどうするのか。
なるほど。
最終的には全部お金につながる。
品質につながる。
TomoyaTakahashi
品質、お金、リードタイム、この3つのQCDですよね。QCDに全部つながります、最終的には。
コミュニケーションと今後の計画
クリス
なるほど。分かれました。大変勉強になりました。本当に大変勉強になりましたよ、これ。すごいいい質問です。
TomoyaTakahashi
というですね、ちょっと今もう1時間ぐらい喋ってるんですけど、この関係の中で。
クリス
すごいすごい。
TomoyaTakahashi
ちょっとね、多分今回分かりにくかったところは多分にあると思うんですよ。僕が喋っててまず分かりにくいなーって思いながら喋ってたんで。
クリス
でも今度なんかAのソフト、書きソフトで書きながらやったほうがよろしいですね、もう1回。
TomoyaTakahashi
そうですね、じゃあリアルにやった時にホワイトボード会をやりますか、一緒にね。
クリス
無印でホワイトボード買おうと思ってなかったね。
開きに行きます、今度は。
TomoyaTakahashi
はい、じゃあまたねこのソフトウェアの構造化っていうところはまたちょっとどっかのタイミングでね、クリスさんと僕でちょっと取ろうと思いますんで皆さん。
もし楽しみにしていただける方がいるんであれば楽しみにしておいてください。
はい、じゃあこの案件ここで終わります。ありがとうございました。
ありがとうございました。
