「System of Systems（SoS）の統合テストは不可能だ」という言説を聞いた

【1】「System of Systems（SoS）の統合テストは不可能だ」という言説を聞いた。

Geminiに聞いたら、こんな回答だった。
結論から言えば、この主張は半分正解であり、半分は言葉足らずです。
正確には、「従来の単一システムで行っていたような、全状態をコントロールし、網羅的かつ決定論的な（結果が必ず一致する）統合テストを行うことは、原理的・実務的に不可能である」というのが真意です。

この話は真理を突いていると思う。

複数システムを組み合わせた全体に対し、統合テストで検証し品質担保できるならば、それは一つのシステムになりうるが、System of Systems の定義に反するので、システムになり得ない。
だから、System of Systemsアーキテクチャでは、複数システムを組み合わせた全体はシステムになり得ず、中途半端な状態にある。
つまり、System of Systems アーキテクチャの品質保証は完全にできない。

実際、各要素である個別システムは単体テスト～システムテストまで全て可能だが、全ての要素であるシステムを組み合わせたテストを検討してみると、本番環境だけでしかテストできないユースケースが多々出てくる。
つまり、本番環境でないテスト環境にて、いくらテストしても、確認できない機能や非機能要件が出てくる場合がある。

特に障害テストが多いように感じる。

【2】よって、複数システムを繋げた全体の品質保証範囲やレベルの上限をどこまで広げられるか、にアーキテクトは知恵を絞ってるわけだ。
つまり、本番環境でしか実際に実行しなければ確認できない機能要件、非機能要件がある前提で、それ以外はテスト環境でできるだけテストして、機能要件も非機能要件も網羅してしまおうという戦略を取ることになるだろう。

【3】「System of Systems（SoS）の統合テストは不可能だ」という前提で、SoSの品質保証するアーキテクトは誰になるのか？
発注者側なのか？
受託者側なのか？

SoSでは全ての品質基準を網羅できない。
よって、SoSのアーキテクトは非常に高度な意思決定と高度な知見を要求される。

契約上は、発注者側になる。
発注者は、各要素の個別システムを各メーカーや各SIerへ開発を受託し、納品してもらうことになる。
それら納品された各システムをつなげて、全体のシステム（SoS）を構成し、一つのモノリシックシステムを完成させたい。
しかし、発注者側のアーキテクトは、SoSは統合テストできない前提を承知したうえで、モノリシックシステムを、品質基準を満たしたうえで動作できるのか？

しかし、賢い発注者なら、受託者側にSoSの品質保証を押し付けるだろう。
賢い発注者であれば、SoSのリスクをできるだけ受託者側に押し付けることで、品質やコストを抑えたいだろう。
よって、発注者は、受託者側に各システムだけでなく、システム全体の統合の責任も契約に入れて、責任を押し付けたい。

すると、受託者は、SoSは統合できない前提のうえで、どこまで品質担保できるのだろうか？
賢い受託者であれば、契約に潜むリスクを見極めたうえで、SoSの品質保証の範囲やレベルを明確に定義して、契約に盛り込んで、発注者と握りたいだろう。
そうでなければ、リスクを全て受託者側に引き受けてしまう罠に陥ってしまうからだ。

【4】SoSの例としては、航空管制システムや自動運転車を含む交通システム、ミサイル発射システムなどの防衛システムなどがあげられるだろう。
それぞれのシステムには、要素となる製品やシステムがあるが、それらを組み合わせて一つのモノリシックシステムを作りたい。
しかし、上記の通り「System of Systems（SoS）の統合テストは不可能だ」。
SoSの品質保証は非常に難しい性質を持つ。
実際にどうやってSoSの品質を担保するのか、思考してみたい。