読書メモ。
- システムズエンジニアリングの探求
- https://www.choeisha.com/pub/books/20827.html
システムズエンジニアリングの理論と実践の両面を解説した必読の一冊です。エンジニアリングの世界に新しく足を踏み入れる人から、深い理解を求めるエンジニアまで、幅広い層に価値を提供します。システムズエンジニアリングの導入からライフサイクル、プロセス、マネジメントまで、包括的に解説しています。
目次 #
- 第 1 章：システムズエンジニアリングの導入
- 第 2 章：モデルベースシステムズエンジニアリング
- 第 3 章：システムとインタフェース
- 第 4 章：ライフサイクル
- 第 5 章：システムズエンジニアリングプロセス
- 第 6 章：ニーズおよび要求
- 第 7 章：設計のモデリング
- 第 8 章：検証および妥当性確認
- 第 9 章：方法論
- 第 10 章：システムズエンジニアリングマネジメント
- 第 11 章：MBSE を組織に導入する
- 第 12 章：モデリングのコツ
- 第 13 章：ベストプラクティス
1 章：システムズエンジニアリングの導入 #
システムズエンジニアリングの歴史 #
古代エジプトのピラミッドは複雑なシステムの典型例です。古代ギリシア人が初めて惑星の動きを観察し、天動説モデルを創造して以来、人類は太陽系という複雑なシステムを観察し続けています。
1960 年代には、システム理論として研究分野が体系化されました。システム理論は「一般システム理論」として、Ludwig von Bertalanffy が仮説検証した理論です。
システム理論の主要な教えは、システムの構成要素を単体として捉えるのではなく、構成要素間または他のシステムとの関係性というコンテキストで捉えるという原則であり、それにもとづく概念上の枠組みがシステム理論であるとされています。システム内の要素またはシステムそれ自体はシステム単体で検討されるべきではなく、他の要素または他のシステムとの関係性の中で検討されるべきであるという考え方は、あらゆるシステムズエンジニアリングにおいて必要不可欠です。
システムがより複雑になるにつれて、複雑なシステムを開発するための新たなアプローチが必要となってきました。20 世紀後半にこのようなニーズが高まった結果、1990 年に米国でシステムズエンジニアリングに関する全米協議会が発足し、それは 1995 年にシステムズエンジニアリングに関する国際協議会（International Council on Systems Engineering: INCOSE）に発展しました。INCOSE は、世界中に 70 以上の支部を持つ、システムズエンジニアリングに関する世界で最も権威ある団体です。
システムを定義する #
重要な点は、システム要素が他のシステム要素と相互作用するという点です。これはシステムを正しく理解し、システムズエンジニアリングを適用するうえで重要な概念です。システムまたはシステム要素を検討するとき、それらが単独で存在するのではなく、他のシステム要素と相互作用することを理解することが重要です。システムズエンジニアリングでは、すべてのものが他の何かとつながっていると考えます。そのため、システム要素間の相互作用の土台と成るそれらの関係性を理解することは、システム要素自体を理解することと同じくらい重要なことです。
システム要素間の相互作用を理解することで、システム要素間のインターフェースを特定し定義することができます。システム要素間のインターフェースを理解することは、あらゆる種類のシステムを特定し定義するために非常に重要なことです。インターフェースを理解するために、インターフェースに流れる情報および物質を理解することも必要です。
次のダイアグラムはシステムに関連する主要な概念をまとめたものです。
┌─────────────┐ ┌───────────┐
│ Stakeholder │─ has an interest in ───────┐ ┌ defines the scope of ─│ Boundary │
└─────────────┘ │ │ └───────────┘
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐ ┌───────────┐
│ Need │─ describes purpose of ─▶ │ System │◀──────── describes ─│ Attribute │
└─────────────┘ └─────────────┘ └─────┬─────┘
▲ │ │
┌─────────────┐ │ │ │
│ Constraint │─ limits the realization of ┘ │ │
└─────────────┘ │ │
│ is made up of │
▼ │
┌────────────────┐ │
┌───────▶│ System Element │◀───────────── describes ┘
│ └───────┬────────┘
│ │
└ interacts with ┘
- A is made up of B: A は B から構成される
- A interacts with B: A は B と相互作用する
- A has an interest in B: A は B に関心がある
- A describes B: A は B を説明する
- A defines the scope of B: A は B の範囲を定義する
- A describes the purpose of B: A は B の目的を説明する
- A limits the realization of B: A は B の実現を制限するシステム（System）がシステム要素（System Element）から構成されています。システム要素それ自体が下位レベルのシステム要素に分解される可能性があります。その場合、ある固有のシステムに対して、複数レベルのシステム階層が特定されることになります。
- Stakeholder：利害関係者 ー 誰または何がそのシステムに関心があるか特徴づける
- 利害関係者（Stakeholder）がシステム（System）に関心があることを示しています。利害関係者の定義とは、システムに関心があるすべての人、組織、モノの役割の定義を意味します。
- 利害関係者を検討するとき、関心があるのは利害関係社の役割です。関連する人、組織、モノの名前ではありません。たとえば、車を所有する Jon という人物がいるとき、Jon は利害関係者ではありません。利害関係者とは、車と相互作用するときに Jon が担う役割です。所有者、運転手、同乗者、スポンサー、保守管理者などの多くの役割を担います。したがって、Jon という人物について検討するのではなく、Jon が担う役割を検討しなければなりません。
- 利害関係者は必ずしも人物である必要はなく、例えば組織である可能性もあります。車で考えると、企業が所有する社用車である場合、組織が利害関係者の役割を担います。同様に、法律は車に関心があるため、法律も利害関係者です。
- Attribute：属性 ー システムの性質を特徴づける
- 属性（Attribute）がシステム（System）を説明することを示しています。属性を特定することにより、ハイレベルなシステムの性質を説明することができます。
- 属性は典型的に名刺で表現されます。寸法、重量、要素番号、名前、タイムスタンプ、データ構造。属性のパターンは無限に存在します。
- Boundary：境界 ー システムの範囲を定義する
- 境界（Boundary）がシステム（System）の範囲を定義していることを示しています。それぞれのシステムには少なくとも１つの境界があります。
- 境界にはさまざまな種類が存在します。物理的な境界、概念的な境界、利害関係社の境界。
- システム境界により、いくつかのシステムの重要な点を理解することができます。境界の内部にあるもの、境界の外部にあるもの、重要なインターフェースが存在する場所。
- Need：ニーズ ー システムの目的を説明する
- ニーズ（Need）がシステム（System）の目的を説明していることを示しています。ニーズは、システムが何をするべきか、何であるべきかを説明します。
- 要求、特徴、目標。
- Constraint：制約 ー システムの実現を制限する
- 制約（Constraint）がシステム（System）の実現を制限していることを示しています。あらゆるシステムには、そのシステムに関連する制約があり、それがシステムの実現方法を制約します。
- 品質制約、実装制約、環境制約、安全制約。これらは制約の一例です。
- 制約は特別な種類のニーズであると説明されることも多いです。
システムズエンジニアリングを定義する #
INCOSE システムズエンジニアリングハンドブックは、以下の定義を採用しています。
「成功するシステムの実現」（The realization of successful systems）
- システムズエンジニアリングは、機械、電気、土木、ソフトウェアなど、エンジニアリングのすべての分野を検討する分野横断的なアプローチです。エンジニアリング分野だけではなく、マネジメント、数学、物理学、心理学など、他のさまざまな分野も含まれるということが重要です。
- システムズエンジニアリングは、ライフサイクルのある特定のステージに限定されるものではなく、ライフサイクル全体に適用されます。システムの初期のアイデアが構想された時点から、システムが最終的に廃棄されるまでのすべてのステージで適用されることを意味します。
- システムズエンジニアリングには知性が必要です。盲目的に指示に従ってはならず、システムズエンジニアリングを効果的に発揮するための健全な良識が求められるためです。
システムズエンジニアリングの必要性 #
システムの失敗には以下の３つの主要な原因があります。
- 複雑性（Complexity）の問題：複雑性が特定されていないため、複雑性を管理することが不可能となります。
- コミュニケーション（Communication）の問題：コミュニケーションが失敗したり曖昧であったりします。
- 理解（Understanding）の問題：さまざまな視点が考慮されておらず、憶測が発生します。
これらは相互に影響し合います。管理されていない複雑性はコミュニケーションの失敗や理解の欠如につながり、コミュニケーションの失敗は複雑性の増加や理解の欠如につながり、理解の欠如は複雑性やコミュニケーション上の問題を増加させます。
これら３つの原因は、「システムズエンジニアリングの３つの害悪（Three Evils of Systems Engineering）」と呼ばれることがよくあります。
2 章：モデルベースシステムズエンジニアリング #
モデルベースシステムズエンジニアリング（Model-Based Systems Engineering: MBSE）は現代のシステムズエンジニア（SE）にとって必須の学習項目です。
MBSE はシステムズエンジニアリングの一種です。システムズエンジニアリングに関する国際評議会 INCOSE は、システムズエンジニアリングの将来に関する世界的なビジョンを定期的に定義しています。INCOSE は、2035 年までにすべてのシステムズエンジニアリングがモデルベースシステムズエンジニアリング環境に完全に移行し、デジタルトランスフォーメーションの重要な要素になるであろうと予測しています。
システムを抽象化する #
「成功するシステムを開発する」というシステムズエンジニアリングの目標を見失わないようにすることが重要です。これは疑う余地のないことのように思えますが、ここで気をつけなければならない重要な点は、システムズエンジニアリングの一部として実施されるすべてのアクティビティがこの目標に貢献しなければならないということです。
┌────────┐ ┌───────┐ ┌──────┐
│ System │◀─ abstracts ─│ Model │─ is made up of ─▶│ View │────────────────┐
└────────┘ └───────┘ └──────┘ │
▲ │
└ is consistent with ┘
- A abstracts B: A は B を抽象化する
- A is made up of B: A は B から構成される
- A is consistent with B: A は B と一貫性をもつモデル（Model）がシステム（System）を抽象化するという、MBSE の最も基本的な概念を示しています。抽象化とは、システムの単純化と考えることができます。モデルはシステムを単純化したものでなければなりません。そうでなければ、それは「システムそのもの」となってしまいます。モデルはシステムを単純化したものであるため、その性質上、モデルに含まれる情報は不完全です。モデリングの目的は、システムを成功裏に実現するための「十分な」情報を取得することです。できるだけ多くであったり、すべての情報を含めることではありません。これは非常に重要です。なぜなら、モデリングに誰の役にも立たない無駄な情報が作成されがちであるためです。モデルに含まれるすべての情報は必ず誰かの役に立たなければなりません。
モデルに含まれる情報はビュー（View）と呼ばれる固有の集合としてグループ化されます。モデルは複数のビューから構成されていることを示しています。この集合はシステムズエンジニアリングの取り組み全体に付加価値を与えなければなりません。
どの利害関係者がそのビューを見たいですか？なぜ利害関係者はそのビューを見たいのですか？どのような情報がビューに含まれる必要がありますか？
もしこれらに回答できない場合、そのビューは有効なものではなく役に立ちません。
ビューが互いに一貫性を持つ必要があることが必要です。それぞれのビューが他のすべてのビューと一貫している場合、それこそがモデルです。逆に一貫していない場合、それは単なるデータです。
ひとたびモデルが成立する（すべてのビューが付加価値をもち一貫性がある）と、モデルはシステムに関連するすべての情報の主要な格納庫として使用されます。これが意味することは、利害関係者がシステムに関して何かを知りたいとき、その問い合わせ対象は常にモデルであるということです。
モデルは巨大で複雑な情報の集合であると想像することができます。それぞれのビューは、そのモデルに対して小さな窓を開くことに似ています。すべての利害関係者がモデルを十分に理解可能であるという信頼につながる十分な数の窓を開かなければなりません。
ビューを視覚化する方法は、コミュニケーションを成功させるため、そして利害関係者間でシステムを理解するために非常に重要です。MBSE に関しては、利害関係者が話すさまざまな言語を Notation（表記法）と呼びます。
表記法はダイアグラムから構成され、ダイアグラムは表記法で使用される実際のコミュニケーションの仕組みを提供します。
表記法は視覚的表現を使用する視覚的言語の場合があります。たとえば、UML（Unified Modeling Language）や SysML（Systems Modeling Language 2019）、SysML 2.0（SysML 2022）、フローチャートなどがあります。本書ではすべての例で SysML を使用します。
以下のダイアグラムは、システムズエンジニアリングのコミュニティ内で 「１枚のスライドの MBSE（MBSE in a slide）」 として知られています。MBSE に関連する主要な概念をまとめたもので、コミュニティで広く使用されています。
┌ Approach ─────────────────────┐ ┌ Goal ───────────────────────────────────┐ ┌ Visualization ───┐
│ ┌─────────────┐ │ │ ┌────────┐ ┌───────┐ │ │ ┌──────────┐ │
│ │ Process Set │ │ │ │ System │◀─ abstracts ───│ Model │ │ │ │ Notation │ │
│ └──────┬──────┘ │ │ └────────┘ └───┬───┘ │ │ └──────────┘ │
│ │ │ │ │ │ │ │ │
│ describes how to use │ │ │ │ │ │ │
│ │ │ │ is made up of │ │ is made up of │
│ ▼ │ │ │ │ │ │ │
│ ┌─────────────┐ │ │ │ │ │ │ │
│ │ Framework │ │ │ │ │ │ │ │
│ └──────┬──────┘ │ │ │ │ │ │ │
│ / \ │ │ ▼ │ │ ▼ │
│ / \ │ │ ┌───────┐ visualizes ┌──────────┐ │
│ is made up of is made up of │ │ ┌─▶│ View │◀──────────── │ Diagram │ │
│ / \ │ │ │ └┬──────┘ │ │ └──────────┘ │
│ ▼ ▼ │ │ │ │ ▲ │ │ │
│ ┌──────────┐ ┌───────────┐ │ │ │ │ │ │ │ │
│ │ Ontology │ │ Viewpoint │──┼──┼─ defines the structure ┘ │ │ │ │ │
│ └──────────┘ └────┬──────┘ │ │ and content for │ │ │ │ │
│ ▲ │ │ │ │ │ │ │ │
│ └─────────────┘ │ │ └─────┘ │ │ │
│ is based on │ │ is consistent with │ │ │
└───────────────────────────────┘ └─────────────────────────────────────────┘ └──────────────────┘３つのグループは以下のとおりです。
- Approach（アプローチ）：オントロジー、ビューポイント、プロセスセットを構成するフレームワークをグループ化しています。
- Goal（目標）：システム、モデル、関連するビューをグループ化しています。システムズエンジニアリング、MBSE の目標はシステムを開発することであり、これはモデルとそれに関連するビューを開発することで達成されます。
- Visualization（視覚化）：表記法と関連するダイアグラムをグループ化しています。
すべてのドキュメントがすべて同じ構造と内容であることを保証しなければならない状況を想像してください。ドキュメントを取り扱う場合、答えは単純です。ドキュメントのテンプレートを定義することにより、それ移行に作成されたドキュメントが一貫性を保ち、同じ見た目と使い勝手をもつことを保証します。ビューの作成について検討する場合も、ある種のテンプレートが検討されるという点で答えは同じです。ビューのテンプレートはビューポイントと呼ばれます。ビューポイントが適切に定義されると、そのビューポイントにもとづいて作成されたすべてのビューの一貫性が保証されます。
ビューの内容の基礎となる共通の概念と関連する用語をする必要があります。それはオントロジーと呼ばれます。言い換えればドメイン固有言語です。
オントロジーとビューポイントを組み合わせると、フレームワークと呼ばれるものができます。フレームワークは、完全なモデルのテンプレートとして作成されます。フレームワークはモデルに対してどのような情報を生成する必要があるかに焦点を当てています。すなわち「モデルを開発するためには『何の（What）』情報を生成しなければならないか？」ということを定義します。
プロセスセットは、フレームワーク、その構成要素であるオントロジーとビューポイントを開発する方法を示すために使用されます。プロセスセットはその情報をどのように生成して使用する必要があるかに焦点を当てます。すなわち、「フレームワークを『どのように（How）』開発および使用するか？」を定義します。
モデルを定義する #
モデルはシステムを抽象化したものです。抽象化とはシステムの表現です。この場合、媒体として視覚的表現またはダイアグラムを使用します。モデルはいくつかのビューで構成されます。それぞれのビューが他のすべてのビューと一貫性を持つ必要があります。モデリングに関しては一貫性が重要であり、これはいくら強調してもしすぎることはありません。もし一貫性の無いビューがモデリングされている場合は、それはモデルではなく単なる画像です。
モデルを構築する際、モデルは常に構造（Structure）と振る舞い（Behavior）の２つの側面を持ちます。
- 構造（Structure）：モデルの「何か（What）」を定義します。モデルの主要な要素は何か、それらの要素間の関係性は何か、それぞれの要素が何をするのかを定義します。構造は、分類（システム要素の種類）と概念レベルの分解（システム要素の構成）の両方に関して、システムの階層化ができるようにします。システム要素間の関係性は、システム要素自体と同じくらい重要です。
- 振る舞い（Behavior）：モデルの「どのような（How）」を定義します。物事がどのような順序で発生するのか、それがどのような条件下で発生するのか、タイミングの制約は何であるのかを定義します。構造にてモデルを階層的に分割できますが、振る舞いは、階層のある固有の層に適用される傾向があります。またその関係性は静的ではなく動的なものとして検討されます。
すべてのモデルには、それに関連付けられた構造と振る舞いの両方があります。すなわち、モデルを構成する構造ビューと振る舞いビューがあります。SysML には９つのダイアグラムがあり、それにより、モデルの構造および振る舞いを視覚化することができます。
ライフサイクルのどの時点で、どのような状況でモデリングを適用するべきでしょうか？答えは非常に簡単で、以下に該当するすべてのステージで適用するべきです。
- システムの中に、特定されておらず管理されていない複雑性がある場合（第１の害悪）
- システムのあらゆる観点を理解する必要がある場合（第２の害悪）
- 利害関係者と効果的かつ効率的にコミュニケーションをとる場合（第３の害悪）
つまり、モデリングを実施することにより付加価値が提供される場合に適用するべきです。
MBSE のすべての活動は、付加価値を提供し、システムの実現に貢献する必要があります。そうでない場合、それを実施するべきではありません。
システムズモデリング言語 #
SysML は視覚的な汎用モデリング言語であり、UML と呼ばれる別の視覚的な汎用モデリング言語にもとづいて作成されました。UML はソフトウェアエンジニアリングの世界にルーツをもちます。UML の最初のバージョンがリリースされた 1997 年よりも前には、ソフトウェアエンジニアリング向けの表記法と方法論が数多く存在しました。
モデリング表記法の目標の１つは、コミュニケーションの基本的な仕組みを提供することです。しかし、昔は利用できる表記法が多すぎたため、表記法を選択することが困難な状況でした。そのため 1990 年代半ばに、ソフトウェア業界は、誰もが使用できる唯一の標準化された共通言語が必要であるという合意に達しました。言語が独占されないことが重要であったため、オブジェクト技術に管理する標準を所有、管理、構成する国際標準化団体である、オブジェクト・マネジメント・グループ（Object Management Group: OMG）がその新しい言語を所有することになりました。1997 年、OMG は UML を正式にリリースしました。
UML は汎用的なモデリング言語であったため、ソフトウェアの領域だけでなく、システムズエンジニアリングのコミュニティの中でも広く使用されていました。INCOSE は 2004 年、システムズエンジニアリング向けに特化した UML のバリエーションが必要であると判断し、SysML が誕生しました。UML が親言語であり、SysML はその方言であるという関係性です。SysML は OMG にて所有、管理、構成されており、OMG のウェブサイトからダウンロード可能です。
SysML は９つの異なるダイアグラムをもつツールボックスです。これらのダイアグラムにより、モデルの構造と振る舞いの両方をまとめて視覚化することができます。
- 構造のダイアグラム
- ブロック定義図（Block Definition Diagram: bdd）：SysML の全ダイアグラムの中で圧倒的に広く使用されています。
- 内部ブロック図（Internal Block Diagram: ibd）
- 要求図（Requirements Diagram: req）
- パラメトリック図（Parametric Diagram: par）
- パッケージ図（Package Diagram: pkg）
- 振る舞いのダイアグラム
- ユースケース図（Use Case Diagram: uc）
- シーケンス図（Sequence Diagram: sd）
- ステートマシン図（State Machine Diagram: stm）
- アクティビティ図（Activity Diagram: act）
（以降の章の記述は省略）