最近は、製品機能の大規模・複雑化に伴い、単一のシステムに留まらない、複数システムを相互接続したシステム、いわゆる「システム・オブ・システムズ(System of Systems)」と呼ばれるものが増えてきました。このようなシステムでは、求められる要求や制約が多岐に渡ります。それらを満足するアーキテクチャを構築するためには、適切な抽象度を保ちつつ、常に全体最適を考えることのできる開発手法が必要です。
システムとは大小様々な要素で成り立っており、この「要素」と「要素間の関係」を定義したものを構造的なシステムアーキテクチャと呼びます。
システムアーキテクチャの構築にあたっては、ユーザの要求を満たすだけでなく、設計のしやすさやテストのしやすさ、運用・保守まで考慮しなければなりません。また、システムが動作する環境において、さまざまな制約やトレードオフが存在するため、これらへの十分な配慮も大切です。
このように、システムアーキテクチャの構築においては、システムのライフサイクルを見渡し、そのすべてにおいて問題なく進められるよう、全体最適な視点に基づいた設計作業を進めることが求められます。
以下は、システムアーキテクチャを構築するための基本的なプロセスを示しています。次ページ以降で、これら4つの工程についてより詳細に説明していきます。
「1. システム要件の定義」では、システムに求められる機能要求と非機能要求を明らかにします。全体最適なシステムを設計するには、事業環境や商品戦略なども踏まえたシステムレベルで要求を捉えることが重要です。
「2. 論理構成要素の定義」では、システム要件を実現するために必要な機能を導出していきます。ここで導出された機能がシステムアーキテクチャの構成要素となります。
「3. 論理アーキテクチャの作成」では、導出した構成要素間の論理的な関係を定義します。具体的には、どの要素とどの要素が協調し、そのときのインタフェースは何かを決めていきます。
「4. 物理アーキテクチャの作成」では、論理要素に対する物理要素を定義します。物理要素を定義するには、処理性能や調達コストなどの制約が大きく関係してきます。様々な要因のトレードオフ分析を実施した結果、最終的にシステム要求、及び制約を満たす最適な物理アーキテクチャを定義します。
車両盗難防止システムの例で示したように、システムアーキテクチャを定義するための言語として「SysML」が挙げられます。SysMLとは自由度の高い汎用的なモデリング言語であり、様々なシステムを定義可能です。
「SysML」のように自由度の高い汎用的な言語がある一方、自動車システム向けの「EAST-ADL」のようにドメインに特化したシステムアーキテクチャ言語も存在します。EAST-ADLでは、分析レベルや設計レベルといった階層の定義に加え、ISO26262やプロダクトラインなどの概念も取り込んでいます。システムアーキテクチャとしてどこまで定義すれば良いか検討する際に、EAST-ADLのような標準規格を参考にするのも効果的です。
システムアーキテクチャは一度構築すればそれで終わりではなく、システムのライフサイクル全般に渡って維持していかなければなりません。また、複数のシステムに対して同じようにシステムアーキテクチャを定義していくことで、機能の統合や相互接続などの全体最適を実現するための検討が進むようになります。
システム開発を行う企業においては、システムアーキテクチャ設計を継続していくシステムアーキテクトの存在が不可欠です。また、システムアーキテクトにとっては、全体最適なシステムを設計することで企業の事業戦略を大きく推進する役割を果たせます。システムアーキテクトを目指し、真に役立つシステム設計を実現させましょう。
複数の機能が同時に動作する複雑なシステムは、システム内部の構造も複雑になりがちです。特に、既存の複数システムを組み合わせた統合システムは、システム構造に一貫性が無く、動作不安定、使い勝手の悪いUI、重複した機能、資源効率の悪さなどの品質低下を引き起こします。
システムアーキテクチャを構築する際は、機能をベースに技術や制約などに依存しない「論理的なアーキテクチャ」から、技術制約や品質要件などを考慮した「物理アーキテクチャ」へと変換していきます。この時、アーキテクチャ構築のインプットとなる機能要件、非機能要件をどれだけモレなく厳密に定義できるかがポイントになります。
また、要件を満たす構造は何通りも考えられるので、アーキテクチャの導出根拠が重要になります。アーキテクチャ導出根拠が残っていると、要件が変わったときに適切な対応を取ることができ、新しい要件が追加された場合に効率よく検討できます。
エクスモーションでは、要求から最良・最善のアーキテクチャが構築できるよう、開発現場のアーキテクトを支援しています。
どのようなシステムにもシステムアーキテクチャは必ず存在します。しかしそれは適切に設計されたものではなく、ソフトウェアとハードウェアを個別に設計した結果を現場の担当者がすり合わせているというケースが少なくないようです。そのように定義されたアーキテクチャでは、継続した拡張や、複数バリエーションへの展開などに困難がつきまといます。
システムアーキテクチャは、それがシステムを作る目的にかなっているか、企業の事業戦略に合致しているかを説明できる構造になっていなければなりません。これは機能個別の設計をしているときには抜け落ちてしまいがちな視点です。常に全体最適の意識を持ちながら、後々まで役に立つシステムアーキテクチャを作り上げましょう。