# アンインシデント Navigation: [[index]] ## 定義 アンインシデント(Un-Incident)とは、正式なインシデント宣言・トラッキングに至らなかった潜在インシデントである。「インシデントではない」ことが判明したイベントではなく、「インシデントとして認識・登録される機会を逃した」イベントを指す。[[Andreas Deuschl]]（[[@2025__SREcon25EMEA__The Un-Incident]]）は、こうした出来事がエンジニアリング環境の 30〜60% を占めると推計し(自身の実務経験に基づく)、「新しいメソドロジーではなく、曖昧さへの焦点の転換」として位置づける。 Un-Incidents の状態は3種に分類される: - **未宣言(Undeclared)**: 誰も宣言しなかった。 - **見落とし(Neglected)**: 気づいていたが登録されなかった。 - **議論のまま終わる(Debated)**: インシデントかどうかを議論したが結論が出なかった。 ## 4 類型(Taxonomy of Un-Incidents) | 類型 | 定義 | 典型シナリオ | |---|---|---| | **No-CI** | 顧客影響はあるが既存分類に当てはまらず非クリティカルとして処理 | SLA 外の軽微劣化、未分類のサービス低下 | | **NOF (Not Our Fault)** | 外部要因・ユーザー設定ミスに起因し自組織の責任外と判断 | サードパーティ障害、誤った設定 | | **Near Miss** | 幸運または予防的行動によりエスカレーションを免れた出来事 | 「ヒヤリハット」、間一髪で回避した障害 | | **Fear Miss** | 不安・過剰反応による不必要なエスカレーション | ヘルプボタン症候群、社内 SEV1 乱発 | (Source: [[@2025__SREcon25EMEA__The Un-Incident]], p.6〜11) ## Gray Zone Playbook 4 類型への対処フレームワーク。**マインドセット → カルチャー → ストラクチャー → プロセス → 事実ベース意思決定** のサイクルで組織全体を改善する(p.13, p.25)。 ### 曖昧さの心理的安全(Mindset / Culture 層) No-CI / Near Miss / Fear Miss に共通して適用される 3 原則(p.15): 1. **宣言を阻まない** — インシデント宣言のハードルを低くする。 2. **宣言に感謝する** — 宣言した行動そのものを評価する文化。 3. **事実ベースのトリアージ** — 宣言後にデータで重大度を判断する。 ### ガット感覚への依存を減らす(Structure 層) 3 戦略(p.16): 1. **オブザーバビリティへの信頼構築** — 問題の影響が明確に見えることで、感覚ではなく事実でインシデント判断できる(Near Miss 向け)。 2. **グレーゾーンの可視化** — SLO による微細劣化パターンの早期検出(Near Miss / No-CI / Fear Miss 向け)。 3. **「ラッキーセーブ」の記録とタグ付け** — Near Miss を可視化・レビュー可能にし、組織学習に変換する。 ### Un-Incidents のレビュー方法(Process 層) - **No-CI / Near Miss**: Post-Incident-Analysis を「簡単にトリガーできる」仕組みを作る。Near Miss は Production Status Meeting の軽量レビューを入口にして Post-Incident-Analysis に接続する(p.20)。 - **Fear Miss / NOF**: 既存インシデントチャネルを経由して Post-Incident-Analysis に流し込む。 - **インシデントプロセスレビュー**: インシデントパターンを分析し、対応プロセスの効率を検証する。「代替手段がなかったから宣言せざるを得なかった」パターンを発見したら → インシデント分類の見直し + 非インシデントサポートチャネル(バグプロセス / アシスタンス依頼 / 明確なタイムライン / エスカレーション選択肢)を整備する(p.22)。 ### NOF インシデントのプロダクト設計への転用 NOF(Not Our Fault)インシデントをプロダクト改善情報源として活用する 7 原則(p.24): - Impact ≠ Fault - 顧客視点で考える - ガードレールの重要性 - 共同責任 - 誤用を想定した設計 - 明確さがエスカレーションを防ぐ - 破壊的変更のサーフェシング ## 横断的知見 - **「インシデントか否か」という問いの置き換え**: Deuschl は「To be or not to be an incident, that is NOT the question」と明言し、問いを「何を学べるか(What can we learn?)」に転換することを中心テーゼとする。これは [[ポストモーテム]] における「学習志向」と同根であり、[[インシデント管理]] のライフサイクル「宣言・対応・振り返り」の入口以前にある盲点を構造化する。(Source: [[@2025__SREcon25EMEA__The Un-Incident]]) - **Near Miss の組織学習**: 現時点ではこの wiki の 1 ソースのみ。[[インシデントシミュレーション]] における [[Hamed Silatani]] の「ヒヤリハット」観察(staged world 実験)との比較は未実施。複数ソースが揃い次第横断的知見に昇格させる。 ## 未解決の問い - 30〜60% という推計値は他の研究・組織でも観察されるか? "own experience" の数字に外部エビデンスはあるか? - Near Miss の「surfingcomplexity.blog」記事(2025-02-01)の詳細内容と、レジリエンスエンジニアリング文脈での Near Miss 理論との接続は? - Fear Miss(過剰反応エスカレーション)を下げるための組織的介入と、心理的安全の低下による過少申告のトレードオフをどうバランスするか? - NOF インシデントの「Impact ≠ Fault」原則は [[Multi-Party Dilemma]] と同じ問題空間にあるか? ## 関連 - [[インシデント管理]] — Un-Incident はインシデントライフサイクルの「入口の手前」にある。 - [[インシデントメトリクス]] — 「宣言に費やす議論コスト」への批判は MTTR 批判と同根。 - [[インシデントシミュレーション]] — Near Miss の記録を訓練と接続する可能性。 - [[Incident Commander]] — Gray Zone Playbook のマインドセット層は IC の心理的安全論と重なる。 - [[レジリエンスエンジニアリング]] — Near Miss は Safety II の文脈で「うまくいった事例」として組織学習の素材。 - [[Multi-Party Dilemma]] — NOF インシデントは組織間境界での責任分担と密接。 ## 出典 - [[@2025__SREcon25EMEA__The Un-Incident]] — 概念の初出。[[Andreas Deuschl]]（[[Dynatrace]]）、SREcon25 EMEA、2025-10-08。