あなたの会社が設計・開発に失敗する理由――ツール？ 組織？ それともデータ共有？：設計部門ごとの違いを無理に統一しない（6/6 ページ）

製品を企画し、販売に至るには開発・設計フェーズと製造フェーズが欠かせない。日本には製造技術に優れた企業が多いが、開発・設計はどうだろうか。一部を見ると優れているが、全体の最適化に失敗した製品を見たことがないだろうか。米Texas Instrumentsと米Mentor Graphicsで開発・設計の問題に長年取り組んだ人物はこの問題をどう捉えているのか。「7つの解決手法」とあわせて紹介する。

[畑陽一郎，MONOist]

ハブを持たないシステムとは

　ハブが問題であれば、ハブを持たないデータ共有システムであればよいということになる。同氏が3番目に紹介したのが、「連合化システム」である。「異なる部門を結び付け、コラボレーションを保つ機能を持っているところは既存のソリューションと似ている。しかしながら、（PDMのような）ある1つのシステムに他の全ての部門の詳細なデータを任せるという構成を採っていない（図11）。連合化システムを使うとどうなるか。例えば自動車の配線設計の場合、金属フレーム上の穴が配線の束が通るほど大きいかどうかを知りたいだろう。この場合、機械設計データ全体は不要だ。穴に関するデータだけでよい。各部門はそれぞれのデータ形式、データベースを利用でき、かつ、全ての企業情報を参照可能だ」（同氏）。

図11　連合化システムとはどのようなものか　他部門に詳細なデータを「見せない」ことでシステムの使いやすさや柔軟性を維持できるという。PDMと各部門は図10のように直接結びつくのではなく、コラボレーションプラットフォームを通して結び付いている。図上からまず3つの目標が記されている。（1）部門ごとの開発が可能であり、部門固有の課題には部門内で対応できること、（2）部門内で性能を最適化できること、（3）効果的なコラボレーションを支援できること。この結果、連合化は現在から将来にわたって主流の手法となり、システム志向アーキテクチャ（SOA）とコラボレーションツールを活用できるとした。

　連合化システムのメリットを一言で言えばこうだ。「それぞれの部門の専門家は慣れ親しんだシステムを使うことになる」（同氏）。

　「企業システム全体も簡単に更新できる。なぜなら、企業データ管理システム全体を再検証することなく、自部門が関係するデータ形式やツールなどを更新できるからだ（図12）。最後にはより多くの技術者や部門が加わることになる。多くの技術者が、PDMシステムを備えた企業環境内で働かなければならなくなるだろう。各部門は他部門が持っている情報にアクセスしなければならない場面が多いからだ」（同氏）。

図12　連合化システムのメリット　図上から3つのメリットが並んでいる。性能面ではデータベースのサイズなどを小さく抑えられること、必要なときに必要な情報のみを選んで取得可能なことが特長だ。使いやすさとして、各部門の技術者が慣れ親しんだUIで利用できることを挙げている。素早くアップデートできるというメリットの意味は、企業環境全体を再検証しなくても、各部門内でデータ形式やツールなどを変更でき、設計のリビジョンを動的かつ非同期で更新可能ということだ。

　「このような手法がEDAに適用された結果、ソフトウェア技術者は、ハードウェア設計と組み込み設計の妥協の産物のようなシステムではなく、ソフトウェア技術者自信が慣れ親しんだ環境で働くことができるようになった。こうして今日、組み込みソフトウェア開発環境は実際の仮想モデルとは独立している。仮想モデルが最終製品を表していようと、プロトタイプであろうと、エミュレーションの結果であろうと、ハードウェアの記述であろうと関係ない。組み込みソフトウェア技術者は、慣れ親しんだ開発環境でそのまま仕事ができる」（同氏）。

結局どうすればよいのか

　Rhines氏の主張は、企業におけるデータ管理が開発・設計フェーズの最重要課題であるということだ。システム全体にまたがった最適化を施すには、データの共有が必要であり、そのためには、「まず、部門ごとに最適なデータ構造とデータベースが必要だ。次にある部門が持つ全情報を、別の部門に押し付けないことだ。第三に必要なデータに選択的にアクセスできるようにしなければならない。データ形式の変換がたやすく、短時間でできるようにしなければならない」（図13）。

図13　設計部門ごとに最適なツールを提供しなければデータ共有は失敗する　全部門を横断したデータベースやデータ構造を工夫するのではなく、部門ごとに最適なものを利用しつつ、必要に応じて他部門のデータを入手しやすくするシステムが必要だとした。

　同氏はこれから開発・設計フェーズの改良に取り組む企業に向けたメッセージで基調講演を締めくくった。

企業システムの全体を再検証することなく開発環境の一部を変更できるようにしよう。これが重要だ。部門ごとにそれぞれのUIと作業環境を与えなければならない。各部門が欲しがり、それを使うことで作業がはかどるようなものをだ。全般的に言えば、各設計部門の違いとニーズの違いを認識することが、設計において世界に認められる企業になるための解決策である。そういった認識があれば、全てのシステム統合を改善し、よりよい製品を作り上げる助けになるだろう。