メインコンテンツまでスキップ

Failure Patterns

本章は、本サイトの中核である。

ソフトウェアや組織において繰り返し観測される 「壊れ方」を、Failure Pattern として記述する。

ここで扱う Pattern は、 原因分析やチェックリストではない。 判断・測定・責務・境界といった前提が、 どのように崩れ、どのように固定化されるかを扱う構造である。

Pattern as Structure​

Failure Pattern は、 単一の誤りや判断ミスから生まれるものではない。

不確実性、責務の分散、測定不在、時間的制約といった 複数の Forces が同時に作用し続けることで、 ある振る舞いが「構造」として安定化する。

本章で扱う Pattern は、 このような Forces が解消されないまま均衡した結果として現れる、 失敗の構造を記述している。

各 Pattern は、次の断面から構成される。

  • Context
  • Forces
  • Failure Mode
  • Consequences(定着する影響)
  • Countermeasures(向きを変える最小介入)
  • Resulting Context(新しい当たり前)

これらは手順ではなく、 同一の状況を異なる観点から切り出した断面である。

Core & Derived Patterns​

本サイトでは Failure Pattern を、 役割の異なる二つの層として整理している。

Core Failure Patterns​

判断・測定・責務・境界といった、 壊れ方の根本構造を扱う Pattern 群である。

多くの状況で前提として存在し、 他の Failure Pattern が成立する土台となる。

Derived Failure Patterns​

Core Failure Pattern が成立している環境で、 実務上よく観測される派生的な壊れ方を扱う Pattern 群である。

技術・組織・運用といった具体的文脈に近く、 現場で診断語として直接利用されやすい。

Patterns の連鎖​

Derived Failure Pattern は、 特定の Core Failure Pattern が前提として存在する状況で、 観測されやすくなる傾向がある。

例えば、

これらは因果関係を示すものではない。 Forces の配置が似た状況で繰り返し観測される、 構造的な連鎖の例である。

想定する読者と利用場面​

本章で扱う Failure Pattern は、 特定の役割や職種を前提としていない。

運用中のソフトウェアに対して、 変更・改善・意思決定を行う必要がある状況で、 「何が起きているか」「なぜ判断できないか」を 構造的に整理したい人を主な利用者として想定している。

例えば、

  • 仕様や判断の前提が分からないまま、変更を求められている
  • 改善活動を行っているが、効果を説明できない
  • 合意はしているはずなのに、後から判断が覆る
  • テストや staging は通っているが、不安が残る
  • 分散・外部連携が増え、影響範囲を説明できない

といった状況において、 本章の Pattern は診断語として利用できる。

Pattern は判断を代替するものではない。 判断を引き受けるために、 前提・力学・構造を言語化するための補助線である。

利用のヒント​

  • 何が起きているか整理できない場合は Context を参照する
  • なぜ止まらないかを考える場合は Forces を参照する
  • 直し方ではなく、判断の前提を変えたい場合は Countermeasures を参照する

Pattern は万能解ではない。 複数の Forces が拮抗する状況で、 判断可能性を回復するための参照点として利用する。