システムオブシステムズにおけるテストの重要性と理想と現実

(注)　以下で書くSoSとはシステムオブシステムズのことを指す。

# 主張
SoSではいきなり多数のシステムを連携させるべきではない。
少しずつスコープ内の要素を増やしていきつつテストを常時する。
そうでないと連携した瞬間に、要素同士が予測しえなかった相互作用を及ぼしあって
なぜか必ずあるタイミングでシステムがダウンするっていう問題が発生した際にも、
いきなり50個ものシステムを連携していたら、それおらの間のどこで問題が発生したから
SoS全体でダウンしたのか？ていう原因の特定がしにくい。

これはSoS全体を1つのシステム、SoSを構成する１つ１つの構成システムの関係を
システムと　コンポーネント(やクラス)の関係性に見立てるとわかりやすい。

①SoS全体とそれを構成する1つの構成システムとの関係性
②システムとそれを構成する1つのコンポーネントとの関係性
これらはアナロジー思考で考えたら両者同じである。

現状として、SoSでは同じコンテキスト内にいる個々の構成システムの運用者やテスト設計者の連携が取れておらず
独立してしまった設計をしていることがアンチ的な【常識】として蔓延してしまってるように感じる。

そのため同じコンテキストにいる構成システム同士は、管理している企業が別々の場合、
理想としては企業同士で連携し合う必要がある。
さもなくば、SoSのサービスアーキテクチャ全体が悪い意味でコンウェイの法則にしたがった構造となることが容易に想像がつく。
ただSoSの基本的考え方としては、
・本来繋ぎたい先の詳細なんて知らずに連携していくこと
・個々の構成システムはバラバラに管理されることを前提としている
というものが現状課題としてある以上、
連携基盤な立ち位置のプラットフォーム側でシステム同士の結合テストやら統合テストを行い、
安全性などを保障してあげる必要性があるようで、こおプラットフォームがまだ確立されていないようです。


# AsIsとToBe
現状はSoS全体のテストという仕組みや体制は普及していないようである。
個々の構成システムの運用者・所有者はいても、SoS全体を統治するテスト設計者や運用者を設けるという観点が
なかったり、その観点があってもできる仕組みがなかったりするSoSプロジェクトしか自分はみたことがない。
(案件数が少ないというのもあるが)
さらにはそこに対する課題意識も「SoSは本来個別に開発した構成システムを連携するが管理は独立しており、全体のマネジメントはしないのが普通」という【よくわからない常識】が蔓延している。

個々の構成システムでは、システムテストが充分に行われているっていう前提で繋げている。
しかしながら相互運用性を高めることや１つのリソースでは実現しえなかったものを
複数のリソースを使って実現できるというSoSのメリットにばかり焦点が当たっていて、
肝心のデメリット　繋げたことによる良からぬ相互作用の発生によって
・あるトランザクションを走らせるとSoS全体が落ちる
・個別で動かしてた際には発生しなかった不整合リスク
など様々なリスクの発生確率が上がることが想像つく。

ToBeは繋げることにより、より大きなビジョンを達成したり、新しい価値の創造のための
情報連携が低リスクでできることである。
そうでなければ繋げることによるリスクが、繋げることによる恩恵を大きく上回ってしまい
結局莫大なコストをかけてSoSのアーキテクチャを考えたのに、使われないSoSになってしまいかねない。

# 対応策
このSoS全体のテストができるためには、個々の構成システムを別々に管理しているっていう体制をどうにかしないといけない。
具体的には、システムAとBを連携してSoSを構築したい場合、
Aの運用管理責任者とBの運用管理責任者同士で密に連携を取り合う必要があったり、
Aのアーキテクトの代表者とBのアーキテクト代表者が密に連携を取り合うなどして、全体をマクロな視点で管理しなくてはいけない。

もしもこの連携をする際に、Aを管理する企業またはBを管理する企業のガバナンスが邪魔している場合には、
そのガバナンスの見直しをする必要もあるだろう。
なのでガバナンスアーキテクチャとも兼ね合いで検討を必要とすることもあるでしょう。

これだけ書いててもすでに非常に労力を伴う地道な土台作りを必要とするのが容易に想像つくが、
これはSoS全体で価値を提供し続けるための【投資】としてSoSのアーキテクチャの妥当性検証にコストをかけるべきだと感じる。
(もちろんすべてのテストを満遍なくやるって意味ではなくて、濃淡つけたテストって意味で書いてます)

そして、マイクロサービスアーキテクチャなどのサービスアーキテクチャの思想に則って、
aて企業が別のシステムBを管理する他の企業bと密な連携をしつつも、徐々にSoSレベルのサービスの粒度に分割しつつ、
そのSoSサービスアーキテクチャの妥当性の検証が充分にされたら
もともとの企業aとbは構造をそのサービスアーキテクチャの形に合わせて全く別の形に変わっていることが望ましい。(逆コンウェイの法則)

## サービスのコンテキスト境界
それ以外にも、SoS全体のコンテキスト境界という観点においても再検討できるための仕組みとしてSoS全体のテストはマストである。

根拠は、システムの上で走ってるアプリケーションサービスの再設計の考え方
モノリシックな構造から、徐々に疎結合なマイクロサービスアーキテクチャに移行していき
アプリケーションのアジリティを高めて迅速に価値提供できるようにする。
ていうこの思考は、なにも１つの構成システムだけに言える話ではなく、
SoSというドでかいシステムにも適用されるだろうという　【一様性】の思想に基づいている。

たとえばあるSoSと、別のSoSが頻繁に連携し合うことを必要としているが、
あるアクセスが集中する時間帯には80%程度の頻度でアクセスエラーが発生し、
連携がうまくできないことによるトラブルが発生しているという場合に、
コンテキスト境界の見直し　SoSサービスアーキテクチャの再検討をするためには、
最初に設計する時点からこの運用がしやすいための指標として、
「別のSoSとの連携をする際に、アクセス集中する時間帯で30%を超える頻度でダウンが発せし始めたらアーキテクチャの再検討をすること」
「SoSサービスの拡張時に、極力他の構成システムに影響を与えることなく、追加分だけ検証すればOKという状態にするため、拡張開始～拡張完了までのタイムの増加率を監視し、その時間が事前に設定した〇時間を超える場合はアーキテクチャの再検討をすること」
などのように、可用性や拡張性、凝集性、セキュリティなど様々な品質観点から
時間の流れとともに変わるSoSサービスアーキテクチャのコンテキスト境界を再検討するということが求められる。

その際に再検討の判断材料になるのが、サービス全体のアジリティなどが低下していることを裏付ける事実データであり、
それを採取するために常時SoS全体を検証モニタリングする必要がある。

これは１つのシステム上で走ってるアプリケーションサービスのアーキテクチャの見直しの思想と同列である。
当然コンテキストの領域範囲を変更したら、テストのアーキテクチャも変えなくてはいけない。



# 運用・保守面
運用フェーズにおいてはSoS全体で指定されたillitiesの品質指標数値を常にモニタリングし、
指標の許容範囲を超えたものに関しては、その発生時刻や発生頻度をいつでもグラフで分析できるようにしておくことが望ましい。
また、ISOなどに記載のある一般的な品質だけではなく、そのSoS固有の品質変数を
モニタリングしつつ考えるためにも、ビジネスサイドに近いデータエンジニアと連携が必要であると考えられる。

たとえば、最初聞いていた重要な品質の変数の求められる指標を満たすように設計されているのにもかかわらず、ユーザーからのクレームが相次いでいるといった場合には、
他の品質変数または、いまだない品質変数を自分たちで明らかにし、
その変数の指標をモニタリングしておく必要がある。
これはFunctionなどの動的な観点でのモニタリングだけではなく、データの品質という観点においてもである。
そのうえで定期的に現在のアーキテクチャの妥当性の検討をSoS全体を管理するアーキテクト数名で行う。
対象のSoSが医療系のような人命にかかわるようなSoSで、停電時など含めた障害に強いことが求められていれば、
拡張性よりも可用性が優先される品質であるという事がそのSoSの特徴のため、
拡張性のパラメタデータよりも可用性のパラメタデータを注力して検討すべきである。
よって、拡張性の観点ではSoSサービスアーキテクチャの見直しをしてコンテキスト境界の変更をする必要がないと判断されても、
非常に高い関心の可用性の観点で変更すべきという結論が出たらリアーキテクティングする必要がある。

## テストの運用のしやすさ
最初からあらゆるテストを不足なく洗い出すのは不可能に近い。
なにかテストが足りておらず、SoSのサービスを稼働してから判明する重要な検証だって当然ある。
その際に追加すべきテストが既存のテストアーキテクチャに影響を与えることなく、
追加できることが望ましいと言えるので、テストの変更や拡張もしやすいための指標として、
たとえば追加すべきテストが明らかになってから～テストの拡張が完了するまで　の時間を計測するといった手段が考えられる。

さらには、コンテキスト境界が変更された際のテストのリアーキテクティング活動も
しやすい指標として、テストアーキテクチャの変更容易性が挙げられる。
逆にほぼ要件の変更が入ることがない安定しているコンテキスト境界のテストに関しては、
変更容易性はほぼ求められておらず再利用性を高めておくことで、
テストアーキテクチャのメンテナンス性を向上させて、より迅速にSoSサービスを提供し続けられるようにする。

# 結論
SoSでは、個々の構成システムのテスト検証以外にも、
次のような手順で細かく検証をした上で全体を繋げるっていうことをする。
①.個々の構成システムの検証、構成システムテストを行う。
②.一気に繋ぐと問題の特定がしにくいので、
構成システムテストが完了したシステムを1つ1つ小さい範囲でつないで構成システム同士の結合テストを行う。
③.②が完了したらSoS全体のシステムオブシステムズテストを行う。

その後の運用では、
SoSの強みである相互運用性や　新しい価値創造、コラボすることにより得られる感動体験という特性を高めるために、
コンテキスト境界の妥当性が無くなってきている部分を早急に明らかにし、
リアーキテクティングするべきなのか？それともしないべきなのか？という両方の観点からのメリデメを議論し、
コンテキスト境界が変更されたらそれに伴って、テストのリアーキテクティングも行う。

ただそのためには組織体制そのものがこれを支援する形になっていないといけず、
そのためには組織のガバナンスの見直しの再検討も必要な場合があるし、
その際にガバナンスを変えることのメリデメ、ガバナンス変えないことのメリデメを評価したうえで調整しないといけない。とても骨の折れそうな活動だ、、、、、。