誤解1：PLMはPDMより一世代進んだソフトウェア製品である。
近年、PLMの概念が広く普及し、PDMソフトウェア製品の中には「xxPLM」という名称に変更されたものもあるため、多くの企業で「PLMはPDMより一世代進んだソフトウェア製品である」という誤った認識が広まっています。実際には、PLMは単一のソフトウェア製品ではなく、企業レベルのビジネス目標達成のために設計されたソフトウェアソリューション群です。PLMソリューションには、CAD、CAE、CAPP、CAM、そしてPDMが含まれます。
もちろん、PLMソリューションにおける重要なサポート管理プラットフォームであるPDMは、重要な位置を占めています。PLMが設定した企業レベルのビジネス目標を達成するためには、PDM自体もソフトウェアアーキテクチャや使用技術において高い要求水準を満たす必要があります。しかし、PDMがどのように進化し、適用範囲がどのように拡大しようとも、PDMはPDMであり続けます。PDMはPLMの一部に過ぎず、特定の技術ではなく、管理機能に重点を置いているのです。
現在、主要なPDMベンダーは次世代PDM製品を「PLMをサポートするPDM製品」と定義しており、これは正確かつ責任ある定義と言えるでしょう。PLMをサポートするPDM製品は一般的に、包括的なエンタープライズモデリング機能、変化するニーズに対応できる柔軟なソフトウェア、優れた開発性と拡張性、そしてプロセス・製造部門からマーケティング・販売部門までを網羅する適用範囲といった特徴を備えています。しかし、どれほど高度化しても、PDMの本質は設計技術センターにあり、製品の研究開発データとプロセスを管理することに変わりはありません。
誤解その2：PDMシステムは単なるPDMであり、万能薬だと考えること。実際には、PDMはソフトウェア技術と製品開発手法の融合によって生まれたものです。市販のPDMシステムを導入すれば必ず優れた製品データ管理が実現できるとは限らず、また市販のPDMシステムを導入しなければ効果的な製品データ管理ができないとも言えません。
PDMソフトウェアシステム自体が「救世主」となるわけではありません。真の「救世主」となるのは、企業がPDM導入時にその本質を真に理解し、PDM導入の「追い風」を活用して研究開発システムを変革することです。変革は多岐にわたり、例えば、このプラットフォーム上で設計データを標準化すること、管理手法を標準化すること、そして研究開発システムの構成において緊急課題と重要な長期目標を統合することなどが挙げられます。これには、市場に焦点を当てた迅速な対応が可能な製品開発チームと、製品の共通点を研究し、コア技術を蓄積・共有する基礎研究に専念する研究部門の両方が含まれます。しかし、この「炭素」（資源／能力）はソフトウェアプロバイダーから「与えられる」ものではなく、企業自身が経営革新を通じて生み出すものです。
さらに、企業は商用PDMソフトウェアを導入する前に、既存のIT能力内で製品データ管理を改善するための特定のタスクをまず実施することをお勧めします。例えば、部品や図面のコーディングシステムを確立したり、設計データやプロセスデータの標準を設定したり、ISO 9000で求められる製品開発プロセスを開発・導入したりといった取り組みが挙げられます。これらの取り組みの成否に関わらず、後々の商用PDMソフトウェアの導入成功に大きく貢献することは間違いありません。いわゆる「タイムリーな支援」を常に待つ必要はありません。
誤解3：PDM導入はIT部門だけの問題であり、単なる「おまけ」に過ぎないという考え方。企業によっては、情報システムの導入は名誉あるプロジェクトとみなされます。このような状況では、PDM導入は確かにIT部門だけの問題であり、「おまけ」に過ぎず、しかもやや人工的なものと言えるでしょう。
企業が製品開発を真に改善するためにPDMを導入するのであれば、それは単なる「花」ではなく、時には「成長痛」を伴うものです。そして、この「成長痛」を実感するのはIT部門ではなく、経営陣や製品開発担当者なのです。特に、受注が殺到し、製品開発業務が多忙を極める現在の製造業において、PDM（製品データ管理）の導入には、経営陣と管理職の勇気と戦略、そして研究開発担当者の忍耐力と献身が不可欠です。しかし、こうした投資は必ず報われます。企業は、技術知識を継続的に蓄積するリポジトリとなる、全く新しい製品開発プラットフォームを獲得できます。設計者は反復的な設計作業を容易に削減でき、各部門は製品データを迅速かつ正確に取得できるため、部門間のタイムリーで正確なデータ転送に伴うコストを削減できます。そして何よりも重要なのは、新入社員のための学習プラットフォームを構築できることです。
例えば、設計者がPDMプラットフォーム上で企業共通の標準部品を検索・利用できるようになれば、部品製造工程が一つ減り、反復作業の削減、治工具の設計・製造の最小化、そして大量の無駄な在庫の削減につながります。これは単なる「支出」ではなく、真に具体的な投資なのです。
誤解その4：PDMを一度限りの投資プロジェクトだと考え、「一発で解決できる」と期待すること。多くの企業はPDM導入前にプロジェクトを立ち上げ、承認を得る必要があり、その後初めてPDMソリューションの選定、購入、導入に必要な資金を確保できます。多くの企業はPDM予算を確保していますが、これらの計画ではPDMを機器購入のような一回限りの投資と捉えています。企業はPDMソフトウェアを購入すれば、PDMサービスプロバイダーがすべての機能を一度に実装してくれると期待し、「一発で目標を達成できる」と考えています。中には、教科書からPDM機能の説明表を作成し、PDM導入プロジェクトの成功度を測ろうとする企業さえあります。
しかし、PDMは管理ソフトウェアであるため、管理改善は短期的な取り組みではなく、「一回で完了できる」ものでもないことを理解することが重要です。製品管理（PDM）を導入する目的は、企業が製品開発中に直面する問題を解決するのを支援することです。 PDM導入においては「全体的な計画と分散的な導入」が重要であり、特定の課題が完全に解決される前にPDM機能をさらに導入しようとすると、かえって問題が増えるだけです。
例えば、ある企業が文書管理と製品構造管理のためにPDMを導入し、図面の設計承認と変更プロセスがPDM内で運用されているとします。一定のメリットを実感した企業は、すぐに製品構成管理を導入したいと考えるかもしれません。しかし、この段階ではPDMに蓄積されたデータはまだ限られており、標準部品や共通部品の整理も完了しておらず、共通部品のシリアル化設計の原則もまだ確立されていません。特に、これらの業務を担当する専任担当者が不足しているため、導入の進捗が遅れています。さらに、製品構成は過去の導入と密接に関連しているため、設計変更プロセスが複雑化し、様々な基本製品構造や部品構成条件の変更が必要となります。これらはプロジェクト開発チームの担当範囲外の業務です。結果として、初期導入作業が十分に統合されず、アプリケーション担当者が長期間にわたってPDM導入業務に追われることになります。導入への熱意は習慣化する前に薄れ、最終的には様々な理由で導入が中止されてしまいます。PDM導入の初期成果が定着する前に、管理要件の高いモジュールを導入することは、明らかに大きなリスクを伴います。かつてレノボのリーダーが「土を敷き詰め、固め、その上にさらに土を敷く」と言ったことがありますが、これはITプロジェクトの原則を的確に表していると思います。どのプロジェクトも徹底的に実施すべきであり、確実に実行されていない部分は延期すべきです。規模や網羅性ではなく、安定性と実用性に重点を置くべきです。
そのためには、企業はITプロジェクトの客観的な法則を認識する必要があります。PDMは一度きりの投資ではなく、管理の改善には長期的なプロセスが必要です。企業はPDMを通常のIT予算に組み込み、毎年具体的な予算と目標（具体的な目標）を設定し、継続的な投資によってそれを厳守すべきです。このようなアプローチによって、企業は優れた成果を達成できるでしょう。誤解その5：PDMを「トップレベルの経営プロジェクト」と誤解する
多くの記事で、PDMは「トップレベルの経営プロジェクト」であると述べられています。この表現は原則的には正しいです。企業経営の変革を伴うITプロジェクトは、経営陣が十分な注意を払わなければ、どれも実現が困難になります。しかし、多くの人が「トップレベルのプロジェクト」という言葉を文字通りに解釈し、誤解しています。PDMの導入には、経営陣の全面的な関与と個人的な監督、そして問題発生時の即時対応が必要だと考えているのです。実際には、ほとんどの経営陣は、この業務に過剰なエネルギーを割くことはできません。その結果、プロジェクトの失敗を「経営陣の関与不足」などと決めつけるケースが多く見られます。
実際には、「トップレベルのプロジェクト」は必ずしも経営陣の個人的な関与を必要とするものではありません。たとえ経営陣にその能力があったとしても、そのような関与は適切ではありません。PDMプロジェクトにおける経営陣の重要な役割は、「人材管理」「権限委譲」「モチベーション向上」です。現代経営学の父、ピーター・ドラッカーが述べたように、優れたリーダーは思慮深く観察力に優れた「観察者」として行動すべきです。
もし企業のリーダーが、真に適任な「才能ある人材」をプロジェクトマネージャーに任命し、PDMプロジェクトに全力を注がせる勇気を持てば、プロジェクトは既に成功への半分を歩んだと言えるでしょう。しかし、真に有能なリーダーを見つけるのは容易ではないため、これには決断力が必要です。真のリーダーは通常、設計、プロセスエンジニアリング、生産といった中核部門のエリートであり、リーダーにとって彼らを手放すのは容易ではありません。これは、PDMプロジェクトに対する企業の真剣度を試すことになります。
こうした状況下で、一部のリーダーは「パラシュート」方式で人材を採用し、経験豊富な人材を高給でPDMのリーダーに据えるという選択肢を取ります。しかし、これはリスクを伴います。新入社員は企業文化への適応や統合に苦労する可能性があります。さらに、企業を理解するには時間が必要であり、そのような人材の安定性自体が問題となります。ITプロジェクトが大きな挫折を経験すれば、チームの自信は揺らぎ、広範囲にわたる長期的な影響を及ぼすでしょう。こうした才能はプロジェクトコンサルタントとして非常に適しています。
もちろん、この「強力なリーダー」がその能力を最大限に発揮できるよう、適切な権限委譲は不可欠です。リーダーはチームメンバーの選定と評価を行う権限を持つべきです。権限委譲のもう一つの側面は、プロジェクトマネージャーがPDM（プロジェクト管理）に関する事項において相当な意思決定権を持つ必要があるということです。完璧なものなど存在しません。プロジェクトマネージャーは経営陣の代弁者ではなく、あらゆる事柄について経営陣に相談すべきでもありません。優れたプロジェクトマネージャーとは、責任を負うことを恐れない人物です。もちろん、プロジェクト管理自体には多くの科学的な手法と技術が存在します。これらの手法を習得したプロジェクトマネージャーは、ほとんどの「リスク」を回避できます。
さらに、「インセンティブ」もリーダーにとって重要な役割です。インセンティブは単に従業員に報酬を与えることではなく、より重要なのは、企業文化に根付かせることです。様々な方法を通して、優秀な人材を会社が認め、尊重し、より大きな成長の機会を与えるべきです。このアプローチは、会社のIT人材プールを継続的に改善・強化し、IT業務の継続的な発展に必要な人材を育成することにつながります。企業の「トップレベルマネジメント」の姿勢を反映するもう一つの重要な側面は、ITプロジェクトにおける一時的な困難に経営陣がどのように対処するかです。この時、経営陣は「道しるべ」としての役割を果たします。まず、自信を維持することが不可欠です。ITプロジェクトにおいて一時的な困難は避けられません。こうした一時的な苦難は、ITプロジェクトを支配する客観的な法則を企業がより深く理解するのに役立ちます。経営陣は速やかに進捗の方向性を示し、必要な総括と調整を行うべきです。