基本情報 平成29年度 秋期 問57：マネジメント系に関する問題

答えは d です。

インシデント管理＝サービスの異常事態（インシデント）を素早く対応・解決する活動。

利用者から「動かないんだけど！」と障害報告が来たら、まず「過去に同じ症状あったかな？」と既知の誤り（Known Error）と照合し、回避策があれば即適用、というのが典型ワークフローです。

👉 覚え方：インシデント管理＝障害報告→既知誤りと照合→対処。

ほかの選択肢：a 顧客満足度評価＝サービスレベル管理／b ディスク空き対策＝容量管理／c プログラム変更影響調査＝変更管理。

なぜこれが正解か

正解は d。ITサービスマネジメント（ITIL等）におけるインシデント管理および サービス要求管理は、利用者からのサービス停止・性能劣化等の連絡を受け、既知の誤り（Known Error Database）と照合し、迅速にサービスを通常運用へ復旧させる活動。根本原因の追求ではなく、早期復旧が目的。

各選択肢の解説

• a 顧客満足度を合意目標と比較してレビュー：サービスレベル管理（SLM）の活動。
• b ディスク空き容量がしきい値に近づき対策検討：容量管理（キャパシティ管理）の活動。
• c プログラム変更時の影響度調査：変更管理（Change Management）の活動。
• d 障害報告と既知誤りの照合：インシデント管理 → 正解。

覚え方・ひっかけ注意

ITIL の主要プロセスを混同しないこと：

• インシデント管理：早期復旧（応急処置）
• 問題管理：根本原因追求（再発防止）
• 変更管理：変更の計画・承認・実施
• 構成管理：CIの追跡

インシデントと問題は別プロセスである点が頻出ひっかけ。「回避策あり＝インシデント解決、根本原因対応＝問題管理」と整理。

ITIL 4 のフレームワーク

ITIL 4（2019）はサービスバリューシステム（SVS）を中心に再構成され、従来のプロセスは34のプラクティスとして再定義された。インシデント管理は 一般管理プラクティス／サービス管理プラクティス／技術管理プラクティス の中の主要要素。

インシデント管理のワークフロー

1. 検知・記録：監視ツールまたはユーザ通報。

2. 分類・優先度付け：影響度×緊急度で優先度マトリックス算出。

3. 初期診断・既知誤りDB照会：回避策があれば適用。

4. エスカレーション：解決困難なら専門チームへ。

5. 解決・復旧：応急処置でサービス回復。

6. クローズ：ユーザ確認、ナレッジ更新。

主要KPI

• MTTR（Mean Time To Repair/Restore）：平均復旧時間。
• MTTD（Mean Time To Detect）：平均検知時間。
• MTBF（Mean Time Between Failures）：平均故障間隔。
• 可用性 = MTBF / (MTBF + MTTR)。
• SLA達成率、初回解決率（FCR）、インシデント件数推移。

関連プロセスとの連携

• 問題管理：繰り返すインシデントの根本原因（RCA：Root Cause Analysis）追求。5Whys、特性要因図（フィッシュボーン）、FTA／FMEAが手法。
• 変更管理：修正パッチ適用、構成変更の承認管理。
• イベント管理：監視ツールからのアラート集約・相関分析。
• 構成管理（CMDB）：影響範囲特定の基盤。

DevOps/SRE時代の進化

• SRE（Site Reliability Engineering）：Google発、エラーバジェット、SLI/SLO/SLA分離、ポストモータム文化。
• オンコールローテーション：PagerDuty、Opsgenie等のページャツール。
• インシデントコマンドシステム（ICS）：大規模障害の指揮系統。
• ChatOps：Slack/Teams上での対応統合（Hubot、Lita）。
• ブレームレスポストモータム：個人攻撃せず仕組みを改善。

試験での位置づけ

FE「サービスマネジメント」分野で頻出。ITIL主要プロセス（インシデント・問題・変更・構成・リリース・サービスレベル・容量・可用性）の活動定義は確実な得点源。応用情報・ITサービスマネージャではSLA設計、災害対策（BCM/DR）、サービスデスク運営まで踏み込む。

選択肢の発展補足

bの容量管理は事業需要予測・現状利用率分析・将来予測の3軸で計画。クラウド時代はオートスケールで動的化、容量管理からコスト管理（FinOps）への重心シフトが進む。cの変更管理はCAB（Change Advisory Board）で承認、緊急変更（ECAB）は別ルートで迅速処理。