なぜ日本の製造業はPLM構築につまずくのか？ よくある失敗事例を見てみる：ものづくり太郎のPLM講座（2）（2/5 ページ）
「すり合わせ」や「現場力」が強いとされる日本の製造業だが、設計と製造、調達などが分断されており、人手による多大なすり合わせ作業が発生している。本連載では、ものづくりYouTuberで製造業に深い知見を持つブーステック 永井夏男（ものづくり太郎）氏が、この分断を解決するPLMの必要性や導入方法について紹介する。第2回では、日本の製造業がPLM導入で失敗する理由について掘り下げる。
失敗あるある（2）PLMプロジェクト推進者の権限不足
2つ目が「PLMを構築する担当者の権限不足」だ。1つ目の「経営層の理解」がクリアでき、経営者がPLM構築の担当者を任命したとする。仮に設計部長がPLM推進プロジェクトリーダーを兼任するとしよう。しかしながら、設計部長の理解や権限だけでは判断や調整ができない事態が生まれる。
そもそもPLMの構築には各部門のBOM情報を整理、連携させたり、時には全社の業務プロセスの変更をしたりするなど、全社的な改革が必要になる場合が多い。一方で、それぞれのシステムは、それぞれの部門が権限を持ち、これらを自由に連携させたり、改変したりすることはできない（※）。例えば、生産管理部のシステムは生産管理部や調達部が管理するシステムとなっているため、設計部が持つ権限の範囲外となり変更に関われない。各部門にシステム変更が必要だと認識させても、情報システム部との連携が必要となるなど、巻き込むべき関連部門が多岐にわたる。
（※）システム導入ベンダーや管理担当が異なる場合もあり、他部門のシステムへのアクセス権限や変更権限がないことが一般的だ。各部門は自部門の業務効率を優先するため、他部門主導のPLM構築によるシステム変更に抵抗感を示す可能性さえある
また、それぞれの部門が抱える既存のシステムは、各部の業務に特化して構築、運用されており、独自の業務プロセスやデータ構造を持つことが多く、他部門から見ても容易に理解できない場合が多い。さらに、中には数十年間運用しているレガシーシステムの場合もある。PLMプロジェクトを推進する設計部長が、これらのシステムの詳細な仕組みや運用ルールを熟知しているとは限らない。
さらに1部門でも反対意見がでれば、説明や説得に多大な労力が必要になる。そうなると、明らかに設計部門の権限を大きく越えることになる。その労力に対しての報酬も不明確なままでは進める意義を失う。また、実際に行動に移しても責任の追及をされるリスクもあるなど、既存の権限のままでは、プロジェクトを背負いきることができないケースが多い。
部門内の変革でも難易度は高い
こうした部門間の難しさがあるのは大きいが、では部門内に閉じた変革であれば、容易に行えるのかというとそうではない。例えば、設計部で閉じた業務改革であっても一筋縄ではいかない。設計部に限っても開発内容に合わせて組織が分かれ、さまざまなソフトウェアを使用しているからだ。機械的な構造を決めるメカ設計ソフト（機械CAD）、電気的な回路を設計する電気設計ソフト（電気CAD）、さらに機械のインタフェースを構築するためのソフトウェアなど、さまざまなソフトやシステムが使用されている。
工作機械にパレットチェンジャーを追加する場合で考えてみよう。パレットチェンジャー本体のメカ設計、それを動かすモーターの設計や制御に必要な回路基板の設計、そしてCNC（数値制御）のインタフェースを変更するソフトウェアの開発が必要になる。この一連の開発や設計は複数の部門や担当者にまたがり行われ、設計変更が起こるたびにメールなどで図面情報を交換して、設計変更に応じた部品変更を行っていく。各CADに登録されている部品情報や設計情報の変更内容がそれぞれのソフトウェアやシステム間で自動的に反映されるようになれば、煩雑な情報のやりとりは激減させられるはずだ。ある調査では30％の工数が削減できるともいわれている。
しかし、このような明らかに成果が見えるような状況でも反対する声があるのが現実だ。「現状でも問題なく業務が進んでいるのだから、わざわざシステムを統一する必要はない」「新しい操作を覚えたくない。CADソフトやPDMへの投資も必要になる」「エレクトロニクス設計は少人数だから、そのための投資は必要ない」など、さまざまなせめぎ合いが発生する。設計部門内でもまとめ上げるのが大変なのに、全社を巻き込む場合は一部門の担当者だけで対処することはほぼ不可能だ。PLMシステムの構築には、関連部署を巻き込む力が不可欠であり、当該担当者に権限を持たせること重要だ。
組織間の責任がたらい回しに
なお、PLM構築プロジェクトで往々にして責任者として任命されるのが、情報システム部門の役員や担当者である。しかし、日本の製造業において情報システム担当役員は他役員より圧倒的に地位が低く、他役員に対して強く進言できない時代が長く続いた（最近は変わりつつある企業も多いが）。かつECM（エンジニアリングチェーンマネジメント）領域、OT（制御技術）領域を自己の責任の担当範囲外としているケースが多く、そもそもモノづくりにおける全体最適の構想すら立案できない。
そのため、PLMプロジェクトの多くが設計担当役員に回ってくる。しかし、残念ながら現在設計担当役員を務める方は、PLMどころかITすらよく分かっていない超図面文化の職人として成果をあげ、昇進してきた人が多い。そのため、「KKDH（勘と経験と度胸とはったり）で乗りきれ」という気質があり、ITを使った自動化や効率化への改革志向が低い傾向がある。裏側に「今できているんだろ？ だったらなぜ新しいシステムがいるんだ？」という保守的な姿勢が見え隠れしているのだ。さらに、先述したように自部門の利益を最優先に考えがちで、下流（生産技術、品質管理、生産管理、調達、サービスなど）をまとめ上げることが難しいため、全体最適には程遠い妥協の産物としてのシステムが生まれがちになるのだ。
部門間で衝突が生じがちなシステム導入ではよくある話だが、部門間代表の担当者同士の話し合いではらちが明かず、プロジェクトマネジャー（PM）や担当役員に課題を投げて判断を仰ぐケースがある。しかし、「現場が納得する方法を検討しろ」と再度投げ返されて、責任のたらい回しにされる事態をよく見かける。それぞれの現場が納得する方法が見いだせないから上位の職域担当者に展開したはずなのだが、まるで自己責務を放棄するかのような責任者が多くて驚かされる。本来は「利益相反が生じる課題は全て俺に挙げてこい。全て俺が決めてやる」ぐらいの気概が欲しいものだ。
これらを考えると、人望があり各部門に対して影響力や権限がある、事業担当役員もしくはそれ以上の役付き役員（常務、専務、副社長クラス）がPLM推進プロジェクトの責任者（もしくは責任者を積極的に支援する立場）としては必要だと考える。
Copyright © ITmedia, Inc. All Rights Reserved.