インシデントから問題・変更・リリースへ｜仕組み

「メールが送れない」という申告が来たとき、運用の現場は4つの管理を順に通します。まずインシデント管理で業務を再開させ（＝復旧が先）、落ち着いてから問題管理で原因を突き止め、直すために変更管理で影響とリスクを評価して承認を取り、リリース管理で本番へ展開する。同じ「直す」でも目的と担当が違うのがこの流れの要です。

先に押さえる

利用者は「どの部署に言えばいいか」を知りません。そこで窓口を1つに束ねるのがサービスデスクで、この単一窓口をSPOC（Single Point Of Contact）と呼びます。サービスデスクは受け付けた申告を記録し、その場で直せるものは一次解決、手に負えないものは専門チームへエスカレーション（段階的取扱い）します。「窓口が1つ＝進捗も履歴も1か所に集まる」ことが、後の分析（問題管理）を可能にします。

受付から復旧までの分岐

1SPOCで受け、一次解決かエスカレーションか

利用者業務が止まっている

↓① 申告（電話・フォーム）＝窓口は1つ（SPOC）

サービスデスク記録・分類・優先度付け

↑②-a 既知の手順で直せる → その場で一次解決

↓②-b 直せない → 専門チームへエスカレーション

運用チーム回避策・復旧作業

↑③ 復旧を報告 → サービスデスクが利用者へ連絡・完了記録

エスカレーションには2種類あります。技術的に上位の担当へ渡す機能的エスカレーションと、判断・権限が要るため上位の役職者へ上げる階層的エスカレーションです。どちらも「窓口はサービスデスクのまま」で、利用者への連絡経路は変わりません。

動きで見る

番号順に追うと、受付 → 復旧 → 原因究明 → 変更の承認 → 本番展開と、担当が入れ替わりながら1件が片付いていく流れが見えます。（図は横スクロールできます）

4つの管理＋構成管理の役割分担

設問はほぼ「この作業はどの管理か」を聞いてきます。目的（何を最優先するか）で切り分けるのが確実です。

管理	最優先すること	典型的な仕事
インシデント管理	まず復旧（業務再開）	回避策の適用、再起動、代替手段での運用継続。原因究明より復旧を優先。
問題管理	根本原因の除去	再発したインシデントの傾向分析、原因特定、恒久対策の立案。再発防止が成果物。
変更管理	リスク評価と承認	変更要求の受理、影響範囲の評価、実施可否の判断。標準／通常／緊急の区分。
リリース管理	本番への展開	展開計画の作成、テスト済み資材の移送、実施、失敗時の切戻し。
構成管理（CMDB）	構成情報の台帳	機器・ソフト・関連の記録と維持。影響範囲がわかるので変更・問題の判断材料になる。

並べると分かるとおり、承認する人（変更管理）と展開する人（リリース管理）は分かれています。そして構成管理は単独では何も直しませんが、他の3つが「どこに影響するか」を判断する土台になります。

見抜きどころ

核は「インシデント管理と問題管理を混同しない」。復旧が先・原因は後です。設問文に「速やかに業務を再開させるため」「暫定的に別の手段で運用」とあればインシデント管理、「同じ障害が繰り返し発生しているので原因を分析」「恒久対策を立案」とあれば問題管理。SLAで合意した回復時間（サービス停止から復旧までの時間）はインシデント管理側の指標で、問題管理の成果は「再発件数の減少」で測ります。指標がどちらに紐づくかで役割を確定できます。

つまずきやすい

「原因が分かったのだからそのまま本番を直せばよい」は誤りです。変更管理を通さない本番投入が事故の元で、影響範囲の評価も切戻し手順もないまま別の障害を生みます。とはいえ全部を重い審議にかけると復旧が遅れるので、リスクの低い定型作業は標準変更としてあらかじめ承認しておき、止血が急ぐ場合は緊急変更の手順（事後承認を含む）で通します。「承認を省く」のではなく「承認の重さを使い分ける」が正解です。

やりがちな運用と、効く歯止め

事故につながる運用

窓口が複数：担当者ごとに直接依頼が飛び、記録が残らない。件数も傾向も見えず問題管理が始められない。
その場しのぎの直し切り：復旧だけで終わり、問題として起票しない。同じ障害が何度も再発する。
無承認の本番作業：影響範囲を評価せず設定変更。別システムを巻き込んで停止する。
切戻し計画なしの展開：失敗しても元に戻せず、停止時間がSLA違反まで延びる。
台帳の陳腐化：構成情報を更新しないため、次の変更で影響範囲を読み違える。

効く歯止め

SPOCの徹底：全申告をサービスデスク経由で記録し、優先度を付けて追跡する。
既知の誤り（既知エラー）の登録：原因未除去でも回避策を共有し、次回の一次解決率を上げる。
変更要求（RFC）と承認記録：誰が何を評価して許可したかを残す。区分（標準／通常／緊急）を明記。
展開計画と切戻し計画をセットで用意し、リリース判定の条件を事前に決めておく。
展開後のCMDB更新を作業手順に組み込み、台帳と現実の差をなくす。