本ブログのタイトルにもあるSysML、SE（Systems Engineering）やMBSE（Model Based Systems Engineering）に携わられている方には馴染みの深い言葉かと思いますが皆さんはSysMLと聞いてどのようなイメージを思い浮かべるでしょうか？「SE/MBSEで使用される言語」「多くのダイアグラムがある」といったイメージをお持ちの方、あるいは「名前を聞いたことしかない」「難しそう」といった方もいらっしゃるかもしれません。
最近ではSysMLという言葉は広く知られるようになってきましたが、まだSysMLを業務で活用されている方は少ないのではないでしょうか。本ブログではこうしたSysMLの概略や背景、SE/MBSEでの活用方法について御紹介します。
まずSysMLと一緒に語られることの多いMBSEから話を始めます。
「実践できるMBSE！導入方法やソリューションをISIDから提案」では、「MBSEは課題解決の手段である」とご説明しました。図1にMBSEによる課題解決の流れの概略を示します。
図1で示す通り、SysMLでモデルを作る前に、まず課題の選定や解決策の検討、情報の繋がりや粒度・階層の整理が必要です。またSysMLでモデルを構築した後にも、情報を取り出して関係者が活用するための仕組み作りが必要になります。このように課題解決の流れにおいてSysMLモデルの占める領域は広くはなく、SysMLはMBSEによる課題解決の本質ではありません。図1ではSysMLでモデルを構築していますが、SysML以外の手段でモデルを構築しても構いません。
しかし一方でSysMLはSEの標準言語として世界的に使用されており、SysMLを使ってモデルを構築することのメリットも確かに存在します。
SysML（Systems Modeling Language）はSEのドメイン固有モデリング言語です。SysMLには9種類のダイアグラムが用意されており、各種システムの仕様記述、分析、設計、検証、評価に使うことができます。また標準化コンソーシアムであるOMG（Object Management Group）ではSysMLに関連する認定試験も提供しています。
| ダイアグラム名 | 説明 |
|---|---|
| 要求図 | 要求を記述し、要求同士、あるいは要求と他のモデル要素の関係を表現する |
| パッケージ図 | パッケージやパッケージ間の関係を表現する |
| ブロック定義図 | システムを構成する要素の型を定義し、要素間の関係を表現する |
| 内部ブロック図 | 構成要素の内部構造間の関係や役割・利用方法を表現する |
| ユースケース図 | システムが実行するユースケースや、参加するアクターを表現する |
| アクティビティ図 | システムの作業や処理の流れ、データの流れを表現する |
| ステートマシン図 | システム内構造の、イベント発生や時間に応じた状態変化を表現する |
| パラメトリック図 | 1つ以上の制約条件とシステム特性の結びつきを表現する |
| シーケンス図 | 時間経過に伴う振る舞いやイベント発生の順序を表現する |
図3に示す通りSysMLは、要求・振る舞い・構造だけでなく、状態遷移や時間推移、さらにはモデル全体のコンテキストやユースケース、ライフサイクルも表現できます。また新しい概念を定義するためのstereotypeなども用意されています。これらの機能により、一つのシステムを様々な観点から確認して必要な情報だけを抽出し、ある概念に沿って整理することができます。
図2に示す通りSysMLは、ソフトウェア工学で用いられるモデリング言語、UML（Unified Modeling Language）の言語仕様を拡張することによって作成されており、システムズエンジニアリング領域に特化した言語仕様となっています。SysMLはUMLをベースとしているためソフトウェア技術の側面が強く残っています。将来リリース予定のSysMLv2ではメタモデルをKerMLに変更することでより自由な表現が可能となる予定です。
詳細につきましては以下の記事をご覧ください。
SysMLは標準言語であるため記述方式が統一されており、国や企業に依らず使用できることが大きなメリットです。独自の書式でモデルを記述してしまうとOEMやサプライヤなど外部企業とモデルをやり取りする際に意図が伝わらず、手戻りが発生する場合があります。しかし標準言語であるSysMLで記述していると意図が伝わるため手戻りの発生を減らせます。またSysMLでモデルを作成しておくことで、外部から新規メンバーが加入した際にもSysMLを知っていれば容易に理解できるというメリットもあります。
国や企業に依らない、人に依存しない、という点は、国境を越えた協業が多く、日本より人の入れ替わりが盛んな欧州では大きなメリットと捉えられ、SysMLの活用が進んでいます。
さてこのSysMLですが、「対象製品を忠実に表現した、大規模なSysMLモデルを作ったが誰にも使われていない」という話もよく耳にします。対象製品をモデル化するために膨大な工数と費用をつぎ込んだ結果、対象製品の詳細情報まで含まれた大規模モデルは作成できたが、ほとんど使われることなく、フォルダの奥にしまい込んである―こうした経験をお持ちの方もいらっしゃるのではないでしょうか。
このような事態を避け、業務でSysMLモデルを活用するためには、図1で示したように、モデルを作成する前に「どのような課題を解決するためにモデルを使うのか」「業務のどこでモデルを使うのか」「どのような情報を提示するためにモデルを使うのか」といったことを考えることが重要です。解決したい課題や、提示したい情報が明確になればモデルに含める情報のスコープや粒度も明確になりますし、どのように情報同士を紐づけておけばよいのか、確認できるようになります。
図5は、ドローンの開発を例に図1の内容を具体化した図です。SysMLと言うとどうしてもモデル作成に目が行きがちですが、実際にはユーザー環境の構築やモデルの運用・保守など、モデルを業務で活用し続けるための仕組み作りもモデル構築と同様に重要となってきます。
ここからはSysMLの活用を支援するツールについてご紹介します。SysMLのダイアグラムを描き表示させるだけでなく、情報を見やすい形で取り出せる、簡単に情報を入力できる、といった点もツールに求められる役割となります。
図6はSysMLモデルの活用例を表現した図です。SysMLに準拠したツールであるCATIA Magicに搭載されているExcel出力機能を使用することで、要件・要素・タスク情報や日程情報を外部に出力して、電通総研製のツール、iQUAVISで表示させることもできます。iQUAVISの日程管理機能を使う事でSysMLに不慣れなユーザーも簡単にタスクやプロジェクトを確認することができ、日常業務の中でSysMLモデルを活用できるようになります。
またCATIA Magicのレポート出力機能を使う事で必要なダイアグラムだけをPower Point資料として必要なメンバーに提示することもできます。（このようなCATIA Magicの各機能につきましては、改めて別のブログでの紹介を予定しております。）
さらに様々な情報を一元管理するデジタルダッシュボードをSharePointで提示するなど、SysMLモデルの変更に連動させて様々な役割の人に必要情報を提示することができるようになります。
SysMLについて主に業務活用という観点でご紹介しました。SysMLでモデルを構築しダイアグラムを描くだけではなく、その前段の課題抽出や解決策の明確化、情報の繋がりの整理、ITを駆使した業務適用などによって、初めて業務が改善されることがご理解いただけたでしょうか。
初めの方で申し上げた通り、モデル化はSysML以外の方法でも構いません。しかし世界的にSEの標準言語として使用されており、多様な観点から情報を抽出できるSysMLは、モデル化の有効な候補であることは間違いないと思います。
さて本ブログでは今後もSysML2.0の動向や、CATIA Magicを使った様々なモデル化、役に立つTipsなどを紹介していく予定です。今後もご期待ください。また電通総研ではCATIA MagicやSysMLに興味をお持ちの方向けにCATIA Magic One Day Workshopも無償提供しております。こちらもぜひご活用ください。
本記事は役に立ちましたか？コメント・問合せも承ります。
