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

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 が拮抗する状況で、 判断可能性を回復するための参照点として利用する。