●どんな講演？
いま注目されているモデルベースシステムズエンジニアリング（MBSE）の考え方をイチから丁寧に解説した講演です。
世界的なMBSE第一人者であるDavid Long氏（Vitech社）と、多くの日本企業でMBSE推進をてがけている石橋金徳氏（イノベーティブ・デザインLLC）によって、わかりやすく解説されています。
●この記事をおススメしたい方は？
・これからシステムズエンジニアリング、MBSEに取り組もうとしている方
→ まずどういう考え方で取り組めばよいか、現場を想定しながら理解できます！
・すでにMBSEに取り組まれている方
→ 肝となる考え方、大事なポイントを復習できます！
・何も取り組んでないけどMBSEに興味のある方
→ MBSEの基礎の基礎を知ることができます！
●講演の流れ
・MBSEとは？
・MBSEの３つの重要な要素
・その3つの要素を踏まえて、実際にMBSEを進めるには？
・モデルを駆使するシステムズエンジニアとはどんな人？（※）
（※）最後のセクションでは、「どんな人がシステムズエンジニアになるの？」「システムズエンジニアの資質とは？」「どうやってシステムズエンジニアになるの？」といった、MBSEの要となるシステムズエンジニアに関する興味深い話にまで展開されています。
●動画視聴のお知らせ
今回の記事では講演の導入部をご紹介いたしますが、全ての内容を見たい！という方のために、講演の様子を収めた動画をご用意しました。下記より視聴お申し込みができますので是非ご覧ください！
●前書き
IoT、自動運転、MaaS、まさに今 “あらゆるシステムとつながる製品開発が必要とされる時代” が到来しています。この複雑化する製品開発は、これまでの製品開発プロセスでは太刀打ちできず、「システムズエンジニアリング」が成功のカギと言われています。そして、その実現手段であるMBSE(Model-Based Systems Engineering)が注目されています。
ZIW2019では、システムズエンジニアリング分野の第一人者であり、米Vitech社社長、INCOSE前プレジデント、「A Primer for Model-Based Systems Engineering」の共著者である David Long が MBSE のアプローチについて講演しました。イノベーティブ・デザインLLC の CEO 石橋 金徳氏にもご参加いただき、日本の状況や課題、そしてどう取り組むべきかを踏まえ、逐次通訳と解説を行っていただきました。では、講演内容をお楽しみください！
●講演内容
【MBSEとは？】
本日は、MBSEの基礎の基礎、入門の入門についてお話したいと思います。
MBSEを一言で表現すると、どのようにシステム開発に関わる情報を表現するか、この一言につきるのではないかと思います。
システムズエンジニアリングという世界においては、どんな目的で、どんな課題を解いていくのか、というProblemも、それに対してどう答え、どういう設計にするのか、というSolutionも文章で書かれます。しかし、文章で書かれると、解釈の仕方や一貫性に難を抱えます。そして、システムズエンジニアが最も苦慮するのは、複数のステークホルダー、複数の専門領域が全く異なる関係者と、この文章を元にコミュニケーションを取りながら実際に問題を解いていかなければならない、ということです。それは、ビジネスオーナーであったり、エンジニアでない方々だったりします。
MBSEをできるだけ単純に、一番本質を捉えた説明をするならば、それらProblemやSolutionをモデルの中に捉えることで、より実際のエンジニアリング活動をしやすくし、一貫性や整合性というものを高く保つことができる手法、ということだと思います。
【モデルを使って、システムズエンジニアは何をする？】
結局、システムズエンジニアは、モデル、システムモデルというものを使いながら何をするのか？
例えば、プロジェクトチームを想像してみてください。プロジェクトチームには、いろいろなバックグラウンド、専門用語を喋る人達がいます。プロジェクトチームの皆さんの知恵を最大限に活用するためには、このProblemとSolutionの方向というのを正しく理解してもらうことはとても大事なことです。
つまり、一つのポイントは、モデルを使って、コミュニケーションとアナリシスをうまくやる、ということです。モデルを使って、たくさんの関係者、違う言語、違うバックグラウンドを持った専門家達のナレッジ・知恵を最大限に引き出すためにコミュニケーションし、より確実で緻密なエンジニアリングを進めていくためにアナリシスを行う、ということが大事なところです。
【MBSEの3つの重要な要素】
1.A defined systems metamodel
2.A process or methodology
3.Defined mappings / projections
MBSEを実践する際、この3つがとても重要です。
1.A defined systems metamodel
一つ目は、「システムを実際に開発していくにあたって、必要となる情報をしっかりと定義する」です。ただし、単なる情報の羅列ではありません。大事なことは、インターリレーション、すなわち、定義した情報と情報の関係性、例えば、Allocationですとか、Decomposition、いわゆる、AがB,C,Dにブレイクダウンされていますよ、というような情報の関係性です。このような情報の関係性もきちっと定義された「メタモデル」、もしくは「インフォメーションストラクチャー（情報の構造体）」が大事になってきます。
2.A process or methodology
二つ目は、プロセス、もしくはメソドロジーです。大きく言うと、情報を「Gather（集約）」し、それらをうまく「Manage（活用）」し、「Analyze（分析）」してくこと、この3つが大事になります。
まずはGather。MBSEを上手に進めていくためのアプローチ、メソドロジーとしてのギャザーとは、先程申し上げた「情報の構造体」、つまり、どんな情報がそもそも必要で、どの情報とどの情報がどのような関係性になっているか、ここを理解した上で、情報を集めていく、ということです。
次にそれらをManage。つまり、集めた情報を上手にオペレーションの中で生かしていく。それからAnalyze。集めた情報をシステムやシステム開発に関する情報についても分析をかけて、それを意思決定に反映していく。これが、このプロセス、もしくはメソドロジーとして大事になってきます。
3.Defined mappings / projections
3つ目が表現方法、表現になります。
今まで、情報の話をしていました。3つ目は、それらをどのように、自分を含め、人間が理解可能にしていくか、どのような見え方にしていくか、いわゆるその情報の構造や情報そのものをどのように可視化していくか、ということです。
可視化の方法はいろいろありますが、「Fit for Purpose」、いわゆる目的に合わせて見せ方、見え方、表し方、を考えていく、というのも、3つ目のポイントとしてとても大事になります。
【メタモデルを定義する：情報を構造化するための基本的な考え方】
システムズエンジニアリングの本を開いてみると、どの本にも必ず書かれている大事なところの一つに「Requirement」という章があります。「Requirement」という言葉、システムズエンジニアリングの中では大変よく出てくる言葉です。日本においても「要求」「要件」という言葉で使われていますが、実はDavidさん達が主に活動されてきたアメリカにおける国防プロジェクト、国防関連の調達・開発プロジェクトの中で使われている「Requirement」という言葉と、少し使い方が異なるかな？と思ったので、あえてそれをDavidにぶつけてみました。すると、こんな答えが返ってきました。
アメリカ、特に国防プロジェクトのような国のプロジェクトにおいて「Requirement」と「Contract（契約）」という言葉はほぼセットです。受ける側は、これに応答できないと契約違反になります。そういう世界観で「Requirement」という言葉は使われているので、我々が日本で使っている「要求」「要件」という言葉は、それと比べるとかなり緩いように感じます。
ですので、もう少し「Requirement」という意味を解説してもらったところ、
「Statement of need」が「Requirement」ですよ、という答えが返ってきました。
「Statement of need」、つまり、一体我々は何を満たそうとしているのか、どんなニーズについて議論を進めようとしているのか。もっと別の言い方をすると、この課題の特徴、特性、制約、この課題そのものに含まれているどんな主題や課題を議論しているのか、ということです。この特徴や特性をしっかり捉え、ここをスタートにしながら、ソリューションに関する特性、特徴に変えていきます。
情報を構造化する際、まずはこの「Requirement」、すなわち「Statement of need」をハッキリさせていく、というところからスタートします。
次にシステムズエンジニアが考え始めるのが「Behavior（振る舞い）」になります。
これは、いわゆる具体的な実現手段ではなく、システムにどのようにアクションしてほしいか、システムにどのような振る舞いを果たして欲しいか、ということになります。
例えば、車があるとしましょう。車が「加速する」とか「減速する」とか「レーンを変える」とか、いわゆる動詞が含まれます。どうやってという「How」ではなくて、一体何を果たそうと、どんな振る舞いを果たそうとするのか、これを「Requirement」の次に考えていきます。
次に考えるのは、実際の実現の手段を伴った姿、フィジカルアーキテクチャです。
これは、どのような手段で果たしていくのか、ということです。例えば、内燃機関なのか、それともハイブリッドの内燃システムなのか、もしくは別の方式であるのか。こういった実現手段を伴ったアーキテクチャを考えていく、というのが次のステップになります。
4つ目に大事になってくるのが、真ん中にあるV（Verification）&V（Validation）です。
作ったものが動くということを確認するのが「Verification」だとすると、本当に目的を果たせるかどうかを証明するのが「Validation」になります。
「Validation」というのは、「Statement of needs」が、その事業やプロジェクト、ミッションの目的に合致した「Statement of needs」になっているかどうか、なっていたかどうか、ここを確かめていくことです。そのStatementに対して、正確にエンジニアリングされているか、自分達の設定した問題を正しく全て解いたか、というのが「Verification」になる、ということです。
よくあるのは、これは日本の皆さまもおそらく共感できると思うのですが、「Validation」がうまくいかない、と。結局、何に向かって、何を作るのか、この最初の設定がうまくいかなくて、もしくは未確定のまま開発やプロジェクトが進んでしまい、最後の最後に非常に苦労する。多くの場合、正しく問題が設定できれば、その後のエンジニアリングの問題点というのは、少なくなる傾向にあるのかな？と思います。
最後にお伝えしたいのは、この4つがそれぞれ大事であるだけでなく、この4つがきちんと関連している、連動している、ということが、ものすごく大事だということです。
そもそもシステムズエンジニアリングというのが、関係性というものを扱っていく、というその言葉の通り、この4つにおいても、どのように互いに関係しているのか、例えば、「Statement of needs」から始まり、それに対して、どのようなふるまいをシステムとして果たさなければいけないか、それをどのように実現して、どのように確かめていくのか、という全体の関係性というのがとても大事なのです。
では、モデルベースドになったら、一体何がどう違うのかというと、何か新しいことが始まる訳ではなく、やはりこれなんです。しかしこれを、より正確に、より精密に、より明確に、より確実にやっていく、と。ここがMB、モデルベースドが掛け算になってくるところの1つの大きな狙いであり、特徴だと思います。
続きが気になる方は、是非動画をご覧ください。
視聴お申し込みはこちら
