応用情報 令和6年度 春期 問3サービスマネジメントに関する問題

正解は「通常のサービスを可能な限り迅速に回復させること」です。

インシデント管理は「壊れたら、まず動くようにする」役割です。

たとえば社内システムが落ちたとき、最優先は「いつ直る？」ではなく「今すぐ仕事ができる状態に戻す」こと。原因究明や恒久対策は後回しで、まず暫定でも復旧します。

• インシデント管理：とにかく動かす（救急医療）
• 問題管理：原因を突き止め再発を防ぐ（外科治療）
• 構成管理：機器の情報を管理（カルテ）
• 変更管理：システム変更時のリスク管理（手術前チェック）

覚え方：「インシデント＝緊急復旧」。

正解は b「通常のサービスを可能な限り迅速に回復させること」です。

ITIL（Information Technology Infrastructure Library）は英国政府発祥のITサービスマネジメントベストプラクティスで、現在はITIL 4（2019年〜）が最新版です。インシデント管理（Incident Management）は ITIL の中核プロセスの1つで、以下の特徴があります：

定義：

ITIL 4 では「インシデント」を「サービスへの計画外の中断または品質低下」と定義し、インシデント管理の目的を「通常のサービス運用を可能な限り早期に回復させること」としています。原因究明ではなく、ユーザへの影響最小化が最優先です。

関連プロセスとの違い：

| プロセス | 主目的 | 例 |

|---|---|---|

| インシデント管理 | 早期復旧 | 「メールサーバ復旧」 |

| 問題管理（Problem Management） | 根本原因特定・再発防止 | 「障害原因を分析しパッチ適用」 |

| 構成管理（Configuration Management） | 構成情報の正確性維持 | 「CMDB更新」 |

| 変更管理（Change Management） | 変更リスクの統制 | 「変更諮問委員会CABで承認」 |

| リリース管理 | 本番投入のコントロール | 「リリーススケジューリング」 |

インシデント管理の典型フロー：

1. インシデント検知：ユーザ通報・監視ツール検知

2. 記録・分類：チケット起票、優先度（影響度×緊急度）判定

3. 初期診断・エスカレーション：1次対応、必要に応じ2次・3次へ

4. 暫定対処（Workaround）：恒久対策ではなく一時的回避策の適用

5. 解決・回復確認：サービス復旧をユーザに確認

6. クローズ：チケットクローズ、Known Error DB（KEDB）登録

KPI例：

• 平均インシデント解決時間（MTTR: Mean Time To Restore/Resolve）
• インシデント発生率
• SLA達成率（時間内対応率）
• 1次対応解決率（エスカレーション削減）

実装ツール：

ServiceNow, Jira Service Management, BMC Helix, Zendesk 等が ITIL準拠の機能を提供します。チケットシステムでインシデント・問題・変更を一元管理します。

他選択肢の解説：

• a「根本原因特定」→ 問題管理の責務
• c「インフラ構成情報の最新化」→ 構成管理の責務
• d「変更によるリスクの評価」→ 変更管理の責務

AP午前ではサービスマネジメント分野で頻出（シラバス「ITサービスマネジメント・ITIL」）。

正解は b「通常のサービスを可能な限り迅速に回復させること」です。

ITILは1989年に英国CCTAが策定して以降、世界中のIT運用部門でデファクトスタンダードとなっています。ITIL 4（2019年〜）は従来のプロセス指向からサービスバリューシステム（SVS）指向へ進化し、アジャイル・DevOps・SREとの統合を志向しています。上級者として理解すべきは「インシデント管理と問題管理の境界」「ITIL 4 のSREとの融合」「実装上のアンチパターン」の3点です。

1. インシデント管理と問題管理の境界

ITILの本質的な設計思想は「短期復旧（インシデント管理）と再発防止（問題管理）を分離する」点にあります：

| 観点 | インシデント管理 | 問題管理 |

|---|---|---|

| 主目的 | サービス復旧 | 根本原因の除去 |

| 時間軸 | 即時（数分〜数時間） | 中長期（数日〜数週間） |

| アウトプット | サービス復旧 | RCA(Root Cause Analysis), KEDB更新 |

| 対応者 | サービスデスク、技術スタッフ | 問題解決チーム |

| 成功指標 | MTTR短縮 | 同一原因の再発防止率 |

両者を混同すると以下のアンチパターンが発生：

• 「原因が分かるまで復旧しない」：ユーザ影響が拡大
• 「とりあえず復旧して原因究明しない」：同じ障害が繰り返す
• 「RCA をインシデント対応中に行う」：障害対応リソースが分散

2. ITIL 4 と SRE（Site Reliability Engineering）の融合

Google が提唱した SRE は「信頼性をエンジニアリング課題として扱う」思想で、ITILと多くの共通点を持ちつつ、定量化と自動化を強化しています：

| 観点 | ITIL 4 | SRE |

|---|---|---|

| 信頼性目標 | SLA（顧客契約） | SLO（内部目標）/ SLI（測定指標）/ Error Budget |

| 運用 vs 開発 | 役割分離 | 統合（最大50%の開発業務） |

| 自動化 | 推奨 | 必須（Toil削減目標 < 50%） |

| インシデント対応 | プロセス重視 | Postmortem文化 + Blameless |

ITIL 4 は 「Service Value System」「Guiding Principles」「Practices」 で SREやDevOpsを包含するメタフレームワークへと進化しました。「Continual Improvement」「Focus on Value」等の Guiding Principles は SRE/DevOps と整合します。

3. インシデント管理の現代的KPI

伝統的なITILは MTTR を主要KPIとしてきましたが、SRE/DevOps文脈では以下のDORA 4 Keysが標準化されつつあります：

• デプロイ頻度（Deployment Frequency）
• 変更リードタイム（Lead Time for Changes）
• 変更失敗率（Change Failure Rate）
• サービス復旧時間（Mean Time to Restore: MTTR）

DORAの研究（Accelerate State of DevOps Report）では、高パフォーマンスチームは MTTR を1時間未満に抑えていることが示されており、これは伝統的ITILの数日単位の対応から大幅に短縮された水準です。

4. インシデント対応の自動化 — Runbook Automation と AIOps

• Runbook Automation：頻出インシデントへの対応手順をスクリプト化し、自動実行。ServiceNow Orchestration, Rundeck, AWS Systems Manager等。
• AIOps：機械学習による異常検知、相関分析、自動分類。Splunk ITSI, Dynatrace Davis, Moogsoft等。
• ChatOps：Slack/Teamsとの統合で全員にリアルタイム共有。インシデントコマンダー方式。

これらにより MTTR を桁違いに短縮し、人的対応をエスカレーション必要なケースに集中させます。

5. ポストモーテム文化と Blameless Postmortem

Google が提唱した「Blameless Postmortem」は「個人の責任ではなく、プロセス・システムの欠陥を分析する」文化です。これがITIL の問題管理と組み合わさることで、組織学習を促進します。具体的には：

• インシデント発生後24-48時間以内に関係者を集めて事実関係を整理
• 「Why」を5回繰り返す5 Whys 分析
• アクションアイテムを Owner と期日を付けて追跡
• 全社で公開し他チームの学びとする

6. 重大インシデントとIncident Commander 方式

大規模障害時にはICS（Incident Command System）由来の指揮系統を導入します：

• Incident Commander：意思決定権者
• Communications Lead：ステークホルダー連絡
• Operations Lead：技術的復旧
• Planning Lead：状況整理・記録

PagerDuty, FireHydrant 等の Incident Management ツールがこのフレームワークをサポートします。

7. ITIL実装のアンチパターン

• プロセス過剰：チケット入力に時間がかかり技術対応が遅れる
• KPI操作：MTTR短縮のため「軽微なクローズ」を量産
• 問題管理の形骸化：RCAが議事録止まりでアクション実行されない
• CMDB劣化：構成情報が古くなり信頼できない
• 変更管理の遅延：CABが意思決定ボトルネック化（高速デプロイの阻害）

ITIL 4 の Guiding Principle「Start Where You Are」「Iterate with Feedback」「Optimize and Automate」は、こうしたアンチパターンを回避する指針です。

8. AP午後問題での出題傾向

AP午後のITサービスマネジメント問題では「インシデント・問題・変更・構成の連携」が頻出テーマです。チケットの状態遷移、SLAの計算、エスカレーション設計、KEDB活用方法を論述できると得点源になります。

実務的示唆：

• 中小組織は ITIL 4 のうち「Incident Management」「Change Enablement」「Service Desk」の3 Practice から始める
• 大組織でも CMDBの正確性 80%維持 が現実的（100%は人的コストが見合わない）
• AIOpsの導入でアラート疲労（Alert Fatigue）を解消し、人的対応を高付加価値業務にシフト

「インシデント管理＝早期復旧」が基礎、SRE・DORA・Postmortem文化との統合まで語れて初めて上級レベルです。