incident-rca

Installation

npx claude-plugins install @windschord/claude-development-skills/incident-rca

Folders: sessions, templates

Files: README.md, SKILL.md

Documentation

インシデント調査で根本原因を特定するための、なぜなぜ分析ファシリテーションスキルです。

概要

インシデント根本原因分析（RCA: Root Cause Analysis）スキルは、システム障害やサービス停止などのインシデント発生時に、なぜなぜ分析を用いて体系的に根本原因を特定することを支援します。推測や意見を避け、ファシリテーターとしてユーザーの思考を整理し、リアルタイムでマインドツリーを作成して全体を可視化します。

主な機能

なぜなぜ分析による体系的な根本原因特定
ユーザーの発言を漏らさず記録
リアルタイムマインドツリー（Mermaid形式）の作成と可視化
ファシリテーターとしての中立的なサポート（推測や意見を言わない）
複合要因の分割と個別分析
最低1つの根本原因の特定保証
煮詰まった時の新しい視点の提供
絵文字を使用しないクリーンなコミュニケーション

使用方法

基本的な使い方

インシデントの根本原因を分析したい

または

なぜなぜ分析を始めたい

分析の開始

スキルを有効化すると、まず成果物の保存先を確認してから、以下のような対話で分析が開始されます：

ファシリテーター: インシデントの根本原因分析を開始します。
                  まず、分析結果の保存先を確認させてください。

                  デフォルトでは以下のパスに保存します：
                  [プロジェクトルート]/sessions/[YYYY-MM-DD]-[incident-name]/

                  このまま進めてよろしいですか？
                  別のパスを指定する場合は、パスをお知らせください。

ユーザー: デフォルトで問題ありません

ファシリテーター: 承知しました。
                  では、発生した事象について教えてください。
                  何が起きましたか？

ユーザー: Webサイトが停止しました

ファシリテーター: いつ発生しましたか？

ユーザー: 2024-01-15 14:30頃です

ファシリテーター: どこで発生しましたか？

ユーザー: 本番環境のWebサーバーです

分析フロー

成果物の保存先を確認（デフォルト: プロジェクトルート/sessions/）
インシデントの確認（現象、日時、場所）
マインドツリーの初期化
第1階層の「なぜ？」を問いかける
ユーザーの回答を記録し、マインドツリーに追加
複合要因がある場合は要因を分割
各要因について「なぜ？」を繰り返す
必要に応じて新しい視点を提供
根本原因を特定
すべての要因について分析完了後、サマリーを作成

マインドツリーの例

単一要因の場合

mindmap
  root((Webサイト停止))
    現象
      2024-01-15 14:30に停止
      全ユーザーがアクセス不可
    要因分析
      なぜ1: サーバーがダウン
        なぜ2: メモリ不足で強制終了
          なぜ3: メモリリークが発生
            なぜ4: ファイルハンドル未解放
              なぜ5: finallyブロック未使用
                根本原因: コーディング規約とレビュープロセスの不備

複合要因の場合

mindmap
  root((APIレスポンス遅延))
    現象
      平均レスポンス 5秒
      ピーク時 15秒
    要因A: DBクエリ遅延
      なぜA1: インデックス未使用
        なぜA2: テーブル設計時に考慮漏れ
          根本原因A: 設計レビュープロセスの不足
    要因B: ネットワーク遅延
      なぜB1: 帯域不足
        なぜB2: トラフィック急増
          なぜB3: キャッシュが無効化された
            根本原因B: キャッシュ戦略の未定義

ファシリテーターの役割

このスキルは、ファシリテーターとしてのロールに専念します：

実施すること

ユーザーに適切な質問を投げかける
ユーザーの回答を正確に記録する
思考の整理をサポートする
分析の進捗を可視化する
新しい視点を提供する（煮詰まった時のみ）

実施しないこと

原因について推測する
技術的な意見を述べる
ユーザーの回答を否定する
特定の結論へ誘導する
答えを与える

なぜなぜ分析の原則

基本ルール

通常は5回の「なぜ？」で根本原因に到達（回数は目安）
「それ以上なぜを問えない」状態が根本原因
「ヒューマンエラー」で止めず、なぜそれが起きたかを追求
システムや組織の構造的な問題に到達するまで深掘り

根本原因の判定基準

システムや組織の構造的な問題に到達している
対策を講じることで再発を防げる
さらに「なぜ？」と問うことができない
具体的なアクションに繋がる

複合要因の分割

複数の要因が存在する場合は、要因ごとに分割して分析します：

1つの「なぜ？」に対して複数の答えがある場合
独立した要因が並列に存在する場合
異なる系統の原因が絡み合っている場合

各要因について個別にマインドツリーを構築し、それぞれの根本原因を特定します。

煮詰まり時のサポート

ユーザーが煮詰まっている場合のみ、新しい視点を提供します：

煮詰まりの兆候

ユーザーが「わからない」と答える
同じ内容を繰り返す
長時間沈黙する
行き詰まりを明示的に示す

提供する視点

時間軸の視点:

発生の前後で何か変更はありましたか？
過去に同様の事象は発生していましたか？

空間軸の視点:

他のコンポーネント/システムではどうでしょうか？
上流/下流のプロセスに問題はありませんか？

人・組織の視点:

プロセスやルールに問題はありませんか？
情報共有やコミュニケーションに課題はありましたか？

技術の視点:

監視やログに何か記録されていませんか？
メトリクスに異常な値は見られませんか？

分析サマリー

分析完了時に、以下の内容を含むサマリーを自動作成します：

# インシデント根本原因分析サマリー

## インシデント概要
- 発生事象: [事象の説明]
- 発生日時: [日時]
- 発生場所: [システム/コンポーネント]

## 分析プロセス
- 分析手法: なぜなぜ分析
- 特定した要因数: [数]
- 「なぜ？」の深さ: [最大階層数]

## 特定された根本原因

### 根本原因1: [タイトル]
- 要因系統: [要因A/要因B等]
- 詳細: [根本原因の説明]
- 推奨対策: [ユーザーが述べた対策、またはなし]

## 分析ツリー

[最終的なマインドツリーを表示]

## 分析履歴

分析中に記録された主要な発言:
1. [記録1]
2. [記録2]
...

テンプレートとセッション管理

成果物

各分析セッションでは、以下の2つのドキュメントが自動作成されます：

1. result.md（分析結果）

分析完了時に作成される、包括的な分析結果ドキュメントです。

含まれる内容：

インシデント事象の詳細（発生事象、日時、場所、影響範囲、検知方法）
Mermaid形式の根本原因分析ツリー
特定された根本原因の詳細説明
再発防止策（即時対応、恒久対策、プロセス改善）
対策の効果測定指標
学びと気づき
関連ドキュメントへのリンク

テンプレート: templates/result_template.md

2. log.md（分析ログ）

分析セッション中の会話を完全に記録したログドキュメントです。

含まれる内容：

分析セッション情報（開始/終了日時、分析者名）
ファシリテーターとユーザーの会話を時系列で完全記録
なぜなぜ分析の各階層での質問と回答
複合要因の分析プロセス
新しい視点を提供した場合の内容
再発防止策の検討内容
分析サマリーと補足メモ

テンプレート: templates/log_template.md

セッションディレクトリ構造

各分析セッションは以下の構造で管理されます：

デフォルトの場合（プロジェクトルート）：

[プロジェクトルート]/
├── sessions/                  # 分析セッションの保存先
│   └── [YYYY-MM-DD]-[incident-name]/
│       ├── result.md          # 分析結果
│       └── log.md             # 会話ログ
└── (その他のプロジェクトファイル)

ユーザー指定の場合：

[指定されたパス]/
└── [YYYY-MM-DD]-[incident-name]/
    ├── result.md              # 分析結果
    └── log.md                 # 会話ログ

ディレクトリ命名例：

2024-01-15-web-service-outage
2024-02-20-api-response-delay
2024-03-10-database-connection-failure

ドキュメント作成フロー

分析開始前: 成果物の保存先を確認（デフォルト: プロジェクトルート/sessions/）
分析開始時: セッションディレクトリを作成し、log.mdの記録を開始
分析進行中: すべての会話をlog.mdにリアルタイムで記録
分析完了時: result.mdを作成し、最終的なマインドツリーと根本原因、再発防止策を記録

制約事項

実施しないこと

原因についての推測や意見の提示
ユーザーの回答の評価や否定
すべての会話・ドキュメントで絵文字の使用
分析の省略（最低1つの根本原因を必ず特定）

実施の限界

以下の場合は、その旨をユーザーに伝え、現時点での分析結果を記録します：

ユーザーが情報を持っていない
ログや監視データが存在しない
新しい視点を複数提供しても進展がない
ユーザーが分析継続を希望しない

ベストプラクティス

1. 中立性の維持

ユーザーの思考プロセスを尊重
答えを与えず、考えを引き出す
記録者として正確に記録

2. 構造化された記録

マインドツリーでビジュアル化
階層構造で整理
時系列で追跡可能

3. 根本原因の確実な特定

「ヒューマンエラー」で止めない
システムや組織の構造的問題まで深掘り
対策可能なレベルまで到達
必ず最低1つの根本原因を特定

4. 複

Source

View on GitHub

Installation

Contents

Documentation

概要

主な機能

使用方法

基本的な使い方

分析の開始

分析フロー

マインドツリーの例

単一要因の場合

複合要因の場合

ファシリテーターの役割

実施すること

実施しないこと

なぜなぜ分析の原則

基本ルール

根本原因の判定基準

複合要因の分割

煮詰まり時のサポート

煮詰まりの兆候

提供する視点

分析サマリー

テンプレートとセッション管理

成果物

1. result.md（分析結果）

2. log.md（分析ログ）

セッションディレクトリ構造

ドキュメント作成フロー

制約事項

実施しないこと

実施の限界

ベストプラクティス

1. 中立性の維持

2. 構造化された記録

3. 根本原因の確実な特定

4. 複

Source