特別対談インタビュー
【特別対談②】PLMとBOMの重要性と日本製造業の課題
②PLMとBOMの重要性と日本製造業の課題
太郎氏：今のような話をやるにしても、BOM構造をしっかり持っておかないといけないということですね。
LIGHTz：はい、理想は、BOMと連携させてより質の高い情報を引っ張ってくることです。
太郎氏： そもそも日本ではほぼBOMの整理をやれてないのが現状です。私もいろいろな企業から依頼されて話を聞くのですが、結局システムがサイロ化されていて、BOM構造がバラバラです。
これができたとしても、原価が分からない、コストも整理されてないということになっていて、「blooplinter」を導入して過去との差分が分かったとしても、結局原価が分からないからどれが正しいのかということが分からない。だから、BOM構造を整理するというPLMのそもそもの正しい姿を描いた後に入れると効果が最大化しますね。未来のソリューションというか PLMの次を目指したものだよね。
LIGHTz：確かに3Dデータを起点として、取ってくるエンジニアリングデータはPLMを介して取ってくるとしても、先にそこが整備される必要があります。
太郎氏：整備されていないと最大効果がでない。もちろん過去との比較ができるから、それはそれでとても素晴らしいですけどね。
LIGHTz：使い方がちょっと限定的になってしまいますが、過去に関してはそうかと思います。今、開発行為をこの中で行うことができるようにしているところです。ある意味、今まで開発過程とか行為は「消費」でした、それを「貯金」にするイメージです。
太郎氏：開発過程を貯金にするとしても、いい設計であればいいと思うけれど、それをどう判断するのですか？
LIGHTz：過去の失敗した設計っていうのを学びの材料として取るかどうかですよね。
太郎氏：そう、だからその設計情報も失敗だったっていうことを登録しないといけないですよ。蓄積だけど、その蓄積がナレッジなのかどうかっていうのは、ナレッジにする要件定義が必要で、結局そこはどのようにコントロールしていくのですか。
LIGHTz：私も設計者なのですが、トランスミッションの設計などをやっていて、ミスしたりしたものは、タグ付けで分けるっていうところまでのアイデアはあるのですが、まだ実装には届いてないです。
太郎氏：上流なんて全くできてないから、結局その設計が正しかったかどうかってことは、後になってみないと分からない。だから後になってみないと分からないうえに、その情報もないということになる。
LIGHTz：「過去にこういうことがありました」という途中までの情報でも引っ張ってこられることに対して、本当に価値がないのかというと、それは同じ道を辿って過去の情報が見つかるっていう意味では価値があると思います。正しい、正しくないという情報を出す、吐き出すというよりは「過去にこういう過程を通った」という情報に対して意味はある。
太郎氏：そうだね。どういう風に設計したのかという思想が分かるから、その製品だけじゃなくて過去の製品が「どういう技術の延長線上でデザインされたか」っていうことが分かれば手助けになると思う。
LIGHTz：それが分かるだけでもかなり違うと思います。例えば３～４アイテムを検討するじゃないですか、その際にある不具合が起きて、その先に3パターン4パターン形状を考えて走らせたときに、どれがうまくいったのかという情報が残っていれば、次に同じことを考える技術者は、どうすればいいのかがすぐに分かるわけです。
太郎氏：そこが見えるだけでも、引き継ぎしたときに「これはどうやって設計するの？」ということにはならない。要するに「そこは私にしか分からない」みたいな人たちはもういらないと。そういう時代じゃないから「そこが分かる」というだけでも素晴らしいですよね。
LIGHTz：最終的にナレッジ情報が紐づいていることを目指しているので、やっぱりPLMが先に整備されていてほしいですね。
太郎氏：そうですよね、PLM導入とはウィンウィンの関係にありますね。弊社でPLM要件定義と、BOMの整理、クレンジングをしているので、そことの連携もありますね。
LIGHTz：この形状認識は他社にないものでこだわっています。他の3Dソフトの類似検索は、結局3Dデータをきちんと扱って検索しているわけじゃなくて、多面的に画像を撮って画像AIで認識させて、それを「3D検索です」と謳っているソフトも結構多いです。それで似たものを引っ張ってくるのは、それはそれでいいと思います。でもそれだと3D CADにいろいろと付加された情報が全然活かされていないです。
太郎氏：エンジニアリング情報に焦点当てているわけですね。形状ではなくて、その後ろの「思想」も読み取ってあげて、認識をさせているってことですね。だから価値がある。類似だけではなくて、じゃあ「どうしてその形状になったのか」っていうことも分かるような助言をしてくれる。この形にも理由があるから、「どうしてその形になったのか」が分かる。
LIGHTz：形の意味がしっかり繋がってくるところ大きな意味があります。
太郎氏：エンジニアはモデリングするときにはそこが必要ですからね。「なぜこの形状で、なぜこの絞りプレス形状になったのか」とか、「強度計算どうなっているのか」とか、必要なのはそういう情報です。この手のソリューションのユーザーがよく間違えるのは、装置部品の加工じゃないという話で、これは強度計算とか人の命を預かるようなものに対するエンジニアリングだから全く属性が違うよって話。そこを混同して考えてはダメですよ。
LIGHTz：また、こういうことができると、製品カテゴリーをまたいで、ぱっと見の形は全然違うけれど、「同じ工程」を持っている、「部分的に同じ形」を持っているみたいな情報で引っ張って来てくれるので、さらにBOMなどがきちんと整備されていると、とてもやりやすい。
太郎氏：やりやすいし最大化するよね。そのBOM構造を整備するっていうのが、マジで日本の課題だと思います。BOM構造を整備できている企業なんてほとんどないと思う。
LIGHTz：グローバルでは当たり前になってきているのに、なぜ日本はそんなに少ないのですかね。
太郎氏：なぜかというと、過去に「二次元図面」で世界に勝ったからですよ。「ジャパン アズ ナンバーワン」で、その生産技術で勝ったわけです。複雑性のある産業では日本はずっとナンバーワンなわけです。
3Dでモデリングするのだけど、そこから生産準備に移管するときに生産準備とか生産技術は何でコントロールするかというと、現場を二次元図面でコントロールします。だから原価やPDMで吐き出したときのBOMに対して、エンジニアリング情報が紐づかないのです。
例えば加工パスとか加工方法、チャッキング方法とかリンク情報は全部二次元図面に集約します。二次元図面が我々日本の「擦り合わせ」と呼ばれているコミュニケーションツールです。過去にそれで勝ってきて、その手法から脱却できないわけですね。勝ったがゆえに捨てられないわけです。
一方でPLMの世界というのはBOM戦略を基軸として情報を紐づけするので、そもそも戦っている武器が違います。我々は、日本というのは現場寄りで戦って、それで世界を制覇したわけですよ。だから未だに、二次元図面に対して情報が紐づいている。だからBOM主体ではなく、二次元図面主体のコントロールだったのです。ある企業では150人くらいパートの方が出社して、二次元図面に転写しているわけです。だからPLM導入になると、そもそもQCDコントロールするのがBOMじゃなくて二次元図面です。
LIGHTz： 確かに工程とかそういうのも書いて、突っ込んでいますよね。
太郎氏：かつ、そのBOP情報も本当はマスタードなBOM構造を持って、そこに対して工程を紐づけないといけないから、BOPを二次元図面から展開していくわけですよ。だから、情報がそこで分断されてしまいます。分断されるから情報が紐づかない。
それで勝ったから立ち戻る先はBOMではなく、二次元図面なのです。だからPLM導入となっても、そもそもBOMは整理されていないし、各部署で個別にサイロ化されたシステムがあるからうまくいかないわけです。
そして、BOMはじゃあ分かった。PLMをやりたいと言って導入しようとするのですが、まず上の人が理解していない。なぜなら二次元図面で勝ってきたから。そのPLMをBOM中心として入れるという構想をそもそも理解できないから、情シスや生産技術の一部門に対して「お前らやれよ」となるわけですが、BOM戦略って横断しているからとても苦労します。
例えばさっきのシステムの話でも「購買システム」、そして「生産技術システム」、「生産管理システム」とあって、それを一つのBOMとして軸を通すためには各部門の調整が必要になるわけです。でも各部門の生産技術や情シスには、そこまでの権限がないわけだからサイロ化する。そして「じゃあ生産技術のここのシステムだけをやりましょうか」みたいな話になっちゃって、全体最適化にはならないのです。
構造的なジレンマが日本はあるからPLMシステムがいつまで経っても入らないし、サイロ化されたものを「じゃあ仕事のやり方を変えましょう」と言っても、その責任の所在も曖昧になっている。やったところで「お前が何かやったから、このシステムが上手く動かない」みたいなことになるわけです。これが日本のPLMが進まない最大の理由です。
LIGHTz：そうするとほぼDX部門みたいな所は何もできないっていうことですよね。
太郎氏：そもそも横断してDXだと言っているけれど、じゃあBOM構造を分かっているかというと分かっていないですよ。まずやらないといけないのが、業務の改善点を明確にした業務フローの定義です。
これって、フワッとしていて耳障りがいいけれど、要するにQCDの何をコントロールしたいかです。「クオリティ」なのか「コストを下げたい」のか「開発のリードタイム」を短くしたいのかっていう。製品としてカメラがあったとして、カメラで何をコントロールしたいのかという話です。「クオリティですか?」、「デリバリータイムですか?」、「それともコストですか?」。まず、そこが描けていないのが問題です。例えばある業界は、デリバリータイムを短くしたけど、バケツリレーでやっているから失敗しているわけですよ。
LIGHTz：効率の問題もあって、時間が足りない。
太郎氏：あれは本質的には「デリバリータイムを短くしたい」ということだったけれど、そもそもその改革点を明確にせずに、バケツリレーだけ早くしましょうという風にやったから失敗したわけです。そのデリバリータイムを「3年かかっていたものを1年半にしましょう」って言ったら、そのためにBOM構造を変えないといけない。さらにその仕様・部品・工程・設備。マスターデータのデザインをそれぞれ機能・性能・重量・形状・寸法・サプライヤーコストとか、そういうテーブルがあるから、そのデザインをしてあげて、各部分が必要な情報をデータ単位にする。
例えば開発・設計BOMであれば商品があって、各モジュールがあって、そのモジュールに対してソフトウェアがあったりとか、加工部品があったりとか、メカ要素があるわけです。そのユニット単位で定義しないといけないし、逆に営業であればモジュールの型番とモジュールの仕様とモジュールのコスト・デリバリータイムが分かればいいわけです。
一方で製造BOMはそうではなくてサイクルタイムなどで工程が分かれる。調達は含有物とかサプライヤーのコストとか。要するに部門ごとでBOMのデザインが違います。データのデザインが違うから、そのデータ単位を決定した後、調達ではどういったデータレイヤーでどんなデータを見せたらいいのか。そして、設計であれば設計のBOMがあるはずです。これらを明確化して、定義してからやっとBOM構造の整理ができていく、そうしないと成功はしないです。
LIGHTz：それができていると我々の「blooplinter」も威力を発揮できますね。情報が整理されていないと「blooplinter」で3D検索できても、よりたくさんの良い情報は引っ張れないですから。
太郎氏：構造が最適であったとしても、作りやすい形状だということと、その設計が良いのか悪いのか、そしてその原価が分からないとダメです。
LIGHTz：「情報を引っ張ってきます」という話をしたのですが、過去の情報はBOMと繋がっていないと持ってこられないし、それを持ってきたところで、使いこなせる人が日本にどれだけいるのかという問題があります。例えば引き当てた情報を見て、「あーなるほどね」と気づいてパパッと思考が繋がっていく人がどれだけいるか。
もともとは、ものづくりの現場、エンジニアリングチェーン向けの設計と生産技術というところをつないでいくソリューションでもあるのです。全部の最適情報が入ってきて、最適なコストが出てきて、その情報をもとに思考を回せる人が現場にいるのかというのが、もうひとつの課題だと思うのですが。
太郎氏：それは要するに、見えるデータを管理してあげた方がいい。設計に対して、そんなにいっぱいの情報を与えなくていいわけですよ。「過去にこれくらいのコストで作りましたとか、設備がどうでした」くらいでいでいいわけですよ。
LIGHTz：ある程度の必要な情報が、必要なところに、必要なだけ届くみたいな感じですね。あと私たちが大事にしたいのはコミュニケーションをさらに活発化しないと日本は勝てないということです。生産技術と設計が対話しないと勝てないと思います。
| 次のページ ＞＞ |
【blooplinterについて】
【YouTube】
