MONOist連載！

二弾目は、PLMの失敗事例に焦点を当てます！

「すり合わせ」や「現場力」が強いとされる日本の製造業だが

設計と製造、調達などが分断されており、人手による多大なすり合わせ作業が発生している。

第2回では、日本の製造業がPLM導入で失敗する理由について掘り下げる！

ーーーーーーーーーーーーーーーーーーーー記事ーーーーーーーーーーーーーーーーーーーー

■PLMの構築はなぜ失敗するのか？

　筆者は自動車部品、半導体製造装置、工作機械などのさまざまなモノづくり現場を訪問し、日々の業務プロセスや実務をこの目で見てきた。中にはPLM構築のお手伝いをさせていただく場合もある。

　その中で、さまざまな企業がPLM（Product Lifecycle Management）システムの構築に失敗する事例を嫌というほど見てきた。例えば、「役員からの指示で動いてみたものの、諦めていつの間にか無かったことにする」といった事例や、「担当者が異動してプロジェクトが進まなくなってしまいどうすることもできない」という事例なども少なからず見てきた。

話を聞いた企業の中には「PLMの構築に2回挑戦したが失敗し、今回が3回目の挑戦だ」や「プロジェクトの開始から4年がたったが一向に進む気配がない。本来であればプロジェクトを主導すべきコンサルタントは議事録しか取らない」というような嘆きも聞こえてくる。

　第1回の「PLMこそ日本の製造業に必要な理由――プロセスをコントロールしろ！」では、日本のモノづくり企業に、なぜPLMの構築が必要なのかを詳しく解説したが、今回は日本企業がPLM構築においてつまずく要因について解説していく。なお、本稿は、PLM構築を一緒に行っているファーストクロスの山口博之氏に一部協力をいただき、執筆を行った。

■失敗あるある（1）経営者のPLM理解不足

　PLM構築でつまずく要因の中でも「あるあるの事例」を3つ挙げる。1つ目は「経営層の理解が得られない」、2つ目は「PLMを構築する担当者の権限不足」、3つ目は「PLM専門外のコンサルタントへの依存」である。

　それでは、1つ目の「経営層の理解が得られない」という要因から解説する。なぜ経営層からPLMへの理解が得られないのだろうか。それはモノづくり部門から経営幹部になる人が減少しているからだ。

　ここ最近、製造業の経営に関わる人物は、営業部や経営企画部などから昇進する人が増えているように感じている。当然、昇進の過程では、事業責任者としてモノづくりの部門を率いることもあるが、製品開発や設計、製造などのモノづくり現場に直接関わる実務経験がないまま経営層になることは珍しくない。

　そのため、PLMの本質的価値を“肌感覚”でリアルに感じられない人が増えている。例えば、設計部や調達部、生産管理部、生産技術部といった現場の実務経験を積まなければ、BOM（部品表）の扱いや部署ならではの管理方法、設計から製造への展開（どのように部品情報が部署間で伝達されているのか）を本当の意味では理解できない。

PLMの本質的価値を真に理解できる経営者は少ない　（※）写真はイメージです

　結果として、製造業における「泥臭い」業務プロセスを網羅的に認識することが難しく「PLMシステムを構築すると何が良くなるのか」というイメージを持つことができない。そもそも、PLMやBOMなどの言葉自体を知らないケースも珍しくないほどだ。これらは欧州の製造業経営者にとっては当たり前の基礎知識となっているが、最近、筆者にも「講演を通じてBOMの基本から経営層に教えてやって欲しい」という依頼さえあり、面食らったことがある。

　大手製造業では特に効率化を求めるあまりセクショナリズムが進み、特定の業務経験しか持たず、他部署の業務プロセスへの理解（解像度）が低下している。勉強不足も相まって製造業の各オペレーションを理解できず、「PLMを構築したい」と部下や周囲から言われてもその必要性が分からず、判断ができない。そのため、プロジェクトをうまく進めることができないのだ。

■失敗あるある（2）PLMプロジェクト推進者の権限不足

　2つ目が「PLMを構築する担当者の権限不足」だ。1つ目の「経営層の理解」がクリアでき、経営者がPLM構築の担当者を任命したとする。仮に設計部長がPLM推進プロジェクトリーダーを兼任するとしよう。しかしながら、設計部長の理解や権限だけでは判断や調整ができない事態が生まれる。

　そもそもPLMの構築には各部門のBOM情報を整理、連携させたり、時には全社の業務プロセスの変更をしたりするなど、全社的な改革が必要になる場合が多い。一方で、それぞれのシステムは、それぞれの部門が権限を持ち、これらを自由に連携させたり、改変したりすることはできない（※）。例えば、生産管理部のシステムは生産管理部や調達部が管理するシステムとなっているため、設計部が持つ権限の範囲外となり変更に関われない。各部門にシステム変更が必要だと認識させても、情報システム部との連携が必要となるなど、巻き込むべき関連部門が多岐にわたる。

（※）システム導入ベンダーや管理担当が異なる場合もあり、他部門のシステムへのアクセス権限や変更権限がないことが一般的だ。各部門は自部門の業務効率を優先するため、他部門主導のPLM構築によるシステム変更に抵抗感を示す可能性さえある

　また、それぞれの部門が抱える既存のシステムは、各部の業務に特化して構築、運用されており、独自の業務プロセスやデータ構造を持つことが多く、他部門から見ても容易に理解できない場合が多い。さらに、中には数十年間運用しているレガシーシステムの場合もある。PLMプロジェクトを推進する設計部長が、これらのシステムの詳細な仕組みや運用ルールを熟知しているとは限らない。

　さらに1部門でも反対意見がでれば、説明や説得に多大な労力が必要になる。そうなると、明らかに設計部門の権限を大きく越えることになる。その労力に対しての報酬も不明確なままでは進める意義を失う。また、実際に行動に移しても責任の追及をされるリスクもあるなど、既存の権限のままでは、プロジェクトを背負いきることができないケースが多い。

製造に関する各チェーンと業務システムの連携イメージ［クリックで拡大］ 出所：経済産業省作成「2023年版ものづくり白書」から

■部門内の変革でも難易度は高い

　こうした部門間の難しさがあるのは大きいが、では部門内に閉じた変革であれば、容易に行えるのかというとそうではない。例えば、設計部で閉じた業務改革であっても一筋縄ではいかない。設計部に限っても開発内容に合わせて組織が分かれ、さまざまなソフトウェアを使用しているからだ。機械的な構造を決めるメカ設計ソフト（機械CAD）、電気的な回路を設計する電気設計ソフト（電気CAD）、さらに機械のインタフェースを構築するためのソフトウェアなど、さまざまなソフトやシステムが使用されている。

　工作機械にパレットチェンジャーを追加する場合で考えてみよう。パレットチェンジャー本体のメカ設計、それを動かすモーターの設計や制御に必要な回路基板の設計、そしてCNC（数値制御）のインタフェースを変更するソフトウェアの開発が必要になる。この一連の開発や設計は複数の部門や担当者にまたがり行われ、設計変更が起こるたびにメールなどで図面情報を交換して、設計変更に応じた部品変更を行っていく。各CADに登録されている部品情報や設計情報の変更内容がそれぞれのソフトウェアやシステム間で自動的に反映されるようになれば、煩雑な情報のやりとりは激減させられるはずだ。ある調査では30％の工数が削減できるともいわれている。

　しかし、このような明らかに成果が見えるような状況でも反対する声があるのが現実だ。「現状でも問題なく業務が進んでいるのだから、わざわざシステムを統一する必要はない」「新しい操作を覚えたくない。CADソフトやPDMへの投資も必要になる」「エレクトロニクス設計は少人数だから、そのための投資は必要ない」など、さまざまなせめぎ合いが発生する。設計部門内でもまとめ上げるのが大変なのに、全社を巻き込む場合は一部門の担当者だけで対処することはほぼ不可能だ。PLMシステムの構築には、関連部署を巻き込む力が不可欠であり、当該担当者に権限を持たせること重要だ。

■組織間の責任がたらい回しに

　なお、PLM構築プロジェクトで往々にして責任者として任命されるのが、情報システム部門の役員や担当者である。しかし、日本の製造業において情報システム担当役員は他役員より圧倒的に地位が低く、他役員に対して強く進言できない時代が長く続いた（最近は変わりつつある企業も多いが）。かつECM（エンジニアリングチェーンマネジメント）領域、OT（制御技術）領域を自己の責任の担当範囲外としているケースが多く、そもそもモノづくりにおける全体最適の構想すら立案できない。

　そのため、PLMプロジェクトの多くが設計担当役員に回ってくる。しかし、残念ながら現在設計担当役員を務める方は、PLMどころかITすらよく分かっていない超図面文化の職人として成果をあげ、昇進してきた人が多い。そのため、「KKDH（勘と経験と度胸とはったり）で乗りきれ」という気質があり、ITを使った自動化や効率化への改革志向が低い傾向がある。裏側に「今できているんだろ？　だったらなぜ新しいシステムがいるんだ？」という保守的な姿勢が見え隠れしているのだ。さらに、先述したように自部門の利益を最優先に考えがちで、下流（生産技術、品質管理、生産管理、調達、サービスなど）をまとめ上げることが難しいため、全体最適には程遠い妥協の産物としてのシステムが生まれがちになるのだ。

　部門間で衝突が生じがちなシステム導入ではよくある話だが、部門間代表の担当者同士の話し合いではらちが明かず、プロジェクトマネジャー（PM）や担当役員に課題を投げて判断を仰ぐケースがある。しかし、「現場が納得する方法を検討しろ」と再度投げ返されて、責任のたらい回しにされる事態をよく見かける。それぞれの現場が納得する方法が見いだせないから上位の職域担当者に展開したはずなのだが、まるで自己責務を放棄するかのような責任者が多くて驚かされる。本来は「利益相反が生じる課題は全て俺に挙げてこい。全て俺が決めてやる」ぐらいの気概が欲しいものだ。

　これらを考えると、人望があり各部門に対して影響力や権限がある、事業担当役員もしくはそれ以上の役付き役員（常務、専務、副社長クラス）がPLM推進プロジェクトの責任者（もしくは責任者を積極的に支援する立場）としては必要だと考える。

■失敗あるある（3）PLM専門外のコンサルタントへの依存

　3つ目の要因として「PLM専門外のコンサルタントへの依存」が挙げられる。製造業の現実を理解していることはもちろん、特にBOMの構造や連携、そしてPLM構築の目的を理解していないコンサルタントにPLM構築支援を依頼しても、プロジェクトが成功する可能性は極めて低い（というか無謀）。

　コンサルタント業界ではPLM領域がブルーオーシャンに見えるらしく、国内外のコンサルティングファームの新たな参入が目立つ。その中には大手のコンサルティングファームなどもあるが、残念ながらPLM構築における成功事例を筆者はほとんど聞いたことがない。彼らは構造改革をきれいな絵で説明しがちだが、PLMに関する改革はきれいな絵を描くだけで成果を生み出せるほど甘くはない。

　現場の業務プロセスを細かく確認、分析して、各企業が何を重要視するのかの未来を見据えた要望も考慮して方向性を導き出し、さらにシステムの要件定義とインプリメントをしていく必要がある。非常に難易度が高く、大手CADベンダーの担当者からは「（本当の意味で）成功する企業は100社の内3社程度だ」と聞いたこともある。PLMの構築にはPLM導入で成功した実績のあるPLMに特化したコンサルタントを招くことがカギだ。

　実績や知見が豊富なPLMコンサルタントを招き入れる大きなメリットは、自社内にはないノウハウを得られる点だ。日本の製造業は自己完結の考えから閉鎖的な場合が多く、社外の状況を知らないケースがよく見られる。自社の運用方法に対しては絶大な自信があるが、競合や同業他社の運用方法を把握しているわけではない。

　各企業を回ってみて、外の状況を知らないのに全てを自力でやろうとする企業が多いことに驚く。特にトヨタ系列ではこの傾向が強く、自社の力だけでPLMを我流に進めていこうとする。もちろんトヨタ系列の各社は地力を持っている。それは、認める。一方でPLM専門のコンサルタントを頼ることは外部で使われているツールや、運用方法を知ることも可能であり、プロジェクト推進にあたり方向性を正してくれる。失敗して大きく時間をロスすることも避けることもできる。

■コンサルタントの選び方には注意が必要

　ただ、先述したように、コンサルタントの選び方には気を付ける必要がある。大手コンサルティングファームの一部では、大きな絵空事を描き「あたかもできるようにふるまう」ものの、実際にそれを実現できるように正しく導いてくれるコンサルタントは本当に限られている。コンサルタントだからといって自社の方向性に関わる部分まで丸投げしてしまう企業も少なからずあるが、それはやめた方がよい。自社の方向性を定めぬまま業務がスタートしてしまうのは最悪のケースだ。自社の未来を見据え、どんな業務プロセスを構築すべきなのかという共通認識を、コンサルタントに依頼する前に社内で持つことが重要だ。

コンサルタントの選定には注意が必要　（※）写真はイメージです

　実は、コンサルタントが「本物かどうか」を見抜く方法がある。まず、PMやPMO（プロジェクトマネジメントオフィス）、各プロジェクトを実行する担当者と面談をすることだ。面談によって自社のプロジェクトに合うのか、実力は十分なのか、がおおよそ分かる。「そんなことは当たり前だろ」と感じるかもしれないが、自社のコアとなる業務改革を始めるのに、面談さえしない企業が意外にも多くあるのだ。

　その上で、コンサルタントとの面談時には以下の点を確認すべきだ。

・企業としていつからこの領域をやっているのか

・現在この領域ができるPM、PL（プロジェクトリーダー）、担当者はそれぞれどれぐらいいるのか

・実績はどれだけあるのか

・採用企業のエンドユーザー訪問（数社）

・PMとPLの職務経歴書の確認

　これらについて確認ができれば、自社に合うかどうかは見極められる。それでも不安であれば信頼できる有識者をアドバイザーとして自社で雇用し、彼らとともに会社、実績、事例、人物のバックチェックを行えば選定ミスを防ぐことができる。

　もう少し掘り下げるとPLMの中でのどの領域が得意なのかも確認した方がよいかもしれない。たとえPLMに関する知識を持っていたとしても、PLMコンサルタントにはそれぞれの得意領域があるからだ。「製品のモジュール戦略の構築」「コンカレントな設計基盤の構築」「製品原価構造の整理」「E-BOM（設計部品表）を基にM-BOM（製造部品表）やBOP（Bill of Process、製造工程表）への展開をするためのBOMのクレンジング」といったさまざまな要望に応じて、最適なコンサルタントを選定する必要がある。

　ただ、PLMの構築には、PLM特化型のコンサルタントを招聘することも有効な手段であることは変わらない。高度な専門知識を外部に頼ることができるためだ。多くのプロジェクトでは、プロジェクトに関わるコンサルタントの良しあしで勝負が決まるといってもいいほど、重要なポイントになる。そのためには自社に合うコンサルタントを真剣に選ぶ必要がある。

■PLMの構築に必要な条件とステップ

　では、これらの失敗事例を踏まえて、PLM構築を成功させるためのカギについてまとめていく。今までに説明してきたことや事例で既に理解をいただいた担当者もいるはずだ。

　まず、絶対条件の一つとして挙げたいのが、経営層のトップがPLM改革を推進する姿勢を示すことだ。例えば、全従業員に向けてPLM構築の意義や期待を明確に表明したり、PLM推進に貢献した担当者を公の場で称賛したりすることで、会社的にPLM活動への「お墨付き」を与える必要がある。改革の意志を示すためには、社長自ら旗を振ることが最も望ましい。

　次に、プロジェクトリーダーを経営層が新たに任命することが必要だ。ここで重要なのは、プロジェクトリーダーが設計部長や生産管理部長といった既存の部門の役職を兼任するのではなく、PLM構築の専任の担当者として任命することだ。これにより、プロジェクトリーダーは既存の部門の利害関係に（ある程度）縛られることなく、全社的な視点で改革を推進しやすくなる。また、専属の担当者になることで、担当者自身の責任感と意欲が高まり、プロジェクトへの積極的な関与が期待できる。

　そして、もし社内のみで改革推進が難しい場合には、外部状況を良く知るコンサルタントの知見を借りることだ。当該コンサルタントから皆の前でPLMの重要性を説得してもらうことももちろん有効だ。筆者もよく講演をさせていただくが、欧州でのBOM、BOP運用の現状や、最新のPLM運用を話すと、来場者の目つきが明らかに変わることを何度も経験してきている。

　実際のプロジェクトの進め方だが、PLM構築においては、単にシステムを導入することだけを目的にするのではなく、綿密なグランドデザインを描くことから始めることが極めて重要になる。

　失敗事例でよく目にするのは、PLMシステムの導入そのものが先行している場合だ。社内の既存業務プロセスを見直し、改革する項目の議論が不十分なままプロジェクトが進んでおり、本質的な業務プロセス変革につながらない。役員の一言でPLMのプロジェクト推進は決まり、専任の担当者は切迫感からプロジェクトは進むものの、肝心の「何のためにやっているか」という議論が掘り下げられていない。いざ導入段階になり外部のシステムベンダーが投入されるが、目的が曖昧（あいまい）でシステムに落とし込むことができないケースもよくある。

　こういうケースは関わる人や組織全てに不幸を生み出すことになる。目的が曖昧なままプロジェクトが進んだ場合でも、システム導入を担う外部のシステムエンジニアは成果を求められるため、要件定義が不十分なシステムを導入せざるを得ない。しかし、目的や要件定義が不十分なシステムが現場の助けになるわけがないのだ。このような状況では、どんなに高価なPLMシステムを導入したとしても、「期待した効果は全く得られず、使い勝手の悪いシステムだけが残る」という残念な結果になる。

　PLMを効果的に活用するためには、「何のためにPLMシステムを導入するのか」「改革によって何を実現したいのか」という目的を明確にすることは前提として必要となる。「設計リードタイムを短縮したい」「製品の品質管理（QC）レベルを向上させたい」「将来的な保守・メンテナンス戦略を描きモジュールの扱い方を検討できるようにしたい」など、具体的な目標が重要だ。そして、その目標達成に最適なBOM構造と業務プロセスを再設計することで勝負が決まるといっても過言ではない。

　あらためてPLM構築を成功させるためのステップを以下に示す。

１．目指すべき将来像を議論する（グランドデザインを明確にする）

２．各業務で利用されているデータデザインを精査する

３．1機種分で必要な各業務のBOM構造や情報を整理

４．BOMを前提としてデータ単位の決定と各業務の連携方法を定義する

５．業務フローに対するIT化の範囲とデータの配置を前提にシステムに落とし込む

　システム導入ありきではなく、将来の自社に必要な業務プロセスから逆算してBOM情報を定義していかないと、意味のあるプロジェクトにはならないのだ。

PLM構築のステップ　 出所：山田太郎氏著「実践！PLM戦略 製造業の競争力優位の経営手法」

■BOM情報の整理の重要性

　このステップの中であらためて強調しておきたいのが、3つ目のステップであるBOM情報（構造）の整理だ。BOM情報（構造）は部門ごとに異なるため、そのすり合わせや整理が必要になる。

　例えば、設計部においては、製品を構成する機能や構造、部品といった要素ごとに細かく階層化されたBOMが用いられる。工作機械を例とすると、加工モジュールとして、スピンドル、モータ、ATCなどがある。スピンドルに連なるものとして回転軸、ベアリングがあり、さらにベアリングもボールなどの階層に分かれている。設計BOMは製品の設計情報や仕様を正確に管理し、設計変更の影響範囲を把握するために欠かせないものだ。

　一方で、調達部では「どの部品を自社で製造するのか、外部のサプライヤーから調達するのか」という内外作の区分を決定する目的や、RoHS指令やREACH規制といった環境規制への管理、そして原価を確認するためなどの目的でBOMを使用する。

　また、製造部では、製品を効率的に生産するための各工程における具体的な作業手順、使用する設備、各工程に必要な作業時間や組み付けルールなどを管理するための情報がBOMに関連付けられる（いわゆるBOPの構築や運営が必要になる）。

　このように、BOMは利用する部門やその目的によって、必要となる情報や構造が大きく異なる。大きくはE-BOM、M-BOMなどと大別されているが、これも企業や部門ごとにひも付けられる情報は異なっているため、企業や部門ごとにあらためて精査する必要がある。PLMを構築する際には、まず各部門がどのような情報を必要とし、どのような構造のBOMを利用するのか、そしてデジタルでの連携はどうするのかという点を明確に定義する必要がある。

　そのため、PLM構築の初期段階において、自社の主要な製品機種における各部門の必要な手順や情報を具体的に洗い出し、各業務部門で必要となるBOMの情報を整理や統合をすることが、プロジェクトを成功させる上で重要なステップとなる。この初期段階での丁寧な情報整理を怠ると、後々のシステム構築や運用において大きな混乱を招くことになる。何度も言うが、将来の自社像を描きながら、アーキテクチャを構成する必要があることが、遠回りに見えても最終的には近道になるのだ。

　以上に述べたように、PLMの構築には「経営者の腹くくり」と「実行に向けた専門組織の立ち上げ」が最低でも必要となる。そしてこの障壁を乗り越えたとしても「将来を見渡したBOM構造の構築」の要件定義を各部門と連携しながら地道に行っていかなければならない。経営者の一言で物事が成せるわけでもなく、各部門が前向きになり、非常に泥臭いプロジェクト推進が必要になる。CADベンダーの担当者が「100社に3社」と発言する意味がご理解いただけるはずだ。

　中でも経営者の腹くくりはプロジェクト推進の一丁目一番地であり、PLM構築の前提条件となる。経営者の熱量にかかっていると言えば、それまでだが、ボトムアップではなかなか成せないのがPLMの構築である。

■プロジェクトの品質監視に関して

　最後にプロジェクトの監視体制について、一言だけ述べておこう。プロジェクトがスタートすると、当初の目的や打ち手がないがしろになることが往々にしてある。実現が大変なので、実施内容はこれぐらいでよいかと手を抜いたり、スコープを縮小したり、検討を浅くしたりする。これを防ぐためにPMは常に監視、チェックする必要がある。

　さて、ここまで泥臭いPLMの構築についての具体的なポイントや問題になりそうな事象について紹介してきたが、いかがだっただろうか。今回指摘したポイントが、日本の製造業のPLM導入促進に貢献する一助となり、PLM構築担当者の参考になれば幸いだ。

　もちろん「経営者に火をつけて欲しい」「グランドデザインから協力して欲しい」「BOMを整理したい」が、そういう有識者とつながりがないということであれば、最強のプレゼンター（筆者）が直接お手伝いさせていただくことも可能だ。第1回の連載でも述べたが、日本の製造業こそPLMに投資をし、活用することでより力を発揮できると信じているので、その後押しをしていくつもりだ。

　次回はドイツ訪問から見えてきたBOM運用の最先端を紹介したい。来月も楽しみにしていただければ幸いである。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

記事はコチラ↓

https://monoist.itmedia.co.jp/mn/articles/2506/24/news005.html