【後編】誰も書かなかったPLMの不都合な真実～PLM導入時のポイント～

前編はこちらからご覧いただけます。

執筆者 板東 司 プリンシパル PLMマイスター

PLM/BOMシステム導入を中心としたコンサルティングのキャリアを25年以上持つPLMマイスター。開発・設計・生産準備・製造領域における構想策定からシステム導入等のプロジェクト経験を多数有し、IT企画から導入・運用までのシステム導入ライフサイクル全般におけるコンサルティングとプロジェクトマネジメントを得意とする。

執筆者 京盛健一 シニアマネージャー

工学博士。研究機関にてバイオマス材料の研究開発と製品不具合の評価分析の技術支援に従事。その後、ITベンダーにてCAD／CAE／PLM製品の導入支援、MBDやMBSEのプロセス構築と実装支援に従事。オーツー・パートナーズ参画後は、設計業務改革の企画構想から業務やデータフローの可視化、設計品質の向上を実現させるための3D活用やプロセスの構築、それらのデジタル実装支援を中心に設計開発DXの実現に取り組んでいる。

この章では、実際にPLM導入を進める際の、押さえるべき要件のポイントを示して行く。

これまでも何度も示してきたように、PLM導入の大きな効果は、3Dを起点にしたコンカレントエンジニアリングの実現にある。では、3D導入の現状はどうかと言うと、図表43に示すように、多くの企業では、3D CADを使ってはいても、正データは2D（図面）であり、十分なデータ活用ができていない。これからは、3Dデータを元に、データを再入力することなしに連携する仕組みを構築する必要がある。究極の姿は、3Dデータのみとして、2Dを作らないことではあるが、サプライヤとの関係などあり、2Dなしでの運用は難しいことから、「3D正（3Dが元データ。必要なときに2D生成）」を目指すことが現実的ではないか。良くある失敗は、業務を急ぐあまり、2D図面上で赤入れをして現場に図面を流しておいて、元となる3Dデータが最新化されておらず、次に参照・流用するときに、誤ったデータを元にしてしまうことである。例え手間でも、そこをさぼってしまうと、3D正は実現できなくなる。

現在、CADベンダーが中心となり推奨・推進しているのは、「(3D)モデル」にあらゆる設計・製造情報を“込めて“、モデルさえあれば、設計意図が正確に後工程に伝わるMBD（Model Based Definition）、さらには、モデルを中心に全ての業務が廻るMBE（Model Based Enterprise）の世界である。図表44は、シーメンス社が描くMBD/MBEの世界である。

繰り返しになるが、現在図面中心で業務をしている企業が、一足飛びにMBEの世界を目指すのはハードルが高い。図表45に示すように、段階的に取り組みを進めるべきと考える。

3D化が進むと、図表31で示したように、開発・設計部門内だけでなく、営業部門や購買部門、保守部門など、各部門で3Dを活用したDXが実現できるようになる。

PLM導入において、最も議論が多く発生し、「正解」を見出すのが難しいのがBOMについてである。この件だけで、ゆうに数冊の本が執筆できるし、現に多くの本が出版されているが、ここでは「論点」を整理し、導入企業の皆さんが検討漏れを起こさないようにしたい（答えを出す所までは、本書の範囲とはしない）。 　まず、BOM連携の先進企業事例を示しておきたい。図表46のように、量産系の先進企業では、E-BOM/M-BOMの分離と連携、さらには拠点別M-BOMの生成までをPLMシステムで実現し、そこからEAIツールやPLMパッケージベンダーの提供する連携アダプタを介して生産管理システムへの連携を実現している。これにより、市場投入までのリードタイム短縮、市場変化への対応力向上を実現している。

また、個別受注系の先進企業では、標準E-BOMから受注E-BOM（製番BOM）の生成の仕組みを実現し、さらには標準E-BOMを利用した個別受注ツール（ETOシステム）の構築まで行い、標準品への誘導、受注～納入までの納期短縮を実現している（図表47．E/M連携、拠点別BOM、EAIツールの活用については、量産系と同様。拠点別BOMについては、図中では略） 。

BOM導入において、どのような論点があるかを示したのが図表48である。以後のページでは、それぞれの内容・ポイントを概観する。

①E/M分離について

E-BOM/M-BOMの役割・配置と情報連携方法について検討する必要がある。ここでは仮に、E-BOM / M-BOMの定義を以下とする。

• E-BOM：製品設計仕様を満足させる為の部品構成情報であり、最新の品番構成を維持、管理するもの
• M-BOM：E-BOMに、モノづくり情報（調達方法や工程など、経時的や場所によって変わる内容）を反映させたもの。製造場所やリソース情報（人・物・金）をも管理する。

このとき、一般的には、以下の４パターンが存在する（量産BOM/製番BOMの違いも含めると、さらにパターンが増えるが、ここでは量産型のBOM運用に限定する）。

1) M-M形：設計がPLM上にM-BOM登録、そのまま生産系システムへ連携

2) E-M形：設計がPLM上にE-BOM登録、製造が生産系システム上でM-BOM登録

3) EM-M形：設計と生技がそれぞれPLM上にE-BOMとM-BOMを、製造が生産系システムへ工程を登録

4) EmM-M形：設計と生技がそれぞれPLM上にE-BOMとマザーM-BOMを登録、各拠点の生技もしくは製造が拠点別にカスタマイズ後、生産系システムへ連携

これらのパターンと、そのメリット/デメリットを図表49に示した。どれが絶対に良い、という答えがある訳でなく、企業のこれまでの文化（例えば、「設計が現場を知らないことは有り得ない」と強く主張する企業もあるし、「設計は機能に専念すべし」という企業もある）や、それを踏まえた現行システムのありようも含めて、どのパターンとするか、検討する必要がある。

一般的には、梱包については「製品の機能・品質を担保するために必要なもの（輸送時の揺れ・振動での損傷を回避するための指示を記述した梱包仕様書等）」はE-BOMで指示し、「製造現場個々の都合に左右されるもの（例えば、輸送事情や輸送業者に左右される、段ボール箱詰めなのか、通い箱なのか、等）」はM-BOMで指示すべきと考えられる。また、素材（材料）や副資材（ウェスや仮止めテープなど）についても、「製品の機能・品質を担保するために必要なこと（例えば、鋼材材質：SUS304など）」はE-BOM（というか、一般的には図面）で指示し、「製造都合に左右されるもの（例えば、何メートルの板材から切り出すか？など、調達単位に依存するもの）」はM-BOMで指示すべきと考えられる。良く、1) M-M型の企業と、E/M分離の議論をすると、「設計が現場（製造）を理解しなくなる。設計は現場（製造）を踏まえて造りやすいものを設計すべき」という意見（反論）に出会うことがある。もちろん、設計が製造を踏まえて設計することは必要であり、現場（製造）と良くコミュニケーションを取って設計すべきであるが、製造に関する全て（すなわちM-BOM）を設計が指示することとは次元の異なる話で、分けて議論すべきと考える。さらに、BOMを分離 （E-BOM/M-BOM/P-BOM/S-BOM/…）すると、それだけ設計変更時の反映の手間が多くなるため、その点も留意する必要がある。

②CAD連携について

3D CADでは、モデル上で構成（アセンブリ）を持つことができる。したがって、理想的には、その構成からE-BOMを作成できれば、わざわざE-BOMを別途登録する必要はなくなり、連携するための手間や、手違いによるミスを減らすことができる。しかし、実際には、全ての設計対象をモデル化できなかったり（オイルなどの液体物、ワイヤーハーネスやパイプなどの軟性体、など）、材料を登録しようとすると、アセンブリとして不自然になったりするケースがある。一般的には、以下のようにE-BOMであるべきものは、できる限り3D CADでも（少なくとも）構成を合わせて、密連携できるようにするケースが多い（図表50）。

• 純粋な幾何/位相的な親子関係でないもの（前加工品のような、工程での前後関係）は、CADには構成させず、M-BOMで構成する（必要なら、「XXXの追加工も可」のように図面で指示する）。
• 純粋な幾何/位相的な親子関係で、モデリングの都合でサボる場合は、CAD上でダミーとして構成する。

③図面構成と品目構成

昔に構築した、図面ベースでの管理システム（すなわち、PDM）では、BOMツリーのキーが「図番」となっているケースが多い。図番のツリーが絶対ダメという訳ではないが、あるべき姿としては、BOMは「品番」のツリーであるべきと考える。理由としては、「図番」は設計内の用語であり、製造現場は基本「品番」で動いていることと、必ずしも品目と図面は１対１ではないケースがあることからである。例えば、ある品目の仕様を表すために、複数の図面が必要なケース（例えば、形状を表す図面と、版下の図面、など）がある。あくまでも、BOMのPM（Parts Master）は品目であり、図面はその仕様を記述する付属文書として捉えるべきと考える（図表51）。なお、「品番」＝「図番」としている企業もあり、その場合はこの議論は必要がなくなる。

④履歴管理について

BOMの履歴管理（品目（PM）の履歴、構成（PS）の履歴、付属文書の履歴）についても良く検討が必要である。PLMパッケージによって、図表52のように何種類かの方法がある（何れか選択、ということでなく、場合によっては組み合わせも有り得る）。利用シーン（目的・用途）や管理負荷を想定して、最適な方法を選択する必要がある。

⑤機番BOMについて

受注生産型の製造業では、マスターBOM（ひな形）と受注BOM（実際に顧客／受注に紐付いたBOM）とを分けて管理したい、というニーズがある。これを、「標準BOM」と「製番（機番）BOM」のように管理できる部品表システムがある（図表53）。技術的なことを言えば、通常BOMの品目および構成のキーは品番のみであるものに、キーとして「製番」を追加し、製番と品番の組み合わせでBOMを持てるようにしたものだ。

3-2節で示したＩ社の事例（図表26）のように、出荷後の機械の状態をしっかり管理し、どのお客様のどの機械のどの部品に交換時期が来ていないかを把握したり、サービスマンが出張先で間違いなく機械の状態を把握した上でメンテナンスしたりすることにより、個別受注型企業における収益の源泉である保守事業を円滑に進め、さらには「攻めの保守（例えば、コマツのKOMTRAXのような能動的なサービス）」を目指すために役立てることができる。

⑥工程設計について

当然のことながら、設計部門が製品を設計するだけでモノ造りができる訳ではない。設計された製品をどういう工程で製造するか、各々の工程でどのような設備を用いるか、などを決め、手配しないと製造には入れない。この製造に入る準備（一般に、生産準備と呼ぶ）をするために必要となるのが工程設計であり、それを具体的にBOMとして表したのが製造BOM（M-BOM）である。近年では、PLMシステムにてBOP（Bill Of Process）を定義し、それをM-BOMに連携できる仕組みも出てきている（図表54）。これを活用したBOM連携の仕組みを構築することが可能となっている。

⑦原価企画/見積りについて

量産型の製造業においては、量産前に製品の原価を作り込み、売価とのバランスを取って、しっかり利益につなげなければならない。また、受注生産型の企業では、商談時に顧客仕様から製品仕様を詰めて、根拠のある見積りを提示しなければならない。このような原価企画や製品見積りの際に、PLMのBOMを活用することができる。

例えば、原価企画においては、BOMを利用した原価積み上げを中心に、正しい原価改善目標を設定し、それに向けた原価低減活動を推進する。原価情報、原価低減ノウハウを社内で蓄積・共有・活用することにより、一層の原価低減につなげることができる（図表55）。その推進のポイントは、

などである。

最新のトレンドとして、受注設計型企業において、さらには、多品種少量生産が求められる量産型企業においても、仕様に応じた設計を迅速に、できるだけ少ない工数で対応することが求められている。こういったニーズに応えるために、「ルールベース設計」の仕組みが用意されている。一例として、シーメンス社の提供するRulestream^®では、一般的な営業コンフィグレータとは一味違う、個別受注にも対応できる設計支援システムが構築可能となっている（図表56）。Rulestream^®は、PLMとも連携することが可能である。

このような仕組みを使って、営業シーン（お客様との仕様調整・見積もり）から、3Dモデルや図面、BOMの生成まで、一気通貫で流す仕組みが構築できる（図表57。画像はシーメンス社ホームページより引用）。

自動設計までは行かないでも、多品種少量生産への対応や、仕向け地違い・仕様違い・色違いなどのバリエーション設計への対応の仕組みとして、150% BOM（Super BOMと呼ぶ場合もある）が用意されている。CADデータと連携した150％ BOMでモジュールを管理することで、効率的なバリエーション対応が可能となっている（図表58）。150% BOMから生成した100% BOMは連携管理されているため、基本（共通）モジュールの変更を仕向機開発へ効率的かつ漏れなく確実に反映することができる（図表59）。

製品の複雑化は益々加速し、より高度な設計開発力が求められる中、CSR観点での情報トレーサビリティーの確保、ベテランの有するノウハウの継承、自社の独自性を活かした発想力を強化する上でも、設計プロセスにおける意思や意図、判断や根拠が形式知として蓄積＆共有されている事が、企業価値を高める上で重要になる。そこで本項では、設計に関するナレッジ蓄積に有効な一つの手段としてRFLP連携に注目し、その機能概要とポイントについて紹介する。

RFLPとはR＝要求、F＝機能、L＝論理、P＝物理の頭文字を意味し、それぞれを構造化しモデル化して連携させるデータ管理の方法である。また、各モデルが持つ情報やパラメータを連携および管理することが可能となっており、設計に関する情報のトレーサビリティーを確保することが出来る（図表60）。

RFLPモデルを構築し、設計に関わる情報群のそれぞれの関連性を可視化できることで、例えば、要求事項の一つに変更があった際、どの機能に影響を及ぼし、それを構成するコンポーネントに影響があるか、どのテスト項目を再検証する必要があるか迅速に特定することが出来る。また逆に、あるテスト要件が満たされない場合に、どの機能、どの要求にまで影響が及ぶかを確認することができる。

また、RFLPモデルを構築する事で、設計ツールとの連携を行う事ができる。図表61に国内で流通しているPLMパッケージにて主に実装されている機能の一部を紹介する。例えば、RとFモデル間の繋がりをQFDとして利用したり、FモデルをFTAやFMEAと連携することができる。RFLPのモデル内容やモデル間の連携に変更があった際、各設計ツールと連携していることで、RFLPモデルのある箇所の変更に伴って再検討や再検証が必要なモデルを特定することができる。高度で複雑化する製品開発において、経験に基づいた影響範囲の特定やレビューだけでは、対策箇所に抜け漏れが生じる事が想定されるが、RFLPモデルを構築し利用することで、そこをシステムにて補完することができるようになる。

これまで、PLM導入においての押さえるべきポイントをいくつか列挙してきたが、皆さんの企業でシステム企画を始める前に、現在地点を把握する客観的なアセスメントを実施してみてはどうか？我々は、3Dへの取り組みに限定した3D活用度のアセスメントや、ECM力を広く見るECMクイックアセスメントなどの手法とツールを用意している。

①3D活用度のアセスメントとプロセス改革方法論 我々の提供する3D-DPRM^®（3D-Development Process Renovation Methodology）は、グローバル競争に打ち勝つ強固な製品開発基盤を構築していくための、「3次元製品開発プロセス改革方法論」である。3D-DPRM^®は、「6σ（シックスシグマ）活動」 の考え方を取り入れ、ITと業務プロセスの視点から、製品開発プロセスのリノベーションを実現することを目指している（図表６２）。改革に着手する前に、まず、各社の3D活用度を正確にアセスメントすることから始める。現状を正しく把握し、有効な施策を策定することから、改革の第１歩が始まる。

現状を調査・分析した後の施策マッピングでは、以下のような改革ステップを定義している（図表63）。このステップの中で、自社がどの位置にあり、どこを目指すべきかを具体的に合意してから改革に着手する。改革内容そのものについては、本書では主旨に沿わないので割愛する。

3D-DPRM^®は3D開発にスコープを絞ったものであるが、より広く「開発・設計力」を把握するための簡易なアセスメントも用意している。ECMの取組レベルを、19項目×5段階にて評価して、他の企業（業界トップランナー）と比較して、自社の実力値を示し、取り組むべきテーマを導き出す（図表64）。この例では、「要件・要求管理」、「解析主導型設計」、「モジュラーデザイン」、「コンカレント化」、「PLM導入」、「3D CAD導入」、「3D活用」の６つを取り組み対象としている。

ここまで、PLMの概要、導入失敗事例、導入成功のコツ、導入の際のポイントなどを見てきた。最後に、PLMシステム（パッケージ）への要望（提言）を挙げて、本書のまとめとしたい。

まず、１章でも記載したが、現在のPLMパッケージおよびPLMパッケージを使用したPLMシステムでは、いわゆるECMの領域だけをカバーし、本来のPLM（Product Lifecycle Management）になっていない点の改善を望む。すなわち、ひとつのシステムで、ECMとSCMの両方の領域をカバーして欲しい。現在、PLMシステムのユーザー（主に設計者）から多く出る要望として、「生産の現状（今、部品の手配や製造がどこまで進んでいて、いくらかかっているのか）を知りたいが、その情報はERPシステムにあり、自分達設計者からは見ることができない」という声が多い（図表65）。それだけのために、全設計者にERPのライセンスを配布することも考えられるが、それはあまりにも高価となる。各社、それをカバーするために、夜間バッチでERPから手配情報や原価情報をPLMのBOMに連携する仕組みを作ったりしているが、システム負荷が高かったり、全ての原価を設計者に公開することはできない、という組織（意識？）の壁があったりして、思ったように実現できていない。PLMとERPが一体となったパッケージがあれば、こういった問題は解決できるようになるのではないか？もちろん、ライセンス価格の問題や、あまりにも巨大で複雑なシステムとなるため現実的ではない、という見方もあるとは思うが、これができれば、本当の意味でのProduct Lifecycle Managementに一歩近付くのではないか。

次に、OOTBで導入するにしても、導入までにあまりに多くの決めるべきこと（スコープ（導入オプションもしくは機能）、運用、設定項目）がある。もちろん、最終的には全てを決めて行かなければならないのだが、一度に見通すことができる範囲は限られている。そこで、スモールスタートで必要最小限の範囲から導入し、運用設計→トライ→修正のサイクルを廻しながら、徐々に範囲を拡げて行けるような製品およびスキーム（契約形態）があることが望ましい（図表66）。ただし、導入側も、これまでのような一括の開発承認稟議を行い、ライセンスを購入し、開発に入る形ではなくなるため、どのような単位で費用や効果を説明していくかが課題となるだろう。

おわりに

ここまで、筆者の経験から、PLMとは何か、PLM導入の失敗事例、失敗しないPLM導入のコツ、PLM導入時の要件のポイント、将来に向けての提言などを記してきた。これらが、PLM導入を検討・推進している読者の皆さんの参考に少しでもなればうれしい。

本書執筆に当たり、全面的に作成を支援し、有用なアドバイスやコンテンツを提供頂いたオーツー・パートナーズの皆さんや、パートナーの皆さんには感謝の意を表したい。また、これまで多くのPLM導入において、多くの成功や失敗を共有してきたクライアントの皆さんにも、この場を借りて感謝の意を伝えたい。

今後、PLM導入に関わるベンダーの皆さん、クライアントの皆さんが多くの成功を共有できることを祈って、筆を置くこととする。ご精読ありがとうございました。