# Incident Commander ## 定義 Incident Commander（IC）とは、インシデント対応において技術専門家が効果的に仕事できる「条件を整える」社会技術的リーダーシップ役割である。IC は技術問題を自ら解くのではなく、People（重複作業の回避・コミュニケーション・意思決定フロー）・System（状況認識の共有）・Business（組織にとって重要なことの把握）の3軸でチームをオーケストレートする（[[@2026__SREcon26 Americas__So You Want a New Incident Commander]] p.7）。 Google SRE Book（[[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]]）の ICS 役割体系では、IC はインシデント対応の最高責任者（Incident Commander）として Ops Lead・Communications Lead・Planning Lead の上位に位置し、善意に基づく独断行動（フリーランシング）を抑制する権限を持つ。IC は技術的役割ではなく調整・統制役割と明確に定義される。 ## ICS の起源と SRE への適用 ICS（Incident Command System）は 1968 年にアリゾナ州フェニックスの消防署長らが山火事対応の統制改善のために生み出した指揮体系である。2004 年に Homeland Security が NIMS（National Incident Management System）として義務化し、連邦援助受給の条件となった（[[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]] p.7–8、transcript）。 > [!contradiction] ICS 起源の地域・年代が2ソースで食い違う > [[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]]（Alice Goldfuss、2016）は起源を「1968年アリゾナ州フェニックスの森林火災対応」とするが、[[@2020__SREcon20Americas__Incident Response in Unfamiliar Sociotechnical Systems]]（Morgan Collins、2020）は「1960年代のカリフォルニア山火事急増と1970年シーズンの混乱を受け、FIRESCOPE（Firefighting Resources of California Organized for Potential Emergencies）タスクフォースが構築した」とする。史実としては ICS は FIRESCOPE を起点にカリフォルニアで開発されたことが広く記録されており、Collins のスライドの方が定説に近い。Goldfuss の「フェニックス・1968年」という記述は登壇者の記憶違いである可能性が高いが、本 wiki は口頭ソースの主張をそのまま記録する方針のため両論併記する。 私有企業（[[Salesforce]]）における ICS の適応は、公共 ICS の Command Staff（Public Information Officer・Safety Officer・Liaison Officer）を省略し、Operations/Planning/Logistics/Finance の4部門を Triage and Diagnosis・Incident Documentation・Incident Communications・Subject Matter Expert という具体目標特化型に置き換える形で行われる（[[@2020__SREcon20Americas__Incident Response in Unfamiliar Sociotechnical Systems]] p.5, p.9）。静的・事前配置の役割期待が強く、相互援助（mutual aid）は主要な関心事にならない点が公共 ICS との構造的差異である。 [[New Relic]] は 2012年クリスマス直前に3日間かかったインシデント（修復ではなく調整コスト——「誰が担当するか・誰に連絡するか・ピザを誰が注文するか」——が律速した）を機に [[Alice Goldfuss]] ら SRE チームが ICS を社内展開した。 ## 標準役割構成（Sev1〜Sev5 共通） | 役割 | 責務 | 主な禁止事項 | |------|------|------------| | **IC（Incident Commander）** | 全体指令・調整・内部コミュニケーション | 自ら技術問題を修復しない | | **TL（Tech Lead）** | 実際の修復。IC への進捗報告。重大変更は IC 承認後に実施 | — | | **CL（Communications Lead）** | 顧客・外部ステークホルダーへの影響情報発信。外部の反応を IC に伝える | — | ## Sev1 拡張役割 Sev1（最深刻）のみで解放される追加役割（[[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]] p.23、transcript）: - **EC（Emergency Commander）**: IC と会社の他部門（マーケ・法務等）の間のリエゾン。IC が技術対応に専念できるよう、会社レベルの意思決定を代行する。 - **LL（Logistics Lead）**: ピザ発注・シフト管理・帰宅指示などのロジスティクスを担う。長期化するインシデントで「クリーンな引き継ぎ」を保証する。 ## 重大度レベル（New Relic 実装、Goldfuss 2016） | レベル | 色 | 意味 | |-------|----|------| | Sev 1 | 赤 | Everything exploded | | Sev 2 | 橙 | One thing exploded | | Sev 3 | 黄 | A part of a thing exploded | | Sev 4 | 緑 | A thing is smoldering | | Sev 5 | 青 | Everything is ok…for now | ## IC 訓練と「全員訓練」方針 New Relic では工学部門の全員を IC 候補、サポート部門の全員を CL 候補として訓練する（[[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]] transcript）。理由は二つ: (1) 「信頼している」という文化的シグナルになる、(2) 実インシデントを観察しながらパターンを学べる。ただし実際には快適な人間だけが立候補し、強制されることはない。訓練計画: IC/CL の合同セッション + ロールプレイ + 定期リフレッシュ。 ## コアコンピテンシー（p.18–20） IC に向く人材のコアコンピテンシーは役職に依存しない: 1. **コミュニケーション**: 技術と非技術の両方の語り口で説明できる能力。 2. **社会技術的リーダーシップ**: 「技術」の外の問題を識別し、異なるグループに問題を提起できる能力。 3. **認知負荷管理**: 複数の作業ストリームを切り替えながら全体状況を維持する能力。 **社内でのシグナル**: Communication は技術と非技術を両方説明できる人。Socio-technical leadership は技術外の問題を異なるグループに提起できる人。Cognitive load は並行作業しながら状況把握を維持できる人。 **社外候補の評価方法**: Communication はインシデントレポートから複数ステークホルダー向け更新を書かせる。Socio-technical leadership はテーブルトップ演習・模擬インシデント。Cognitive load はリバースシャドーイング（インシデントタイムライン再構築）。 ## IC チームの3類型（Vanessa Huerta Granda, SREcon26） | 類型 | 特徴 | デメリット | |------|------|----------| | **Deliberate IC Team**（意図的専任） | 明示的責任・意図的育成・制度的経験の蓄積。Vanessa 推奨。 | オーバーロードリスク | | **IC per domain team** | 各チームが自チームのインシデントを担当。強いオーナーシップ。 | 一貫性が失われやすい | | **IC volunteer team** | 自発的参加。スキル普及・共有責任文化の強化。 | ストレスが高い | ## アンチパターン（p.9） - **最強エンジニアを IC にする**: IC は技術力バッジではなく、最強エンジニアを IC にすることは最強エンジニアを技術問題から引き離すことになる。 - **オンコール担当者をそのまま IC にする**: 役職に関係なく IC 適性を見極める必要がある。 - **最上位者（Most senior person）を IC にする**: 上位の役職が IC の適性を保証しない。 ## 横断的知見 - **「trained volunteer（任意訓練制）」(Goldfuss 2016) → 「deliberate IC team（専任チーム）」(Granda 2026) への進化**: Goldfuss は 2016 年時点で「全員を訓練し、快適な者が任意で立候補する」アプローチを採り、強制アサインを回避した。一方 [[Vanessa Huerta Granda]] は 2026 年に「Deliberate IC Team（意図的専任チーム）」を最良実践として推奨する。10年間の実運用がより構造化されたチーム設計の必要性を明示した変化と読める。両者は「IC は技術役割でない」という核心では完全に一致する。(Source: [[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]], [[@2026__SREcon26 Americas__So You Want a New Incident Commander]]) - **ICS 導入の具体的 ROI: 3日間 → 3時間**: Goldfuss は ICS 導入前後で同種の大規模インシデントの対応時間が3日から3時間に短縮されたことを実績として示す唯一のソース。他ソース（SRE Book・Granda）は IC プログラムの重要性を論じるが、明示的なビフォー/アフター比較は Goldfuss 2016 のみ。(Source: [[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]]) - **chatbot（Hubot/Nrrd 2016）→ AI エージェント(2026)という tooling の連続性**: Goldfuss の Nrrd は `nrrd 911 ic me` 一行で役割宣言・チェックリスト配布・ステータス自動要求（10分未更新で促進）を自動化した。Google の AI-assisted ICS（[[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]]）はこの「IC の情報処理負荷を tool が下げる」方向性の延長線上にある。ツールが変わっても IC が情報の経路長を短くし混乱を防ぐという構造的役割は変わっていない。(Source: [[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]], [[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]]) - **IC 導入には組織の前提条件が必要であり、成熟度モデルで段階的に位置づけられる**: [[Narimichi Takamura]]（[[@2024__SRE NEXT 2024__組織的なインシデント対応を目指して]]）はコマンダーロールを「さまざまな前提が整ってはじめて効果を発揮する、企業によっては単なるオーバーヘッドになりうる」ベストプラクティスとして位置づけた。これは [[インシデント対応成熟度モデル]] の Response フェーズ Empowerment（権限委譲）プロセスが Absent/Reactive 段階では機能しにくく、Proactive 以降で初めて効果を発揮するという示唆に対応する。SRE Book の ICS も IC 体系を前提とするが、その前提となる「組織全体が連動して動ける体制」自体が Proactive 段階の定義と合致する。(Source: [[@2024__SRE NEXT 2024__組織的なインシデント対応を目指して]], [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]]) - **SRE Book と Huerta Granda の定義は「IC は技術役割でない」で収束する**: [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]] は IC を「調整・統制役割」と定義し、フリーランシング抑制を主機能とする。[[Vanessa Huerta Granda]]（[[@2026__SREcon26 Americas__So You Want a New Incident Commander]]）も「IC は最強エンジニアのバッジではない」と明言し、IC の仕事を People/System/Business の条件整備とする。10年の実践知と教科書的定義が同じ方向を指す。(Source: [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]], [[@2026__SREcon26 Americas__So You Want a New Incident Commander]]) - **IC の補助としての AI エージェントは人間 IC の役割定義を前提とする**: Google SRE AI([[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]])は ICS の4役割（IC/Ops/Communications/Planning）に対し4種のエージェントを補助層として被せる設計を採るが、それは Huerta Granda が定義する「IC の Real Job（People/System/Business の条件整備）」の補助という形で読める。IC そのものを置き換えるのでなく IC の情報処理負荷を下げる方向性。(Source: [[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]], [[@2026__SREcon26 Americas__So You Want a New Incident Commander]]) - **IC の役割は SRE Book の ICS 4役割の「上位」と「実装論」で別々に書かれている**: SRE Book は IC を4役割体系の権限頂点として「何をするか」を定義し、Huerta Granda のスライドは「どう人材を見つけ・チームを作り・育てるか」を扱う。両者は相補的で、教科書が落とす「IC プログラム運用の実践論」をHuerta Granda のスライドが補完する。(Source: [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]], [[@2026__SREcon26 Americas__So You Want a New Incident Commander]]) - **「Warm Blanket Fallacy」は熟練 IC の限界を明示した唯一のソース**: [[Morgan Collins]]（[[@2020__SREcon20Americas__Incident Response in Unfamiliar Sociotechnical Systems]]）は「経験豊富な Incident Commander の存在が不慣れな環境（他組織との連携）での成功を保証しない」ことを「Warm Blanket Fallacy」と名付けた。他の本 concept 出典（Goldfuss・Huerta Granda・SRE Book）はいずれも自組織内での IC 育成・運用を論じるが、組織間（inter-organizational）対応という文脈で IC の経験が転移しない条件を明示したのは Collins のみである。対策として「支援合意の事前確立」「共通基盤の構築」「指揮の分散とコーディネーションへの注力（Coordination > Command）」を提示しており、これは Eason の「human mutex」やゴールドファスの「調整コストの律速」と同じ「IC の本質は技術力でなく調整力」という結論を、COVID-19 下の組織間対応という新しい文脈で再確認するものである。(Source: [[@2020__SREcon20Americas__Incident Response in Unfamiliar Sociotechnical Systems]]) - **Facebook の IMOC は「技術的に直さない」という IC の核心定義を、New Relic とは独立に同年(2016年)に確立していた**: [[Gareth Eason]]（[[Facebook]]）は SREcon16 Europe（2016年7月）で、Facebook の IMOC(Incident Manager On Call) の役割を「技術的にインシデントを直さないことが explicit な non-goal」と明言した。これは同じ 2016 年に [[Alice Goldfuss]]（New Relic、SREcon16 Americas）が確立した「IC は自ら技術問題を修復しない」という定義（[[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]])と実質的に同一であり、異なる大陸・異なる会社が同年に独立して同じ役割設計原則にたどり着いたことを示す。Eason はこの保護機能を「blame umbrella（エスカレーション後は技術対応者が責任範囲を離れたと感じられる）」と呼んでおり、この用語自体は本 wiki では [[@2016__SREcon16__Incident Response @ FB, Facebook's SEV Process]] が初出（Goldfuss 講演では同じ語は確認できていない）。(Source: [[@2016__SREcon16__Incident Response @ FB, Facebook's SEV Process]], [[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]]) - **「人間のミューテックス」という比喩による IC の調停機能の明確化**: Eason は IMOC の機能の一つを「複数人が同時に問題解決を試みる際、まず1つの案を試し他は待たせる」役割として「human mutex」という並行処理の比喩で説明した。SRE Book の「フリーランシング抑制」やニューレリックの IC 定義でも同種の機能（重複作業の回避）が語られるが、Eason のように計算機科学のロック機構に明示的に例えたソースは本 wiki では他にない。IC/IMOC の調停機能を技術者に直感的に伝える具体的な比喩として記録に値する。(Source: [[@2016__SREcon16__Incident Response @ FB, Facebook's SEV Process]]) - **Area Command は Major IC 単体では吸収できない「インシデント間のリソース競合」に対する ICS 由来のメタ統制機構**: [[Brent Chapman]]（[[@2021__SREcon21__Evolution of Incident Management at Slack]]）は、同時多発インシデントが増えるにつれ Slack IC ローテーション新設だけでは解決しない「複数インシデント間のリソース競合」問題に直面し、公共安全 ICS から Area Command（メタインシデントとして他インシデントを俯瞰し優先順位付け・仲裁する層）を輸入した。本 concept の他ソース（Goldfuss・SRE Book・Huerta Granda）が単一インシデント内の IC/TL/CL 分離を扱うのに対し、Chapman の Area Command は「IC 層をもう一段重ねる」という、インシデント間統制の具体的解決策を示す点で独自である。(Source: [[@2021__SREcon21__Evolution of Incident Management at Slack]]) - **iMAG(Google)→ Slack IM という、同一実践者による異なる組織への ICS 移植の追跡可能な系譜**: [[Brent Chapman]] は Google 在職時に ICS を基にした社内プロトコル「iMAG(Incident Management At Google)」を開発した本人であり、Slack 移籍後にほぼ同じ ICS 原則(全員訓練・重大度ガイドライン・Vision & Plan によるボトムアップ合意形成)を再現・発展させた。Goldfuss(New Relic)・Eason(Facebook)が同年(2016年)に独立して同種の設計に到達した「収斂」の実例だったのに対し、Chapman のケースは同一人物が複数組織へ ICS を移植した「持ち出し」の実例であり、ICS 適用パターンの生成メカニズムに関する対照的な事例を提供する。(Source: [[@2021__SREcon21__Evolution of Incident Management at Slack]]) - **IC 訓練率の定量目標とその超過達成という、育成戦略の実績データ**: Chapman は Commander クラス受講率の目標を「全エンジニアの15%」と設定し、実績で約25%(エンジニアリングマネージャー・ディレクターは約75%)を達成したと報告する。本 concept の他ソースは訓練方針(全員訓練・Deliberate Team 等)の設計思想を論じるが、具体的な目標値と達成率を定量報告するのは Chapman が唯一である。(Source: [[@2021__SREcon21__Evolution of Incident Management at Slack]]) - **Incident Review 主導権の「no give backs」ハンドオフという、IC-EM 間の責任境界を明文化した実装**: Chapman は「IC はインシデントレビューを主導しない、最も関与したチームの Engineering Manager が主導する」という原則(本 concept の他ソースにも共通する「IC は技術・調整役割に閉じる」という考え方と整合)を、「IC の最後の責務は担当 EM を指名すること。指名は後戻り不可」という具体的な運用ルールにまで落とし込んでいる。役割分離の理念を曖昧にしないための実装的工夫として記録に値する。(Source: [[@2021__SREcon21__Evolution of Incident Management at Slack]]) - **医療分野のアルゴリズム誘導プロトコルは「標準化による人的単一障害点の解消」という Goldfuss の狙いを別分野から裏付ける**: [[Sarah Butt]]（[[@2021__SREcon21__When Systems Flatline - Enhancing Incident Response with Learnings from the Medical Field]]）は、ACLS のような医療の決定木プロトコルが「誰が担当しても同じ手順が回る」標準化を実現し、特定個人・特定チームへの依存（人的ボトルネック）を減らすと説明する。これは Goldfuss（[[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]]）が Nrrd chatbot で目指した「役割宣言・チェックリスト配布の自動化により属人性を減らす」という設計と同じ方向性であり、医療とソフトウェアという異なる分野が独立に「標準化＝属人性排除」という結論へ収斂している。(Source: [[@2021__SREcon21__When Systems Flatline - Enhancing Incident Response with Learnings from the Medical Field]], [[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]]) - **チェックリストの起源は医療（WHO 手術チェックリスト）にあり、Nrrd の自動チェックリスト配布はその実装形態の一つと位置づけられる**: Butt は WHO の手術用チェックリストを個人・SRE チーム・非 SRE チーム参加者向けの3種チェックリストの直接のモデルとして提示し、「アドレナリン下では通常忘れない手順も忘れる」という認知負荷の問題を根拠とする。Goldfuss の Nrrd が自動化していた「役割宣言時のチェックリスト自動配布」は、この医療由来のチェックリスト文化を tooling で実装した具体例として読める。ただし本 concept の他ソース（Goldfuss・SRE Book・Huerta Granda）はチェックリストの起源を明示しておらず、医療との系譜を明言したのは Butt が初めてである。(Source: [[@2021__SREcon21__When Systems Flatline - Enhancing Incident Response with Learnings from the Medical Field]], [[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]]) - **「正しい問題を正しいタイミングで解く」という迅速安定化の原則は、Collins が指摘する Warm Blanket Fallacy の逆側の教訓を補う**: Butt の ATLS 由来の迅速安定化（原因の深掘りより先に影響を止める、「連鎖する why」を後回しにする）は、個々のインシデント内での意思決定規律を扱う。一方 Collins（[[@2020__SREcon20Americas__Incident Response in Unfamiliar Sociotechnical Systems]]）の Warm Blanket Fallacy は、熟練 IC の経験が組織間の不慣れな環境で転移しないという、より高次の限界を扱う。両者は矛盾せず、Butt の原則は「単一組織内で IC がどう判断すべきか」、Collins の指摘は「その判断力が別の文脈でどこまで通用するか」という異なる層の問いに答えており、IC の意思決定規律（What）と適用限界（Where）を補完する関係にある。(Source: [[@2021__SREcon21__When Systems Flatline - Enhancing Incident Response with Learnings from the Medical Field]], [[@2020__SREcon20Americas__Incident Response in Unfamiliar Sociotechnical Systems]]) - **IC とインシデントアナリストは「似て非なる別々のスキルセット」であり、これは Chapman の「no give backs ハンドオフ」・SRE Book の IC/TL/CL 分離と同じ「IC は事後分析を主導しない」という結論に、より早い時点（2023年）から到達していた**: [[Vanessa Huerta Granda]] と [[Emily Ruppe]]（[[@2023__SREcon23Americas__Incident Commanders]]、SREcon23 Americas）は、IC が対応(response)に密接に関与しすぎているため事後検証(post-incident review)を担当すると社会技術的要因を見落としやすいと明言する。これは [[Brent Chapman]]（[[@2021__SREcon21__Evolution of Incident Management at Slack]]）が Slack で制度化した「IC はインシデントレビューを主導しない、最も関与した EM が主導する」という運用ルールと結論が一致するが、Huerta Granda/Ruppe はこの制度設計の背後にある理由（対応と分析は別スキルであり、対応に人間として関与した当事者はレビューに偏りが生じる）を明示的に説明した点で相補的である。(Source: [[@2023__SREcon23Americas__Incident Commanders]], [[@2021__SREcon21__Evolution of Incident Management at Slack]]) - **「インシデントのサイクル(Circle of Incidents)」というライフサイクル図は、Goldfuss/Chapman が語る「学習を次の対応改善に還元する」プロセスを、平常運転→インシデント→事後学習→システム変化という循環として明示的に図式化した唯一のソース**: 本 concept の他ソース（Goldfuss・Chapman・SRE Book）は IC プログラムの構築・運用を論じるが、インシデント自体を「変化し続ける社会技術システムの中で繰り返される循環」として明示的に図示したのは [[@2023__SREcon23Americas__Incident Commanders]] が初出である。この循環モデルは [[インシデント管理]] の他のライフサイクル定義（Slack の Response/Review/Analysis 等）とも整合し、IC の役割（Response 局面の調整）とアナリストの役割（Review/Analysis 局面の調査）が同じサイクルの異なる局面を担当する、という役割分離の根拠を補強する。(Source: [[@2023__SREcon23Americas__Incident Commanders]]) - **Maguire（Jeli, SREcon23 Americas）は本 concept の全ソースが前提とする「IC を選定・育成する」という組織的関心の向け方そのものを問い直す**: 本 concept の他ソース(Goldfuss・Huerta Granda・Chapman・SRE Book)はいずれも「良い IC をどう見出し・育て・チーム化するか」という IC 中心の設計論を扱うのに対し、[[Laura Maguire]]（[[@2023__SREcon23Americas__An Organizational Response to Incidents]]）は「Incident Commander に集中する組織的関心(Attention)の非対称性」自体を問題として提起し、対応の大半を担う「フォロワー」側の働き——[[Followship]]——に焦点を移す。IC 個人の適性・育成論を積み上げてきた本 concept に対し、「そもそも IC だけに注目してよいのか」という上位の問いを追加する点で独自であり、両者は対立ではなく補完関係にある(IC の設計論 × フォロワー側の働きの可視化)。(Source: [[@2023__SREcon23Americas__An Organizational Response to Incidents]], [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]]) - **「Solo Artist（個人突破型）vs Band Member（チーム活用型）」という行動分類は、インシデントシミュレーション実験が明らかにした IC の有効性パターンの実証的区分**: [[Hamed Silatani]]（[[Uptime Labs]]、[[@2024__SREcon24EMEA__Incident Groundhog Day]]）が20名のインシデントマネージャーを対象に行ったステージドワールド実験では、参加者は2つの行動パターンに分かれた。**Solo Artist** は全負担を一人で抱え、ログやシステムを一人で渡り歩いて解決を試み、ストレスが高く非常に活動的だった。**Band Member** は早期にチームの他のメンバーを巻き込み、ワークロードと思考力を分散した。チームを巻き込んだ参加者は Slack で早期に「調査チームを作りましょう」と明示的に呼びかけた例が際立っていた。Silatani は将来の実験でストレスレベルと「コントロール感」を測定し、負荷分散とウェルビーイングの相関を確かめたいと述べている。本 concept の他ソース（Maguire の Followship・Chapman の Area Command・Wood の「3つの帽子」）が「IC 一人への集中を緩和すること」を異なる角度から支持しているのに対し、Silatani の知見は実験的行動観察という手法で同じ結論（チーム活用が有利）を裏付ける。(Source: [[@2024__SREcon24EMEA__Incident Groundhog Day]]) - **「3つの帽子」モデルは、ICS の正式な IC/TL/CL 役割体系を「役職(roles)」ではなく「対応に必須の core needs」として再定義する、最小導入版として位置づけられる**: [[Thai Wood]]（[[@2023__SREcon23Americas__If I Can Do It on an Ambulance - Scalable Incident Response Using ICS]]）は、最初にページを受けた人が Organizer/Commander/Manager・Connector/Liaison・Expert/Specialist の3つの帽子を同時にかぶっており、これらは「誰が何と呼ばれるか」ではなく「対応に絶対必要な機能」だと説明する。SRE Book の IC/TL/CL 体系（本 concept の中心的定義）と機能的に対応する（Organizer≈IC、Connector≈CL、Expert≈TL）が、Wood のモデルは severity・命令系統・正式な役職名を意図的に排除し、チーム単体・今日からでも導入できる規模に縮小している点で異なる。「小さく始めて育てる（seed）」という Wood の比喩は、本 concept の「IC 導入には組織の前提条件が必要」（Takamura, SRE NEXT 2024）という知見に対する、成熟度の低い組織でも着手可能な実践的な入り口を提供する。(Source: [[@2023__SREcon23Americas__If I Can Do It on an Ambulance - Scalable Incident Response Using ICS]], [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]], [[@2024__SRE NEXT 2024__組織的なインシデント対応を目指して]]) - **「ランブックは安全を買えない」という Wood の主張は、Goldfuss の Nrrd chatbot によるチェックリスト自動配布とは異なる次元の限界を指摘する**: Goldfuss（[[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]]）はチェックリスト配布の自動化で属人性を減らす方向性を示すが、Wood はチェックリストやランブックという文書形式そのものが「書かれた時点の想定未来」であり、実際のインシデントの状況とは乖離しやすいと指摘する。両者は矛盾しない。Goldfuss は「配布の自動化」という運用面の改善を扱い、Wood は「文書に頼りすぎることの限界」という認識論的な指摘を扱っており、後者は本 concept の対応能力構築において、文書化(documentation)と訓練(practice)は別物であるという補助線を追加する。(Source: [[@2023__SREcon23Americas__If I Can Do It on an Ambulance - Scalable Incident Response Using ICS]], [[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]]) ## 未解決の問い - Wood の「3つの帽子」モデル（チーム単体から始める最小導入）と、Granda の「Deliberate IC Team」（組織的専任チーム）は、どの成熟度で接続・移行すべきか？ - IC プログラムの ROI（コスト削減・MTTR 短縮等）を定量化した研究はあるか? Goldfuss の「3日→3時間」は事例証拠だが統計的研究はあるか? - 「全員訓練・任意立候補（Goldfuss 2016）」と「専任チーム（Granda 2026）」はどんな組織規模・成熟度で使い分けるべきか? - LL（Logistics Lead）とツール自動化（Nrrd の10分プロンプト等）は EC/LL という人的役割をどこまで代替できるか? - AI エージェントによる IC 補助（SRE Book ICS の情報集約・ハンドオフ文書生成等）と人間 IC の分担をどう設計するか? - Deliberate IC Team のオーバーロードリスクはどう計測・緩和するか? - IC のコアコンピテンシー（特に認知負荷管理）の評価手法として、リバースシャドーイング以外に有効な方法はあるか? - 組織間（inter-organizational）インシデント対応における「支援合意」は、実際の企業間でどのような契約・SLA として具体化されているか? Collins のスライドは概念提示に留まり実例を示していない。 - Butt の3種チェックリスト（個人／SRE チーム／非 SRE チーム参加者）は、実際にどのツール（Slack bot、Wiki、ランブック等）でどう実装され、更新・陳腐化をどう防いでいるか? 具体的な実装事例を持つソースを探す。 - 医療の ACLS/ATLS のような「アルゴリズム誘導決定木」を SRE のインシデント種別（ネットワーク障害、DB 障害、CDN アラート等）ごとに実際に構築した組織の事例はあるか? Butt は概念提示に留まり、SRE 側の具体的な決定木の実例を示していない。 ## 関連 - [[Sarah Butt]] — 医療分野（ACLS/ATLS/WHO チェックリスト）の実践を SRE インシデント対応に応用 - [[インシデント管理]] — IC が機能するインシデントライフサイクル全体 - [[ポストモーテム]] — インシデント後の学習プロセス - [[クロスインシデント分析]] — 複数インシデントを横断する学習プログラム（[[Enova]] の実践） - [[Vanessa Huerta Granda]] — IC プログラム構築10年以上の実践者 - [[Gareth Eason]] — Facebook の IMOC（IC 相当役割）を紹介 - [[Morgan Collins]] — Salesforce Principal SRE。組織間インシデント対応における IC の限界（Warm Blanket Fallacy）を提示 - [[Brent Chapman]] — Google iMAG の設計者。Slack で Major IC/Slack IC/Area Command を構築 - [[インシデントアナリスト]] — IC と対をなす、事後調査を担う役割 - [[Emily Ruppe]] — [[Vanessa Huerta Granda]] と共同で IC/アナリスト役割区分を発表 - [[Followship]] — IC 個人への組織的関心の集中を問い直す、フォロワー側の働きに焦点を当てる補完概念 - [[Laura Maguire]] — Followship の提唱者 - [[Thai Wood]] — 「3つの帽子」モデルで IC/TL/CL 体系を最小導入版に再定義 - [[Hamed Silatani]]、[[Uptime Labs]] — Solo Artist vs Band Member の実験的観察 - [[インシデントシミュレーション]] — staged world 実験の詳細と Allspaw の4活動分類 - `structures/` の関連 MOC: `[[notes/sre/AIOps - Fault Localization - MOC]]`（一方向参照） ## 出典 - [[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]] — SREcon16 Americas。ICS 草創期（New Relic 2012〜2016）の実践事例。全員訓練・Hubot ツール・ROI 証拠（3日→3時間）。 - [[@2026__SREcon26 Americas__So You Want a New Incident Commander]] — SREcon26 Americas。IC プログラム構築の実践論（チーム構造・コンピテンシー・育成）。 - [[@2021__SREcon21__When Systems Flatline - Enhancing Incident Response with Learnings from the Medical Field]] — SREcon21。医療分野（ACLS/ATLS/WHO 手術チェックリスト）のアルゴリズム誘導決定・迅速安定化・標準化チェックリストを SRE に応用する提案。 - [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]] — ICS 4役割体系と IC の権限・責務の教科書的定義。 - [[@2018__Google SRE Workbook__Incident Response]] — IC/OL/CL/PL の役割を実例（Google Home・GKE 等）で検証。 - [[@2016__SREcon16__Incident Response @ FB, Facebook's SEV Process]] — SREcon16 Europe。Facebook の IMOC が New Relic と同年独立に同じ設計原則へ収斂した実例。 - [[@2020__SREcon20Americas__Incident Response in Unfamiliar Sociotechnical Systems]] — SREcon20 Americas。ICS の起源（FIRESCOPE）・民間企業向け再編・組織間対応における Warm Blanket Fallacy。 - [[@2021__SREcon21__Evolution of Incident Management at Slack]] — SREcon21。Google iMAG の設計者が Slack で Major IC/Slack IC/Area Command を構築した経緯と運用課題の進化。 - [[@2023__SREcon23Americas__Incident Commanders]] — SREcon23 Americas。IC とインシデントアナリストの役割区分、「インシデントのサイクル」ライフサイクルモデル。 - [[@2023__SREcon23Americas__An Organizational Response to Incidents]] — SREcon23 Americas。IC 個人への組織的関心の集中を問い直し、フォロワーシップという補完的視点を提示。 - [[@2024__SREcon24EMEA__Incident Groundhog Day]] — SREcon24 EMEA。20名のステージドワールド実験で Solo Artist vs Band Member の行動差を実証。Allspaw の4活動分類を実験的に検証。 - [[@2023__SREcon23Americas__If I Can Do It on an Ambulance - Scalable Incident Response Using ICS]] — SREcon23 Americas。ICS 全体ではなく最小限の「種」から始める「3つの帽子」モデルと、ランブック批判・practice の重要性。