４．アソシエティビティの罠　つづき　（およびスケルトン）　

　　

設計を進めて行くうちに、このような事がチーム員間で頻発するようになりました。そのたびにその原因追及とモデル復旧作業が必要となり、とても設計作業などできない事態となっていきます。当然スケジュールはベタ遅れ、モデルを成立させるために自分の欲しい理想的な形状を捨てなければならない、などという完全な本末転倒も起きていました。チーム内で話が済めばまだ良いほうで、他のチームで作った小さなパーツを共用するために引っ張ってきたら、全然関係の無い別プロジェクトのパーツが数百個くっついてきた、というようなまるで笑い話みたいな現象も実際に発生しました。もちろん笑い話では済みませんでしたが。

操作コンサルに相談しても、「別の会社ではこのやり方で上手く行っていた。それはあなた方の使い方に問題があるのではないか？」と言われるばかりです。後からよくよく考えてみれば、少なく見積もっても数千点の部品で構成され、かつ長年にわたって設計変更を重ねながら使っていく我々の製品と、部品点数がせいぜい数十点、しかも使い捨てに近い携帯電話の筐体設計とでは、同じように行くわけがありません。

最終的に開発業務を一時中断し、別のコンサル会社に再度操作教育をお願いして、それまでに作っていたモデルは全て一から作り直すということをやりました。彼らの指導の主な内容は、Pro/Eの売りであったはずの「アソシエティビティ」機能と「リレーション」機能を、ごく限られた場合を除いてまったく使わないようにする、というものでした。開発は半年遅れとなってしまいましたが、それでようやく仕事が回り始めました。

これに関連して「スケルトン」という手法も一時トライしました。形状や性能、機能に直接的に関係する寸法をあらかじめ簡単な線画で表現しておき、その線に関連付ける形で3Dのモデリングをしていきます。仕様や大きさの異なる製品を新たに設計する際には、このスケルトンの寸法を変えるだけで、ほぼ自動的に図面まで出来上がってしまう、というものです。これも余程慎重にやらないとエライ目にあいます。アセンブリが大規模になるにつれてスケルトンそのものが階層化・肥大化・複雑化して、折り重なった二次元図面のように見にくくわかりにくくなってしまうのです。どれかの線の長さを変えようとして、実は変えたくない寸法まで間違って触って変えてしまったりすることがあります。また、このスケルトン・ファイルを介して非常にたくさんの形状データが関連付けられてしまうため、サブアセンブリやパーツを無造作にまったく別の機種で共用しようとすると、元の関係が全部繋がってしまうという現象が起きることがあります。いろいろの失敗を経て、結局ごく限られた場合（ステアリング・リンケージの動きなど）を除いて「スケルトン」手法はまったく使わなくなりました。