PLMシステム改善PJ担当者のための覚書： 戦略構築のためのライフサイクル管理論（5）（1/3 ページ）

自社の製品開発戦略をしっかり把握しているでしょうか？ 製品開発・生産技術の効率化を追求していたとしても、しっかりとした戦略とマネジメント意識がなければ意味がありません。本連載では、マネジメント技術としてのライフサイクル管理を考えていきます。

[久次昌彦／プログレス・パートナーズ，＠IT MONOist]

もったいない！

　PLMシステム構築プロジェクトに関してお客さまと話しているとよく「うちはPLMシステムを持っているけど使い方はPDMどまりです」なんてことをよく聞きます。

　これでは非常にもったいない。

　PDMシステムを構築するのであればCADに付属するLDM（ローカル・データ・マネジメント）システムを使っても十分CADデータをバージョン管理していくことは可能です。

　PDMシステムにはCADデータなどのドキュメント管理機能だけでなく、パーツ／部品表管理および設計変更管理などの機能がありますが、PDMシステムを運用している企業でもほとんどの場合、ドキュメント管理とパーツ／部品表管理程度で、設計変更などの設計ドキュメントをワークフローを用いて運用している企業はさらに限定されてきます。

ライフサイクルすべてを賄うビッグバンプロジェクトは「NO」

　PLMシステムの導入がなかなか進まない理由の1つに、PLMシステムのネーミングになる「プロダクト・ライフサイクル」という部分がシステム導入に際して大きくハードルを上げているといえます。

　プロダクト（製品）のライフサイクルの言葉から製品の企画段階から設計生産を投資して保守・サービスを経て廃棄するところまでをイメージし、「企画・設計から廃棄までのデータの管理なんてとてもそんな大きなシステムを構築できない」と思ってしまいます。

　またPLMシステム構築はERPシステム構築と異なりビックバン的な導入プロジェクトはほとんどなく、どちらかというと部門ニーズに合わせ、設計部門などが中心となった部門最適なシステム構築プロジェクトとなる傾向にあります。

　部門ニーズから発生したシステム開発ですから、おのずと他部門まで巻き込んだプロジェクトを避けてこぢんまりとしたシステムに落ち着かせようといった傾向になります。

　PLMシステムは本来、製品情報を一元管理し、モノづくりにかかわる人たちに正しい情報を適切なタイミングで部門に応じた形で提供することで、このモノづくりのコンカレントエンジニアリングを推進する情報基盤として使われるべきものです。

　このように部門の壁を超えてコンカレントエンジニアリング環境を構築するシステムを、特定の部門内だけでモノづくり情報を共有するのは非常にもったいないと思います。

　最近のPLMソフトウェアの中には、かなりカスタマイズもしやすく柔軟に設計業務要件を取り込んだり、設計部門以外のニーズにも柔軟に対応したり、他システムと簡単に連携できる仕掛けを持つものも出てきました。

　そこで最新のPLMソフトウェアを使うことで実現する、部門の壁を越えた情報基盤となるPLMシステムの構築方法や、PLMソフトウェアとして何を実現し、何を実現しないでおくべきかといった選択基準について解説していきたいと思います。

　プロダクトのライフサイクルにわたる製品情報を一元管理するPLMシステムの構築はプロジェクトの推進方法として、プロダクトのライフサイクルに関係する各部署を巻き込んだビックバンプロジェクト型で推進すべきでしょうか？

　答えは「NO」です。

　PLMシステムで管理されている製品情報は、電子化されることで情報の複製や共有および伝達スピードが飛躍的に向上させることができますが、それを活用する方法としては紙でも十分業務ができ、プロダクト・ライフサイクルのすべての部署に一気にシステムを導入する必要はありません。

　逆に製品情報がきっちり蓄積される前に他部門も巻き込んでシステムを構築しても、後工程が必要とするデータが蓄積されるまではデータを活用する部門にとってシステムは意味を持ちません。

　PLMシステム構築プロジェクトはちょうどレゴブロックを作るイメージでプロジェクトを推進するのがシステム構築のリスクも少なくプロジェクトを進めることができます。

　設計部門には設計部門が要求する、部品表の管理方式やドキュメントの登録および検索方法。または原価やコンプライアンス情報が簡単に見られる仕組みをそれぞれ機能モジュールとして構築していきます。

　また、品質管理部門であれば、FMEAまたは標準化を推進するための作業手順書（SOP）や製品特性および検査特性などを登録させる機能が要求されます。

　PLMシステムを使うことで、このようにバラバラに各部門で入力されたデータもリレーションという関連性を付けて一元管理していくことが可能です。

　PLMシステムを構築するに際しては、このようにあたかもレゴブロックのように積み上げていく各部門の情報を最終的にどのように活用していくのかを検討し、設計情報管理のあるべき姿としてシステムのグランドデザインをシステム構築の初期の段階で検討しゴールを定義しておくことが重要です。

なぜ 、ビジネスモデルとしてのPLMか

　その作業が前回ご紹介したビジネスモデルのPLMの検討になるわけです。

　PLMシステムを用いて製品開発に関するさまざまな情報を世代別に関連付けて管理しておくことで、利用者は簡単に自分が必要とする最新のデータを見つけることが可能になるとともに、関係する情報にはリレーションをたどって必要な情報に漏れ抜けなく気付かせることが可能となります。

PLM導入プロセス

　いままでの話をまとめると、

1. 最初にPLMシステムの構築に先立って、PLMシステムを構築するとどのような効果が出るのかをビジネスモデルとして検討します
2. その次のステップとして部門別に必要なインプット情報とアウトプット情報を定義してシステムとしての入出力を構築していきます。この段階では各部門の情報は個別に部門データベースとして蓄積されていきます
3. その後、蓄積されたデータをノウハウとして活用するために各情報間にリレーションという形で関連性を持たせることで、自分の知っている情報から他部門で作成されている成果物にアクセスすることを実現していきます

　このようにあたかもレゴブロックを積み上げる方式でPLMシステムを段階的に構築するのが、モノづくりにかかわる部門に製品のライフサイクルにわたる情報を提供する情報基盤となるPLMシステムを構築するポイントで、段階的なアプローチを取ることでシステム構築のリスクを抑える1つの方法です。

　PLMシステムを選定するに際しては、このようなプロジェクトの進め方が可能なPLMシステムを選択することが重要です。

機能要件

　そのために要求されるPLMシステムの機能要件としては、

1. データベース設計が柔軟にでき、データベースのテーブルや項目の追加が簡単にできること
2. データを表示する画面の変更が簡単にでき、同じ情報をユーザーやロール別にコントロールすることが可能なこと
3. 個々の機能の変更内容が極力ほかの機能に影響しないアーキテクチャで、業務の成熟度に合わせて業務機能が簡単に追加・削除できること
4. データへのアクセスコントロールが柔軟にできること
5. 情報間の関連付けをするリレーションが後からでも柔軟に追加・変更できること

が挙げられます。