thinking-archetypes

システム・アーキタイプ

概要

システム・アーキタイプ（Peter Senge、「The Fifth Discipline」）は、繰り返し現れる構造パターンです。ソフトウェアのデザインパターンと同様に、一度認識すれば、行き着く先と介入すべき場所を予測できます。なかなか解決せず、繰り返し発生する問題の多くは固有のものではありません。既知のパターンの一例であり、そのパターンがレバレッジポイントを示しています。

基本原則： 繰り返し発生する問題には、通常、構造パターンがあります。そのパターンに当てはめれば、取るべき介入策が見えてきます。

トリガーカード

何度も対処しているのに、同じ問題が繰り返し発生する場合：

1. 問題を中立的に説明する — 症状、これまでに試したこと、何が繰り返し起きているかをまとめます。
2. 以下のクイックリファレンスカードを使って、アーキタイプに当てはめる（失敗する対処、負担の転嫁、成長の限界、共有地の悲劇、エスカレーション、成功が成功を呼ぶ、成長と投資不足）。
3. 症状ではなく構造に介入する — そのアーキタイプの重要な問いを使います。

よく検討しても当てはまるアーキタイプがない場合は、無理に当てはめず、thinking-systems に進んで一からマッピングしてください。初めて起きた一度限りの問題なら、そのまま修正してください。

使用する場面

• 何度も「修正」しているのに、同じ問題が繰り返し発生する
• その場しのぎの修正によって、時間が経つにつれて状況が悪化した
• 明確な原因が見当たらないまま成長が停滞した
• 共有リソース（CI、ステージング、キャッシュ、サービスクォータ）の状態が悪化し続ける
• 2つの取り組みが互いにエスカレートしている（サービスの重複、アラートやしきい値をめぐる競争）

Problem keeps recurring despite fixes?  → match an archetype
Quick fix made it worse?                → match an archetype
Growth hit an invisible ceiling?        → match an archetype
Shared resource degrading?              → match an archetype

使用しない場面

• システムを一からマッピングする必要がある（構成要素、相互作用、創発的な振る舞い）— 代わりに thinking-systems を使います。アーキタイプは、繰り返し現れる構造をパターンに当てはめるための近道です。システムになじみがない場合は、まずマッピングしてから、アーキタイプに当てはまるかを確認してください。
• パターンが見つかり、どこに介入すべきかを知る必要がある — thinking-leverage-points（Meadowsの階層）を使います。アーキタイプは構造を示し、レバレッジポイントは最大の効果を得るために、その構造のどこに働きかけるべきかを示します。
• 原因が明確な初めての一度限りの問題 → そのまま修正してください。当てはめるべき繰り返しの構造はありません。
• よく検討しても当てはまるアーキタイプがない → 無理に当てはめないでください。thinking-systems に進み、実際の構造を一からマッピングします。
• 特定の不具合があるコードパスを特定する必要がある → パターンマッチングではなく、仮説の差分分析を使います。

クイックリファレンスカード

症状をパターンに当てはめます。主要な問いは、効果的な介入点を示します。

アーキタイプ	構造	見分けるポイント	主要な問い（効果的な介入点）
失敗する解決策	その場しのぎの対処で症状は和らぎますが、遅れて現れる副作用によって事態が悪化します	「前の四半期に直したのに、なぜまた起きたのか？」という声がある。対処には次第に大きな量が必要になります	「この対処はどのような副作用を引き起こすでしょうか？」
負担の転嫁	根本的な解決策の代わりに症状を抑える回避策が使われ、依存が生じます	恒久的な回避策がある。「本当の解決策はわかっているが、時間がない」という声がある。本来備えるべき能力が衰えています	「この回避策に頼ることで、どのような能力を身につけられずにいるでしょうか？」
成長の限界	成長を加速するループが、抑制要因にぶつかります	急成長の後に伸びが止まった。努力を増やしても効果が薄れている。リソースが上限に達している	「10倍の規模になったとき、何が制約になるでしょうか？」
共有地の悲劇	各関係者が共有リソースを使うことで利益を得る一方、全体として使いすぎることでリソースが枯渇します	共有の CI／ステージング／キャッシュ／クォータが劣化している。各自が局所最適を目指している。明確な所有者がいない	「このリソースの長期的な健全性には、誰が責任を持つでしょうか？」
エスカレーション	2者が相手の動きに反応し、競争の悪循環に陥ります	「相手が X をしたので、こちらも Y をしなければならない」という声がある。軍拡競争のような動きがある。双方が自分を守ろうとしています	「競争を激化させるのではなく、ゲームのルールを変えられるでしょうか？」
成功者のさらなる成功	最初の成功によってリソースが増え、優位性が積み重なる一方で、他の選択肢が育たなくなります	過去の成功が新たな投資の最大の判断材料になっている。現行の取り組みに資源を注ぐため、実験的な取り組みが後回しになっている	「現在の成功を支えるために、将来の成功の芽を摘んでいないでしょうか？」
成長と投資不足	需要が上限に近づく一方、パフォーマンスが劣化して危機に至るまで、処理能力への投資が遅れます	インシデント後に後追いで投資している。「当面はこれで十分」という状態が常態化している	「今、処理能力を追加せずに 50％成長したら、何が失敗するでしょうか？」

アーキタイプ別のソフトウェア例

• 失敗する解決策： メモリリークを隠すためにサーバーを追加する → コストが膨らみ、リークは残ります。アラートを無効にする → システムが劣化し、最終的に障害が発生します。
• 負担の転嫁： 自動化する代わりに、運用チームがいつまでも手作業で介入する。バグを直さないまま、フィーチャーフラグで隠す。
• 成長の限界： コードベースの拡大に伴い開発速度が低下する（複雑さの限界）。エンジニアを増やしても開発が速くならない（調整コスト）。
• 共有地の悲劇： チームが共有 CI に過剰な負荷をかけ、全員のビルドが遅くなる。誰もリソースを整理しないため、クラウドコストが急増する。
• エスカレーション： マイクロサービスのチームが互いに対抗して機能を重複実装する。アラートのしきい値を互いに引き上げ続ける。
• 成功者のさらなる成功： レガシーモノリスにすべての注意が向けられ、新しいアーキテクチャが成熟しない。
• 成長と投資不足： 負荷でデータベースがクラッシュするまでアップグレードされない。セキュリティへの投資は侵害の後にしか行われない。

診断プロセス

1. 問題を中立的に説明する — 症状、関係者や関係するもの、これまで試したこと、繰り返し発生していることを記述します。責任を追及しません。
2. ループを図にする — 何が何を引き起こすのかを整理します。強化（増幅）ループとバランス（抑制）ループがどこにあるか、遅れがどこにあるかを示します。
3. クイックリファレンスカードを使って、アーキタイプに当てはめる。2つが当てはまる場合、システムは複層的である可能性があります。両方を記録します。
4. 症状ではなく構造に働きかける — 主要な問いを使い、根本的な解決策、取り除くべき制約、追加すべき不足したフィードバックや遅れたフィードバックを見つけます。どれも当てはまらない場合は、そこで止めて thinking-systems を使用します。

検証チェックリスト

• 責任を追及せずに問題を説明している
• ループ（強化、バランス、遅れ）を図にしている
• 特定のアーキタイプに当てはめている（または、当てはまるものがないため thinking-systems にエスカレーションしている）
• 介入の対象が、繰り返す症状ではなく構造になっている
• 介入の副作用を検討している

センゲの知恵

「私たちが気づいていない構造は、私たちを閉じ込めます。それが見えるようになれば、もはや以前と同じように私たちを縛ることはありません。」

このパターンは、誰かがそれに気づき、パターンを生み出している構造を変えるまで続きます。変えるのは行動ではなく、行動を生み出すものです。