# 複雑性の経済的支柱 (Economic Pillars of Complexity) ## 定義 複雑性の経済的支柱は、Kent Beck が発表し、トレント大学経済学部教授 Enrico Zaninotto の発表に基づいてソフトウェアエンジニアリングへ応用したモデル(Kent Beck, "Taming Complexity with Reversibility," Facebook post, July 7, 2015)である。組織がそれぞれの柱をどれだけ制御できるかによって、競争の激しい生産プロセスの複雑性にどれだけうまく対処できるかを測る。4本の柱は状態(States)・関係(Relationships)・環境(Environment)・可逆性(Reversibility)からなる。フォード社の事例(T型フォードへの標準化・科学的マネジメントによる分業の単純化・ALAM への訴訟)は状態・関係・環境の3本柱を制御できた例として、生産プロセスを後戻りできなかったことは可逆性を制御できなかった例として引かれる。ソフトウェアの場合、状態(データ・機能の増加)・関係(抽象化レイヤー・マイクロサービス化による部品間関係の増加)・環境(有意義な影響を及ぼせるスケールを持つ企業はごくわずか)の3本柱は制御が難しいが、可逆性だけはバージョン管理・ブルーグリーンデプロイメント・カナリアデプロイメント・feature flag・CI/CD といった技術的ソリューションによって明示的に向上できる、ソフトウェアが本領を発揮する柱である。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 2 複雑なシステムの舵を取る]] §2.2-§2.2.5) ## 横断的知見 - **1章の本質的複雑性/偶発的複雑性という二分法(診断)と、2章の経済的支柱という四分法(処方)は、「複雑性は減らせない」という同じ結論を異なる粒度で補完する**: [[本質的複雑性と偶発的複雑性]] が集約するとおり、1章はFrederick Brooksの区別を用いて複雑性は本質的か偶発的かを問わず持続可能な形では削減できないと論じ、可用性を高めるキー・バリューストアの例で「複雑性を増やさずに機能や可用性を高めることはできない」と具体化していた。2章はこの前提を引き継ぎ、「単純化は実用性を下げビジネス価値を制限し、成功の可能性は複雑性と共に上昇する」と述べたうえで、複雑性そのものを減らす代わりに状態・関係・環境・可逆性という4本柱のうちどれを組織が制御できるかに着目する対処法を提示する。1章が「複雑性は削減できない」という否定的な結論(診断)を導くのに対し、2章は「削減できないなら、どの軸を制御できるかを見極めよ」という建設的な処方箋へ接続しており、両章は同一書籍内で診断と処方の役割分担を持つ。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 1 複雑なシステムとの出会い]] §1.3-§1.3.2, [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 2 複雑なシステムの舵を取る]] §2.2) - **二次資料(『SREの探求』14章)は本モデルを「複雑さの経済的な柱」として簡略に引用しており、一次資料(2章)によって初めて4本柱の内実とフォード社の具体例が確認できる**: [[カオスエンジニアリング]] ページの未解決の問いは、Rosenthal の「複雑さの経済的な柱」(状態・関係・環境・不可逆性、Kent Beck のモデル)が Bradesco の実験カテゴリ(Hardware/Communication/App-Microservice/App-Middleware/App-Database)とどう対応づけられるかを尋ねていた。一次資料である本書2章を読むと、4本柱はいずれもフォード社の生産プロセスという非ソフトウェア領域の具体例(状態=T型フォードへの標準化、関係=科学的マネジメントによる分業単純化、環境=ALAM訴訟、可逆性=フォード社が制御できなかった柱)で導入されたのち、§2.2.5でソフトウェアへの適用が論じられる。Bradesco の実験カテゴリのような技術インフラの故障モード分類とは抽象度が異なり、2章の原典は両者を直接対応づける記述を持たない。したがって未解決の問いは本章によって解消されないが、少なくとも4本柱が組織論・生産プロセス論に起源を持つモデルであり、技術インフラの実験カテゴリ分類とは異なる階層の概念であることが原典によって確認できる。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 2 複雑なシステムの舵を取る]] §2.2-§2.2.5, [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] §14.2) - **ソフトウェアが「可逆性だけを明示的に向上できる稀有な柱」だという2章の主張は、CPS(サイバーフィジカルシステム)を扱う17章によって、ソフトウェアが物理世界に対して作用する場面ではこの優位性が失われるという限界を与えられる**: 2章(既出)は、ソフトウェアがバージョン管理・ブルーグリーンデプロイメント・feature flag等によって可逆性を明示的に向上できる稀有な立場にあると論じる。この主張は暗黙に「ソフトウェアの変更はロールバック可能である」ことを前提とするが、17章(Nathan Aschbacher著)はサイバーフィジカルシステム(CPS)——ソフトウェアが物理的な世界に対してデプロイ・作用するシステム——において「物理的な世界では、少し時間を置いてから単純に再試行すること自体ができないケースがまま」あり、その間に「本当に火事や浸水に巻き込まれてしまうかもしれない」と明記する。これは2章が可逆性の技術的実現手段として挙げるロールバック・feature flagが、ソフトウェアがアクチュエータを介して物理世界に不可逆な結果(火災・浸水・機械的損傷)を生んだ後では機能しないことを示す——2章の可逆性の優位性は、ソフトウェアが情報空間に閉じている限りで成立する前提付きの主張であり、CPSという物理世界への越境によってその前提が破れることが、独立した2つの章の突き合わせで初めて明らかになる。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 2 複雑なシステムの舵を取る]] §2.2.5, [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 17 サイバーフィジカルで行こう]] §17.4) ## 未解決の問い - CPSにおいて、2章が挙げる可逆性向上の技術群(バージョン管理・ブルーグリーンデプロイメント・feature flag等)のうち、物理的なアクチュエーションが発生する前の段階(ソフトウェアの意思決定・計画部分)に限って適用できるものはあるか。17章はCPSにおける可逆性の限界を指摘するのみで、CPSのソフトウェア部分にどこまで2章の可逆性向上手法を適用できるかには踏み込まない。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 17 サイバーフィジカルで行こう]] §17.4) - Rosenthal の複雑性の経済的支柱(状態・関係・環境・可逆性)は、Bradesco の実験カテゴリ(Hardware/Communication/App-Microservice/App-Middleware/App-Database)とどう対応づけられるか。2章原典はソフトウェアへの適用を一般論として述べるにとどまり、具体的な実験カテゴリとの対応は示していない。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 2 複雑なシステムの舵を取る]] §2.2.5, [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]]) - 状態・関係・環境の3本柱がソフトウェア企業にとって制御困難だという2章の主張は、すべての企業規模・業種に一般化できるか。大規模プラットフォーム企業(環境に影響を及ぼせるスケールを持つ)は例外になりうるか。 - 可逆性を明示的に向上させる技術群(バージョン管理・feature flag・CI/CD等)のうち、どれが実際にカオスエンジニアリングの実験対象になりやすいかは2章では具体化されていない。後続章(4章以降の実践事例)で確認できるか要追跡。 ## 関連 - 概念: [[カオスエンジニアリング]] / [[動的安全モデル]] / [[本質的複雑性と偶発的複雑性]] / [[ソフトウェア複雑性]] / [[機能安全]] — CPSにおける可逆性の限界(17章) - 概念(隣接領域、直接の知見統合はなし): [[可逆性と不可逆性]] — 物理学・システム論における可逆性/不可逆性を扱う概念。本ページが扱うソフトウェア・生産プロセスの可逆性とは対象領域が異なる - source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 2 複雑なシステムの舵を取る]] — 本モデルを紹介する一次資料 - source: [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] — 同一著者による二次的な要約 - source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 1 複雑なシステムとの出会い]] — 複雑性が削減不可能であることを論じる前章 - source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 17 サイバーフィジカルで行こう]] — CPSにおいて物理的な不可逆性が可逆性向上の技術群を無効化しうることを示す章 ## 出典 - Casey Rosenthal, Nora Jones, 「複雑なシステムの舵を取る」, Casey Rosenthal・Nora Jones 編『カオスエンジニアリング ― 回復力のあるシステムの実践』, オライリー・ジャパン, 2022, 2章(§2.2-§2.2.5)。原注: Kent Beck, "Taming Complexity with Reversibility," Facebook post, July 7, 2015. - [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] — Casey Rosenthal, 「初めにカオスありき」, David N. Blank-Edelman(編)『SREの探求』, オライリー・ジャパン, 2021, 14章(§14.2) - Nathan Aschbacher, 「サイバーフィジカルで行こう」, Casey Rosenthal・Nora Jones 編『カオスエンジニアリング ― 回復力のあるシステムの実践』, オライリー・ジャパン, 2022, 17章(§17.4)。