SoSとマイクロサービスの違い
システムオブシステムズ（SoS）とマイクロサービスは、どちらも複数の要素（システムやサービス）が連携する点で似ていますが、その成り立ちや目的、思想が根本的に異なります。
1. 概念の定義
システムオブシステムズ（SoS）
定義
複数の独立したシステムが連携して、単独では実現できない全体目標を達成するための仕組み。
特性
各システム（構成要素）は自治性を持ち、独立して運用が可能。
各システムには個別の目標があるが、全体の目標達成のために協調する。
分散的で動的に進化する（システムが勝手に追加・削除される場合がある）。
具体例
・災害対応システム（医療、通信、物流が連携）
・グローバルな軍事防衛システム
・スマートシティ（交通、エネルギー、水道、通信などの連携）
マイクロサービス
定義
単一のどでかいアプリケーションを小さなサービス群に分割し、各サービスが極力独立してデプロイや運用可能なアーキテクチャ。
極力と書いたのは、種類によっては単独でデプロイできないから。
特性
各サービスは特定のビジネス機能を担当。
APIを介して疎結合にサービス同士は連携し、独立してスケールや更新が可能。
具体例
・オンラインショッピングサイト（カート管理、ユーザー認証、商品検索などのサービスに分割）
・ストリーミングサービス（動画配信、ユーザー推奨、課金管理など）
2. スコープと目的の違い
システムオブシステムズ (SoS)
目的
既に独立して価値を持つ複数のシステムを連携させ、単独では実現不可能な、より広域で新たな価値や能力（創発的振る舞い）を生み出すこと。
スコープ
企業間、社会インフラ全体。スマートシティ（交通システム＋電力網＋行政システム）のように、複数のドメイや組織にまたがる極めてマクロな視点。
マイクロサービス
目的
単一のアプリケーションを開発・運用しやすくするために、ビジネス機能に沿って小さく自律的なサービスに分割すること。
スコープ
単一のアプリケーション、または単一の企業内。
ECサイト（商品サービス＋注文サービス＋決済サービス）のように、比較的ミクロな視点。
3. 構成要素の自律性と所有権
システムオブシステムズ (SoS)の場合
自律性
完全な運用上・管理上の独立性。
構成する各システムは、異なる組織によって所有・管理され、独自の目的とライフサイクルを持つ。
例えば、航空管制システムにおいて、航空会社の予約システムと気象庁の気象情報システムは全くの別物です。
特性上、なんか知らない間に破棄されてるとかっていう現象が起きる。
所有権
分散・連合型。中央集権的な所有者は存在しない。
マイクロサービスの場合
自律性
技術的な独立性
各サービスは独立してデプロイ・スケールできるが、全体として単一のアプリケーションという共通のビジネス目標を共有する。
所有権
単一組織。通常、一つの企業や事業部門が全てのマイクロサービスを所有・管理する。
4. 設計思想の違い
システムオブシステムズ (SoS)の場合
ボトムアップ / 創発的
既存の独立システムを後から繋ぎ合わせることで、新たな価値を「創発」する。
最初から全体の完成形が設計されているわけではない。進化し続けることが前提。
マイクロサービスの場合
トップダウン / 計画的
単一のアプリケーションをどう分割するか、というトップダウンの設計思想から生まれる。
全体のビジネス目標は最初から明確。
こっちの方が、目的思考のもとに設計される。
5. 連携とデータ管理
システムオブシステムズ (SoS)
連携
主に標準化されたインターフェースやデータフォーマットを介した、疎な連携。
各システムの内部には干渉しない。
データ管理
各システムが自身のデータを完全に所有。
システム間でデータを共有・再利用することはあるが、データストアを共有することは稀。
マイクロサービス
連携
APIやメッセージブローカーを介した、SoSに比べると比較的密な連携。
時にはサーガパターンのような複雑な連携も行う。
データ管理
各サービスが自身のデータストアを所有するのが原則（No Shared Database）。
他のサービスのデータが必要な場合は、API経由で取得する。
(でないと、データ隠蔽できておらず、カプセル化の原則に反する)
6. 変更と進化
システムオブシステムズ (SoS)
進化の非同期性
構成する各システムは、全く異なるタイムラインで勝手に進化・変更される。
SoS全体として、その変化に追従し続ける必要がある。
マイクロサービス
進化の同期性（概念上）
各サービスは独立してデプロイされるが、アプリケーション全体の整合性を保つという共通の目標があるため、APIの互換性など、ある程度の協調が必要。
7. 運用と管理の違い
システムオブシステムズ (SoS)
管理の複雑性
各システムが異なる組織に属している場合もあり、管理権限や調整が複雑。
ガバナンスが重要（各システムの目的と全体目標の整合性を取る必要）。
進化性
動的に構成システムが追加・削除される。
予期しないインターフェース変更や、相互作用の複雑性がマイクロサービスよりも増す。
例：スマートシティで交通とエネルギー管理システムを連携させる。
マイクロサービス
運用の複雑性
各サービスを個別にデプロイ・スケール可能だが、全体の連携やトラブルシューティングに注意が必要。
進化性
ある程度設計した範囲内でサービスを追加・削除。(適応度関数などのガードレールあり)
全体の一貫性を保ちながら変更を管理。
例：ECサイトのカート機能を拡張したい場合、該当サービスだけを更新可能。
8. 技術的な特徴
| 項目 | システムオブシステムズ | マイクロサービス |
|---|---|---|
| 自治性 | 各システムが完全に独立して運用可能 | 各サービスは単独で動作可能だが、全体に依存 |
| 結合性 | システム間の結合が緩く、動的に再構成可能 | サービス間はAPIを介して疎結合 |
| 進化性 | 構成要素が頻繁に変化（追加・削除）することを前提 | サービスの追加・削除は柔軟だが同一アプリ内 |
| 運用 | 異なる組織や運用チームが担当することが多い | 同一チームや組織内で運用される |
| 信頼性 | 個々のシステムが障害を起こしても他のシステムに影響を及ぼしにくい | 一部のサービス障害が全体に影響する可能(カオス実験などで予防) |
9. アナロジー
システムオブシステムズ
異なる国々が、それぞれの法律や文化を保ったまま、条約を結んで国際連合を形成するようなもの。
また、異なる組織同士の統合などもこれに該当する。
マイクロサービス
一つの会社が、専門性の異なるチームを作り、それぞれが自律的に動きつつも、会社全体の利益のために連携するようなもの。
スクラムオブスクラムズは、こちらに該当します。
10. 現実のSoSアーキテクチャ
過去に入ったSoSの案件でのSoSアーキテクチャは、
SoSと名前が付いていますが、実際には分散蜜結合モノリス状態でした。
正直、SoSアーキテクチャを考えるには、クリーンアーキテクチャにある原則やら、
マイクロサービスアーキテクチャの思想がどうしても求められました。
相違点の要約
| 項目 | システムオブシステムズ | マイクロサービス |
|---|---|---|
| 目標 | 複数の独立システムの協調で全体目標を達成 | アプリケーションの柔軟性やスケーラビリティ向上 |
| 構成単位 | 独立したシステム（異なる目的や運用方針） | 独立したサービス（同じ目的のアプリ内） |
| 運用の独立性 | 各システムが完全独立で運用可能 | 単独運用可能だがアプリ全体に依存 |
| 管理の複雑性 | 異なる組織・運用方針間の調整が必要 | サービス間の依存性管理が必要 |
| 信頼性 | 個々のシステムが障害を起こしてもマイクロサービス以上に影響が波及しにくい | 設計によっては他のマイクロサービスに障害の影響が伝わる |
ここまでの結論
SoSは、多様なシステムを統合することで大規模な目標を達成するための枠組みで、運用や管理が高度に分散しています。
マイクロサービスは、単一のアプリケーションを効率的に運用するためのアーキテクチャパターンで、開発やデプロイの柔軟性を重視します。
SoSとマイクロサービスは異なる目的で設計されていますが、SoSの一部にマイクロサービスアーキテクチャが採用されるケースも多々あります。
ハイブリッドで考えることが重要
超大規模なエンタープライズアーキテクチャは、
SoSかマイクロサービスの二者択一ではなく、両者が階層的に組み合わさったハイブリッド構造として捉えるのが最も現実的です。
階層構造として見るアーキテクチャ
これは、アーキテクチャを異なるズームレベルで見ることで理解できます。
ズームアウト(全体俯瞰)と、ズームイン(詳細に虫の目)に分けて考えてみましょう。
1. Zoom Out 企業全体 = システムオブシステムズ (SoS)
まず、企業全体の視点(マクロ)で見ると、その構造はまさにシステムオブシステムズです。
各事業部門が所有・運用する大規模なシステム群は、それぞれが独立した目的とライフサイクルを持つ「システム」として存在します。
例：ある製造業のエンタープライズアーキテクチャ
・システムA：販売・顧客管理システム（CRM, 例: Salesforce）
・システムB：生産管理システム（MES, 例: 自社開発）
・システムC：物流・在庫管理システム（SCM, 例: SAP）
・システムD：人事・会計システム（ERP, 例: Workday）
これらは、異なるベンダー、異なる技術、異なる所有者（事業部門）を持ちながら、
企業全体のビジネスを成立させるために連携します。
このレイヤーの設計思想はSoSの考え方に基づきます。
ただ、実際には多くの企業で、システム間が密に連携しているか。
もしくは、業務の構造とあっていない形で設計され、その後に無理やり繋げられています。
2. Zoom In 個々のシステム = マイクロサービス
次に、上記の一つ一つのシステムにズームイン（ミクロ）してみます。
例えば、自社開発された「システムB：生産管理システム」の内部を見てみましょう。
この単一のシステムが、それ自体、マイクロサービスアーキテクチャで構築されている可能性があります。
例：「生産管理システム」の内部アーキテクチャ
マイクロサービス1：受注オーダー受付サービス
マイクロサービス2: 製造ライン計画サービス
マイクロサービス3: 品質検査記録サービス
マイクロサービス4: 設備稼働監視サービス
これらのマイクロサービス群は、単一のプロダクト開発チームによって管理され、
「生産管理」という一つのビジネス能力を提供するために、SoSよりは密に連携します。
このレイヤーの設計思想はマイクロサービスの考え方に基づきます。
結論
現代のエンタープライズアーキテクトは、
SoSの視点で事業部門をまたがるシステム間の疎な連携を設計し
マイクロサービスの視点で、単一のシステム内部におけるサービス間の密な連携を設計する
という、両方のスケールで思考する能力が求められます。
したがって、「SoSかマイクロサービスか」ではなく、
「SoSとして連携する、マイクロサービスで構築されたシステム群」 というのが、
超大規模アーキテクチャの現実的な姿といえます。
次回は、より実践的なSoSに使える設計原則や思想について触れてみたいと思います。