• BPnet
  • ビジネス
  • IT
  • テクノロジー
  • 医療
  • 建設・不動産
  • TRENDY
  • WOMAN
  • ショッピング
  • 転職
  • ナショジオ
  • 日経電子版
日経テクノロジーonline SPECIAL

MBSEの目的を徹底講習

慶應義塾大学大学院
システムデザイン・マネジメント研究科特任助教
石橋金徳

システム開発の効果的な手法としてMBSE(Model-based Systems Engineering)が注目を集めているが、慶應義塾大学大学院の石橋金徳氏は「MBSEはシステムズエンジニアリングのための手法に過ぎず、システムズエンジニアリングの正しい理解がなければ成功はない」と警鐘を鳴らす。システムの要求や構成を明らかにするシステムズエンジニアリングが実現できる人材がいて初めて、MBSEが実現し、開発に大きな効果が期待できるという。

 石橋氏は昨年のACE 2016 JAPANでもMBSEについて講演。その時は「システムズエンジニアリング」の定義を具体的に解説し、その手法としてMBSEがあることを解説した。昨年は大変な人気で今年はそれに続く講演として、システムズエンジニアリングの進め方と、そこにMBSEがどうあてはまるかをテーマに語った。

 石橋氏によると、INCOSE(International Council on Systems Engineering)においてシステムズエンジニアリングは、「システムの実現を成功させることができる複数の専門分野にまたがるアプローチおよび手段」と定義されている。そのためのひとつの手法がモデルを駆使してシステムズエンジニアリングを実行していくMBSEである。システムズエンジニアリングとは、必要な機能や性能を実現するための手段(How)を探すだけでなく、何を実現しなければならないか(What)、そもそも何を目的に開発をするのか(Why)、を明らかにすることを含んだエンジニアリング活動である。システムおよび開発全体をしっかり俯瞰できる能力を持ったエンジニア(システムズエンジニア)がこの活動の過程と結果を各種要求、振る舞い、実現手段、妥当性検証項目などの要素として捉え、要素間の関係性も含め段階的に詳細化しながら記述すると「システムの全容を表す図面」(石橋氏)としてのシステムモデルを作ることができるという(図1)。

[画像のクリックで拡大表示]
図1 システムズエンジニアがシステム開発を進めるために必要となるシステムに関する指針・方針、分析結果、意思決定、全体戦略、全体構成などが記述されている。

 しかし、昨今MBSEの導入を試みる日本の開発の現場ではその基本姿勢が忘れられていることが少なくないと石橋氏は言う。「単にシステム記述言語の記述方法を現場に浸透させればMBSEの効果が得られると考えてしまい、効果が出ないと『MBSEの成果は可視化』という苦しい言い訳に陥りがち」(石橋氏)。システムズエンジニアリングそのものに対する理解不足と、システムと開発全体をしっかり俯瞰できるエンジニアの不在が、MBSEの効果が得られない要因となっているというわけだ。

 石橋氏は、「MBSEの効果を最大限引き出し開発で成果を上げるのは、システムズエンジニアリングを体験や経験を通じて真に理解しているシステムズエンジニア(相当のエンジニア)しかいない」と断言する。システムズエンジニアはシステムの目的を根拠に基づいて明確に定義し、システムの勘どころを押さえて開発を推進していく立場の技術者で、「開発現場の優秀なプロジェクトマネージャや技術リーダーに求められる視座と視野を持つ」という。そういうエンジニアは、システムと開発全体を俯瞰して要求の分析や全体構成の検討と明確化を行うために、Excelなどで作った独自のシステム全体の主要情報をまとめた表や、全体俯瞰のためのオリジナルの“ポンチ絵”を作っていることが多い。MBSEにおけるシステムモデルはまさにそうした全体俯瞰と理解、他のエンジニアたちへの指事の明確化のための表やポンチ絵の役割を果たすもので、「彼らにシステムモデルを持たせればまさに“鬼に金棒”。鬼(システムズエンジニア)が金棒(システムモデル)を振り回して開発を進めるのがMBSEである。MBSEの導入を試みるのであればまず“鬼”に相当する人を見つけるべき。希少な技術者だがきっとあなたの周りにもいるはずだ」と石橋氏は断言する。

外部環境まで取り込んでモデル化

 石橋氏はMBSE導入の前提となるシステムズエンジニアリングでは、「システムの内部構成だけでなく、外部の構成にまで視野を広げることが必要」と指摘する。例えば、飲料の自動販売機であれば、飲み物を無人で販売するという機能だけでなく、製造や設置など販売を始めるまでの準備段階や、老朽化した後の廃棄段階なども含めたライフサイクル全体で、システムの外部の構成やそれらとの相互作用を明確化し、それを根拠に要求事項を整理していくことが重要という。システムを取り巻く意味的、時間的、物理的な俯瞰に基づき検討して外部環境を分析することで「『システムにはこんなインタフェースが必要』とか『システムを確実に検証するにはこういう試験装置が必要になる』など、俯瞰的に設計段階で考慮すべきことや俯瞰的な検証戦略などが明らかになっていく」(石橋氏)。

 システムの全容を要素の関係性に注意を払いながら記述する表現方法としてSysML(OMG Systems Modelling Language)は有効だが、それを開発の現場で活用しようとSysMLによる記述結果をそのまま持ち込み、他のエンジニアに理解を求めても意味はないと石橋氏は釘を刺す。「SysMLは、システムズエンジニアリングを理解しシステムと開発全体を俯瞰し、その視座と視野で開発を牽引する技術者に特化した言語。それ以外の人には、SysMLで記述されたシステムモデルの一部をそれぞれの立場に合わせた別の見せ方に切り取って見せることを考えなければならない」からだ。

 システムモデルから立場の異なるエンジニアに合わせた別の見せ方を自動生成する技術がMBSE関連技術の中でも大きな注目を集めている。例えば、SysMLで記述されたシステムモデルから任意の模式図表現を自動生成したり、任意の一覧表現を即座に自動生成したりする技術である。伝える相手、伝える情報、開発のシーンによって様々な見せ方を使い分けることで、システムモデルを元にして多くの関係部署やエンジニア、サプライヤーらと適時正しい全体像と正確な情報を交換しながら開発を進めることが可能だ。現場で使う際の表現方法は多種多様ながら、ベースとなる情報はシステムモデルに一元化する。つまり「システムモデルをシステムに関する情報の“本丸”に位置付ける」(石橋氏)というのである。

 石橋氏は「さらに粒度の低いシステムに関する情報、例えば部品のCADデータやテストデータなども、SysML記述ツールと ArasなどのPLMを連携させることでMBSEにおけるシステムモデルの一部とすることができ、システムに関する情報の“本丸”をさらに重厚にし、大規模複雑なシステム開発を牽引する“鬼”にとって心強い“金棒”にすることができる」という(図2)。PLMを基盤にしたものづくりの現場においても、適切な考え方とその実装の注意点を踏まえることで、システムズエンジニアリングの考えをうまく活用して全体俯瞰的に検討しながら、複雑さに比例して増えていくシステムに関する様々な情報を合理的にしっかりとモデルとして整理し活用するアプローチをとることができ、それによってユーザーの高度なニーズ、激しい現場の環境変化、さらには安全の論証にもしっかり対応した複雑なシステムの開発は可能になるというわけだ。

[画像のクリックで拡大表示]
図2 粒度の低いシステムに関する情報(例えば部品のCADデータ)もPLMとシステムモデル記述ツールとを連携することで、MBSEにおけるシステムモデルの一部とすることができる。