　日本の多くの製造業では、CADやPLMシステムが事業部や部門別に選定され、個別最適化されてきました。そのため、1つの企業の中に、複数のCADシステムやPLMのパッケージが混在し、社内の事業部間でもCADデータや技術情報の共有がやりづらい状況になっている状況がよく見られます（社外とのアプリケーションの違いによるデータ共有は以前から問題でした）。

　なぜこのようなことになってきたのでしょうか。

　理由は、事業部や製品別に製品開発プロセスを最適化されてきたからです。製品開発部門の権限が情報システム部門よりも強いことが多く、全体最適よりも個別最適が優先されてきたことが1つの要因になっていると考えられます。多くの企業で事業部制をとっており、各事業部の売上や収益を最大化することが、企業の売上や収益になるという考え方になっており、それに合わせてCAD・PLMシステムも個別最適化されてきた、ということが主な経緯です。

組織統合や再編成の効果が出ない「個別最適」のワナ

　最近ではM＆Aのような企業同士の統合だけでなく、企業グループの中の類似事業を統合して1つの事業部として再編成する状況をよく聞きます。

　組織としては統合されても、旧組織の事業部がそれぞれ別のCADやPLMシステムを使っていることが多く、そのままでは技術情報の共有や交換も容易ではありません。また、開発プロセスや設計・生産連携方式についても従来のままで、個別のローカルルールが多く存在しています。業務プロセスや情報体系の標準化をまず推進しないと、CAD・PLMシステムを統一できなくなっています。

　日本の製造業は従来、事業部別に意思決定する「個別最適」の良さを発揮してきました。しかし、それは現在のグローバル競争における海外競合に対する変革のスピードの遅くなるという問題を生んでいます。異なるCADシステムやPLMシステムに投資した減価償却費が残っています。今後のIT運用コストも大きな負担になっており、これまでに投資したITシステムが負の遺産と言ってもいいのかもしれません。

　今後、新興国市場を中心としたグローバル競争を勝ち抜くためには、新商品開発プロセスを柔軟に進化させる能力、開発プロセスの進化に合わせたITインフラ構築能力、開発プロセスやITインフラをガバナンスする導入方法論、がより重要になってくるのではないでしょうか。

PLMコスト最小化を阻むのはこの3つ

　PLMコストといっても、製品ライフサイクル全体で発生するコストですので、非常に広義です。ここでは、PLMコストを、

製品開発業務で発生するコスト
製品開発業務を支援する主要なITツール（CAD/PLMシステム）の導入・運用コスト

に絞って議論を進めます。

　これまでも、多くの企業で事業部別に個別最適化されてきた開発プロセスやITインフラを全体最適化してPLMコストを最小化しようとする動きは、多くの企業で検討されてきました。

　ここではその中から代表的な推進上の課題をご紹介します。

個別最適化された設計・生産連携プロセス

　1番目は、事業部単位で規定された開発プロセスや、開発部門と生産工場で複雑に絡み合った設計・生産連携プロセスです。これが、開発プロセスやITインフラを簡素化できない大きな要因になっています。特に、開発部門と生産工場の連携が個別に最適化されていることが多く、多数のローカルルールが存在しています。部品表や図面の出図プロセス、設計変更の際の帳票や伝達情報のなかに、固有の書式やコード体系、個別に定められた運用ルールなどです。

　図面や部品表に代表される、いわゆるモノづくり情報の伝達方法は“そのプロセス”の生産性を最大化するために、個別最適化されていることが多いのです。さらに、実際にはそれらの情報に記述されていない、いわゆる「阿吽（あうん）の呼吸」でコミュニケーションが成立している場合も存在します。このように情報伝達プロセスを可視化・分析するだけでも時間がかかる作業となっています。

業務プロセスの全体最適と個別最適化の層別

　2番目は、企業レベルで開発プロセスやITインフラを統一化するに当たって、企業レベルで全体統一すべきもの、事業部や部門別に個別最適化すべきもの、を区別する判断が難しいという点です。

　筆者は、企業レベルで全体最適を推進する部門（開発プロセス企画部門や情報システム部門のような部署）と、製品別の事業部が対立構造になりやすい、という点を指摘します。全体最適化することで企業が得られるメリットと、個別最適を失うことで事業部が得られるデメリットの比較が難しいのです。

　連載第4回でもこの点については言及しました。企業レベルで統一すべきもの、事業部の特色を生かすために集約レベルの業務アプリケーションとするもの、個別最適化したプロセスで残すものを戦略として層別する必要があります。

　図1は、製品開発プロセスの事業部別の違いを可視化し、その後、統一と個別最適を仕分けし、集約してバリエーションを削減するイメージを示しています。

図1　開発プロセス差異分析と集約化

プロセス改革を阻害する組織の壁

　3番目は、開発プロセスやITインフラの集約や標準化に関する事業部間の合意形成と、実行推進です。新しい開発プロセスやモノづくり情報体系や、統一化したCAD/PLMシステムを導入する際に、現場からの強い抵抗に合うことがあります。

　日本の製造業にありがちな組織の壁が障壁となり、ゆっくりと議論は進行するのですが、結果的に合意形成に時間がかかり、企業が期待する達成時期を逸脱してしまうことに陥ってしまいます。

コラム：ゼロからPLMベストプラクティスを導入する新興国、プロセス変更で困惑する日本

　筆者は以前、某新興国のローカル企業でPLM導入企画のコンサルティングを実施しました。

　通常、日本の製造業で開発プロセス改革やPLMシステムの導入企画を実施する際には、現状業務のヒアリングや、情報システム・既存技術情報の調査に多くの時間をかけます。

　しかし、驚きだったのは、その企業にはPLMに関連する情報システムがほとんどなかったことです。現状業務やシステムに関連する調査にはほとんど時間を使いませんでした。また、導入予定のパッケージにはほとんどカスタマイズを加える必要がありませんでした。パッケージが持つ「ベストプラクティス」をそのまま採用できたのです。

　新興国企業がこのようなスピードでグローバルPLMを導入することが可能だとすると、日本製造業にとって大変な脅威になるのではないかと感じました。