第4次産業革命とも言われているICT（Information and Communication Technology、情報通信技術）の発達により、IoT（Internet of Things、モノのインターネット化）が進展した。その結果、複数のシステムが相互に連携し、これまでにないサービスを提供するSoS（System of Systems）が多く生まれている。一方で、システムに対する要求の多様化・高度化・複雑化に対応できる開発手法の現場浸透は鈍く、開発現場は深刻なリソース不足に陥ってきている。自動車業界において、システム開発への対応として、2020年頃からModel-Based Development（MBD）が試行されてきているが、中流工程以降への適用や、簡単な（複雑でない）設計の見える化に留まっており、複雑化するシステム開発への対応は不十分と言わざるを得ない。
我々は、複雑化するシステムへの設計対応として、設計論に関する理論的背景を持つMBSEに着目するに至った。MBSEは複雑な設計内容の見える化に留まることなく、創発的設計解を生み出しやすくするプロセス能力を持っている。創発的設計プロセスの実現は、望む設計目標の設定と、それを実現する機能分析及び、機能の背景にある主要設計パラメータ間の関係性の見える化が重要であると考えており、SysML及び、推奨設計プロセスであるOOSEM（the Object-Oriented Systems Engineering Method）に関して、効果実証のある実践的ノウハウの蓄積を行ってきた。

SysMLはモデリング言語であり、システムのモデリング方法は利用者に委ねられている。これに対して、MBSEは、宇宙・航空分野を中心に発展してきた、“システムズエンジニアリング”の考え方をベースにプロセスの標準化やモデリング手法の標準化が行われている。システムズエンジニアリングの特徴は、①目的指向と全体俯瞰、②多様な専門分野を統合、③抽象化・モデル化、④反復による発見と進化、のような点にあり、ライフサイクルプロセスモデルはISO/IEC/IEEE 15288:2015（Systems and software engineering — System life cycle processes）で定義されている。そこで定義されている設計プロセスを実現する手法の1つとしてINCOSE（The International Council on Systems Engineering）が提唱するオブジェクト指向概念を背景としたOOSEMがある。我々は、メカ・エレキ・ソフト複合システム開発からソフトウェア開発まで、モデルを使ったシステムズエンジニアリングが実践できるように、設計フレーム“V2 Professor”を構築し、MBSE/MBDを実践している。“V2 Professor”は、運用設計段階では、DoDAF（The Department of Defense Architecture Framework）を採用し、システム構想設計段階では、ISO/IEC/IEEE 15288:2015、IEEE Std 1220-2005（IEEE Standard for Application and Management of the Systems Engineering Process）をライフサイクルモデルとして採用し、設計方法論（Methodology）は、OOSEM、RFLPアプローチ、技術ばらし、QFD（Quality Function Deployment：品質機能展開）、STAMP/STPA（System Theoretic Accident Model and Processes / System Theoretic Process Analysis）、等を採用している。

開発現場では、常に、市場の多様化対応や開発期間の短縮、手戻りの未然防止が求められ、設計・部品の流用率向上、試作回数削減による設計・開発の効率化は必然となっており、プロセスの標準化や部品の共通化、作業の自動化改善を継続している。また、熟練者が個人で保有している属人的なノウハウを若手に伝授していく仕組みの構築も、システムエンジニア不足の解消として喫緊の課題である。このような中で発生した概念“設計DX”は、デジタル化による設計効率化であると勘違いされることが多いが、本来は、今までにない製品の創出や複雑な設計を、ロバスト性を担保しつつ効率的に行うことが目的である。したがって、設計DXの考え方、目的は、MBSEと同じであることから、MBSEの開発支援環境づくりは、設計DXの考え方に基づけば良いことが分かる。

• （1）設計書をデジタル化するだけでは現状は変わらない
  ドキュメントベースの設計書作成では、書き方や読み方が人によって異なる。このような設計書を電子化、ペーパーレス化すること、すなわち、デジタル化は実現できている。さらに、設計繋がりが希薄なままの内容を、モデルという形に押し込めば、エディタを使ってモデル間が繋がっているように見える。これでは、却って設計誤りを増やしてしまう事になりかねない。
  • （a）繋がっているように見えてしまうので、レビューが希薄になる可能性がある。
  • （b）後からまとめてトレーサビリティを取ろうとするが労力がかかるため、適当に関係付けて終わる。
  • （c）設計時にトレーサビリティを考えないため、設計内容が局所最適になっている可能性がある。
• （2）新機能実現の仕組みを創発するプロセス
  システム設計解を決定する前に行う、複数の設計解候補によるトレードオフ解析は、運用時の想定外を極力減らす目的として非常に重要な設計タスクである。トレードオフ用の設計解候補は、一般に、SysMLではない表現方法を使用していることが多いと思われるが、SysMLのパラメトリック図を中心としたモデルにより、その骨格を表現することが可能である。創発そのものはいまだに人にしかできないタスクであるが、パラメトリック図を中心に、その設計根拠を十分に説明する資料を紐付けることができれば、有識者のレビューにより、更に新しい発想が生まれる可能性がある。
  本論文では後章にて、以下のような課題を解決支援する設計フレーム“V2 Professor”関連ツールを紹介する。
  • （a）創発を生みやすい設計プロセス、すなわち、“分析（要求機能の分析）と統合（物理原理に基づく複数の設計解候補案のトレードオフとインテグラル）”を実践しやすくする
    ⇒ 6章モデリングプロセスからの逸脱をチェックする設計支援ツール
  • （b）機能のモジュール化により、適切な機能的インタフェースの見える化を実現する
    ⇒ 7章モジュラー設計の効率化支援ツール

次章では、システムズエンジニアリングのツールチェーンの実現に必要な設計プロセスの理解の程度を、もう少し詳しく説明する。

David Long、Zane Scott（MBSEソリューションの一つGENESYSを作成しているVitech社）は、図1に示すように、古典的SE（システムズエンジニアリング）と階層的MBSEを比較し、階層的に問題を解くアプローチこそがMBSEの核心である（階層的MBSE）と説明している。

図 1. 古典的SEと階層的MBSE^（1）

左：図2 2元Vee^（2）　右：図4 階層的MBSE（図1右半分）

階層的MBSEは、SEBoK（The Guide to the Systems Engineering Body of Knowledge）で定義されている2元Veeとみなすことができるので、2元Vee（2元V字）の具体的なプロセス実現の一つがMBSEであるとも言える。2元Veeでは、レイヤの横方向の要求（RQMTS＝Requirements）／機能的振る舞い（BEHAVIOR＝Behavior）／アーキテクチャ（ARCH＝Architecture）のみならず、縦方向にも同様のプロセスが想定されている。
横方向（Entity Vee）は、そのレベルの成果物を作成するプロセスを意味する。縦方向（Architecture Vee）は、システムレベルの要求、アーキテクチャ設計、コンポーネント設計である。図2の縦方向の階層と図4（図1の右半分）のLayerは、図3のとおり同等の関係にある。従って、図2の縦方向の階層ごとにアサインされたエンジニアチームに求められるスキルの違いが、図4のLayerごとにアサインされるエンジニアチームにも現れてくる。一般的に、設計初期に考えるステークホルダ要求に対応するシステム要件は、ステークホルダ要求からシステムの設計解を求めるための仮説である。図4のLayer1（要求）には、開発対象システム全体に関する幅広い知識を持ち、初期の仮説的なシステム要件と最終の設計解を整合させることのできるエンジニアで構成するチームをアサインすることが求められる。Layer2（機能的振る舞い）には、システムアーキテクチャ設計に長けたチーム（アーキテクト）、LayerN（最下層レイヤ）には、メカ／エレキ／ソフト／制御の開発専門チームをアサインすることで、製品の特質に合わせて組織能力を活かせるプロセスを実現することができる。これは、ソフトウェア開発分野では、ドメイン駆動と言われてきた開発の考え方であり、ここでもソフトウェア開発のベストプラクティスの考え方が活かせる。

表1 モデル分類

設計を効率的に進めるためには、システムズエンジニアリングツールチェーンは上記のモデル全てを表現し、それらを相互に連携できる必要がある。以下は当社にて連携を考えつつ、試行しているツール群の一部である。

図6 ツールチェーンの概要

表2 利用実績（検討中含む）ツール一覧

既製ツールをツールチェーンとして活用するためには、各ツールが扱うモデルのデータ構造の違いを吸収すること、つまり、ツール間で連携するデータが項目単位で正確に対応づくまで、データ合成や分解を繰り返すデータマッピングの考え方が必要となる。現在は、異なるメーカーのツール間をつなぐデータマッピングは部分的にしか実現できておらず、今後の課題である。
例えば、図4の、階層化MBSEのLayer1で使うツールを考えてみる。開発対象システムの要求（RQMTS）と機能的振る舞い（BEHAVIOR）を、1DモデルとしてSysMLにてシステムモデルを作成し、そのモデルに基づいて、3Dモデルとしてアーキテクチャ（ARCH）：システムのLayer1における設計解を求めたとする。このとき、1Dモデルや3Dモデルの設計妥当性確認は、1D-CAE（Computer-Aided Engineering）、3D-CAEと呼ばれるシミュレーションツールを活用する。ここで重要なのは、その階層の抽象度にあったプラントモデリングを行うことである。シミュレーションモデル作成には、プラントモデリングツールを利用するが、設計検証用としてシミュレーションを利用するので、設計モデルの抽象度レベルに応じたシミュレーションモデルを利用することになる。例えば、Layer1のシミュレーションモデルを、それ以下の階層のシミュレーションモデルの抽象度（詳しさ）と同じにしてはならないのである。各階層の検証用シミュレーションモデルは、それぞれ別ものとして管理することも必要である。
新製品・新機能を開発する際、抽象度の高い1Dモデルから3Dモデルに具体化・具現化していく場合と、現物的な3Dモデルから抽象的な1Dモデルを作成する場合がある。後者は、多くの設計変数を持つ3Dモデルから目的変数に相当する変数のみを残し1Dモデルとするので、モデル縮退（MOR：Model Order Reduction）と呼ばれる。現物を完全にシミュレーションすることは現実的（時間的、技術的）に不可能な状態において、次元を落として解析時間とデータの容量を大幅に削減して主たる機能を表現する。1Dモデルを使う機能設計においては、システムの要求を満たす目標値を決定し、構造設計へ続ける。さらに、3Dモデルを適用した構造設計では、目標値となるように構造を探索、その結果を1Dモデルへフィードバックして、機能設計を修正する。1Dモデルから3Dモデルへの一方通行ではなく、機能設計と構造設計をサイクルで回すというのがポイントである。このサイクルを円滑に回すためにも、モデリングツールとシミュレーションツールや他計算ソフトウェア等との連携及び、抽象度を合わせた開発プロセスが不可欠になる。つまり、SysMLモデル（1Dモデル）と3Dモデル間のパラメータ（設計変数）連携を構築することで、設計効率化を図ることができる。
さらに、既製ツールでは開発プロセスを埋められない部分に関して、自製ツールを開発して埋めようとしている。次章以降、その例を示す。

SysMLは統一されたモデル作成方法を提供してくれるが、モデリングプロセスルールには自由度があり、利用者自身が定めた設計プロセスに沿って、その内容を定める必要がある。特に、大規模システムに適用する際には、設計プロセスと利用モデルの関係性を、利用者自身がモデル利用ガイドとしてまとめて、モデリングプロセスルールを明文化することがある。その例としては、要求図と要件記述している平文との関係性、要求図とユースケースの使い分け、作成図間のトレーサビリティの取り方等である。それらのモデリングプロセスルールを逸脱していないかチェックして、モデル設計作業が円滑に進むように支援するツールが、本章で紹介するV2 Professor Model Design Partnerである。

「MBSEを実践したら、誰でも効率的な設計ができるようになりますか」という質問を受けることがある。MBSEは、大規模・複雑なシステムを実現する「体系的な考え方」であり、開発現場がMBSEを実践しようとすると、考え方を具体的な手法・手順にする必要がある。従って、質問に対する答えは、「MBSEを正しく理解して、正しく実践できるような環境を整えれば、今よりは開発効率が良くなる」である。これは、「考え方は分かったが具体的にどうすれば良いかを教えて欲しい」という質問の答えでもある。
本稿は我々なりに理解した「MBSEを実践していく方法」の一部である。我々は“V2 Professor”として設計プロセスのノウハウを見える化することを目的とし、モデル間のトレーサビリティが確保できる標準設計ガイドラインを整備するところから始めた。10年以上に渡って現場での実践とフィードバックを繰り返してきた結果、MBSEによるパラダイム変換をより一層実感している。これまで、V2 Professorを実践する中で、貴重な改善情報をフィードバックしていただいたお客様、当社での実践者の皆様に感謝申し上げるとともに、さらに、MBSEの効果を出せる具体的手法を届けられるよう継続努力していく所存である。