# Adaptive Choreography ## 定義 Adaptive Choreography(適応的コレオグラフィ)とは、円滑な協調に必要な criteria and attributes(Klein et al, 2005; Johnson et al, 2011)、足場(scaffolding)、elements of choreography から成る枠組みであり、Incident Command System(ICS)に内在する指揮統制構造の代替として Laura Maguire の博士論文第7章で提示された、インシデント対応のモデルである([[@2020__PhD__Controlling the Costs of Coordination in Large-scale Distributed Software Systems - Chapter 7 Adaptive choreography]])。第5章で抽出された elements of choreography(recruiting・delegation・taking direction・synchronizing・side channeling・model updating・cross-checking・escalation 等)が、事前に固定された役割ではなく、分散した対応者間で動的に(dynamically)再配分・分担されることを核心とする。一次出典はこの論文のみであり、本概念ページはこの2020年の記述に厳密に基づく。 ## Incident Command モデルとの対比 ICS(とそのソフトウェア実装)は Incident Commander(IC)個人の能力向上に訓練を集中させ、対応者を IC のリーダーシップに従う受動的な「フォロワー」とみなす前提を含む。第7章はこの前提を明確に否定し、認められているか否かにかかわらず全対応者が微細で検出しにくい形で協調そのものを能動的に管理していることを示す。Adaptive Choreography のもとでは、IC は指揮官(commander)から調整役(coordinator)へと機能転換し、活動追跡・リソース確保・外部世界への緩衝材といった支援機能を担う複数の役割のひとつになる。対応者(Response Engineer)は自己組織化する単位として、タスクの引き受けと手放し、優先順位付け、同期、状況共有を負荷の変化に応じて継続的・流動的に行う主体となる。 中心図(Figure 7.1)は、IC・Comms・Planning の3ボックスが Legal・Compliance/Regulatory・Client Support・Users (External)・Management という外部ステークホルダーとそれぞれ双方向に接続し、同じ枠内の下段には複数(可変数)の Response Engineer が多対多の双方向矢印で結ばれたメッシュを成し、Service Owner Management・複数の Vendor Support Engineer・Vendor Management 等と接続する構造を示す。 ![[ch07-fig7.1-adaptive-choreography-model.png]] (Figure 7.1 Adaptive Choreography as an incident response model。Source: [[@2020__PhD__Controlling the Costs of Coordination in Large-scale Distributed Software Systems - Chapter 7 Adaptive choreography]]) ## Scaffolding(足場) 継続的な適応能力は適切に足場かけ(scaffold)されている必要がある。足場は tacit devices(agreement・convention・precedent・salience、Klein et al, 2005)と adaptive mechanisms(ツール類・慣行)の両方から成り、コレオグラフィを動的に調整すべき時を知るためのアフォーダンスを提供する。ソフトウェア自体、役割間相互作用への期待、媒体を流動的に切り替える仕組みに埋め込みうる。例として ChatOps のユーザーチャンネル(問題の早期兆候の受信・ユーザーへの更新提供の一貫した場)、共同拠点チームにおける動的に再構成される物理・仮想の「コントロールルーム」が挙げられる。 ## エスカレーションの動態と elements of choreography の再配分 elements of choreography は協調ネットワーク全体で実質的に充足される必要があるが、すべての参加者が常にすべての要素を発揮する必要はない。共通基盤の確立に投資が少ないグループでは新規参加者を追いつかせる労力が増し、行動は文脈依存で強調・弱化される。Branlat & Woods (2011) のサイバーセキュリティチーム研究が示す「純粋な中央集権も純粋な分散も失敗しやすく、統治は両者のバランスを取る必要がある(polycentric control architectures)」という知見が、CDI における協調設計の直接的な含意として引用される。 ## 横断的知見 - **Response Trio(コンダクター・コミュニケーター・問題解決者)との構造的な差異**: [[@2023__SREcon23Americas__Human Observability of Incident Response]](Matt Davis, 2023)は Adaptive Choreography を、ステークホルダーがコミュニケーターのみを介して接続する固定3役割の三角形として紹介する。しかし一次出典である本論文第7章は "conductor" "communicator" "problem solver" のいずれの語も使わず、中心図(Figure 7.1)は IC・Comms・Planning に加え可変数の Response Engineer が多対多で結ばれるメッシュ構造を示す。固定3役割への還元は Davis による二次的な単純化・再構成である可能性が高い。詳しい比較と `> [!contradiction]` の全文は [[@2020__PhD__Controlling the Costs of Coordination in Large-scale Distributed Software Systems - Chapter 7 Adaptive choreography]] と [[Followship]] を参照。(Source: [[@2020__PhD__Controlling the Costs of Coordination in Large-scale Distributed Software Systems - Chapter 7 Adaptive choreography]], [[@2023__SREcon23Americas__Human Observability of Incident Response]]) - **第6章の「フェーズとしての協調」「役割への機能割当としての協調」という2つの既存枠組みへの批判は、Adaptive Choreography が固定役割ではなく動的な再配分を核心とすることの理論的な動機づけである**: [[@2020__PhD__Controlling the Costs of Coordination in Large-scale Distributed Software Systems - Chapter 6 Discussion]] は、協調をフェーズに区切る見方(Klein et al. 2005)と、協調を単一の役割に割り当てる見方(Beyer et al. 2016)の両方が、複雑性・速度・関与する役割数の増加のもとで破綻すると論じる。第7章はこの批判を引き継ぎ、IC を commander から coordinator へ機能転換させ、elements of choreography を対応者間で動的に再配分するという Adaptive Choreography の核心設計へ直接接続する。(Source: [[@2020__PhD__Controlling the Costs of Coordination in Large-scale Distributed Software Systems - Chapter 6 Discussion]], [[@2020__PhD__Controlling the Costs of Coordination in Large-scale Distributed Software Systems - Chapter 7 Adaptive choreography]]) - **第6章のサイドチャネリング論(叱責ではなく制度化)は、第7章の scaffolding という設計要素の必要性を準備する**: 第6章は、サイドチャネル形成(Allspaw-Collins effect)を排除すべき逸脱ではなく必要な適応として扱い、更新の共有・引き出しを強化すべきだと主張するに留まり、具体的にどう強化するかは示さない。第7章の scaffolding(tacit devices と adaptive mechanisms)は、この「どう強化するか」という第6章が残した設計課題に対する具体的な答え(ChatOps のユーザーチャンネル、動的に再構成されるコントロールルーム等)を提供する。(Source: [[@2020__PhD__Controlling the Costs of Coordination in Large-scale Distributed Software Systems - Chapter 6 Discussion]], [[@2020__PhD__Controlling the Costs of Coordination in Large-scale Distributed Software Systems - Chapter 7 Adaptive choreography]]) ## 未解決の問い - Adaptive Choreography の効果(協調コストの実測的な低減)は、ICS 運用組織との対照実験・準実験でどの程度定量的に確認できるか? 本論文は事例コーパスに基づく質的な提案に留まる。 - 足場(scaffolding)の設計指針(どのツール・慣行がどの elements of choreography を支えるか)は、本論文の記述からどこまで具体化・体系化できるか? - Response Trio のような後年の簡略化された提示は、Maguire 自身の別の講演・論文で明示的に採用・修正されているか? 現時点では未確認(第7章には存在しない)。 - Adaptive Choreography を実行すること自体のコストが高くなりすぎるのはどのような条件下か。結論章が今後の課題として挙げる(Source: [[@2020__PhD__Controlling the Costs of Coordination in Large-scale Distributed Software Systems - Chapter 8 Conclusion]] p.161)。 - ポストインシデントの振り返り(post-incident work)の分析範囲を、技術的な原因追及だけでなく choreography についての省察にまで広げるには、どのような支援が要るか(Source: [[@2020__PhD__Controlling the Costs of Coordination in Large-scale Distributed Software Systems - Chapter 8 Conclusion]] p.161)。 ## 関連 - [[Followship]] — 「対応者は受動的フォロワーではない」という本概念の主張が後年フォロワーシップとして展開される原形 - [[Incident Commander]] — IC 個人の役割設計。本概念は IC を「複数の支援役割のひとつ」へ再定義する - [[Joint Activity]] — elements of choreography の理論的基盤 - [[Common Grounding]] — 足場・共通基盤の維持プロセス - [[Laura Maguire]] — 提唱者 - [[@2020__PhD__Controlling the Costs of Coordination in Large-scale Distributed Software Systems - Chapter 7 Adaptive choreography]] — 一次出典 - [[@2020__PhD__Controlling the Costs of Coordination in Large-scale Distributed Software Systems - Chapter 6 Discussion]] — 既存の協調モデル(フェーズ・役割割当)への批判、サイドチャネリング論という理論的な準備段階 ## 出典 - [[@2020__PhD__Controlling the Costs of Coordination in Large-scale Distributed Software Systems - Chapter 7 Adaptive choreography]] — 一次出典。枠組み・Figure 7.1・scaffolding の全記述 - [[@2020__PhD__Controlling the Costs of Coordination in Large-scale Distributed Software Systems - Chapter 6 Discussion]] — 既存の協調モデルへの批判とサイドチャネリング論。第7章への橋渡し