Failure Pattern を参照した介入戦略の設計

Context

Failure Pattern は、 問題の原因を特定するための分類ではない。

現場では、複数の Failure Pattern が同時に成立し、 それぞれが相互に影響し合っていることがほとんどである。 この状態で「どれが原因か」を特定しようとすると、 判断は容易に停止する。

Restoring Decision-Making において Failure Pattern を参照する目的は、 原因を断定することではなく、 現在どのような力学が働いているか を共有することにある。

Objective

本トピックの目的は、 Failure Pattern を用いて 介入戦略の選択肢を整理することである。

介入とは、 元の正しい状態に戻す行為ではない。 成立してしまった力学に対して、 どこに介入すれば状況が変わりうるか を判断する行為である。

Minimal Inputs

Failure Pattern を参照するために、 最低限固定すべき前提は以下である。

• 観測されている Failure Pattern
  単独ではなく、併存している可能性を含めて扱う

• 影響が顕在化している領域
  判断・測定・責務・境界・時間など、どこに歪みが出ているか

• 介入可能な範囲
  技術的・組織的・契約的に変更可能な領域

これらが整理されていない場合、 Pattern は単なるラベルに堕する。

Working Model

Failure Pattern を参照した介入は、 以下の作業モデルに基づく。

• どの Pattern が成立しているかを特定する
• それらが同時に成立している前提で考える
• 各 Pattern の Countermeasures を 「解決策」ではなく「力学をずらす方向」として読む
• どの方向にずらすかを選択する

ここで重要なのは、 すべての Pattern を解消しようとしないことである。

Tactics

Failure Pattern を参照する際の介入は、 個別施策ではなく、判断の焦点を変えるためのものである。

• 何を決めないと前に進めないのかを明確にする
• どの前提が暗黙のまま動いているかを可視化する
• どの Pattern をいまは受け入れるかを選択する

これらは実装作業ではなく、 戦略的な判断の選択である。

Risks

Failure Pattern を用いた介入には、 固有のリスクが存在する。

• Pattern 名がレッテル貼りとして使われる
• 単一 Pattern に還元して議論してしまう
• Pattern を「悪」として排除しようとする

これらは、 Pattern を原因論として扱った場合に発生する。

関連する Failure Patterns

本トピックは、 すべての Failure Pattern と関係する。

特に以下の Pattern とは、 参照関係が強い。

• Decision-less Agility
  判断を避ける構造に、どこで介入するかを考えるため

• Metric-less Improvement
  介入効果をどの単位で測るかを意識するため

• Responsibility Diffusion
  誰の判断として介入するかを明確にするため

AI Collaboration

AI を介入検討に利用する場合、 Failure Pattern は有効な入力となる。

ただし、AI に Pattern 名を渡すだけでは不十分である。

• どの Pattern が成立していると考えているか
• それを原因ではなく力学として扱っていること
• 今回はどの力学を動かしたいのか

これらを明示しない場合、 AI は Pattern を分類ラベルとして扱い、 実行可能な判断には寄与しない。