thinking-five-whys-plus

Five Whys Plus

既知の直接的な障害から、証拠に裏付けられた因果の連鎖をたどり、対処可能なシステム上の根本原因を特定したうえで、その障害を防げたはずの対策を提示します。

使用する場面

• 障害がコンポーネント、経路、またはサブシステムまで特定されている場合。
• 直接原因は分かっているものの、再発の原因やシステム上の根本原因が分かっていない場合。
• 症状だけに対処する修正が失敗し、障害が再発した場合。
• 直接原因がなぜ発生し得たのかに対処する予防策が必要な場合。

使用しない場面

• 障害が特定されていない、または原因候補が複数残っている場合 — まず切り分けます。
• 根本原因が証拠で裏付けられており、対処可能な場合 — 修正します。
• 次の「なぜ」に答える証拠がない場合 — 証拠を集めます。
• プロセス、ツール、または設計上の要因がない単発のエラーの場合。
• IS/IS-NOT 分析が必要な、選択的に発生する不具合の場合。
• コミット前に、将来起こり得る障害を予測する場合。

手順

1. 特定済みの問題を記述します。 観測された症状、確認済みのコンポーネント／経路、期間、範囲、影響を記録します。特定できていなければ中止します。
2. 証拠をもとに「なぜ」を連鎖させます。 前の回答を新たな結果とし、原因候補を挙げ、ログ、コード、設定、メトリクス、または証言を引用して、代替原因を示して排除します。推測になる場合は中止します。
3. 掘り下げる前に分岐させます。 同じ結果を引き起こす可能性のある別の要因を問い、証拠のある独立した経路をすべて残します。残った分岐を、単一の根本原因に無理にまとめず、因果関係の集合として扱います。
4. 各経路とその集合を反実仮想で検証します。 候補ごとに「この原因を取り除けば、この経路を遮断できるか」と問いかけます。次に「残った原因の集合を取り除けば、観測された障害を防げるか」と問いかけます。取り除くことでそれぞれの経路を遮断できる、独立して十分な分岐は残します。別の分岐でも障害が起こり得るというだけで、候補から除外してはいけません。
5. 分岐ごとに停止基準を適用します。 原因が証拠で裏付けられ、制御可能で、対処可能で、再発を防止し、個人を責めるものではなく（単に「誰かがミスをした」ではなく）、その経路に対する反実仮想の検証に合格した場合に限り、その分岐を終了します。人的エラーに行き着いた場合は、なぜそのエラーが起こり得たのかを問いかけます。
6. 残すすべての根本原因に対策を提示します。 システム上の修正、実行責任を担える担当者による対処、再発の確認方法を明記します。直接的な症状への応急処置だけでなく、発生を可能にした条件の除去を優先します。
7. 検証済み、またはそれ以上進められない時点で終了します。 停止基準を満たして対策が指定されたとき、またはこれ以上の検証に必要な証拠がないときに終了します。習慣的に分析を引き延ばしてはいけません。

出力

Problem: <localized symptom + component>
Chain:
  Why1: <cause> | Evidence: <...> | Ruled out: <...>
  WhyN: ...
Causal set check: would removing all retained roots block the failure? yes/no
Roots:
  - <systemic cause> | Pathway counterfactual: <...>
    Countermeasure: <action that removes the enabling condition>
    Verification: <how to confirm this pathway is blocked>

検証

• いずれかの段階に証拠がない場合、代替原因を検討していない場合、残した根本原因がその経路に対する反実仮想の検証に合格しない場合、または因果関係の集合全体で障害を説明できない場合は、因果の連鎖を反証します。
• 根本原因が修正され、検証された時点、または問題がまだ特定前の段階にある場合は、このスキルの適用を終了します。
• 過剰適用を防ぐための注意：既知の単一行の不具合に完全な因果の連鎖を適用しないでください。個人への非難で終わらせないでください。データなしに分析を深掘りしないでください。