MBSEとシミュレーションとをつなぐMBD

大規模な開発プロジェクトの失敗、複雑な製品開発での手戻りの悪循環、という話を耳にすることがしばしばあります。これらはなぜ起きるのでしょうか？どのようにしたらうまく行くのでしょうか？これを考えるカギは「複雑性への対応」にあり、社内の知見を「集合知」として活用しながら開発ができるようにすることが重要です。それを実現する手段が「MBSEとシミュレーションとをつなぐ」ことです。日本ではこれを（広義の）MBDと呼ぶことが増えてきましたが、そのやり方は一般的には定義されていませんので、そのポイントを考えてみましょう。

Systems Engineering[SE]：全体俯瞰と細部集中のバランス

「木を見て森を見ず」ということわざがあります。これは物事を全体俯瞰することと細部に集中することのバランスの大切さを述べたものです。従来は、「製品全体の集合知を持ったベテラン」が全体俯瞰と細部の集中のバランスを取ってきたと思われますが、昨今は、製品が複雑になりすぎたりベテランが減ったりして、そのようなやり方が難しくなってきました。最初に記した、大規模な開発プロジェクトの失敗や複雑な製品開発での手戻りの悪循環は、そのような場合によく起きていると考えられます。

こうした状況に対応するための考え方がシステム工学（Systems Engineering[SE]）と呼ばれるものです。開発したいものを「システム」としてとらえて分割し、その部分の専門家の知見を集合させ、「部分の詳細は把握していないが全体をシステムの視点で俯瞰をする役目」の人（システムズエンジニア）を据えることで、全体の開発を成功に導く考え方であり、「V字モデル（V字プロセス）」を用います（図1）。V字の左は、開発すべきものへの要求分析から、必要な機能を階層的に洗い出しながら目標を下の階層に落とし、その実現方法（アーキテクチャ）を決めてゆく過程であり、右は、アーキテクチャに沿って（モノでの階層を登りながら）機能の実現を検証する過程です。そしてそれぞれの階層を「一人の人間が俯瞰できるレベルの複雑さ」にすることで、どれほど複雑なシステムであっても開発可能になるということです。

図1：システムズエンジニアリングのV字

「ン字」プロセスは日本の製造業の特徴

ここで、日本の製造業の開発の仕方をこのV字プロセスに当てはめてみましょう。すると、「開発目標が決まったら従来製品をベースにした詳細設計から始めてしまう」ために、Vの形になっていない場合がほとんどであることがわかります。この形がカタカナの「ン」に似ていることから、これを我々は「ン字プロセス」と名付けました（図2）。このようなプロセスになったのは、明治以降急激に西洋の製造業のやり方を取り入れた日本の歴史的背景があったと分析されます。すなわち「欧米で開発されたものをうまく真似して、それでもン字の右で試作＆修正を高速で実現できたので、より品質の良いものを安く作る」ことができていたわけです。その成功体験がシステム思考での製品開発に舵を切るのを妨げているとも言えます。日本の製造業が、大規模プロジェクトの失敗や複雑な製品開発での手戻りの悪循環を減らすには、今までのやり方ではうまく行かないことを認識して、この「ン字」をV字にしていくことが重要なのです。

図2：日本の製造業で典型的なン字プロセス

MBSE（Model Based Systems Engineering）：洗練されたSE

Systems Engineeringという言葉が出てくるのは、1960年代頃からで、超巨大で複雑なシステムを開発する必要性に伴って考え出されたものです。例えば、アポロ計画に代表される宇宙開発、アメリカの広い国土に大規模電力網を敷くための計画などが有名です。はじめは、要求分析も機能分解も仕様の記述も、全て文書でしたので、資料を作製するのも、それを他の人が読むのもとても骨の折れる泥臭い作業でした。

「図示的な表現」を用いることで、書類だけでは把握が難しかった「システム記述」をわかりやすく表現してSystems Engineeringを進めようというやり方が、1990年代から出てきました。これがMBSE（Model Based Systems Engineering）です。すなわち、頭についた「MB」とはシステムを表現する「記述モデル」のことです。広く採用されている記述モデルがSysML（System Modeling Language）です。すなわちMBSEによって、システムズエンジニア的視点での集合知がより多くの人に見えやすくなったと言えます。しかしこの状態では、部分の詳細の知見は集約されているとは言えません。これを次に述べます。

MBD：SEによる製品開発でシミュレーション（CAE）をシステマチックに使う

Systems Engineeringには「工学（Engineering）」という言葉が入っています。岩波国語辞典には、以下のように書かれています。

工学：役に立つ（世の中に価値を生む）生産物を得るために、計画・設計・製造・検査の段階に基礎的科学を応用する技術の総称

すなわち「工学」は、そもそも目的志向の学問なのです。だから、Systems Engineeringが「要求分析」から入るのは工学として当たり前であり、工学をシステマチックにやろうとしているだけ、とも言えます。ちなみに、INCOSEというSystems Engineeringの国際会議では「Systems Engineeringは、工学だ！（SE is Engineering！）」という話をよく聞きます。

基礎的科学は、目の前にあるものを調べて（実験して）理解するところから始まりましたが、特に物理の分野から「理論を数式で表現して、現象を予測する」というやり方が広まりました。そしてその理論を用いた計算を効率化するのが「コンピューターシミュレーション」であり、そのためのモデルが「計算モデル」です。このシミュレーションの計算ロジックには、各分野の詳細な理論（知）が詰まっているわけですから、Systems Engineeringにコンピューターシミュレーションを組み合わせて初めて、従来ベテランエンジニアが担っていた「集合知」を発揮することができることになります。本ブログで述べようとしていることは、まさにそこなのです。

シミュレーションをシステマチックに使用するという点では、制御系の開発分野が先行していました。それはV字プロセスに載せて、計算モデルでのバーチャルな検証[MILS, SILS]、あるいはリアルとバーチャルを組み合わせること[HILS]を適切に使い分ける考え方です。これをMBD（Model Based Design, Model Based Development）と呼びました。すなわち、この「MB」は「計算モデルを使う」という意味です。

近年は制御系のみならず、システム全体を計算モデルでシステマチックに検証しながら開発してゆくことをMBDと呼ぶことが増えました。この「制御のみではなく開発全体に適用するMBD（広義のMBD）」には、実は明確なやり方の定義がありません。欧米では、システムズエンジニアとアナリスト（計算実施者）とは完全に分業化されていて、アナリストはシステムズエンジニアの要望に応じた計算は実施するが、システムズエンジニアはシミュレーションのことがわかっていないので、どのような計算を要望するのが望ましいかをわかっていないと聞いています。すなわち、そのインターフェイス部分がシステマチックではないのです。

「MBSEとシミュレーションとをつなぐMBD」とは？

では、広義のMBDをシステマチックに実施するためには、どういうポイントが必要でしょうか？Systems Engineeringで重要な概念は「複雑なシステムを分割して階層的に考えることで、それぞれの階層は一人の人間が俯瞰できるレベルにすること」でした。この考え方と計算モデルを組み合わせるということは、必然的に一つの重要なポイントが導かれます。

重要なポイント1：V字の左側のそれぞれの階層に適したモデルで検証すること

SEで階層的に考えているわけですから、それを検証する計算モデルも、各階層で必要であるという当たり前のことです。このイメージを、図3に示します。

図3：MBSEとMBD（CAE）との連携イメージ

次に、左Vの各階層では、目標の連鎖が重要でした。それを考慮すると、各階層の計算モデルは、上位で決めた目標を達成できるかどうかを下位の計算モデルで検討できるようにしなければなりません。これが2つ目の重要なポイントになります。

重要なポイント2：目標の連鎖を実現するように、各階層のモデルを「中間特性」でつなぐこと

このためには、各階層の計算モデルは、「上位の層で定義した特性の目標」の達成を検討できるように作成することが必要になります。このように階層間を目標としてつなぐ特性を「中間特性」と名付けました。

このポイントを具体的に示すために、単純なベンチの座面の構造検討でのイメージを図4に示します。
上位層では、「曲げ応力」と「座面最大たわみ」の目標を満たすように「座面の断面係数」と「断面二次モーメント」の満たすべき範囲を決め、下位層では、この断面係数と断面二次モーメントの範囲（ある値以上）を満たすように座面の断面寸法を決めます。このように階層で分けることで、上位の目標割付はそのままで、下位のアーキテクチャ（ここでは断面形状パターン）を変えることができるために、設計範囲が広がるのです。

従来のシミュレーションのやり方としてついやってしまいがちなのが、下位の式を上位に代入してしまうことです。図4の例で言うと、矩形断面と決めてしまって、b, hをパラメータとしてシミュレーションするということです。モデルが一つになって一見楽に見えますが、そうすると「矩形断面」というアーキテクチャを変えることができなくなりますので、全体俯瞰をすれば見えてくる「他の断面の可能性」を消してしまうことになります。

現在の製造DXの技術を使えば、階層を持たせて人の判断を残したままで、省力化したいところはとことん自動化するシステムを構築することも可能になっています。

図4：ベンチの板の構造を決める階層とそれを結ぶ中間特性

3つ目に、SEで階層的に考える際にはV字の左側は「機能で考える」ことが重要でしたが、製品（システム）には要求が複数あり、それを満たすための機能もそれぞれ複数あることを考えると、必然的に3つ目の重要ポイントが導かれます。

重要なポイント3：目標の連鎖を検討する階層は、必要な目標とその機能ごとに複数作成し、その複数の目標間の背反を検討できるようにすること

複数の目標は全く別の分野の可能性が高く、これらを統合的に検討するシステムを作製しても現状の計算環境では非常に重いシステムになってしまい、現実的ではないでしょう。QFDのように複数の分野の背反を可視化して検討順序を考えやすくしたり抜け漏れをなくするようにするやり方が望ましいと考えられます。

自動車の複数性能に関する機能と、それに対応する「中間特性」との関係性を二元表で表した例を図5に示します。

図5：複数性能の背反検討のための二元表

まとめ

大規模な開発プロジェクトの失敗、複雑な製品開発での手戻りの悪循環はなぜ起きるのか、どうすればいいのか？という問いに対して、システムとし分割すること、日本の製造業での開発の仕方の特徴から、そもそも工学（Engineering）で目的志向の考え方で目標を階層的に落とすことの重要性を述べ、「MBSEとシミュレーションとをつなぐMBD」で、その解決に向けて「企業の集合知を結集」した開発の仕組みを作ることができることを示しました。そして、その具体的なやり方のポイントを3点挙げました。

ISIDは、この重要なポイントを踏まえつつ、製造業の各社様ごとに適した具体的なやり方を定義する支援をし、さらにはそのために必要なシステムを構築し、運用していくためのご支援を提供しています。ぜひ、ご相談ください。