　モジュール化など多岐にわたる開発を実現し標準化を進める第一歩は現行の業務・システムを見直すことだ。「本当にこの業務が必要か？」「代わりの方法ではダメなのか？」「自分たちの競争力の源なのか？」と何度も自問自答して、どの業務に従来のやり方を残すか、あるいは業務のやり方を多少変えてでも商用の標準機能を利用するかを決め、全社的に最適となる開発業務プロセスを定義できるようにしたい。

　また、最近の商用のパッケージシステムにおいては、カスタマイズ工数を低減するためにさまざまな技術が提供されているので、それらを検証し活用することも一案である。PLM領域で一例を挙げると、業務に適合するためのデータモデル、プロセスモデルについて、標準のモデル（クラス）を拡張できる、または独自に定義できる仕組みを利用できるケースがある。その場合、従来型のAPIを利用したプログラミングを必要とするカスタマイズより、はるかに少ない工数で対応でき、領域をまたぐような開発プロセスの定義にも有用である。加えて、将来的なシステムのバージョンアップ対応にもメリットがある。

グローバル分散開発環境に対応したPLMシステム

　グローバルな拠点間協力の実現については、共通化すべき設計データ・プロセス、セキュリティルールを整備し、一方ローカルで任せるような業務についても定義することが前提となる。さらにそれを踏まえて、グローバルに展開された開発拠点ごとのさまざまな要件に合わせた体制を構築する必要がある。例えばネットワークの太さや拠点間の協業の濃度によって、PLMサーバを複数化し、拠点間データの同期対象（CADデータなどの設計データ実体またはメタデータ）・データセキュリティ・頻度のバリエーションなどを考慮することなどが行える（図3）。状況に合わせてうまく活用することが重要である。

図3：単一サーバによらない、拠点間の複数PLMサーバの連携パターン例（クリックで拡大）

　また、設計・開発システム側と量産システム側とをつなぐプロセスについても、以前の状況を改善しやすくなってきている。具体的には、外部システムで利用しやすいフォーマットでのPLM側からデータの書き出し、またPLM側で定義した生産関連情報をERP側に適切にマッピングする機能などが存在する。あるいは最適なワークフローやハンドラーを搭載した、システム間のコネクタが提供されているケースもある（関連記事：シーメンス、ドイツの統合ソフトウェア企業 TESIS PLMwareを買収）。設計・開発側の業務と量産側との間、特に拠点が離れている場合は、そこに課題を持つ企業も多いが、上記のような技術の積極的活用を図ることが解決策となり得るだろう。

最後に

　筆者は、前職のPLMシステム開発元で勤務していた時から現職に至るまで、多くの製造業の皆さまと触れ合ってきたが、今回取り上げた課題は各所で見られるものである。当事者としても「分かってはいるけども……」と対応しかねていることも多い。しかし、これまでになく環境が大きく変わる中、行動に移す時期はまさに今であり、手を付けるのが遅くなればなるほど事態は悪化しリスクは増える。特に、業務オペレーションのICT活用は情報システム部門に一任して終わるようなものではなく、経営陣が率先して取り組む全社戦略である、ということを訴えたい。