PLMシステム導入の実務——図面・部品データを一元管理する仕組み

PLM(Product Lifecycle Management)という言葉を初めて聞いたのは、二社目に転職した直後だった。前職は図面をファイルサーバーのフォルダで管理する、いわゆる「フォルダ管理」の会社だったので、正直なところ「PDMやPLMなんて大手が使う大げさな仕組みだろう」と高をくくっていた。ところが実際に導入プロジェクトのメンバーに巻き込まれてみると、これがとんでもなく地味で、とんでもなく効く仕組みだと痛感することになる。図面のバージョン管理、部品表(BOM)との連携、変更履歴の追跡——どれも「あるある」の現場トラブルを潰すための機能だった。

この記事では、実際に中堅製造業でPLM導入プロジェクトに関わった経験をもとに、導入の実務でつまずくポイント、フォルダ管理からの移行で起きる混乱、そして「入れて終わり」にならないための運用設計を、できるだけ具体的な数字とエピソードを交えて書いていく。ツールのカタログスペック比較ではなく、現場でどう転がるかという話に絞っている。

フォルダ管理の限界を数字で見る

念のため補足しておくと、私は別にフォルダ管理を全否定したいわけではない。設計者が3〜4名程度の小規模チームであれば、命名規則さえ徹底できていればフォルダ管理でも十分に回る。実際、私が経験した中で一番小さかった現場は設計者2名の町工場に近い会社だったが、そこではPLMどころかPDMすら導入せず、Excelの図面台帳とフォルダ管理だけで問題なく回っていた。人数が少なければ「誰が何をやっているか」を口頭で把握できてしまうからだ。

問題が顕在化するのは、設計者が10名を超えたあたりからだと感じている。加えて、外注設計者や協力会社が図面データにアクセスする機会が増えると、フォルダ管理の限界は一気に露呈する。私が経験した会社では、外注先3社に図面を渡す際、毎回メールでZIPファイルを送るという運用をしていた。これが原因で、外注先が古いリビジョンのまま加工を進めてしまい、量産初回のロットで寸法不良が発生したことがある。手戻りコストは部材費と再加工費だけで80万円ほど、納期遅延によるペナルティも含めると100万円を超える損失になった。この一件が、経営層にPLM導入の予算を認めさせる決定打になった。

PLM導入の是非を議論する前に、まずフォルダ管理がどこまで持つのかを見ておきたい。私が最初にいた設計部門は設計者が12名、年間の新規図面が約1,800枚、改訂図面を含めると年間3,000枚以上が動いていた。ファイルサーバーのフォルダ構成は「案件番号/機種/ユニット/図番」という4階層で、ルールとしては悪くなかった。

ところが実際に運用すると、次のような問題が毎月のように発生した。

• 最新版のつもりでコピーした図面が、実は1つ前のリビジョンだった(発生頻度:月2〜3件)
• 同じ図番のファイルが「_最新」「_final」「_final2」と複数存在し、どれが正か判断できない
• 設計変更の履歴が個人のメールやチャットに散らばり、誰がいつ何を変えたか追えない
• 外注先に渡した図面のリビジョンと、社内で更新した最新版が食い違う

これらのトラブルにかかっていた時間を試算すると、設計者1人あたり月に4〜6時間程度、「これ、どっちが正しいか確認して」というやり取りに費やしていた。12名で月50〜70時間、年間で言えば600〜840時間、人件費換算で数百万円規模の無駄が発生していた計算になる。この数字は上層部を説得する際の材料としてかなり効いた。感覚論ではなく「探す時間」「確認する時間」を工数として可視化することが、PLM導入の稟議を通す第一歩だった。

PLMとPDMの違いを実務目線で整理する

導入検討の場でよく混同されるのがPDM(Product Data Management)とPLMの違いだ。ベンダーの営業トークでは「うちはPLMです」と言われても、実態としてはPDM相当の機能しか使わないケースが大半だった。

PDMは図面・3Dモデル・部品表といった設計データの一元管理とバージョン管理が中心。対してPLMは、企画・設計・調達・製造・保守・廃却までの製品ライフサイクル全体を対象範囲としており、原価管理やサプライヤー連携、品質管理(不具合トラッキング)まで含む思想になっている。

現場感覚で言うと、設計部門単体で導入を主導する場合はPDM機能で十分なことが多い。PLMをフルスペックで導入しようとすると、生産管理・品証・購買部門を巻き込んだ全社プロジェクトになり、予算も期間も跳ね上がる。実際に私が関わった案件では、当初「PLM導入」と銘打っていたが、最終的にはPDM機能(図面管理・部品表管理・変更管理)を中心に構築し、原価管理や保守情報との連携は「フェーズ2」として先送りした。これは正しい判断だったと今でも思う。最初から全部を狙うと、要件定義だけで半年以上溶ける。

導入プロジェクトで実際に起きた混乱

移行データのクレンジングが想定の3倍かかった

フォルダ管理からPLMへの移行で一番時間を食ったのは、システムの設定ではなく「既存データの整理」だった。過去10年分の図面、約2万枚をPLMに取り込む計画だったが、いざ棚卸しを始めると、命名規則が守られていないファイルが全体の3割ほど存在した。図番の後ろに手入力の日付が付いていたり、拡張子違いのファイルが混在していたり、そもそも図番が振られていない試作図面が大量に出てきた。

当初「移行作業は1ヶ月」の見積もりだったが、実際には3ヶ月かかった。教訓としては、移行前のデータクレンジングにこそ十分な工数を確保すべきで、ここをケチると本番稼働後に「PLMに入っているデータが信用できない」という最悪の評判が立ってしまう。一度この評判が立つと、現場は結局フォルダ管理に戻ろうとする。これがPLM導入の最大の失敗パターンだ。

設計者の入力負荷への反発

もう一つ大きかったのが、設計者からの反発だ。フォルダ管理時代は「保存」ボタン一つで終わっていた作業が、PLMでは属性入力(材質・重量・仕入先候補・変更理由など)が必須項目として増える。ベテラン設計者からは「入力に時間がかかって図面を描く時間が減る」という不満が噴出した。

これに対しては、必須入力項目を最小限(図番・名称・改訂理由の3つ程度)に絞り込み、その他の属性は後から購買や品証側で補完できる運用に変更した。最初から完璧な情報構造を求めると現場が疲弊する。私の経験則では、必須項目は5つ以内に抑えるのが現実的なラインだ。それ以上になると、入力を省略したり適当な値を入れたりするケースが増え、結局データの信頼性が落ちる。

承認フローがボトルネックになった

PLMの目玉機能の一つがワークフロー(承認フロー)だが、これも設計次第で逆効果になる。導入当初、図面リリースに「設計→検図→課長承認→品証確認」の4段階承認を設定したところ、承認待ちの図面が滞留し、リリースまでの平均日数がフォルダ管理時代の1.5倍(2日→3日)に伸びてしまった。

原因は、承認者が出張中や他業務で承認画面を開かないことだった。対策として、承認期限のリマインド通知(24時間経過で自動アラート)と、代理承認者の設定を追加した結果、平均リリース日数は1.2日まで短縮できた。ワークフローは「厳格にすればするほど品質が上がる」わけではなく、承認者の実際の稼働状況を踏まえて設計しないと、システムがボトルネックそのものになる。

移行ツールを自作するか、ベンダー任せにするか

データクレンジングの際、もう一つ判断を迫られたのが「移行作業を自分たちでやるか、ベンダーに委託するか」だった。見積もりを取ったところ、ベンダー委託の場合は2万枚の移行作業で約450万円という提示があった。これに対して、社内のベテラン設計者が簡易的な移行用マクロ(Excelマクロで属性を抽出し、CSVでPLMに一括インポートする仕組み)を自作したところ、外部委託費用はゼロで済んだ。ただし、その設計者の工数を2ヶ月ほど拘束することになったので、厳密には「タダ」ではない。人件費換算すると150万円前後は投入している計算になる。

この経験から言えるのは、移行作業を完全に内製化するか外部委託するかは、社内に「システムに強い設計者」がいるかどうかで判断すべきということだ。いなければ無理に内製化せず、多少高くても実績のあるベンダーに任せたほうが結果的に安く済む。中途半端に内製化を試みて失敗し、結局ベンダーに泣きつくという最悪のパターンも他社事例で聞いたことがある。

部品表(BOM)連携でつまずいたポイント

PLM導入の実利が最も出るのは、設計BOM(E-BOM)と製造BOM(M-BOM)の連携だ。フォルダ管理時代は、設計が作った部品表をExcelでコピーし、生産管理側で別のExcelに転記し直すという二重管理が常態化していた。この転記作業で発生した誤り(部品数の転記ミス、旧版部品の混入)が、実際に欠品や誤発注の原因になったことが年に数回あった。

PLM導入後はE-BOMをそのままM-BOM側にインポートし、差分だけを生産管理側で管理する形に変更した。効果は明確で、転記ミスに起因する欠品件数がゼロになった。ただし連携設定自体は簡単ではなく、ERPとのインターフェース仕様のすり合わせに2ヶ月ほどかかっている。ERP側の部品コード体系とPLM側の図番体系が完全には一致しておらず、変換テーブルを別途用意する必要があった。

BOM連携を検討する際に確認すべきポイントを整理しておく。

BOM連携の効果を数字で示すと、導入前は年間で欠品・誤発注が12件発生しており、そのたびに緊急発注や生産計画の組み直しが発生していた。1件あたりの対応工数を平均2人日と見積もると、年間24人日、稼働日換算で約1ヶ月分の工数がBOM不整合の後始末に消えていたことになる。導入後1年間の実績では、この件数が2件まで減少した。残った2件は、いずれもBOM連携の対象外だった仕入品(標準部品カタログからの直接発注品)で発生しており、この領域は現在も改善検討中だ。ここから学べるのは、PLM導入後もカバーしきれない領域は必ず残るということ。全部を一気に解決しようとせず、効果の大きいところから優先的に手を付けるのが現実的なアプローチだと思う。

変更管理(ECR/ECN)を機能させる運用ルール

PLMの中核機能であるECR(Engineering Change Request)/ECN(Engineering Change Notice)の仕組みは、正しく運用できれば設計変更の抜け漏れを大幅に減らせる。私が関わった現場では、導入前は「変更連絡がメールで飛んできて、誰が対応したか分からないまま放置される」というケースが月に1〜2件発生していた。

導入後の運用ルールとして、以下を徹底した。

1. 変更要求(ECR)は必ずシステム上で起票し、口頭・メールでの依頼は受け付けない
2. 影響範囲(関連図番・関連ユニット)を起票者が入力し、自動的に関係部署へ通知が飛ぶ
3. ECN発行後、対象図面のリビジョンが自動更新され、旧版には「廃版」のステータスが付く
4. 外注先への図面配布は、承認済みECN経由でのみ実施可能とする

このルールを徹底したことで、変更連絡の抜け漏れは半年でほぼゼロになった。ただし、起票が「必ずシステム経由」という縛りは、緊急対応が必要な現場では窮屈に感じられる場面もある。実際、生産ラインで不具合が発生し即対応が必要なケースでは、まず口頭で応急処置を指示し、事後24時間以内にシステム起票するという例外ルールを設けた。ルールは現場の緊急度に応じて逃げ道を用意しておかないと、結局「守られないルール」になって形骸化する。

実際にあった変更連絡の抜け漏れ事故

導入前の話として、忘れられない事故がある。ある部品の材質をSS400からS45Cに変更した際、変更連絡がメールで関係部署に流れたが、購買担当が休暇中でメールを見落とし、旧材質のまま発注が進んでしまった。納品されてから間違いに気づいたが、既に加工まで完了しており、材料費と加工費で60万円分がまるごと廃棄になった。この手のヒューマンエラーは、どれだけ「気をつけよう」と言っても再発する。仕組みでしか防げないというのが私の結論で、これがECR/ECNをシステム化する最大の動機になった。

システム化後は、ECNが発行されると関係部署全員に通知が飛ぶだけでなく、購買担当が発注確定操作をする際に「対象部品に未読のECNがあります」という警告が表示される仕組みを追加した。これによって、休暇中の見落としがあっても発注段階で二重にブロックされるようになった。単純な通知だけでなく、業務フローの要所要所にチェックポイントを埋め込むことが、変更管理を実効性のあるものにするコツだと感じている。

ベンダー選定で見るべき現場適合度

PLM製品はWindchill、Teamcenter、Enovia、あるいは中堅製品まで幅広く存在する。機能一覧の比較表だけを見て選ぶと、実際の現場適合度を見誤ることが多い。私が選定に関わった際に重視したのは以下の点だった。

まず、使っているCADとの親和性。3D CADで作成したアセンブリ構造をそのままPLMの部品構成として取り込めるかどうかは、日々の作業効率を大きく左右する。次に、カスタマイズの自由度とその保守コスト。導入時に自社仕様へ大幅にカスタマイズすると、初期費用は抑えられても、バージョンアップのたびに追加改修費がかかり続ける。実際に他社事例で聞いた話では、カスタマイズしすぎたPLMがバージョンアップできず、5年以上古いバージョンのまま塩漬けになっているケースもあった。

もう一つ軽視されがちなのが、サポート窓口の対応言語とレスポンス速度だ。海外製品の日本語サポートが実質的に代理店経由でしか受けられず、トラブル時の一次回答に3営業日かかるという話も聞いたことがある。導入前のトライアル期間に、あえて軽微なトラブルを問い合わせてみて、サポートの反応速度を確認しておくことをお勧めする。

初期費用とランニングコストの内訳を把握する

見積もり比較の際に見落としがちなのが、初期費用だけでなくランニングコストの内訳だ。私が経験した案件では、ライセンス費用(ユーザー数課金)、サーバーインフラ費用(クラウド版かオンプレか)、保守サポート費用(年間ライセンス費の15〜20%程度が相場)、そしてカスタマイズ改修費用の4つに分けて比較した。

私が関わった案件では、5年間のトータルコストで比較すると、初期費用が安かったA社の製品よりも、初期費用がやや高かったB社の製品のほうがトータルでは安く済むという逆転現象が起きた。理由は、A社製品がカスタマイズ前提の設計思想で、要件変更のたびに追加費用が発生する構造だったからだ。初期費用の安さだけで飛びつくと、後から痛い目を見る典型例だった。

導入後に定着させるための地道な工夫

システムを入れただけでは現場は変わらない。私が見てきた中で定着に効いた施策をいくつか挙げる。

まず、旧フォルダへのアクセス権限を段階的に絞ること。「新旧併用OK」の期間を長く取りすぎると、みんな使い慣れたフォルダに戻ってしまう。私の現場では、本稼働から2ヶ月後にフォルダの書き込み権限を閲覧のみに変更し、実質的に後戻りできない状態を作った。強引に見えるかもしれないが、これをやらないと移行は永遠に完了しない。

次に、部門ごとに「PLM相談役」を1名置いたこと。全員がヘルプデスクに問い合わせるのではなく、まず身近な相談役に聞ける体制にしたことで、初歩的な質問による混乱が減った。相談役には運用ルール策定の議論にも参加してもらい、現場の声を反映しやすくした。

最後に、定量効果を定期的に発信すること。図面検索時間の短縮、変更連絡の抜け漏れ件数の推移などを月次で共有し、「入れてよかった」という実感を現場に持たせることが、次の投資(フェーズ2の原価管理連携など)の理解を得るうえでも重要だった。

これから導入を検討する人へ

PLM導入は、システムを選ぶプロジェクトというより、業務プロセスを見直すプロジェクトだと捉えたほうが実態に近い。私が痛感したのは、技術的な難易度よりも「人がどう動くか」を設計する部分に苦労が集中するということだ。必須入力項目を絞る、承認フローに逃げ道を用意する、旧環境への後戻りを物理的に断つ——どれも地味な工夫だが、これらを積み重ねないと立派なシステムも使われないまま形骸化する。

これから導入を検討する設計者や管理職には、まず自部門の「探す時間」「確認する時間」を1週間だけでいいので記録してみることを勧めたい。数字にしてみると、思っている以上に無駄な時間が積み上がっていることに気づくはずだ。その数字こそが、稟議を通し、現場を巻き込み、最終的にシステムを定着させるための一番の武器になる。

もう一つ付け加えるなら、PLM導入は「一度入れたら終わり」ではなく、継続的に運用ルールを見直していくプロジェクトだということも強調しておきたい。私が関わった現場では、本稼働から3年が経った今でも、四半期に一度は運用ルールの見直し会議を開いている。新しい部門がPLMを使い始めるたびに、既存のルールでは対応しきれないケースが出てくるし、CADのバージョンアップやERPの更改に合わせてインターフェース仕様も変わっていく。導入プロジェクトのゴールを「本稼働」に置くのではなく、「使われ続ける状態を維持すること」に置き直すと、担当者としての気の持ちようもだいぶ楽になる。完璧な仕組みを一発で作ろうとせず、小さな改善を積み重ねていくつもりで臨むのが、結局は一番の近道だと感じている。