長いことCADやPDM（製品データ管理）の記事を担当しております。その担当になる前、新入社員の時の配属先は日経コンピュータという雑誌の編集部でした。コンピューター・システムといえばまだ汎用機（メインフレーム機）が全盛で、その担当である全社IT部門を「EDP部門」「電算部門」と呼んでいた時期でした。

　CADを担当するようになって分かったのが、ほとんどの企業では設計部門の方が中心になって導入を進める一方で、全社IT部門はあまりCADに関係しないということ。私は「設計部門の技術IT担当者と、全社のIT部門はあまり協力する体制にはない」という認識を持っていました。それぞれ必要な知識やスキルが異なっていたためで、当時はそれでもうまくいったのだと思います。

　しかし最近は、両部門の担当者が一緒に取材に出てこられる企業があり、そういった相互の協力体制のある企業の方が、うまくシステムを導入されているように感じます。そこで、両者の連携に役立つ企画もやってみたことがありますが、正直なところ不発気味でした。

　2000年頃にPLM（製品ライフサイクル管理）という言葉ができて、今から思えばこの言葉が両者を結び付けるべきキーワードだったのかもしれない、と思います。しかし当時はPLMをどういう構成要素に分けて考えるべきかも、構成要素同士をどう結び付けるかもはっきりとはしていませんでした。

　デロイト トーマツ コンサルティング（本社東京）は、そのPLMの構成要素を「開発戦略」「開発業務」「技術」「開発マネジメント教育」「IT」などに分けて整理しています（図）。この全てをカバーできるベンダー、コンサルティング会社やコンサルタントはあまりなく、それぞれ得意なところが異なる、といいます。

図●PLMの構成要素
図●PLMの構成要素
デロイト トーマツ コンサルティングの資料を基に作成
[画像のクリックで拡大表示]

　例えば、ITベンダーはBOMやCADのシステムといった「IT」と「開発業務」を連携させるのが得意。「技術」に基づいて「開発業務」のあり方を設計するといった場面では技術系コンサルタント会社が得意、と傾向が分かれます。その中で、「開発戦略」を踏まえて「開発業務」がどうあるべきかを検討するところを手掛けるコンサルタント会社は意外とないそうです。

　設計開発業務の「見える化」に取り組むにしても、開発戦略を踏まえておかないと、詳細に業務フローを作成して「この場面で転記作業をなくせば時間を短縮できる」「ここで過去のトラブル事例を参照できれば品質問題の発生を低減できる」と積み上げていくアプローチになりがちだとか（関連記事）。このアプローチは、全体を捉えるのに向くとはいえません。業務フローがあればシステム要件定義ができるため、「開発業務」と「IT」のつなぎには役立ちますが、状況によってはムダに細かく業務フローを作成することになりかねない、といいます。

　このような位置付けで、開発戦略を踏まえた設計開発業務の改革についてのセミナー「演習で学ぶ、開発設計改革と新体制作りの実務力養成講座」を企画しました。PLMという言葉でまとめてしまうとシステム導入の話と区別しにくくなるのですが、技術ITを全社的視点に連携させる上での基本になると思います。技術IT部門と全社IT部門を直接連携させる話から形はかなり変わっていても、目的は同じと考えています。