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

　　

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

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

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

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