事例3　CAE による試作レス達成までの道程

　これまで私は複数のメーカーでCAEエンジニアとして勤務してきた。メーカー内のCAEエンジニアは主に設計からの解析依頼に対応するか、社内に必要な技術開発をCAE主軸に取り組むことが多い。また、CAEの専任部署であることが多く、これにより設計、製造と部門や部署はおろかロケーションさえ異なることが多い。本稿ではそのような企業に私が31歳（社会人7年目）から4年ほど所属していた当時、CAEでフロントローディングによる設計プロセスの変革と試作レスを達成した経験を述べる。

　当初はCAEにより試作回数を削減したいとの設計部門長からの要望に、CAE部署が技術開発テーマとしてテーマアップされていたものを私が担当したのがきっかけである。あくまでも当初の課題は試作工数が増大しており少しでもCAEにより試作回数を削減できればうれしい、程度のものであった。しかし、私が取り組む中で、現場を観察し、設計者や試作者と話をしていく中で徐々に見えてきた本質的な課題は大きく下記の3 点であった。

　① 勘と経験による設計のため、設計時点において設計形状の良否がわからず固定の設計日数で出図をしていた
　② ①により試作者が試作を繰り返す中で製品形状の修正を行い、製品を出荷していた
　③ 設計者―試作者間の本質的なコミュニケーションがなされていなかった

　このうち、②については試作工数が増大しているという目に見える課題として認識されており、CAEでアプローチ可能と判断されて相談があったのだが、そのほかについては当事者同士では気づかない隠れた課題であった（図1）。

　私はCAEエンジニアとして業務する傍ら組織開発も同時に学びを深めていたことから、CAEで目に見える課題にアプローチしつつ、隠れた課題についても同時に働きかけることとした。

　CAEにより②の課題にアプローチするためには①の課題を解決する必要がある。そのために越えなければならない技術的なハードルは、勘と経験の設計から脱却し設計形状の合否判定基準を決めることである。

　そこで、これまでに設計されてきた製品をCAEにより解析し、試作結果と比較することで設計形状の合否判定基準を決めることとした。そのためには膨大な量の解析を実施する必要があることから、解析自体を自動化し解析作業工数の低減を図ることとした。取り組み始めると解析の自動化自体はこれまでCAE作業に従事してきたこともあり数カ月で完成した（実際にはその後もブラッシュアップを進めており解析の完全自動化のプログラム作成までは2 年ほど改善を繰り返すこととなる）。これは設計者が設計した3 次元CAD形状と製作条件を記載した定型のインプットファイル（仕様書）を読み込みさえすれば、あとはバックグラウンドで解析を実行し結果が出力されるものである（最終的には合否判定基準を決めたために設計の合否がわかるように自動化した）（図2）。

　この中で苦労したことは、Ⅰ．メッシュ作成、解析、ポスト処理でおのおのソフトが異なるため、そのソフト間連携をとること、Ⅱ．100％止まらない自動化プログラムを構築することである。　

　前者においてはソフトウェアが異なることで販売ベンダーも異なり、ソフト間連携にはどのベンダーサポートも自社領域でないために相談に乗ってもらえず、自力で解決しなければならなかったこと。後者においてはAIや統計などの帰納的な方法では100％の認識精度を達成できないため、演繹的な方法を採用したことである。具体的には、仕様の範囲内であればどんな形状が入力されたとしても止まることなく結果が得られなければ設計者は使ってくれないため、100％止まることのない自動化にする必要がある。そこで、3 次元CADの形状認識においては幾何学的に決まるルールから数学的に確実に認識できるようにしたこと、メッシュ作成方法においては品質の良いメッシュが必ず作成できるアルゴリズムとパラメータを採用したことである。　

　これらを乗り越えるためには自力で勉強し、試行錯誤を繰り返すほかなかった。それは、このときは私自身も明確に取組みの効果を説明できなかったことが大きい。社内外を含め私の取組みを理解してもらえることはなく、一人で黙々と調べて学び、試行錯誤を繰り返した。このとき私を駆り立てていたものは、私の取組みを理解できない人たちを見返してやるという怒りの感情だったと思う。　

　合否判定基準を決めることについては、これまで過去に設計したものを解析し、実製品と比較することを繰り返した。また、設計時に出図された形状をそのまま解析したとしても、最終製品までには試作、修正により設計形状から変更されていたために、試作者が都度どのように修正するかを直接現場で観察し、修正した寸法を形状に反映し解析するということを地道に繰り返した。これは後から試作者に修正箇所と方法を聞いたとしても暗黙的に作業をしているために抜け漏れがあり解析と合わないことが多々あったため、自ら足を運び作業を観察しなければ正しい情報が得られなかったためである。　

　また、それ以前に試作者との関係性を構築するために、現場の掃除、試作準備、試作時の手元作業など、いわゆる泥臭い作業から始めた。それは当時のCAE部署は現場の人からするとインテリ集団で近寄りがたい存在であり、私が話を聞こうとしても暗黙知まで聞き出すことはできなかったためである。このような取組みを丁寧に行うことで試作者の暗黙知を知ることができるようになり、設計形状合否判定自動化プログラムに合否判定基準を組み込むことで形式知化を行った。

　設計形状合否判定自動化プログラム（以下、本プログラム）が完成しても設計者がすぐに使うことはなかった。それは彼らからしたら、いくら入力が3次元CADと製作条件ファイルだけだとしても、そもそもこれまで解析をすることがなく設計をしており、その後の修正は試作者が行っていたため、解析をすること自体が負担で価値を感じていなかったこと、合否判定の信頼性がなかったことが大きな理由である。そこでまず試作者に使ってもらうことにした。これまで合否判定基準を決めるための取組みを行っていく中で試作者とは関係性ができていたために、彼らはすんなりと使い始めた。具体的には1 度目の試作結果を見て、次どのように修正すればよいかを本プログラムをもとに検討することにした。これにより、本プログラムを使用することで試作回数を半分以下に減らすことができ、大きな効果を得ることができた。　

　この結果を設計者が見たことで、設計時点で本プログラムを利用することの価値に気づき、自然と設計者側から本プログラムを使用するようになった。当然のことながら、本プログラムで出図した製品を試作すると明らかに試作回数が低減した。その結果を見て以降は、設計者も本プログラムを積極的に使用するようになった。これまで設計日数により出図していたプロセスから、設計時点で本プログラムを使って合格した設計形状のみを出図するプロセスに変わることとなった。

　設計者が本プログラムを使うようになっても設計日数は減るどころか増える結果となった。これは本プログラムを使う前までの設計方法が従来通りであり、本プログラムに入力するための3 次元形状を経験により設計しており、加えて、設計した3 次元CADを本プログラムに入力し合否判定を行った後、再度設計形状の修正を繰り返していたために従来以上の工数を要していた。従来は顧客からの仕様を受け取るとすぐに3次元CADソフトで形状をつくり始めており、過去の類似形状をもとに3 次元CADソフトだけで設計を行っていた。そこで、1DCAEを導入し簡易設計形状を検討したうえで3次元CADソフトにより形状を作成する方法に変えた。これにより、設計開始から本プログラムに投入するまでの時間を低減することができ、本プログラムに投入後も少ない修正回数で出図するに至った（図3）。

　設計で本プログラムを使い始めて試作回数は低減したものの、数回の試作は必要ですぐに試作レスにはならなかった。それは、設計者は本プログラムを使用しているものの、当初はその合否判定基準が低く、設計上の合格点数が試作レスの基準ではなかった。また、本プログラムはあくまで設計した形状を入力して合否を判定してくれるが、どこをどのように修正すると合格点数が向上するかを示してくれるものではなかった。そのうえ、合格した形状で3次元CADをもとに設計レビューをするものの、試作者から試作レスのための改善提案がなされることはなかった。　

　それは普段から設計者と試作者は一緒に昼食をとり、休日にはBBQに行くような間柄であったにもかかわらず、業務時にはモノづくりの肝となる試作時の形状修正方法を話すような関係ではなく、業務の中で試作者はこれまで設計者の出図したものを受けて試作をし、形状を修正するという主従関係の指示の中で業務を行ってきたことによるものである。また、試作者はどのように修正すればよいか頭の中ではイメージできているものの、それを言語化して設計者が理解できるように伝えることができなかったためである。　

　そこで、解析のポスト処理結果を見せることでこれまで試作者の頭の中にあったイメージを可視化し、共通の図をもって議論できるようにした。また、上司がいるような堅苦しい設計レビュー時ではなく、設計途中で設計者の座席でモニタを見ながらワイガヤで議論するように場をつくり、試作者が意見できるように意識的に働きかけた。これにより、試作者が気軽に設計途中に形状案を意見し、それを設計に反映させることで合格点数が向上していき、最終的には試作レスで製品をつくることができた。

　当初、部署もロケーションも異なるCAE部署に身を置き開発を行っていた。しかし、すぐにそれではうまくいかないと思い、現場上長に掛け合い、設計試作現場に席を置いて開発を行った。それはCAEを行っていたとしても、あくまでもモノづくりは現場であり、暗黙知は設計者や試作者の中にしかなく、CAEエンジニアはCAEソフトを操作できたとしても、実際に現場で起こっている入力条件が何もわからないと気づいたからである。　

　本プログラムの作成は、解析ソフトやプログラミングを知ってさえいればつくることが可能な技術的な課題である。一方、設計プロセスの変革やコミュニケーションロスの改善は隠れたプロセスであり、まずはその目に見えていない課題の本質がどこにあるのか現場を見て観察することが必要である。また、課題を見つけたとしても、設計プロセスやコミュニケーションの改善は当事者の意識や当事者間の関係性の問題である。これらは状況に合わせて対応が必要な適応を要する課題である（図1、図4）。

　技術的な課題と適応を要する課題を働きかける側が混在することなく意識的に切り分け、それぞれにアプローチしていくことが必要である。

　なぜこの取組みがうまくいったのか。取り組む中で何が1 番重要であったか。改めて振り返ると、絶対に止まらない本プログラムを開発したことでも、合否判定基準をつくったことでもない。その1 番のポイントは設計者―試作者間の本質的なコミュニケーションの質が変化したことである。そして何よりも彼らは私が働きかける前と後で何ら関係性が変わっていないと思っており、自分たちの力でできるようになったと思っている。働きかける側が意図して計画して働きかけているにもかかわらず、相手は無意識のうちに会話の中の語りが変わり、関係性が変わり、モノづくりのプロセスが変わり組織が良くなっていく。まさにこれがCAEによる伴走型組織開発の理想形ではないかと思っている。　

　本記事が少しでも読者の皆さまのお役に立てば幸いである。