U「システムが落ちた！」——そのとき情報システム部門はどう動くのでしょうか。インシデント管理と問題管理はどう違うのか、変更管理とリリース管理は何が異なるのか、試験では混同しがちなプロセスの違いを問う問題が頻出です。ITILのサービスライフサイクル5フェーズと主要プロセスを整理すれば、経営情報システムの得点源になります。
ITIL（IT Infrastructure Library）は、ITサービスマネジメントのベストプラクティスをまとめた国際的なフレームワークです。英国政府機関OGCが策定し、現在はAxelosが管理しています。中小企業診断士試験では、ITILv3のサービスライフサイクル5フェーズ・主要プロセス（インシデント管理・問題管理・変更管理）・SLAの構成要素・サービスデスクの種類が出題されます。各プロセスの目的と対象を正確に区別することが合格への近道です。
ITILとは何か——誕生の背景とv3の位置づけ
| バージョン | 発行年 | 主要概念 | 試験との関係 |
|---|---|---|---|
| ITIL v2 | 2000年代初頭 | サービスサポート・サービスデリバリの2分冊 | 古いバージョン |
| ITIL v3 | 2007年（2011年改訂） | サービスライフサイクル5フェーズ | 試験で主に出題される |
| ITIL 4 | 2019年 | アジャイル・DevOps・クラウドへの対応 | 最新版だが試験での比重は低い |
サービスライフサイクル——5フェーズの全体像
サービス戦略（Service Strategy）
ビジネス目標に沿ったIT戦略を策定するフェーズ。「どんなサービスを、誰に、どのような価値で提供するか」を決定する。財務管理・需要管理・サービスポートフォリオ管理が主なプロセス。
サービス設計（Service Design）
戦略で決定したサービスを具体的に設計するフェーズ。SLA策定・可用性管理・キャパシティ管理・情報セキュリティ管理・サプライヤ管理が主なプロセス。
サービス移行（Service Transition）
設計されたサービスを本番環境に移行・導入するフェーズ。変更管理・リリース管理・構成管理・ナレッジ管理が主なプロセス。本番環境への影響を最小化しながら安全に移行する。
サービス運用（Service Operation）
稼働中のサービスを日々管理・維持するフェーズ。インシデント管理・問題管理・イベント管理・アクセス管理・要求実現が主なプロセス。サービスデスクがこのフェーズの窓口機能を担う。
継続的サービス改善（CSI）
全フェーズを横断して継続的に改善するフェーズ。PDCAサイクルでサービスの品質・効率を向上させる。7ステップ改善プロセスが中心で、メトリクスの収集・分析・改善実施を繰り返す。
インシデント管理・問題管理・変更管理——3つの違いを完全整理
| プロセス | 目的 | 対象 | 成果物 | 優先事項 |
|---|---|---|---|---|
| インシデント管理 | サービスの正常状態をできる限り早く復元する | サービス障害・機能低下の個別事象 | インシデント記録・回避策・復旧手順 | スピード（MTTR短縮） |
| 問題管理 | インシデントの根本原因を特定し、再発を防ぐ | 繰り返し発生するインシデントの根本原因 | 問題記録・根本原因分析（RCA）・既知エラーDB | 品質（再発防止） |
| 変更管理 | ITインフラ・サービスへの変更を承認・制御する | システム・設定・手順等のあらゆる変更 | 変更記録・RFCの承認/却下・変更スケジュール | リスク管理（影響最小化） |
| リリース管理 | 承認された変更を本番環境に安全に展開する | 変更管理で承認されたリリースパッケージ | リリース計画・展開記録・ロールバック手順 | 安全な展開 |
インシデント管理の流れ
検知・記録 → 分類・優先度付け → 調査・診断 → 回避策の実施（暫定復旧）→ 解決・復旧 → クローズ。目標はMTTR（平均復旧時間）の最小化。根本原因の解明は問題管理に委ねる。
問題管理の流れ
問題の検知（繰り返しインシデント等）→ 問題の記録・分類 → 調査・根本原因分析（RCA）→ 既知エラーとして登録 → 解決策の実施 → 問題のクローズ。既知エラーDB（KEDB）が重要な成果物。
変更管理の流れ
変更要求（RFC）の提出 → 影響・リスク評価 → 変更諮問委員会（CAB）での審議 → 承認または却下 → 変更の実施（リリース管理へ）→ 変更のレビュー・クローズ。
構成管理（CMDB）
ITインフラの構成要素（CI: Configuration Item）を記録・管理するデータベース（CMDB）を維持するプロセス。変更管理・インシデント管理・問題管理の基盤となる重要なプロセス。
インシデント管理 vs 問題管理：インシデント管理は「今すぐ直す」、問題管理は「なぜ起きたかを調べ二度と起こさない」
変更管理 vs リリース管理：変更管理は「変更してよいか審議・承認する」、リリース管理は「承認された変更を実際に本番に展開する」
問題 vs インシデント：問題（Problem）はインシデントの根本原因。1つの問題が複数のインシデントを引き起こすことがある。
SLA（サービスレベル合意書）——構成要素と主要指標
可用性（Availability）
システムが利用可能な時間の割合。稼働率（Uptime）で表す。例：「月次稼働率99.9%以上（許容ダウンタイム約44分/月）」
信頼性（Reliability）
障害なく継続稼働できる平均時間。MTBF（平均故障間隔）で表す。MTBFが長いほど信頼性が高い。
保守性（Maintainability）
障害発生後の復旧にかかる平均時間。MTTR（平均修復時間）で表す。MTTRが短いほど保守性が高い。
応答時間（Response Time）
インシデントや問い合わせへの初回応答時間。重要度（Priority）によって目標値が異なる。例：Priority1は30分以内。
スループット（Throughput）
単位時間あたりの処理件数や転送量。業務ピーク時に必要な処理能力を定義する。
セキュリティ要件
情報の機密性・完全性・可用性に関する要件。アクセス制御・暗号化・監査ログ等の基準を明記する。
| 指標 | 英語名 | 計算式・意味 | 良好な値 |
|---|---|---|---|
| 稼働率 | Availability | 稼働時間 ÷ 計画稼働時間 × 100(%) | 高いほど良い（99.9%以上が目安） |
| 平均故障間隔 | MTBF | 総稼働時間 ÷ 故障回数 | 長いほど良い |
| 平均修復時間 | MTTR | 総修復時間 ÷ 故障回数 | 短いほど良い |
| 稼働率の計算式 | — | MTBF ÷（MTBF + MTTR） | MTBFが大きくMTTRが小さいほど高い |
サービスデスク——機能と3種類の構成
ローカルサービスデスク
- 各拠点・事業所ごとにサービスデスクを設置
- ユーザーと同じ場所にあるため対応が迅速
- 各国語・時差対応が容易
- コストが高く、ノウハウが分散しやすい
- 大企業・グローバル企業に多い形態
中央集権型サービスデスク
- 全社で1か所（または少数拠点）に集約
- コスト効率が高く、ノウハウが集積しやすい
- スタッフのスキル向上・標準化がしやすい
- 時差・言語の問題が生じやすい
- 国内中心の企業に多い形態
仮想サービスデスク
- 複数の物理的拠点を技術（電話・ITシステム）で一体化
- 24時間365日対応が可能（時差を活用）
- 場所を問わないリモート対応
- 管理が複雑になりやすい
- グローバル企業・フォロー・ザ・サン対応に適す
| 機能 | 内容 |
|---|---|
| インシデント受付・記録 | ユーザーからの障害報告・問い合わせを受け付け、記録・分類・優先度付けを行う |
| 初期診断・解決 | 1次対応として可能な範囲で解決を試みる（スクリプト・FAQの活用） |
| エスカレーション | 解決できない場合、専門チーム（2次・3次サポート）に引き継ぐ |
| ユーザーコミュニケーション | 対応状況の通知・進捗報告・完了確認をユーザーに行う |
| 要求実現 | パスワードリセット・ソフトウェアインストール等の標準的な要求に対応する |
| サービスカタログ管理支援 | 提供サービスの一覧（サービスカタログ）に関する問い合わせへの対応 |
サービス運用の主要プロセス——5つを押さえる
インシデント管理
- サービス障害・機能低下を管理
- 目的：正常なサービスを最短で復旧
- MTTR（平均修復時間）が主要KPI
- 回避策（Workaround）を活用して暫定復旧
問題管理
- インシデントの根本原因を特定・管理
- 目的：再発防止・インシデント数の削減
- 既知エラーDB（KEDB）を整備・活用
- 反応型（インシデント後）と予防型の2種
イベント管理
- システムやサービスの状態変化（イベント）を監視
- 異常の早期検知・自動対応を実現
- 監視ツールによるしきい値超過アラート等
- インシデント管理の前段として機能
アクセス管理
- システム・データへのアクセス権限を管理
- 権限付与・変更・削除を適切に処理
- 情報セキュリティ管理の運用面を担う
- IDの有効化・停止・削除が主な業務
要求実現
- ユーザーからの標準的な要求を処理
- インシデントではない軽微な依頼が対象
- 例：パスワードリセット・ソフトウェア追加
- サービスカタログに基づく定型処理
試験対策——頻出論点と混同を防ぐ比較整理
| 論点 | 正しい理解 | よくある誤り |
|---|---|---|
| インシデントと問題の違い | インシデント＝サービス停止の事象、問題＝その根本原因 | 「問題を解決＝インシデント管理」と混同する |
| 変更管理とリリース管理 | 変更管理＝承認審議、リリース管理＝本番展開 | 「変更管理が展開まで実施する」と誤解する |
| サービスデスクのフェーズ | サービス運用フェーズの機能 | 「設計フェーズで定義されるから設計に属する」と誤る |
| SLAとOLAの違い | SLA＝顧客との合意、OLA（運用レベル合意）＝IT部門内の合意 | SLAが内部の合意だと誤る |
| MTBFとMTTRの大小 | 稼働率＝MTBF÷（MTBF+MTTR）。MTBFは長く、MTTRは短いほど良い | MTTRが長いほど良いと誤る |
| CSIの位置づけ | 全フェーズを横断する常時実施のプロセス | 「最後の5番目のフェーズ」として独立していると考える |
5フェーズと主要プロセスの対応まとめ
- サービス戦略：財務管理・需要管理・サービスポートフォリオ管理
- サービス設計：SLA管理・可用性管理・キャパシティ管理・情報セキュリティ管理・サプライヤ管理
- サービス移行：変更管理・リリース管理・構成管理（CMDB）・ナレッジ管理
- サービス運用：インシデント管理・問題管理・イベント管理・アクセス管理・要求実現（サービスデスクはここの機能）
- 継続的サービス改善（CSI）：7ステップ改善プロセス・メトリクス収集・改善報告
よくある質問（FAQ）
ITILは規格（ISO）ですか？
変更管理のCABとは何ですか？
インシデントの優先度はどう決まりますか？
サービスカタログとは何ですか？
ITIL v3とITIL 4の主な違いは何ですか？
ITILのサービスマネジメントは、「システムを作る」ことよりも「サービスとして継続的に価値を提供する」という考え方に基づいています。5フェーズの流れを頭に入れ、各プロセスの目的と対象を区別できれば、経営情報システムの得点が安定します。特にインシデント管理・問題管理・変更管理の3つの違いは、毎年のように出題されるテーマですので、比較表で繰り返し確認しておきましょう。
