システムエンジニアリングとしての SysMLの記事のリンク

青木淳さんが書かれたSysMLの記事が分かりやすかったのでリンクしておく。
ラフなメモ。

【参考】
「システムエンジニアリングで SysML を使いこなす」第1章　概要編－システムエンジニアリングとしての SysML | オブジェクトの広場

「システムエンジニアリングで SysML を使いこなす」第2章　実践編－電光掲示板を設計する(1) | オブジェクトの広場

「システムエンジニアリングで SysML を使いこなす」第2章　実践編－電光掲示板を設計する(2) | オブジェクトの広場

上記の記事を読んで面白いと思った点は2つある。
一つは、SysMLという共通言語が複数の専門家集団の意思疎通に重要な役割を果たすこと。

ソフトウェア組込製品でも、システムの大規模化・複雑化によって、開発作業はハードウェア技術者やソフトウェア技術者に細分化され専門化した。
結局、開発プロセスや開発組織そのものも局所最適化されてしまっている。

一方、市場要求や技術革新によって、どんどん製品や技術が陳腐化していくので、製品自体をその次代の技術に合わせて全体最適化する必要が出てくる。

しかし、今までの日本人が得意とする、すり合わせ技術だけでは、システムの複雑化や市場変化の速度に付いていけない。
そこで、モデルベースエンジニアリングのように、システムアーキテクチャを全体最適の観点で構築し直し、ハード・ソフトの専門家も一緒に開発していくスタイルへ変化せざるを得ない。
そういう場面で、ハード・ソフトの専門家同士で会話するための共通言語となるSysMLが必要となり、役立つのだ、というストーリーと理解した。

確かに、例えば、製品ドメインの専門家、熱力学や電気・ロボットなどの自然科学の専門家、そして、機械学習やクラウド等のソフトウェアの専門家のように、多数の専門家から成る集団で開発する場合、共通言語がなければ、価値ある製品を作ることは難しいだろう。
共通言語だけで解決できるわけではないが、必要条件の一つにはなりうる。

もう一つは、あらかじめ全ての顧客要求や製品の部品やアーキテクチャを決める必要はなく、未決定の要素をリスク管理の対象とみなして開発を進めて、必要な時に随時決定すれば良いこと。

製造業の製品開発ではどうしてもWF型開発になりやすいが、各工程の内部は実際はアジャイル開発っぽい雰囲気が出てくる。
原材料や部品の発注があるので納期厳守でWF型開発が王道だが、中身の開発は試行錯誤が普通。

昨今の開発では、要件を全て決めてから開発する、という流れの方が少ないだろう。
その時に、製品のアーキテクチャをSysMLで表現した時、どの部分の要件が未決定であるか、を明確に区別して管理することは重要になってくる。
その未決定の要件はリスク管理の対象として扱い、リスクが顕在化してきた時に、アーキテクチャを明確に固めていく。

そのプロセスでは、SysMLにあるユースケース図、ブロック図、シーケンス図、アクティビティ図などを使えば、複数の観点でアーキテクチャを分析することで整合性が取られることになる。
つまり、SysMLというモデリング言語によって、リスク管理を支援していることになるわけだ。

そんな事を考えると、設計と開発プロセス、モデリングは表裏一体のように思える。
それらを操れることで、開発をコントロールできるわけだ。