モデルベース・システムズ・エンジニアリング(MBSE)とモジュラー化の間に矛盾はあるでしょうか? 

最近、Modular Management社の同僚の一人から興味深い質問を受けました。自動車業界の企業では、一元化された要件のリポジトリとこれを信頼できる唯一の情報とするために、製品ラインアップにモデルベース・システムズ・エンジニアリング (MBSE) の考え方を展開しているようだ、というものでした。 

弊社の組織内では、モジュラーシステムを実装または管理する際に、企業や事業体のさまざまな組織とプロセス間で要件を共有するための信頼できる唯一の情報源としてPALMAという弊社内で開発したシステムを活用しています。どちらのメソッドも同じ目的を実現しようとしています。では、MBSEとモジュラー化(およびPALMA)の間に矛盾はないのでしょうか?　簡潔に答えると、ネタバレになりますが、これら 2 つのプラクティスの間に矛盾はないといえると思います。 

筆者はABB社のチーフエンジニアとして、MBSEの手法を用いて複雑なシステムをモデル化する大規模な試みに携わっていました。加えて、PALMAでモジュラー化を実装した経験もあります。これらの経験に基づいて、2つのソリューション間に矛盾は無いと感じています。このトピックに関する混乱をなくすために、その理由を掘り下げてみよう。 

このフォーラムでは、次のことを説明したいとおもいます。 

• MBSEはどのような問題を解決しようとしているのか? 
• モジュラー化はどのような問題を解決しようとしているのか? 
• 広範なモジュラー化されたシステムにMBSEを実装した個人的な経験。 
• MBSEのウサギの穴に入る前に考慮すべき重要な要素。 

まずは、MBSEを理解することから始めましょう。 

モデルベース・システムズ・エンジニアリングが解決しようとしている問題とは? 

プロジェクトが失敗するのは、正しい要件の理解が不足しているからであり、製品が市場に投入された後、下流における不具合関連の問題を解決するには最大100倍のコストがかかるということが、MBSEの主な前提となっています。これらのコストの詳細については、ブログ「Everyone cites that bugs is 100x more cost to fix in production」の研究をご覧ください。 

市場に出回っている既存製品の修理にかかる費用を正確に数値化することは難しいかもしれませんが、例えば、戦艦の建造において、処女航海の時点で砲の数が多すぎて船が扱えないことに気づくよりも、最初から必要な砲の数に対して正しい船の長さ、高さ、幅の軍艦を建造する方が間違いなく簡単です。これは、1628年8月10日にストックホルム港で、わずか1300メートルの処女航海で沈没した有名な戦艦ヴァーサ号のケースであり、沈没した場所は建造された造船所の視界内にありました。この沈没はスウェーデン国王にとって大きな大失敗であり、多くの船員の命を不必要に犠牲にし、スウェーデン帝国に衝撃を与えたといわれています(詳細はvasamuseet.se でお読みください)。 

ヴァーサ号の欠陥は建造時の検証段階から解っていたようで、ヴァーサ号の建造を監督していた船長のセーフリング・ハンソン(Söfring Hansson)は、30人の部下を甲板上を行ったり来たり走らせてて、船を恐ろしく横揺れさせてその欠陥を示していたようです。 

もし1600年代にコンピュータとMBSEがあれば、すべての建造データをドメイン別にカテゴリー分けされたモデル体系に落とし込み、船舶のシステムを視覚的に表現できただろうと思われます。そして、このデータは、船の建造に関わるシステム要求、設計、分析、検証、妥当性確認活動で共有することができたに違いありません。 

今日、MBSEは、文書ベースの情報交換ではなく、ドメインモデルを情報交換の主要な手段として作成し、活用することに重点を置いたシステムエンジニアリングの技術的アプローチとして活用されています。このアプローチは、システムの異なる部分間の関係を見やすくし、管理しやすくすることで、システムエンジニアリングにおける複雑性がもたらす課題を克服するのに役立っています。 

図 1. MBSEは、情報交換にドキュメント駆動型のアプローチではなく、ドメインモデルの使用を推奨しています。 

もしヴァーサ号を建造する際にこのようなモデルがあれば、相反する要件を解決する必要があることは、船の建造に関わるすべての人にとって明らかだっただろうと思われます。設計段階でこのような矛盾を解決していれば、検証段階で同じことをするよりもはるかにコストがかからず、はるかに早く、そして最終的にはヴァーサ号を救うことができたに違いありません。 

この話の要点は、意思決定を行う際には、誰もが同じデータにアクセスできる必要があり、MBSEはそのデータを提供するための手法であるということなのです。MBSEでは、開発プロセスの早い段階で潜在的な問題を特定するために、ドメインモデルがすべての要求を満たす必要があります。

モジュラー化が解決しようとしている問題とは? 

モジュラー化は、製品のライフサイクル全体におけるコストを削減することができます。その経済性は、開発段階からサプライ・チェーンやサービス段階を通じて発揮されることになります。モジュラー化のもうひとつの重要な利点は、この手法を採用するメーカーが、市場の要求を満たす新製品をより早く市場に投入できることです。これらの利点は、モジュールの再利用を最大限に活用し、設計のバリエーションが発生する場所を事前に予測・計画し、事業環境の変化などによる急速な開発の変化を予測することによって達成されることになります。 

戦略的なモジュラー化を使用すると、モジュールを次の 3 つのカテゴリーのいずれかに分類できます。 

• 再利用を最大化するモジュールは「オペレーショナルエクセレンス」カテゴリーに分類。 
• 異なる顧客ニーズを満たすために製品のバリエーションを必要とするモジュールは、「顧客親密性」カテゴリーに分類。 
• 企業や製品性能の中核であり、技術変革に対してアジャイル性が必要なモジュールは、「製品リーダーシップ」カテゴリーに分類。 

この3つのカテゴリーを先ほどのヴァーサ号の例に当てはめれば、大砲はプロダクトリーダーシップモジュールとみなされ、ヴァーサ船を経験に基づいてさまざまなサイズに対応させることは顧客親密性モジュールとみなされたと思われます。同時に、ヴァーサ号を安定させるためのオペレーショナルエクセレンスに基づくバラスト計算も行われたはずです。 

歴史上のこの時期、彫刻の多様性は重要であったため、これらのモジュールには高いバリエーションの可用性が求められていました。その結果、造船業者は、スタイリング要素としてバリエーションを持つモジュール（顧客親密性）を組み込んでいたと思われます。 

図 2. 進水時のヴァーサ号模型。 写真提供者不明 is licensed under CC BY-NC 

PALMAによる製品全体の可視化 

モジュラー製品システムのライフサイクルにおける数々のステージを管理するために、私たちは、製品と要件管理のためのソフトウェアソリューション、PALMAの使用をお勧めします。この機能豊富なツールの一番のポイントは、モジュラーシステムを常に追跡できることです。製品を360度から見渡すことができるため、製品に関わる関係者は、モジュラーシステム全体の収益性に基づいて、新しいモジュールのバリエーションを自信を持って導入することができます。この方法により、収益の見込めない顧客要求対応を無くす事ができます。多くの点で、このアプローチはMBSEのようなもので、ドキュメント主導のアプローチを使う代わりに、情報モデルによってa Single Source of Truth（唯一の真実の情報源）を作成するわけです。 

図 3. PALMAは、ドキュメント主導の情報交換から情報モデルの使用への移行を推進しています 

 モジュールとそのモジュールバリアントの複雑性コストは、生産、調達、およびエンジニアリングの原価計算データから計算され、モジュラーシステム全体に配賦されます。コンフィグレーション（構成）を持つ製品のコストと収益性は、各構成について計算することができ、コストに関する判断は、個々のモジュールバリアントではなく、全体の構成に基づいて行われるべきです。 

例えば、各構成に対してコスト最適化されたモジュールバリアント（種類）をいくつか投入する代わりに、1つのモジュールバリアントをオーバーサイジングしてモジュラーシステム全体に適合させた方が利益の出る場合があります（大は小を兼ねる）。もちろん、その逆もあり得ます。メーカーが1つの大量生産構成を最適化し、頻度の低い他の構成に対応するためにバリアント（種類）を投入する場合です。いずれの状況においても、一つの製品の最適化につながる限定的な洞察ではなく、モジュラーシステムの複雑さにかかる総括的なコスト検討に基づいてモジュール種類数は決定されるべきなのです。 

再びヴァーサ号を例に考えると、PALMAを使えば、どのような船体形状が必要な砲門数に最も適合するかを計算することができ、同時に正確な製品コストの見積もりを素早く出して、初期構成と比較することができたはずです。PALMAを使用することで、造船会社は、計画されたモジュールのバリエーションと異なる製品構成を完成させるためのスケジュールを、計画プロセスの早い段階で知ることができたでしょう。モジュラーシステムの計画段階におけるこの貴重な洞察は、発注主である国王の構成要求に対応するための再優先順位付けを可能にしたであろうと思われます。 

PALMAとMBSEはどちらも信頼できる唯一の情報源になろうとしていますが、モジュラー化はMBSEとは異なる問題を解決しており、アプローチは互いに補完し合う可能性があります。 

MBSEツール用にモジュラーシステムをドキュメント化することはできますか? 

現在知られているMBSE支援ツールを鑑みると、あるものはPALMAの代わりに、モジュラーシステムをMBSEシステム上に直接文書化できるようです。 

これはオプションですが、MBSEツールの主な目的は、要求を追跡し、それらが矛盾しないことを確認することであり、必ずしもモジュラーシステムの収益性を解決することではないため、この利点が失われている可能性があります。 

PALMAは、モジュラーシステム内のすべてのモジュールバリアントを追跡しますが、完全な要件管理システムではありません。MBSEは、信頼できる唯一の情報源であると同時に、完全な要件管理システムにもなることを目指しています。さらに、開発プロセスの早い段階でシステムの動作を視覚化するために、ツールにシミュレーションを含めることさえ試みています。 

MBSEの推進者の中には、MBSEツールですべてを文書化し、PALMAのメリットを実現するために必要なのはモデル内部の改善だけだと主張して、PALMAを放棄しようとする人もいます。これは理論的には正しいかもしれませんが、MBSEの問題点はそこでは無いはずです。 

大規模モジュラー化システムへのMBSE導入経験 

筆者は以前勤めていた会社で、メカトロニクスとソフトウェアの両方をカバーする大規模なモジュール化システムにMBSEを導入しようとしたことがあります。このプロジェクトで私が経験したのは、MBSEは理論的には素晴らしいが、商用製品に対して長期的に活用し成功するためには、包括的すぎるアプローチだということです。もちろん、防衛産業における非常に複雑な製品や、原子力発電所のようなインフラ製品など、ミスの代償が甚大で、要件が一般的に安定しているような例外はあります。量産でかつ大規模な製品のほとんどでは、MBSEツールに多くのデータをモデル化する必要があり、そこからビジネスに価値を得ることはできないと思われます。MBSEに必要なすべての要件を詳細に記述するのに費やす時間は、比較的単純な製品であっても膨大です。このMBSE検討レベルのプロセスにおける労力の正当性は、プロジェクト内における利害関係者に対して説明することにも多くの労力を要することになります。 

第二に、商用製品の要件はますます急速に進化しているため、製品開発中に要件が変更された場合、要件の作成に何年も貴重な時間を浪費することになります。実際、2001年にアジャイル開発プラクティスが発明された主な理由は、要件の変化のペースの速さに対処することでした(詳細:ハードウェアとモジュラー化のためのアジャイル開発)。 

さらに、今日の製品の多くは、白紙からの開発ではありません。製品がしばらく前から存在している場合、ソフトウェアの多くは前世代製品からキャリーオーバーされたものであり、文書化されていない多くの機能がコードに隠されている可能性があります。この概念については、別のブログ「Improve your Software Architecture by Code Refactoring, Not Rewrite」で詳しく説明しています。 

PALMAにモジュラーシステムを実装することは、最初は同じように途方もない作業のように思えるかもしれません。しかし、PALMAにおける要求ドキュメントは、市場要求とそれを満たすモジュールバリアントの関連付けに用いられます。モジュールバリアントの詳細な技術的側面は、既存のドキュメントでカバーでき、必要に応じてMBSEツールにリンクすることもできます。モジュラーシステムの収益性に最も重要な要素は、生産、調達、開発データに基づいており、PALMAにインプットし、文書化を図るほうががはるかに容易です。 

図4. MBSEとPALMAでカバーされる要件の違い。 

 つまり、MBSEアプローチと比較して、PALMAは必要なデータが大幅に少なく済むことを意味しています。その結果、PALMAの導入で組織が成功する可能性は、MBSEよりもはるかに高くなります。私は、多くの包括的なMBSEプロジェクトが、今後の改善に大きな期待を寄せて出現するのを見てきましたが、膨大なドキュメントの負荷が現実のものとなったときに、最終的には埋もれてしまうのを見てきました。プロジェクトの利害関係者は、システムの包括的なドキュメントよりも、機能する製品を優先します。結局のところ、機能的な製品は会社に価値を生み出し、 顧客からのフィードバックを受けて、将来的に製品をさらに成功させるためにステップバイステップの変更を加えることができます。完璧なMBSEモデルは、製品が設計され、テストされ、構築され、顧客に出荷される迄、会社に利益を保証しません。 

MBSEとは別のアプローチが考えられますか? 

先に述べたように、MBSEは、開発プロセスの早い段階でシステム要件を理解し、後でコストのかかる変更を避けるという問題を解決しようとするものです。 

アジャイルアプローチでは、製品関係者から迅速なフィードバックを得るために、段階的な実装と頻繁な製品デモ（エミュレーション）が必要です。このプロセスは、不必要で無駄な開発を排除し、開発サイクルが手遅れになる前に顧客の優先順位を理解するのに役立ちます。 

アジャイル開発プラクティスは、今日の多くの商用製品に適した軽量なアプローチで、MBSE手法と同じ問題に対処しています。しかし、1628年の戦艦建造や原子力発電所などの複雑なシステムには、より堅牢な方法が必要です。アジャイル開発を成功させるためには、PALMAによるモジュラー化されたシステムによって、結果を劇的に改善することができます。 

最後に、PALMAとモジュラー化は、MBSEルートとアジャイルプラクティスのどちらにも多くの価値を提供するということです。しかし、開発方法論に関係なく、モジュラーアーキテクチャに投資するメリットに勝るものはありません。 

もっと知りたいですか? 

企業と組織にモジュラー化を実装する方法について詳しく知りたい場合、またはこのトピックに関するフォローアップの質問をしたい場合は、以下の連絡先より、メッセージを送ってください。