第1回では、PLM導入の目的設定と、その土台となる製品データのマスター管理について解説しました。出図データのマスター管理が回り始め、正はPLM上のデータであるという認識が共有できたら、次はそのデータを各工程で使い切る段階に入ります。 第2回では、データを全工程で共有して並行作業を可能にする「データ一気通貫」への移行と、その先で管理の幅を広げる「部品表連携」の始め方について解説します。部品表連携は必ずしもデータ一気通貫の前提条件ではありません。製品データの共有ルールが整えば、部品表の整備を待たずに着手できる部分があります。順序を分けて説明します。 われわれ南国ソフトのPLMサービスの責任者は自動車メーカー2社で設計実務経験と設計開発部門へのCAD/PLM推進を担当し、さらに複数のCADベンダーでお客様のCAD/PLM導入や業務改革を支援してきた実績があります。その長年の現場経験を元に、理想論にとどまらない実践的なアプローチをお伝えします。
心理的ハードルを下げるデータ共有ルール
製品データのマスター管理が回り始めたら、次に視野に入るのが「データ一気通貫」です。これは、企画・構想の段階から製造、販売、保守に至る各工程が同じデータを参照し、並行して作業を進める状態を指します。単にデータが共有されているだけでなく、各工程が同時に動けている状態（いわゆるコンカレントエンジニアリングが出来ている状態）が目標になります。
そのためには、完成前のデータを公開する必要があります。正式に出図する前の検討段階の図面や3Dデータを、関係部署が参照できる状態にするということです。ところが、最初のこの一歩で止まってしまうことがよくあります。作成者の立場からすると、検討段階のデータを見せることで各部署から要望や指摘が集中し、形状を変えた経緯を問われる場面も増えます。それならば固まるまで出さないでおこう、という判断につながり、公開の時期が後ろに倒れていきます。
ここを越えるために有効なのが、データの状態を明示する仕組みです。PLM上のCADデータに「検討中」「設計中」「出図済み」といったライフサイクル属性を付与し、それぞれの意味を利用者全員で共通認識にします。検討中は設計方針が固まっておらず大きな変更の可能性がある、設計中は方針は決まったが詳細設計の途中である、出図済みは出図を経たものである、という定義です。参照する側は属性を確認することで、検討中のデータを見て型設計に着手するのは避けよう、といった判断ができるようになります。第1回で触れた、承認済みのデータは一般ユーザーが移動・削除できないようにするといった権限設定の考え方を応用し、検討中のデータは設計部門と生産技術部門のみが参照できるようにしておけば、意図しない使われ方をより確実に防げます。
ただし、属性を定義しただけでは足りません。その属性が付いたデータをどう扱うかについて、作成する側と参照する側の認識を揃えることが要点になります。データの状態に応じて何をして良いのか何を控えるべきかを具体的に整理し、データを扱う側のリテラシーを高めていくことが公開を進める条件になります。
「部品表連携」の対象を製品開発のE-BOMに絞り込む
部品表連携は30年以上前から必要性が指摘されながら、いまなお多くの企業が取り組みの最中にあるテーマです。頓挫する要因の多くは、複数のシステムと業務要件を一度にまとめようとする点にあると考えられます。また運用の実現性も忘れ去られがちです。
ここで本稿の対象を整理しておきます。まず最初に念頭に置いているのは製品開発の工程で扱う設計部品表（E-BOM）です。調達用の品目リストや生産管理の部品構成表、製造部品表（M-BOM）は、この段階では対象外とします。
さらに、E-BOM自体も二つに分けて捉える必要があります。ひとつは、ERPや社内の既存システムで管理されている、出図を経て内容が確定したE-BOMです。もうひとつは、開発の途中にある構成、いわゆる設計BOM（仕掛BOM）です。前者は既存システムがマスターとして機能しており、業務も成立しているケースが多いと思われます。一方で後者は、担当者の手元の表計算ファイルやCADの組立構成に留まり、組織として管理されていないことが多い領域です。この二つを区別せずに「部品表連携」として一括で議論すると、話が噛み合わなくなります。
もう一点、着手前にお勧めしたいのは、自社で「部品表」と呼んでいるものの棚卸しです。用途も呼称も異なるものが同じ言葉で語られていることが少なくありません。ここで必要なのは統合ではなく、対応関係の把握です。それぞれのリストで名称が違っていても実質は同じ部品番号を指している、という程度まで整理できていれば十分です。
そのうえで、まずは敢えて確定したE-BOMをPLMに取り込みCADと紐づけることから着手することをお勧めします。設計BOM運用の不安定さを排除し、確定したE-BOMとCADとの紐づけ作業のプロセスが成立するかを見極めます。ここでの目標は部品番号などで自動で紐づかせることです。自動紐づけが上手く行かない場合は、CAD側の属性や部品構成の持ち方を再考する必要があるかもしれません。
そこが上手く行ったら、次は設計BOMへと範囲を拡張していくのが良いでしょう。BOMの運用とPLM内での操作という2つの不確定要因に一度に取り組むのは失敗のリスクを高めてしまいます。当初取り込む確定E-BOMもバリエーションなど多数存在するでしょうが、1種類から始め、運用が成立することを確認したうえで範囲を広げていきます。
部品表オブジェクトの充実
部品表オブジェクト（WindchillでいうWTPart）にCADデータを関連付けられる状態になったら、次はそのオブジェクトに紐づける情報の種類を増やしていきます。部品表は、製品に関する情報を集約する枠として機能させることができます。
最初に取り組みやすいのは文書類です。設計書、仕様書、検討結果をまとめた資料、試験報告書、取扱説明書といった文書は、PDFや表計算ファイル、文書ファイルの形で各部署が個別に保管していることが多い領域です。これらをPLMに登録し、該当する部品表オブジェクトに関連付けます。そうすると、部品を起点にして、その部品がどの仕様に基づいて設計され、どのような検討を経て決まったのかまで辿れるようになります。第1回で述べた命名や属性のルールは、CADデータだけでなくこれら文書類にも同じ考え方で適用します。
次の段階としてお勧めしたいのが、CAEなどの検証データの関連付けです。解析の結果そのものに加えて、どの部品のどのバージョンの形状を用いた検証なのかを対応付けておきます。これができていると、部品の形状に変更が入った際に、その部品を対象とした検証をやり直す必要があるかどうかを判断できるようになります。関連付けがない状態では、過去の検証結果が現在の形状に対して有効なのかどうかを確かめる手立てがありません。この点は第3回で詳しく取り上げます。
注意点として、関連付ける対象は最初から広げすぎないことをお勧めします。登録の手間が増えるだけで参照されない情報が積み上がると、運用そのものが続かなくなります。どの文書を対象にするか、誰がいつ登録するかを決めたうえで、対象を順に増やしていく形が現実的です。近年は蓄積した文書をAIで検索・要約する取り組みも進んでいますが、その効果も、どの部品に関する文書なのかという対応関係が整っていることに左右されます。
この積み重ねが進むと、設計BOMをPLM上で管理して確定時に既存システムへ渡す形へ切り替える、E-BOMとM-BOMの関係を定義する、設計変更を関係部署へ確実に伝達する変更管理を運用する、といった次の段階に手が届くようになります
データ中心の仕事へ移行するプロセス改革
マスター管理の推進にあたっては、データの登録・蓄積と並行してデータを実際に使い切る仕組みを整えることが極めて重要です。ここで鍵になるのは、コンカレントなデータ活用によって生まれる利点を、データを作成した側にも還元することです。後工程からのフィードバックを早い時期に受け取れる状態は本来歓迎されるものですが、設計の進捗や成熟度に見合わない細かい指摘が届けば逆効果になります。フィードバックの内容と時期を、設計段階に合わせてあらかじめ定めておく必要があります。あわせて、出図から現物が出来上がるまでの期間が短縮される分、出図の時期そのものを後ろへ動かすといった業務プロセスの見直しも検討対象になります。
コンカレントエンジニアリングの組み立てには分析が必要です。作業の並列化は手戻りのリスクを伴いますので、DSM（Design Structure Matrix）などを用いて現状の作業の依存関係を可視化し、同時に進めた効果が大きい作業と、前工程が確定してから着手すべき作業を切り分けたうえでプロセスを再構築します。
並行して進めるうえでは、参照しているデータが更新されたことに気づける状態も欠かせません。金型設計のように設計部門の製品データを参照して進む業務では、参照元に変更が入ったことが速やかに伝わるかどうかが成否を分けます。ここはPLMの機能が効く領域で、誰がどのデータをいつ変更したか、あるいは変更しようとしているかを把握できます。前述した部品表オブジェクトへの紐づけができていれば、これから加える変更がどの範囲に影響するかを事前に確認することも可能になります。もっとも、実務は人と人のやり取りで進むものですから、システムだけに委ねず、日常的に状況を共有しておくことの重要性は変わりません。
自動車メーカーでの経験が活きる、現場に即したプロセス改革支援
データ一気通貫と部品表連携は、システムを導入すれば実現するものではなく、部門をまたいだ業務プロセスの見直しを伴います。どの段階のデータをどこまで公開するか、どの部品表から着手するか、部品表オブジェクトに何を紐づけるかといった判断は、製品の特性や組織の事情によって変わります。
南国ソフトは、自動車メーカーの開発現場でこうしたプロセスの移行を実際に進めてきた経験を有しております。部門間で調整が必要になる箇所も、そこで何が論点になるかも把握しておりますので、御社の実情に照らした進め方をご提案できます。
現場目線の確かなサポートとUXUIを基軸とした技術力で、御社のPLM推進を支援いたします。ぜひお気軽にご相談ください。
お問合せはこちらから
南国ソフトは2026年1月からPTC社のパートナーとして活動しています
