俺的MBSE格言集
日本ではなかなか普及が進まないMBSE。まぁ、とっつきにくい話ではあるよねぇ。MBSEやシステムズエンジニアリングの教科書は凄く抽象的な内容で、とってもわかりにくい。かといって「具体例で分かりやすく解説！」等と謳ってる入門書やゼミなら理解できるかというと、実はそうでもない。なぜなら本当に理解しなければいけないのは具体例ではなく教科書に書いてある抽象的な内容だから。具体例ではわかった気になるけど応用できない、となりがち。
じゃあどうすれば良いの？教科書的（抽象的）な内容と、具体的な内容の間をつなぐような説明があればよいのではないか。という訳で抽象的なMBSEの内容を少しだけ具体化した俺的MBSE格言集を発表したいと思います。日本でのMBSE普及の一助になれば幸いです。クセ強めの内容ですので異論反論あるかも？なので異論反論ある方はぜひコメント欄に書いてください。
俺的MBSE格言その１
システムズエンジニアリング（SE）は「型」「規律」である。
システムズエンジニアリングは設計の再現性、説明性、検証性を高めるための手順やルールです。実は結構面倒くさい、規律の多い設計手法なのです。例えるなら武術の型、将棋の○○囲いの手順のようなもの。慣れていない人にとってはやりにくいし面倒くさいしうまくいかないし、自己流でやった方がうまくいくよ！と思うかもしれません。でも武術と同様、自己流の方が強いのは最初のうちだけ、最終的には型をマスターした人の方が強いです。
俺的MBSE格言その２
MBSEはSEの「規律」を形式化・構造化したものである。
MBSEはSEプロセスをシステムモデリング言語で形式化し、SEプロセスの情報をリポジトリで構造化したものです。MBSEがうまくいかないときは、形式化に問題があるか、形式化しようとしているプロセスに問題があるか、その両方か、です。自分のやっているプロセスに問題があることを棚に上げてMBSEが役に立たないと思っている人はかなり多い。
俺的MBSE格言その３
MBSEで技術プロセスは変わらない、変わるのは構成管理だ。
技術プロセスはSEでもMBSEでも、本質的にやることは何も変わらない（形式化されるだけ）。従来の手法（ドキュメントベースSE）とMBSEの違いって、設計情報をドキュメント体系で管理するかモデルリポジトリで管理するかに尽きます。
俺的MBSE格言その４
最初にプロセスのスコープをブロックで定義せよ。
すべての技術プロセスには、範囲と抽象度で定義されるスコープがあります。MBSEのモデル作成で一番初めにやることは、スコープをブロックで定義することです。例えば要求分析なら[《block》コンテキスト空間]、要件定義なら[《block》システム_ブラックボックス]、論理アーキテクチャ設計なら[《block》システム_論理アーキテクチャ]といった具合。このスコープのブロックに、ポート付けたり内部ブロック図やステートマシン図やアクティビティ図、シーケンス図を追加すること、これがMBSEで「形式化された技術プロセス」な訳ですよ、要するに。
俺的MBSE格言その５
要求は、そのスコープのダイアログに出てくる言葉を使って書け。
「要求」とか「仕様」の書き方のお作法はいろいろありますが、MBSEならシンプルに「要求で使う固有名詞はそのスコープのダイアログに出てくるものだけにする」というルールさえ守ればだいたいオッケー。ダメな要求の典型パターン①設計対象外の内容が書いてある、②要求の粒度が合ってない、③用語の定義があいまい、のほとんどが回避できます。コンテキスト空間ブロックを見ながら書けばシステム要求が、システムのブラックボックス定義ブロックを見ながら書けばシステム仕様が、システムの物理アーキテクチャを見ながら書けばサブシステム要求が、自然と書けるはずです。
俺的MBSE格言その６
包含関係による要求分解と論理アーキテクチャはセット。
アーキテクチャで分割しないのに要求を分解しても無意味だし、アーキテクチャで分割したのに要求を分解しないというのはありえない。要求分解とアーキテクチャ設計がセットになるのは自明のことなんだけど、意外と気づいてない人多いかも。
俺的MBSE格言その７
ダイアグラムのフレームを粗略に扱うべからず。
フレームの意味を無視してダイアグラムを書いている人って結構多い。大半が「説明用の絵としてわかりやすくしたい」という理由からだと思うが、そういうのはパワポでやってください。リポジトリ構造が壊れる原因になります。ダイアグラム操作はリポジトリへの入力であることを忘れずに、モデリングツールではフレームを正しく使ったダイアグラムを作成しましょう。