設計フロンティア：モデル化をしませんか
とあるデザインレビューの場にて
設計現場に身を置いたことがある方なら、きっと一度は耳にしたであろう質問があります。「どうしてこういう設計なのか説明せよ」
なぜこのような質問が発せられるのでしょうか？
それは、レビューをする側（レビュアー）には設計者の頭の中にある考え方や理由、つまりプロセスが見えないからです。レビュアーに示されるのはアウトプットだけ：図面、3D CADモデル、説明資料、解析結果などがそれにあたります。
この問いに対し、準備のない設計者は記憶をたどりながら答えます。「○○を達成するために、△△という制約があるので、それらを満たすように設計しました。」、と。しかし、このような受け答えではレビュアーからはさらに質問がきます。「それはわかっていて、どうしてこの設計になるのか質問しているのです」。再び設計者は答えを必死に模索します。「A、B、Cという３つのパラメータがあり、AとBがトレードオフの関係にあるので、制約の中で最適と思われる点を選択しました。」（以下さらに続く…）
こうしたやり取りは、スマートとは言えないものです。私自身が設計者としてのキャリアの初期には、このような問答のループに何度も陥ってしまったものです。
では、何が問題だったのでしょうか？
モデル化して伝える
欠けていたもの
先ほどの議論を生産的なものにするには、設計対象に関わるパラメータと設計結果の関係性を初めに明示することが必要でした。このパラメータの抽出とその関係性の明示こそが、私たちが「モデル化」と呼ぶプロセスです。先ほどの議論にはモデルが欠けていたのです。
モデルは、インプット・プロセス・アウトプットから成るといわれます。英語の頭文字をとってIPOと称されます。
アウトプット：設計対象から期待する結果
インプット：その結果を得るために設計者が用意するパラメータ
プロセス：インプットとアウトプットの間の関係式
（関係式の導出については下記の記事をご覧ください）
モデルが冒頭の議論にあった場合
設計者はIPOをレビュアーに提示します。レビュアーは設計者が何をどのように検討したかが即座に把握できます。議論は既に行われたことの確認という付加価値を生まないものにはなりません。より良い設計に至らしめるにはモデルをどのように修正するかという生産的な議論になります。
モデルとは何か
"モデル"という単語は、多くの人々が何となく理解しているものの、具体的な定義は意外にも存在しません。とはいえ、モデルには主に2つの側面があると考えられています。
対象とするシステムを簡略化し、その本質を表現したもの。
例えば、原子の惑星モデル（ラザフォードモデルやボーアモデル）がこれに該当します。ビジネスモデルも該当します。事業体が付加価値を提供し、収益を得る仕組みを説明しているからです。
この側面では、現象の理解を目指し、本質を数学的に表現します。対象とするシステムの特定の側面について記述を与えることで、実際の代わりとなる数理的あるいは実体的なもの。
数理的な例としてはCAE解析、実体的な例としては風洞実験などが挙げられます。最近ではAIもこの一環と言えるでしょう。
この側面では現象の観測と整理を目指します。
これら1と2は、相補的な関係にあります。つまり、どちらか一方だけでなく、両方の側面を混合して考えることが大切であるということです。
誰もが行っていて、明示できないのがモデル
誰でも行っている
設計者は無意識的にも意識的にも、常にモデルを操作しています。設計の成果物であるCADも、構想段階で用いるポンチ絵やブロックダイアグラムも、詳細設計段階で用いる計算式も、全てがモデルです。さらに極論を言えば、人が頭の中で考えていること、それ自体が全てモデルともいえるでしょう。
だからこそ、人は他人が示したモデルを素早く理解することができます。
先の例に挙げたビジネスモデルなどはその最たる例です。多くのビジネスマンはビジネス書にあるビジネスモデルの説明を受けて感心しながら読み進めるものです。
明示できないのがモデル
設計の話に戻すと、実は多くの設計者は自分でモデルを明示するとなると途端に手が止まってしまうのです。
よくあるのが、頭の中では何となくわかっていたつもりのアウトプットが、言語化する段階で混乱してしまうというものです。レンズやLEDなどの光学部品のアライメントを設計する場面を想像してみてください。このときのアウトプットはなんでしょうか？そしてインプットは？
一つの答えはアウトプットが光学特性でインプットが構造特性、というものでしょう。両者の関係性をきちんと明示できていれば、設定した部品公差を関係部門に説明することは容易でしょう。逆にこの関係性を示すことなく、厳しい公差を製造・調達部門に提示したら、調整に手間がかかることでしょう。
モデル化の手を止めるこの他の要因としては、検討範囲がとめどなく広がってしまって収拾がつかなくなる、今まで気づいていなかった要因を見つけてしまい見て見ぬふりをしたくなる、用意したインプットではアウトプットが説明しきれない、定量化できない、など多岐にわたります。
こうして設計者はうまくできない、面倒だと感じてやめてしまうのです。そして、生まれるのが「暗黙知」、つまり明示されず、共有もされないモデルです。
明示されないモデルがもたらすもの
あらためて整理してみると、設計者以外に見えているものはインプットとアウトプットのみで、それぞれ設計に取り入れたパラメータや制約、3DCADモデル、図面、設計書を指します。設計者以外には見えないものはプロセス、すなわちインプットに対してどうやってアウトプットを作ったのかです。これによる問題は色々ありますが、今回取り上げたいのは設計の最適さと再現性に関する2点です。
設計の最適さを判断できない
設計が基準を満たせているかどうかはアウトプットだけで判断できます。しかし、より良い設計解の有無は結果（設計空間上の1点）だけでは判断できません。判断するとしたら、設計者にヒアリングして思考過程（モデル）を白日のもとに晒して検証するか、レビュアーが自分でもモデル化を実施・再現し検証することになります。設計の再現性がない
同種の機能を設計する際にモデル作りから始めないといけません。そして、過去の知見がきちんと活かされるかどうかはモデルを作る人次第になってしましまいます。この点は別の稿で説明する予定です。
これらは、設計におけるモデル化が明示されないことによる問題であり、その解決は設計の効率化だけでなく、組織全体の競争力向上にも寄与します。
第5節：モデル化するには
モデル化の最短ルートは、適切なフレームワークの下で設計者を訓練することです。（※）
この目的に適したフレームワークとしては、システムエンジニアリングとFMEAの併用が有効です。
システムエンジニアリング
システムエンジニアリングのフレームワークは様々ありますが、ASPICEは体系的で分かりやすいです。（ただし、導入や実践が容易というわけではありません。）
自動車産業界がまとめたものですが、内容は汎用的でどの産業でも適用できます。もしかしたら車載向けの厳しい規格やプロセスがまとめられたものと想像されている方がいらっしゃるかもしれませんが、そのようなことはありません。ASPICEではフレームワーク・考え方、設計行為の捉え方を示しています。大枠を理解した上で、各々の設計現場に適した形に落とし込むことが良いでしょう。
システムエンジニアリングにより、設計の全体像の中でどこにフォーカスしているかを明確化できますFMEA
VDA-AIAGが発行しているFMEAハンドブックは網羅的なモデル化の手法を提供してくれます。
これもASPICEと同様に自動車産業がまとめたものであるものの、やはりフレームワークですので、各設計現場において必要な要素を組み合わせることが良いです。
FMEAを活用することは設計の再現性に大きな効果を発揮します。
（※）
AIが論理的な構造を自身で構築する能力を獲得するまでは、まだ時間がかかるでしょう。AIは人間が作ったモデル構造を学習して再現したり模擬したりすることは可能ですが、モデルの作成や検証は当面、人間が担う必要があります。この点については、別の稿で取り上げたいと思います。
モデルが揃った設計
私たちがこれまで見てきたように、設計プロセスのモデル化は、設計の最適性と再現性を向上させるための重要な手段です。
しかし、全ての設計対象をモデル化するのは実際問題としては非常に労力がかかります。事業内容によっては費用対効果の面で全てをモデル化することは不要と判断されるかもしれません。
しかし、全ての設計内容をモデル化できたとしたらどうなるでしょうか？
全ての設計要素をモデルに基づいて結びつけることが可能になります。結びつけられた製品全体の最適設計が実現できるのです。
では、製品全体のような膨大な組合せの最適化はできるのでしょうか？
少し前までであれば費用対効果の観点から夢物語で終わっていたでしょう。しかしAI技術の進捗著しい現在、人間ではできなかった超多変量の最適化は可能なところまできています。モデルが揃っていたら、どのような要求・要件でも設計時間・コストともに限りなくゼロに近いもので設計結果を出力できるのです。これは非常に大きなインパクトをもつでしょう。もしかしたら貴社は全ての設計要素のモデル化に取り組まれないかもしれません。しかし、貴社の競合会社のいずれかが実施してしまったら、その差は取り戻せないことでしょう。
少しずつでもモデル化を進めていきませんか。
この記事が気に入ったらサポートをしてみませんか？