Keeping the reasoning with the geometry: rules, reactions and checks in production automotive CAD

自動車製造の世界には、車両がショールームに到着するずっと前の段階で起こる、静かな危機が存在します。エンジニアは何年もかけてバンパーの曲線やセンサーの配置を設計しますが、その作業の中で最も価値のある部分、すなわち「あらゆる決定の背後にある理由」は、しばしば最初に消失してしまうものです。デザイナーが会社を去るとき、彼らは「何が（what）」の背後にある「なぜ（why）」を携えて去っていきます。コンピュータファイルには車の正確な形状は残っていますが、それらの形状を正当化した論理は、跡形もなく消え去ってしまうのです。これにより、次のチームはパズルを解かされることになります。彼らは部品間の隙間が12ミリメートルであることを確認できても、それが10ミリメートルであるべきなのか、あるいは隠れた配線との衝突を避けるために12ミリメートルという妥協案が取られたのかを知る術がないのです。数十年もの間、業界はこの問題を解決するために、ルールを別個の文書やスプレッドシートに保管し、誰かがそれをチェックすることを忘れないようにと願ってきました。しかし、文書はそれが統治すべき設計から乖離していき、理由は何度も繰り返し失われていくのです。

本論文は、実際の自動車生産という極めて重要な環境でテストされた、異なるアプローチについて報告するものです。ルールを設計の外側に置くのではなく、著者はそれを設計の「内側」へと移動させました。車の部品が、開かれたり変更されたりするたびに、一連の厳格な条件に対して自動的に自己チェックを行う様子を想像してください。もし設計がルールに違反した場合、モデル自体が即座にエラーをフラグ立てし、エンジニアが作業している画面上に直接警告を表示します。これは単にレビューを待っているだけの受動的なファイルではありません。それは監視し、値を割り当て、変化が起きた瞬間に反応する能動的なシステムなのです。この研究では、4つの実際の自動車プログラムと、ドライバーの駐車を支援するための特定のセンサーネットワーク、そしてこの手法の限界をテストするための折りたたみ式アームレストを対象としました。その結果、人々が去った後も「理由」を存続させるシステムが実現しましたが、同時に一つの厳しい真実も明らかにしました。コンピュータモデルは間違いを示すことはできますが、人間にそれを修正させることはできないということです。

この研究の核心は、「知識活性化設計（Knowledge-Activated Design）」と呼ばれる手法です。従来のエンジニアリングでは、ルールはマニュアルやスプレッドシートの中に存在し、車の部品の3Dモデルとは切り離されています。エンジニアはマニュアルを見て、ルールを見つけ、そしてモデルを確認することを記憶していなければなりません。もし彼らが忘れたり、あるいはマニュアルが古くなっていたりすれば、設計には隠れた欠陥が紛れ込んでしまう可能性があります。この新しい手法では、ルールはモデルのコード内に直接書き込まれます。モデルが再構築されるとき――例えばデザイナーがバンパーの形状を変更したとき――ルールは自動的に実行されます。それは新しい形状を古い要件と照らし合わせます。もし形状が間違っていれば、モデルは即座に赤色に変わるか、警告メッセージを表示します。エンジニアは、週次の会議や別途のレビュープロセスを待つことなく、その判定を目の前で確認できるのです。

著者はこれを、駐車支援用の複雑なセンサーネットワークでテストしました。これらのセンサーは扱いが難しいものです。なぜなら、デザインを担当する人々、電子部品を詰め込むエンジニア、車両を組み立てるチーム、安全性の専門家、そしてスケジュール管理者の、5つの異なるグループの要求を満たす場所に配置されなければならないからです。車の外装スキンを変更すると、センサーの配置が台無しになる可能性があり、修正のために長い会議の連鎖が必要になることもあります。これらのセンサーに関するルールをコンピュータモデルに直接組み込むことで、システムはあらゆる可能な位置を即座にテストすることができました。デザイナーが新しい位置を提案すると、モデルは即座に、それがセンサーの視界を遮っていないか、あるいは金属部品に近すぎないかを示しました。モデルは単に「はい」か「ノー」を言うだけでなく、地面に当たる検知コーンや、適合しないブラケットといった「結果」を示したのです。

このアプローチは、チームの働き方を変えました。ある事例では、センサー配置に関する詳細を熟知していたシニアエンジニアがプロジェクトの途中で退職しました。かつてであれば、これはチームがなぜ特定の場所が選ばれたのかを理解しようとする数週間の混乱を招いたはずです。しかし代わりに、後任のエンジニアは同じコンピュータファイルを開き、部品の中に組み込まれた「理由」を見つけました。チェック、ルール、そして決定の履歴はすべてそこにあり、可視化され、機能していました。新しいエンジニアは推測したり周囲に尋ねたりする必要はなく、モデルが何が許容され、なぜそうなのかを教えてくれたのです。これは、「なぜ」という理由が設計そのものの中に保存され、それを生み出した人々が去った後も存続できることを証明しました。

しかし、この研究は、この手法が通用しなくなる明確な境界線も明らかにしました。著者は、ルールがどこまで通用するかを見るために、二つ目の例として折りたたみ式アームレストを作成しました。このケースでは、主要な測定値がコンピュータの外、ラボでの物理的なテストに基づいていました。モデルはその数値を保持し、それに対してチェックを行うことはできますが、その数値自体を導き出すことはできません。ルールが物理的なテストによって固定された値に依存しているため、システムは意思決定を完全に自動化することはできなかったのです。これは、この手法が強力である一方で、人間の判断や外部データに代わるものではないことを示しました。モデルはルールを強制することはできますが、答えが自身のロジックの外にある場合、ルールを自ら作り出すことはできないのです。

おそらく最も示唆に富む発見は、システムが完璧に機能したにもかかわらず、人間がそうではなかった状況から得られました。ある自動車プログラムにおいて、3つの異なるグループが別々の合意形成を行い、その結果、ある重要な寸法が安全限界を徐々に超えていきました。コンピュータモデルはこれが起きていることを察知していました。設計が更新されるたびに、モデルは警告を点滅させ、ルールが破られていることを示しました。それは明白で、否定しようのない事実であり、全員に見える状態でした。しかし、車のリリースを担当するエンジニアたちは、その警告を無視して設計を承認することに決めたのです。彼らには、おそらくコストや時期に関連した独自の理由があったのでしょうが、コンピュータは彼らを止めることはできませんでした。モデルはエラーを示すことはできましたが、決定を強制することはできなかったのです。これは、システムは理由を可視化するものの、プロジェクトを止める権限は持たないという、決定的な限界を浮き彫りにしました。イエスかノーかを決める力は、ソフトウェアではなく、依然として人間にあります。

本研究は、ルールをモデルの内側に移動させることは、エンジニアリングの知識を存続させるための強力な方法であると結論付けています。それは静的な図面を、自らを説明する「生きた文書」へと変貌させます。設計が変わったとき、それが安全性、パッケージング、および製造に与える影響を即座に把握することを可能にします。しかし、これはすべてを解決する魔法の解決策ではありません。ルールを最新の状態に保つための規律が必要ですし、現実の企業で行われる複雑な交渉を覆すこともできません。最大の利点は、必ずしもスピードやコストではなく、「明晰さ」にあります。幾何学的な形状の背後にある理由が、建物と共に立ち去ることはなくなります。デザイナーがファイルを開くとき、彼らは単に形状を見ているのではありません。彼らは、誰にも誤って削除されることなく保存された、その形状を構築した「議論」を見ているのです。