高田広章 教授・David Hetherington 氏の特別講演と、村上和幸 氏の講演と懇親会

SYSMOD を構成する主な要素

SYSMOD が何を定めているのかは、SYSMOD のオントロジーを見ることで理解できます。誰が（Role）、何を（Process）、どんな手法で（Method）行うのか。その作業には何が入力され、何が出てくるのか（Product）。方法論（Methodology）は、これらの組み合わせです。ツール（Tool）は、そのうちの Method を助けるものとして位置付けられています。

図の中で Tool から出ている線は、Method を助ける（facilitates）1 本だけです。関係が集まっているのは Method のほうです。

SYSMOD のドメイン知識モデルは、この構造を主要な概念とその関係として描いたものです。それぞれの概念は、次のように定められています。

• Role（役割）： 手法を実行し、成果物に責任を持つ人に求められる力量プロファイルを表します
• Method（手法）： システム開発において意味のある成果物を作り出す、一連の作業のまとまりです
• Product（成果物）： 手法への入力となり、手法から生み出されるもの。その責任は Role が負います
• Process（プロセス）： それらの手法をどの順序で実行しうるか、筋の通った基本的な流れを示します

役割ごとの力量（Skill & Competence）

直前の Figure 1.1 に、方法論を構成する要素のひとつとして Role がありました。SYSMOD は、その役割ごとに求められる力量も定めています。次の図は、システムテスタの力量（6段階、力量0 = スキル無しを含むと7段階）を9つのスキルに対して定義したものです。

Tim Weilkiens SYSMOD – Pragmatic MBSE with SysML 第3版より。掲載許諾を得ています。

テストが突出し、SYSMOD・SysML・工学分野がそれに続きます。プログラミングやシステムアーキテクティングは相対的に低い。役割ごとに、求められる力量の形が違うことが一目で分かります。

これが力量管理の基です。 力量が管理されていなければ、プロジェクトに適切な経営資源を割り当てることができません。誰をどの役割に就けるのか、その判断の根拠がないまま人を配置すれば、プロジェクトは滞ります。プロジェクトの遂行に、力量管理は欠かせません。

SYSMOD のプロセス

方法論は、そのまま持ち込んで動くものではありません。組織は、さまざまな方法論を自分たちに合う形へテイラリングして適用します。SYSMOD は、そのプロセスも定義しています。

図の上段は、組織の上位層・間接部門・支援部門が行う仕事です。方法論を組織へ導入する Adoption Process と、それを支える Infrastructure Process。下段は、組織が用意したものを使う層です。Analysis Process と Architecture Process を、プロジェクトマネージャ・要件エンジニア・システムアーキテクトが担います。

一見すると、誰にでも描けそうな図です。けれど、こうした図があることで、複雑に見える構造が簡単に示されます。簡単になるから理解でき、理解できるから対話ができる。MBSE 方法論が現場にもたらすのは、この順序です。

SYSMOD インフラ構築プロセス

前節のテイラリングは、このプロセスの最初の活動です。方法論を自分たちに合う形へテイラリングする（Tailor the MBSE Methodology）。そこから3つの流れが同時に進みます。組織へ展開する（Deploy the MBSE Methodology）、教育と伴走を用意する（Provide MBSE Training and Coaching）、モデリング環境を整えて保つ（Set up and maintain the SME）。

このプロセスの成果（outcome）は、組織に合わせた MBSE 方法論が展開され、それを回す環境と、使い手の力量が揃っていることです。その成果を支える成果物（outputs）は3つです。

• MBSE 方法論 ― 組織に合わせてテイラリングされたもの
• システムモデリング環境（SME: Systems Modeling Environment） ― それを実際に回すための環境
• MBSE トレーニング ― 使う人が力量を身につけるための教育プログラム

方法論だけを配っても、組織は動きません。テイラリングした方法論と、それを回す環境と、使う人の訓練。3つが並んで進むことが、図に描かれています。

SYSMOD 要件分析プロセス

MBSE 導入プロセスとよく似た形をしています。違うのは、対象とするシステムです。導入プロセスが扱うのは MBSE 方法論そのものでしたが、分析プロセスが扱うのは、これから開発しようとしている製品です。同じ型を、対象を変えて当てています。

対象とするシステムを System of Interest（SoI）と呼びます。SoI は、工学的につくられたシステム（Engineered System）に限りません。組織、組織体、マネジメントシステムなど、構成要素から成るものはすべてシステムです。方法論も、役割と責任、求められる力量、手法、プロセス、成果物から成ります。MBSE 方法論になると、そこにモデリング言語とモデリングツールが加わります。方法論もまたシステムであり、そのシステムを分析して、組織や組織体に合ったシステムに仕立てることができます。

このプロセスの成果（outcome）は、問題と目的が明らかになり、誰のどの要求に応えて何を作るのかが、ステークホルダーと合意されていることです。その成果を支える成果物（outputs）は次のとおりです。

• ベースアーキテクチャ（Base Architecture）
• ドメイン知識（Domain Knowledge）
• 要件（Requirements）
• リスク（Risks）
• ステークホルダー（Stakeholders）
• システムコンテキスト（System Context）
• システムアイデア（System Idea）
• システム目標（System Objectives）
• システムプロセス（System Processes）
• システムユースケース（System Use Cases）
• ユースケースアクティビティ（Use Case Activities）

これらは別々の文書ではありません。1つのモデルの中で互いにつながっているからこそ、整合性を検証できます。図が込み入って見えるのは、その関連をすべて描いているからです。

SYSMOD アーキテクチャ定義プロセス

要件分析プロセスが「何を作るのか」を定めるのに対し、アーキテクチャ定義プロセスは「どう組み立てるのか」を定めます。要件分析プロセスの成果物、つまりシステムコンテキスト、要件、ベースアーキテクチャ、システムユースケースが、そのまま入力になります。

このプロセスの成果（outcome）は、要件を満たす構造が決まり、なぜその構造にしたのかを要件までたどれることです。その成果を支える成果物（outputs）は次のとおりです。

• 論理アーキテクチャ（Logical Architecture）
• 製品アーキテクチャ（Product Architecture）
• シナリオ（Scenario）
• システム状態（System State）

SYSMOD を補完する手法として、FAS（Functional Architectures for Systems） があります。図の左側に «Optional» として置かれている機能アーキテクチャ（Functional Architecture）は、この手法で得られるものです。FAS 手法の概念と詳細は、書籍 Model-Based System Architecture, Second Edition に記載されています。

どのアーキテクチャの話なのか

ここまでに、ベースアーキテクチャ、論理アーキテクチャ、製品アーキテクチャ、テストアーキテクチャ、機能アーキテクチャと、いくつもの「アーキテクチャ」が出てきました。会議で「アーキテクチャ」と言われて、どれの話なのか分からなかったことはないでしょうか。

SYSMOD は、それらを型として区別しています。

System Architecture と Physical Architecture は斜体、つまり抽象です。実体としては存在しません。「アーキテクチャ」とだけ言ったとき、それは何も指していない。 具体的になんのアーキテクチャを指しているのか明確に分離して考えることが重要になります。

汎用 SysML を、自分たちの組織に合わせてテイラリングする

SysML は汎用の言語です。あらゆるシステムを書けるように作られている分、そのままでは目の前の仕事の言葉になっていません。だから、組織に合わせて語彙を足します。SYSMOD が定めているのが、次のような拡張（ステレオタイプ）です。他にもありますので、さらに詳しい内容は SYSMOD の書籍 をご参照ください。

まず、アクター。SysML の Actor に、ユーザ、外部システム、センサ、アクチュエータ、機械システム、境界システムといった名前が与えられます。環境への影響も型として持っています。

そして、分野。要素がソフトウェアなのか、機械なのか、電気なのか。その区別を型として持っています。MBSE をソフトウェアの話だと思っていた方には、ここが意外かもしれません。

ブロックも同じです。システム、サブシステム、システムコンテキスト、ドメインブロック、文書ブロック、ユーザインタフェース。ここまでの図に何度も出てきた «domainBlock» や «systemUseCase» は、こうして定義された語彙でした。

汎用の言語を渡されただけでは、現場は動きません。組織に合わせてテイラリングする。 それが、インフラ構築プロセスの最初に置かれていた活動です。