「SysMLによるシステムモデリングの実際　－システムモデリングの取り組み（３）－」

この連載では、システムモデリングの支援をしているコンサルタントが、実際の活動を通して得られた知見を元に、各メーカーがSysMLによるシステムモデリングに取り組む動機や取り組みの内容、取り組みの成果を紹介しています。

第1回と第２回の記事では「システムモデリングに取り組む動機」と題して日本の製造業に蔓延る問題を紹介し、各メーカーに共通している5つの本質的な問題を挙げました。

このうち、「組織の壁」に対する対策を第3回、「ニーズ・課題との乖離」と「ノウハウが伝わらない」に対する対策を前回の記事で紹介しました。今回は、「部分最適から抜け出せない」と「目的や根拠が曖昧」に対する対策を紹介し、最後に全体をまとめます。

要求をもとに機能と部品を分けて検討し、機能を実現するための最適な方式や部品を複数の候補から選択します。これは３０年以上も前から当たり前に行われている（いた）システムエンジニアリングそのものです。この当たり前の行為が、第２回の記事で述べたように派生開発の繰り返しによって、開発現場で実践されなく（できなく）なっています。部分最適から抜け出すためには、今一度、システムエンジニアリングの基本に立ち戻る必要があります。

図 2は、機能と部品の分離の概念図です。機能展開と部品展開を別々に実施し、機能と部品の末端同士を割り当て、その中から最適な組み合わせを選択します。一見簡単そうですが、すんなりこのような図ができあがることは稀です。

最も多いのが、機能展開をしているつもりが、いつの間にか部品展開になってしまうパターンです。例えば、車の機能展開にエンジンが登場してしまいます。エンジンの機能（役割）は何でしょうか。それはひとつでしょうか。機能展開では、これらをよく考える必要があります。つまり、機能展開をするためには、システムの本質を的確に捉える必要があります。

また、候補として挙がる部品（方式）の選択肢が少ないというパターンも良くあります。例えば、荷物を垂直に上げ下げする必要がある場合に、ソフトウェア視点では、センサを駆使して複雑な制御で実現しがちです。しかし、メカ視点でもアイデアを出すことができれば、簡単なリンク機構で実現できるかもしれません。専門家は特定の分野には精通しているものですが、それが裏目に出ると、その専門性のみで物事を解決しようとしがちです。より良い選択肢を増やすためにも、様々な視点で実現方式を検討できると良いです。

機能と部品の割り当ての最適化については、いろいろな観点で評価する必要があります。対象とするシステムの特性によって一概には述べられませんが、例えば、IoTのようなシステムでは、処理負荷や通信負荷などを考慮する必要があります。

図 3は、PCと装置の役割分担の検討例です。

SysMLのアクティビティ図で、動作（やること）やモノ（情報）の流れを分析し、PCと装置に対する動作やモノの割り当てパターン（方式）を可視化しています。方式1の場合は、PCと装置の間で情報1を受け渡します。一方で、方式2の場合は、情報2を受け渡します。通信頻度や通信量などを考慮してどちらが適切か判断します。また、受け渡す情報が異なるため、PCと装置のそれぞれが担う動作にも違いが生じます。方式１の場合は装置の負荷が高いですが、方式２ではPCの負荷が高くなります。

方式選択の評価は必ずしも定量的である必要はなく、定性的な評価でも十分な結果が得られることがあります。定性的な評価で方向性を定め、詳細を定量的に検討するなどのように、段階的に方式を選択すると軌道修正がしやすくなります。

「機能と部品の割り当ての最適化については、いろいろな観点で評価する必要があります。」
と先に述べましたが、その評価項目は要求分析の結果と紐付いていると、方式選択の目的や根拠が明確になります。図 4にその概念図を示します。

要求分析の際に、要求を目的－手段の関係で特定の方式に依存しないレベル（仕様）まで展開します。仕様が要求と結びついていることから、まず各仕様の妥当性や影響範囲を判断することができます。また要求の発生源である利害関係者や要求される状況などを元にして、各仕様の重要度などを判断することも可能です。そして論理的に展開された仕様を方式選択の評価項目として活用することで、客観的に方式選択を評価できます。

例えば、図 4の場合、方式１と方式２の○と△の数は一緒ですが、要求展開を根拠にすると、仕様４の重要度が低いと判断できるため、総合評価では方式１を最も高く評価しています。

ここで説明したのは方式選択における根拠の明確化でしたが、同じように、目的－手段の関係で要求を展開し、システムの様々な設計結果と結びつけることによって、設計過程における各種判断の目的と根拠を明示し、残すことができます。

全５回にわたって、SysMLによるシステムモデリングの実際を紹介してきました。扱う製品や技術、企業の文化や強みなどの違いによって、表層の課題は様々です。しかし、多くの企業が似たような背景の中、共通の課題を抱えています。この共通の課題に対して、システムモデリングを適用することで、企業の課題解決を促進できます。
ただし、一朝一夕に効果が出るものではありません。テーマを絞って短期間で実施したプロジェクトもありますが、人材育成と絡めた数年がかりでの取り組みが大半であるのが実際です。

システムモデリングを有効な道具として使いこなすためのポイントを述べて、この連載を終わりにします。

改善活動を進めるにあたり、既存のやり方をすべて捨てる必要はないですし、現実的ではありません。まずは、どこが課題かを見極めるところから始めましょう。現場ごとに文化や強み、置かれている状況は様々です。画一的なやり方を押し付けても現場では受け入れられません。現場の特性を踏まえて、活動していきましょう。モデリングを始めると、モデリング自体に目が行きがちですが、モデリングした結果の共有や検討が重要です。そして、利害関係者を巻き込んでこそ、モデルは真価を発揮します。