thinking-systems

システムのマッピングとレバレッジ

問題を個別の要素ではなく、構造と相互作用として捉えます。境界、ストック／フロー、ループ／遅延、繰り返し現れるパターンをマッピングし、副作用を確認したうえで、実行可能な範囲で最もレバレッジの高い箇所に介入します。

使用する場面

• 症状がサービス／コンポーネントをまたいで発生し、単一スタックへの修正では解決しないか、別の箇所に問題が移ります。
• ある場所への変更が別の場所を壊すなど、振る舞いが創発的です。
• 局所的な修正をしても問題が再発します（症状だけでなく、構造に問題があります）。
• パラメーターやバッファーの調整が定着せず、介入の優先順位を決める必要があります。

使用しない場面

• 明確なスタックトレース／差分がある単一コンポーネントの線形なバグです。トレースして修正します。
• スループットが明らかな単一の段階によって制限されています。制約理論を使います。
• 意思決定が、提案された1つのアクションから続く結果の連鎖です。二次的影響の分析を使います。
• アプローチ（計画、探索、安定化）の選択です。まず Cynefin を使います。

手順

1. システムの境界を定めます。 目的、関係者、境界、入出力のフローを明示します。意思決定の時間軸の外にあるノイズは除外し、症状につながる可能性のある経路はすべて含めます。
2. ストックとフローをマッピングします。 蓄積するストック（キューの深さ、負債、キャッシュサイズ、WIP）と、それらを増減させるレートを列挙します。フローが急変してもゆっくりしか変化しないものを記録します。
3. フィードバックと遅延を見つけます。 各ループ候補について、強化（増幅）かバランス（抑制）かを分類し、同方向（＋）か逆方向（−）かを記します。遅延（TTL、デプロイの遅れ、メトリクスの遅れ、立ち上げ時間）も明示します。逆方向のリンクが偶数なら強化ループ、奇数ならバランスループです。遅延が長く、修正が強い場合はオーバーシュートのリスクがあります。
4. 問題が再発する場合は、繰り返し現れる構造と照らし合わせます。 再発またはポリシーへの抵抗がある場合に限って確認し、パターンを無理に当てはめないでください。
   • 失敗する解決策 — 手早い修正の後、遅れてより悪い副作用が生じる
   • 負担の転嫁 — 回避策によって根本的な修正がおろそかになる
   • 成長の限界 — 成長がバランスを取る制約にぶつかる
   • 共有地の悲劇 — 局所最適化によって共有ストックが枯渇する
   • エスカレーション — 相互反応がスパイラル状に強まる
   • 成功の連鎖 — 配分によって優位性が複利的に拡大する
   • 成長と投資不足 — 需要に対してキャパシティの拡大が遅れ、危機に至る 十分に確認しても当てはまるものがなければ、ゼロから作成したマップを維持します。
5. 症状を構造までたどります。 フローとループを上流へたどり、直接的な症状と構造的な要因（相互作用、遅延、誤った目標、情報不足）を切り分けます。
6. レバレッジの高さで介入の優先順位を付け、その後に副作用を確認します。 実行可能な範囲で、より高いクラスを優先します。目標／パラダイム → ルール／情報 → ループ構造（ゲイン、バランスを取る仕組みの追加、遅延の短縮） → ストック／フローのトポロジー → バッファー／パラメーターの順です。候補ごとに、実現可能性、影響範囲、遅れて元に戻るリスクを評価します。有害な強化ループのゲインを下げる、または必要なバランスループを強化しつつ、新たな共有地の悲劇やエスカレーションを生まない施策を優先します。
7. 終了します。 実行可能な中で最もレバレッジの高い介入を決定し、ループ／遅延の応答を監視するシグナルを設定します。構造が変わるか、監視で介入の失敗が判明した場合にのみ、再度マッピングします。

次のいずれかに該当したら終了します。 境界、主要なストック／フロー、支配的なループと遅延、該当する場合はアーキタイプ、そして副作用を確認した介入の優先順位を明示できた場合、または問題が単一の線形な原因に帰着した場合。

出力

boundary: <system purpose and edges>
stocks_flows: <stock → inflow/outflow list>
loops:
  - name: <loop>
    type: reinforcing | balancing
    delay: <where cause lags effect>
    links: <brief +/->
archetype: <name or none>
structural_driver: <one sentence>
interventions_ranked:
  - level: <goals|rules|loops|structure|params>
    action: <what>
    side_effects: <feedback/elsewhere/delay risk>
chosen: <highest feasible>
watch: <signals that confirm or falsify>

検証

• 反証： あるコンポーネントを取り除くだけで、他への影響なしに問題を完全に説明して解決できるなら、システムのマッピングは誤りです。局所的なデバッグに切り替えます。利用率から、固定された単一の段階だけが上限になっていると分かる場合は、制約理論に切り替えます。
• 終了： 介入と監視を設定したら、ループを追加し続けないでください。
• 過剰適用を防ぐ： 再発の根拠なしにアーキタイプを当てはめないでください。実行可能なより高いクラスがある場合、レバレッジの低いパラメーター調整を第一候補にしないでください。独立したアーキタイプ／フィードバック／レバレッジの手順を別途作成しないでください。これらの確認は、このマップ内だけで行います。