制御と複雑性：システム設計における緊張

制御と複雑性：システム設計における緊張

LLMがソフトウェア開発に浸透して以来、無数の組織が自分たちの実践と組織構造を急速に変えてきた。新しいコードを書くためのコスト計算はやり直され、旧来の手法は疑問視され、置き換えられ、別の用途へと転用された。人間とLLMは互換ではないのだから、両者をめぐる力学もまったく異なる。だがシステムはあくまでシステムであり、具体的に何が変わろうと、指針や警告を与えてくれる既知のパターンは存在する。

まず一歩引いて、自分が置かれているシステムが設計時にどのような思考に基づいていたのかを見なければ、そこから導かれる施策や方針はちぐはぐなものになりかねない（ここでいうちぐはぐさとは「互いにぶつかり合う」「衝突する」という意味であり、「筋が通らない」という意味ではない）。そこで本稿では、二つの考え方を対比しながら、私たちがどうシステムを組織するかを論じたい。

一つは分析的分解であり、目標はシステムを常に制御可能な状態に保つことにある。もう一つは複雑系の視点に立ち、システムは分析できないと考える。関心は、望ましい創発的行動を促すために、さまざまな相互作用とメカニズムを解明することに置かれる。

この二つを並べて比べることは、システム設計におけるさまざまな前提と鍵となる要素を整理するのに常に役立ってきた。今、新たな変革が提唱されている状況でも、この比較は依然として意味を持つ。

二つの考え方

分析的分解と制御

古典科学、工学、そして多くの管理手法の核心にある考えは、全体はその各部分から理解できるというものだ。複雑なものを、一つ一つの構成要素を徹底的かつ詳細に理解できるまで細かく分解できれば、全体がどう動くかも分かるはずだ。この方法——分析的分解（「デカルト＝ニュートン的」と呼ばれることもある）——は、現代生活の無数の領域で信頼でき、安定して機能してきた。

この分解し、分析し、理解する能力は、通常、時間とともに変化する因果関係の理解にも及ぶ。作用には反作用があり、出来事には実質的な原因があり、それらは追跡でき、評価でき、客観的に検証できる。そこから逆にこう推論できる。ある対象を十分に理解していれば、外力が加わったときにそれがどう振る舞うかを予測できる。

これが、あらゆる予測可能性と信頼性の上に機械やプロセスを構築する基盤だ。高次の目標を一つ置き、互いに独立した部品を多数用意し、問題を分解し、十分にテストされ公差内に収まったコンポーネントを組み立てれば、使える解が得られる。一つの帰結として、機械の中のどの部品もそれぞれの役割を果たしていれば、機械自体もうまく動くはずだ、という考えが導かれる。

これには、混沌とした無秩序な世界を飼いならし、各パラメータを制御して、変動を境界の内側に収めることが必要になる。設計時に十分な公差と冗長性を確保しておけば、物事はうまくいくはずだ。もしうまくいかなければ、深く入り込み、分解し、どこが壊れたのかを突き止め、直し、そのぶんだけ良くなる。

この方法は至るところにある。信号処理や通信——そこでは、冗長性によって損失のある情報伝送が検出・訂正される——から、産業における品質管理——そこでは統計的プロセスを用いて生産の許容範囲を画定できる——まで続く。

それは人間のレベルにも存在する。人間工学では、作業記憶（典型的なオペレーターが頭の中で同時に保持できる事項数）や理想観察者（最適な頻度で計器を監視する理論上の人間。これに照らして「慢心」を定義する）といった概念が構築され、人間が関与するシステムで、人を常に理想的なパラメータの範囲内で行動させることが目指される。

組織のレベルでもはっきり見て取れる。官僚的なプロセスと階層構造は、トップダウンで一貫性を維持し、集合体全体を協調して動かすためのものだ。規律と可読性のメカニズムが働き、組織の進化を制御下に置く。さらに大きな尺度では、組織は自分が置かれた環境、市場、あるいは立法の背景を制御しようとしばしば試みる。

要するに、あるプロセスの内部でどの程度の混沌を許容するかを決めることで、その外部に対して、他者がやり取りするためのより明確なインターフェースを定義できる。この抽象化が、複雑な集合体を扱いやすい一つの単位にまとめ上げる、単純だが有効な方法を生む。

ソフトウェアは結局のところ、この思考法の理想形となった。システムは、ある程度の、苦労して手に入れた決定性を保証する言語で書ける。理想的には、実行結果は常に同じで、摩耗もなく、昨日動いたものは明日もどこでも同じように動く。現場から遠く離れた場所で下された戦略的判断は、あらゆる階層で決定論的に強制できる。

つまりシステムは、コンポーネントからボトムアップで組み上げつつ、トップダウンの意図と整合させることができ、それによって加工工程や人間の行動に由来する変動を制限できる。その理想は、高度に予測可能で、制御され、競争力があり、機敏に反応するシステムだ。

複雑性と創発

問題は、複雑系が定義上、分析的分解に抵抗することだ。

複雑系については多くの競合する記述があり、あるものは振る舞いのレベル、あるものは構造のレベルに関する。それらは突き詰めれば、こういう一文に集約される。「事物の相互関連が多すぎ、状態が多すぎて、表現も予測も制御もできなくなる」。

他の鍵となる要素はこうだ。これらのシステムは動的で、自らの歴史に深く影響され、しかも開かれている——絶えず変化し、絶えず相互作用し、その仕方は明確な境界を尊重しない。ここから緊張が生まれる。多数の主体が、それぞれ異なる目標、視点、表象、自由度を持つ。システムを分析し終えるころには、それは別のものになっている。システムを観察すること自体が、重要な仕方でそれを変えてしまうことさえある。

言い換えればこうだ。システムの振る舞いに不意を突かれたと気づいたときには、何が起きたかを解明し終えるころにはそれは別のシステムになっており、あなたの戦略の修正は遅れるか、あるいはさらなる直感に反する不意打ちを生むか、そのどちらかになる。複雑系は制御されるというより、影響を受ける。

この動態性が、同じように動的な調整を促す戦略を生む。これらの調整を予測可能にできない以上、介入はしばしば小さな歩みで、反復的になる。逆に言えば、制御したい要素や相互作用を単純化できないなら、制御する側の振る舞いの多様性を増やし、より良い調整を続けられるようにすればよい。これは通常、「制御器——人間であれ何であれ——を置き、それが制御するものの複雑性を相殺するのに十分な内部複雑性を持たせる」ことを意味する。サイバネティクスの言葉で言えば、より適応的で動的な制御機構を作ろうとする試みだ。

平衡は、物事を静止させて保つことでは得られない。動かし続けることでしか得られない。

理想のシステムは自己認識と柔軟性を備え、挑戦が大きくなっても適応し続け、自らを動かし続ける。その理想に到達できるかどうかは、まだ決着していない。

それらがどう組み合わさるか（あるいは組み合わさらないか）

システムはたいてい、問題とその潜在的な解法を限定的に定義することから生まれる。その定義は扱いやすく、有効だ。運用の範囲と規模が包括的になるにつれ、システムを導こうとするさらなる介入は見返りが減り、意図しない結果をますます生むようになる。物事がもつれ合うとき、そこに現れているのは複雑系の効果だ。

私が最もよく見てきた対処法は、倍賭けだ。分析を増やし、分解を増やし、より多くの状況をカバーする柔軟な自動化に力を注ぐ。これが今度は成功と失敗の性質を変え、ときに頻度は低いがより大きな事故を生む。この組み合わせは、壊れる部分をできるだけ置き換えることで成立する。偶然そうなることもある。順序立ったプロセスであることはほとんどない。

より珍しいのは、分析と制御を中心に据えた方法からどこまで捨てられるかを見極め、どうしても変えられないものは何かを見つけ、そこから外へ向かって複雑性を意識した仕組みを広げようとする対処法だ。こちらはずっと居心地が悪い。この立場を取れば、自分が本当にすべてを掌握しているという思いを手放さなければならないからだ。企業にとって、それを公に認めるのは極めて居心地の悪い状況である。

実際、より大規模な事故が本当に避けられるのかについては、以前から論争がある。たとえば Jean-Christophe Le Coze は次の分類を示している。

1. 「決定論」の系譜：技術システムそのものの特性（緊密な結合や複雑性など）が、事故を防ぐあらゆる努力を最終的に打ち砕く。
2. 「認知」の分岐：組織は「予見の失敗」に見舞われる。事故が進行していることを示す微弱な信号や兆候は、権力構造に見られず、受け入れられず、世界観も新しい挑戦に適合しない。そこで事故が起きる。
3. 「自己組織化」の系譜：システムを適応的とみなし、成功も失敗もシステムの自己組織化の結果と捉える。与えられた資源のもとで問題空間と解決空間がどう探索されるかを調べる。

これらの見方は完全に相容れないわけではなく、あるカテゴリに属する著者が別のカテゴリの見方を借りることもよくある。 だがそれぞれの視点には固有の焦点がある。つまり、重要であり考慮に値するとみなされるものだ。制御の構造、システムの歴史性、権力構造の力学、システムの適応と変化の本質、参加者の限られた視点、文化をめぐるさまざまな概念などである。

この論争に関わる多くの人は、事故は予測できず避けがたいと言いながら、事故の確率を下げるのに役立つ説明を依然として探している。既知の方法の限界を吟味し、考慮すべき範囲を広げ、新しい洞察を明らかにする視点を加えていく。

どの実践がうまくいかないか（そしてどんな状況でうまくいかないか）、どの実践が特定の文脈で役立つかをよりよく掴むために学ぶべき文献は、各分野にすでに大量にある。ここで私が持ち出した対立、すなわち制御のための解析的分解と、創発のための複雑性という対立は、粗く、細やかさを欠いている。だが願わくば、まさにそのために、システムの変革を考えるための道具になればと思う。

私たちがやっているのは過度な単純化であり、自分がどの種類の誤りを犯そうとしているのかを分かっているのは役に立つ。George Box（1976）が言うように、「すべてのモデルは誤っているのだから、[私たちは]それが肝心なところで誤っていることに警戒しなければならない」。

実践における二つの考え方の対比

やや誇張した例を挙げて、ソフトウェアに関わる論点を捉えるときの比較的典型的な二つの視点を示す。解析的分解（制御に注目）と、複雑性（意図的に影響だけに関心を絞る）である。

論点	解析的分解 / 制御	複雑性 / 創発
研修と教育	明確に定義されたカリキュラム、教師とトレーナーのベストプラクティス、評価の仕組みを定め、成果を予測可能にし、受講者の水準を揃える。	探索、試験、情報交換を促す環境をつくる。指導と支援を提供する。
安全	失敗を招く望ましくない行為を防ぐ。危害は封じ込めるか設計段階で除去し、手順やベストプラクティスからの逸脱はリスクとみなす。	成功へ向かう望ましい行為を育てる。人が手順の隙間をどう埋め、障害をどう迂回し、問題からどう回復するかを見つける。
正しさ	ソフトウェアの挙動が仕様や API の取り決めに一致する。テストが通り、機能が揃い、既知の境界の内側で動作する。	ユーザーや顧客が作業を無事に終えられる。目標はそのニーズに応じて変わりうる。
信頼性	稼働時間が許容範囲に収まり、SLA や SLO などで検証できる。負荷試験と十分な検証で障害を避けられる。	顧客が不満なら、いくつのナインも意味をなさない。ソフトウェアが実際に使えるかどうかは、本番環境に出して初めて分かる。回復と不測の事態への備えを用意する。
事故への対応の仕方	runbook でベストプラクティスを定義する。問題の調査とトリアージをできるだけ効率的に行うための取り決めと手順を定める。情報の明確さと迅速な診断のために作る。故障の原因を突き止め、再発を防ぐ。	想定外の事態には即興が要るかもしれない。何が起きるかは分からない。未知に対処する力を築く。調査は正常な動作に注目し、まずシステムが本来どう動いていたのかを明らかにする。
機能の開発	ユーザーのニーズと既存の解決策の長所短所を理解し、それに基づいて何をどう作るかを判断する。	候補の機能を実際の場面で試し、反復し続けることが、どの機能が本当に役立つかを見つける最良の方法だ。
標準と仕様	検証可能なプロセスと結果に基づいて曖昧さなく書き、実行を操作可能で拡張可能、かつ明確にする。	目標を軸に書き、実際の実行を支え導く人、現実に合わせてルールを調整する人に向けて書く。

カテゴリーごとに、取る態度によって選ばれる手法も活動もまるで違ってくる。重なることもあれば、決して重ならないこともある。コストとエラーを抑えようとする力が、実験の有効性や実験しようという意欲を損なうことがあるし、複雑系がどう動くかについての信念が、説明責任を果たすために普通使われる各種の指標と衝突することもある。

この表を漫画的だと言ったのは、現実の世界では境界がここまではっきりしていることも、ここまで露骨なこともめったにないからだ。たとえば、制御を中心に据えた階層構造でも、管理者の目標を揃えたうえでシステムの複雑さに対処するために権限を委譲することは十分できる。何を強調するかは、権力を持つ者が誰を信頼するかで変わりうる。集中型の制御は分析的分解の側で最も効果を発揮しやすいが、制御を中心に据えていない手法でもその恩恵を受けるものはある。

実際、多くの活動はどちらの手法でも使える。別々の相手に役立つこともあれば、同じ一人の相手に同時に役立つこともある。

活動	分析的分解 / 制御	複雑性 / 創発
Code Review	バグと欠陥を見つける。責任を追跡し割り当てる。品質を確保する。	認知を形成し、チーム内およびチーム間にフィードバックの場を用意する。
SLO 採用	すべてのチームが信頼性を十分に管理するための組織的な道具。	優先順位づけの道具。チームが許容できる信頼性の水準について議論し定義することを通じて価値が生まれる。
リファクタリング	技術的負債を返済し、複雑さを下げ、保守性と柔軟性を高め、使うパターンを統一する。	エントロピーの増大に対抗し、新たに得られた情報や要件の変化に応じて、コードベースを移り変わる文脈に適応させる。
カオスエンジニアリング	想定される障害シナリオが適切に許容または復旧されることを検証する。	実験主導の演習。参加者は障害シナリオ下でのシステムの振る舞いについて仮説を立て、それを確かめるか反証するかを試みる。
プラットフォームの利用	共有プラットフォームは良いアーキテクチャパターンを促し、悪いパターンを抑え、その上に構築するチームから複雑さを抽象化できる。	プラットフォームはシステムに手段を与え、共有要素をコモディティ化することで規模の経済と専門分化の利点を得る。セルフサービスでのアクセスによって組織のボトルネックも解消する。

この一覧の活動が分析的分解と複雑性に沿った手法の 両方 に役立ちうるとしても、必ずそうなるわけではない。

たとえば、制御を中心に据え、定められた規範からの逸脱をすべて排除しようとするコードレビューは、対立的になったり、不安を煽ったり、本当のフィードバックを妨げたりしかねない。それでも、自動化と適切な社会的規範を組み合わせることで、程度の差はあれ両方の目的を同時に支えられる実践もある。

私の経験では、これらの活動が実際にどう進み、ときに誰かの期待を裏切るのはなぜかを理解したいなら、背後にある立場が本当に重要になる。ある活動を他の活動に対してどう優先づけるかを決めるときにも、この立場は同じくらい効いてくる。参加者やステークホルダーがより高次の目的と期待する結果に同意していなければ、その活動がどう実行されることを期待されているか、実際にどう起きるか、システム全体の中でどれだけの重みを与えられているか、いずれにもずれが生じる。

こうした活動の一部を変えたい、足したい、あるいはやめたいという人がいたら、まず問う価値がある。その変更の本質は何で、どちらの視点に寄っているのか。

手法の間を行き来する

ひとつのヒューリスティックとして。複数の視点が使えるとき、何らかの恣意的な基準で最良のひとつを見つけようとすることもできるし、補完的あるいは交差するアプローチを取って、できるだけ多くを使うこともできる。ひとつの視点だけを選ぶと、制御であれ創発であれ、特定の状況でその種の活動を最大化する実装を探しがちになる。組み合わせるアプローチは、選んだ活動が複数の性質に同時に資するようにしようとする。トレードオフとして。

望んだものが手に入らないこともある。制御のために活動を設けた組織が、実のところ、実践者たちがそれを密かに複雑性に沿った貢献へと作り替えていることに依存していると気づくかもしれない。その一方で、組織の意思決定者は自分が思っているより制御できていなかったり、成果を自分の施策に誤って帰属させていたりする。そこで制御の仕組みを調整し、ついでにその隠れた適応行動を妨げてしまうと、本来持っていたものを失いかねない。

逆に、創発のために設けた活動を、制御のためのもののように機械的に実行すれば、期待した成果は得られない。見た目も手触りも、ただの空回りになる。組織は制御も得られず、適応的な効果も得られない。

信頼性や正確性といった広いテーマやカテゴリーには、たいてい、使える選択肢や原則が明示的に書かれていない。ただ、組織には制御—創発のスペクトル上におおよそ収まる汎用的な道具がたいていあり、それは多くの場合、プロセスの設計と実行の仕組みをめぐっている。

気に入らない振る舞いに直面したとき、たとえば他チームの人間が断りもなく自分のチームが担当する敏感なコードを変更したときは、いくつか手が打てる。彼らと話し、所有権を再確認し、期待されるプロセスを説明する。変更要求を出す前に RFC ドキュメントかチケットを求める。コードの所有権ファイルに頼って、同意のない意図しない変更が先に進むのを止める。重要なコードを他チームがアクセスできないリポジトリへ移す。

いずれも比較的局所的なやり方で、すぐ周りの構造を利用して振る舞いを変え、望まない動きを止める。ごく小さなコストで大きな効果が出ることもあるが、望ましい振る舞いを意図せず起こりにくくしてしまうこともある。

もっと創発寄りのやり方なら、まず、他チームがなぜ断りもなくこうした変更を送ってくるのかを突き止めるところから始めるだろう。どんな制約と圧力があって、今の振る舞いが彼らにとって合理的になっているのか。このプロセスが理想的な望ましい状態だと全員が同意しているのに、しばしば無視されるのなら、彼らにとって何がそれより重要なのか。それを理解してはじめて、介入を設計すべきだ。こうした問いは、Le Coze が以前に指摘したパターンの助けを借りることが多く、一本の糸を引くように組織全体をほどいていくことになる。既存の信頼がなければ時間もかかるし難しいが、期待を組み替えうるし、大きな変革につながることも、上流での小さな介入で済むことも同じくらいある。

複合的なアプローチとしては、複雑さを認識できる手法でまず状況を広く理解し、それに基づいて単純だがてこの効くチェックと障壁を設計する——最小限の制御で大きな見返りを得る、というやり方がある。これには複雑さの側に立って、システムの構造や目的だけでなく、個々のコンポーネントや参加者がどう相互作用するかを見る姿勢が要る。それらの相互作用が理解しやすくなれば、分析手法もより有効に働くはずだ。

危ういのは、こういうシステムに直面する可能性だ。複雑さを扱う手法を受けつけず手に負えないように見えるか、あるいは領域をまたぐ介入に対して硬直しすぎて、結局は純粋な局所防御に逆戻りしてしまう——しかもその防御はより遅れて現れ、同じ効果を得るには余計な手間がかかる。

だとすれば問題は、どちらのやり方が優れているかではない。今のやり方が限界に達しているとどう見極めるか、そしてそのとき何をするかだ。

省みられないシステム設計の罠

人は知識の有無にかかわらず、自分のシステムをいじり続けてきた。たいていはうまくいく。だが常にそうとは限らない。少なくとも計画どおりにはいかない。何を見るべきか知っていても、正しくやれるとは限らない。それでも勝算は上がる。

LLM が牽引する今の変化の波でも、同じことが言えるかもしれない。技術が新しく、設計パターンも固まっていないため、多くの人の試みはどこか場当たり的だ。そのアイデアには面白い要素や側面も少なくなく、参考に値する。だがシステムとして見ると明らかな抜けがあり、いずれ対処せざるを得ない。

技術評論の記事を読んでいて、大規模な変更を主張する例にぶつからないことはほぼ不可能だ——ここではリンクを貼らない。たとえば次のような主張がある。

• コードレビューを各種の障壁（テストや自動チェック）で置き換える。だが、そこからどんな役割が生まれうるのか、静的障壁とより適応的な障壁が性質上どう違いうるのかは、ほとんど問われない。
• ソフトウェアの仕事を高レベルの仕様記述に分解し、それをブラックボックスの中でコードに翻訳して、外部チェックだけを行う。だが、仕様記述が異なる抽象度をどう覆うのか、外部チェックをどう制御可能に保つのか、学ぶ価値のある情報がこれらの境界を双方向にどう行き来するのかは説明されない。
• 全員が何らかの「agent の管理者」になることを求め、同時に agent を tight な制御ループに置く。だが、委譲と制御の仕組みを全体として変えることで、この類推から何が失われるのか（少なくともどんな二次効果が生じるのか）は問われない。
• システムレベルで観測可能な結果だけに注目し、内部構造への強制を放棄して、システムが自ら十分に自己組織化すると信じる。

制御を中心にシステムを設計するなら——障壁を設け（スイスチーズモデルを思い浮かべよう）、大量のテストを行い、プロセスと手順でベストプラクティスを保証する——もう一方の種類の仕組みにも同じくらい注意を払う必要がある。制御が実際に効いているかを判断する仕組みだ。つまり、こう問うことになる。

• 自分の観察が今も有効で、正しい信号を捉えていると、どうやって分かるのか。
• システムへの理解がいつごろからずれ始めたと、どうやって分かるのか。
• 物事を読みやすくするために、分析がどの重要な要素を落としたり覆い隠したりしているのか。
• どの程度の変動が許容され、必要な変動を抑え込んでいないか。
• 最適化しているものが、別の場所で脆弱性を生んでいないか。
• 制御は本物か、それとも見せかけか。それが変わったとき、どうやって気づくのか。

調律の行き届いたシステムは、ある種の仕方で攪乱を補償する。そしてその仕方こそが、問題が蓄積している信号を覆い隠したり抑え込んだりする——技術的にも、文化的にも。上の問いの目的は、こうした振る舞いを覆い隠しているのは何なのか、誰かが真剣に考えたことがあるのかを突き止めることにある。

創発を狙って設計するなら——自己組織化、市場に似た仕組み、あるいはローカルな文脈を握る参加者への意思決定権の委譲を思い浮かべよう——別の問いが浮かぶ。

• システムの各部分が互いに足を引っ張り合っていないか。
• 目標の整合は効いているか。何によって一貫性を保つのか。
• 可読性を手放すことで、どんな能力や効率を犠牲にしたのか。
• 制御中心型システムの効率を失うことに耐えられるか。それはいつ必要になるのか。
• 適応とドリフトをどう見分けるのか。
• 異議を守っているのは何か、システムの辺縁から情報を外へ運び出しているのは何か。

複雑系の視点に立つ手法は規定性を伴う立場を取ることにしばしば抵抗するため、慣性の増大や広範囲の失準を招くリスクがつきまとう。創発的な性質が成否を決めるが、慎重な思考と能動的な働きかけがなければ、物事は勝手に進み、手に負えなくなる。

分析的分解や制御を核に据えたシステム設計を誰かが強く推すたびに、こう問おう。自分が正しいことをしていると何を根拠に分かるのか、適応するためにどんな仕組みに頼っているのか。自己調整と無限の柔軟性を約束するように見える設計を誰かが強く推すたびに、こう問おう。一貫性をどう保つのか、良い結果を得るためにどんな条件に依存しているのか。あるやり方から別のやり方への切り替えを誰かが強く推すたびに、こう問おう。現在の振る舞いにはどんな依存関係が関わっているのか、そこから生じる二次的な影響は何か。

テック企業は、新しい技術の誇張された約束をめぐって自らを作り変えようと、しばしば先を急ぐ。新しい技術を既存のワークフローに組み込むには、たいていそのワークフローを先に作り変える必要がある。そうした作り変えは変動を減らし制御を強めることを狙いがちだが、サブシステムの境界をまたぐ形で、動的に安定していた入り組んだ相互作用をかき乱す。

物事を予測可能にする自動化は、適応と進化に役立つ予測不可能性の一部を必ず取り除く。同じように、システムの一部をより適応的にしようとすれば、必然的にそれをより予測不可能にするかもしれない。どちらもシステムの残りの部分に連鎖的な影響を及ぼす。

システムはどこで、どのように、ある動作モードから別のモードへ移行するのか。どこに制御が要り、どこに要らないのか。何を分析して分解し、何を生態系として扱うのか。

これらの問いに答えがなければ、私たちのシステムがどう失敗を避け、どう成功するのかも、うまく答えられない。システムはシステムだ。これからもシステムとして動き続け、システムとして失敗する。