MBSEとモデリングツール

昨今、システムは大規模・複雑化し、その対応策として他のシステムと連携して動作することも増えています。このような状況では、従来にはなかったさまざまな考慮が必要です。例えば、連携する他システムへの考慮が必要です。具体的には、自分のシステムが正常に動作しているとしても、連携する他のシステムが停止したり、他のシステムの動作や連携インターフェースが変わったりする際にどうあるべきかを考慮しなければなりません。また、他のシステムとつながる部分はセキュリティ上の問題点になりやすく、そのインターフェースは外部からの攻撃の入り口になりえます。さらに、自分のシステムに関するデータを他のシステムで保持する場合には、その保持する側が攻撃され情報が漏洩する危険性も考慮しなければなりません。

そうした状況への対応策として最近注目されているのが、MBSE (Model Based Systems Engineering) です。

MBSEとは？

MBSE (Model Based Systems Engineering)とは、その名の通り「モデルベース」の「システムズエンジニアリング」です。システムズエンジニアリングとは何か、の定義については、さまざまなドキュメントや書籍に記載があります。一例として「システムズエンジニアリングハンドブック第4版」では、「システムを成功裏に導くための、学際的なアプローチおよび手段」と定義しています。学際的、つまり、単一の領域で完結するものではなく、複数の領域が対象であり、複数の領域にまたがる知識・経験が必要とされます。システムズエンジニアリングは、対象のシステムの設計と製造だけが対象ではありません。企画・要求定義から廃棄までライフサイクル全体が対象です。

システムズエンジニアリングを実施する場合の手段として、Word/Excelに代表されるようなOfficeツールを用いるドキュメントベースのシステムズエンジニアリングも広く行われています。しかし、こうしたドキュメントベースでは、多くの情報の関係の把握や抜け漏れの確認などは容易でなく、また多くの人が分散・分担して作業を行うことも容易ではありません。そのため、大規模で複雑なシステム、特に「System of Systems」と呼ばれるような、複数のシステムで構成されるシステムの場合には、ドキュメントベースでのシステムズエンジニアリングでは対応が困難です。

こうした背景があり、「モデル」を活用したMBSE、モデルベースエンジニアリングがこうした状況の解決策として注目されています。

なお、前述の「システムズエンジニアリングハンドブック第4版」では、従来型のドキュメントベースのシステムズエンジニアリングと比較したMBSEの利点として「コミュニケーションの改善」「システムの複雑さを管理する能力向上」「製品品質の改善」等を挙げています。

モデルの記述とSysML

「モデル」(あるいは「システムモデル」)についてもさまざまなドキュメントや書籍でさまざまな定義が行われていますが、ここでは「対象のシステムを何らかの観点で抽象化したもの」と定義します。つまり、対象のシステムそのものではなく、対象のシステムに関するさまざまな内容を一貫性・整合性がある情報として表現したものです。その表現方法の1つとしてSysMLがあります。

MBSEとSysMLはセットとして考えられることが多いですが、MBSEを実施する場合にSysMLは必須ではありません。しかし、MBSEを実施する際に、現時点でもっとも広く利用されている表現方法はSysMLです。

しかし、SysMLだけでは対象のシステムの全ての内容を適切に表現できるとは限りません。例えばSysMLだけでなく、フォルトツリー解析(FTA)・脅威モデリングなどの表現方法を組み合わせて利用することもあります。

特に、MBSEはシステムの設計だけが範囲ではありません。例えば対象のシステムの企画のためには、システムに関係する企業やビジネスの分析も必要となるでしょう。こうした分野ではArchimateやBPMNの表現方法が有用です。システムの運用スケジュールはロードマップのような表現が適切な表現方法である場合もあるでしょう。SysMLだけで全てを表現することは容易ではなく、無理矢理SysMLで表現してもわかりづらいものとなるでしょう。

SysMLの作図とモデリングツール

SysMLで定義される要素や関係は、四角形・円・線などの基本的な図形と文字の組み合わせで表現されます。つまり、Visioのようないわゆる作図ツールや、場合によってはExcelやPowerPointのようなOfficeツールでもSysMLの定義に沿った図を作成することは可能です。

一方で、世の中にはモデリングツールと呼ばれるツールもあり、SysMLが利用可能なモデリングツールもあります。これらのモデリングツールと作図ツールは何が異なるのでしょうか。表現を変えれば、なぜMBSEにモデリングツールが必要なのでしょうか。

対象のシステムをモデルとして表現する際には、さまざまな観点に応じた多数の図を利用します。しかし、これらの図は独立したものではなく、いずれも、1つの対象のシステムを異なる角度から表現したものです。つまり、同じもの(対象のシステム)を異なる観点(図)で示したものですので、当然ながらそれぞれの図の内容にはつながりがあります。例えば、ある図の内容を変更すると関係する別の図の内容も変更する必要があります。複数の図として表現された内容の関係・一貫性・影響範囲などを確認できる、いわゆるトレーサビリティの確保も必要です。複数人での共同作業への考慮も必要です。これらの内容は、作図ツールでは実現は困難です。

また、システムを図として表現することには長所・短所があります。目的によっては、図として作成した内容を文章・表の形で表現してその表現で確認するほうが有用です。このような、表現形式の変更も作図ツールでは対応できない範囲です。

一方で、モデリングツールと呼ばれるツールにもさまざまなツールがあります。シミュレーションが可能な高機能なものもあれば、単にSysMLの作図をする程度の作図ツールと変わらないものもあります。価格が高い方が良いツールとは限らない点も注意が必要です。この点は、「UML/SysMLモデリングツールの選び方」にまとめてあります。

Enterprise Architectを利用したMBSE

Enterprise Architectは、SysML 1.5に対応するモデリングツールです。SysML 1.5の作図時には、クイックリンクに代表される、記法に即した作図の支援の仕組みがあるほか、この説明ページに含まれるフォルトツリー解析(FTA)・脅威モデリング・Archimate・BPMNなども同一のモデルとして記載可能で、それらのすべてに対してトレーサビリティの機能で「つなげる」ことができます。例えば、UAF (Unified Architecture Framework) に含まれるロードマップについて、SysMLのブロック定義図をコピーして「ロードマップ表示」「要素間の接続を非表示」とした図を作れば、スケジュールの表現が可能になります。これらは同一のものですので、例えばブロック要素の名前を変えればロードマップの内容も自動更新されますし、片方の図からもう片方の図への移動も容易です。

Enterprise Architectは他のモデリングツールに比べると価格が安いため、MBSEの実現はできないと誤解されてしまう面もあります。しかし、ツールの価格と機能は必ずしも比例しません。次の項の「動画デモ」にあるように、MBSEの著名な方法論の1つであるMagicGridについては、そのドキュメントに記載されているシミュレーションの内容以外はEnterprise Architectで実現できます。

一方で、ツールを購入するだけではMBSEは実現できません。必要以上の機能を持つ高価なツールを購入するよりは、その分をMBSEやSysMLなどの教育や実際の現場でのコンサルティングに投資すべきです。ツールはただの道具ですので、MBSEの実現のためにはシステムズエンジニアリングやSysMLの知識が必要です。MBSEの実施では、先導し伴走する知見者の有無が成功するかどうかに大きく影響します。

弊社では教育やコンサルティングのサービスは提供していません。弊社のようなツールベンダーが提供するものよりも、はるかに良い教育・コンサルティングを提供する専業のプロフェッショナルが日本にも多くいらっしゃることがその理由です。ツールベンダーが提供する「二番煎じ」のサービスよりは、そうした専業のサービスを利用すべきです。

MBSEに関連する動画デモ

動画デモのページには、MBSEに関連する動画デモも多数掲載しています。すべてYouTubeに掲載していますので、いつでも誰でもご覧いただけます。

特に、「その他」の分類にある以下の動画をぜひご覧ください。

Enterprise ArchitectでMagicGridはどこまで実践できるのか？その1
Enterprise ArchitectでMagicGridはどこまで実践できるのか？その2
Enterprise ArchitectでMagicGridはどこまで実践できるのか？その3
Enterprise ArchitectでOOSEMはどこまで実践できるのか？
Enterprise Architectで UAF (Unified Architecture Framework) はどこまで実践できるのか？