ITサービスマネジメントまとめ｜ITIL・SLA・インシデント管理を図解で整理

過去問でSLAという言葉が出たとき、定義はなんとなくわかるのに、ITILとの関係がぼんやりしていました。「SLAはサービスデザインの産物で、ITILはその器」——そう整理できた瞬間に、周辺プロセスがひとつながりに見えてきたのです。

この記事では、ITサービスマネジメント（ITSM）の考え方から出発して、そのベストプラクティス集であるITIL v3の5つのプロセス群、サービス品質の約束事であるSLA、そして試験頻出のインシデント管理と問題管理の違いを順番に整理します。比較テーブルと図解を中心に構成していますので、一度読むだけで全体の地図が頭に入るはずです。

ITサービスマネジメントとは

ITサービスマネジメント（ITSM）とは、ITをただ「システム」として見るのではなく、ビジネスに価値をもたらす「サービス」として管理するという考え方です。

従来のIT管理は「ハードウェアが動いているか」「ソフトウェアが正常か」という技術的視点が中心でした。一方ITSMは、「そのITが利用者にとって役立っているか」「障害が起きたとき迅速に回復できているか」というサービス視点で考えます。

プロセス群

ITILv3 サービスライフサイクル

プロセス

ITILv3 に定義された総プロセス数

次元

ITIL 4 のサービス管理4次元モデル

ITSMとPDCAサイクルの関係

ITSMはPDCAサイクルを基盤として動きます。サービス戦略（Plan）→ サービス設計・移行（Do）→ サービス運用（Check）→ 継続的改善（Act）という循環が、ITILのライフサイクルに重なっています。

Plan 戦略・設計

Do 移行・導入

Check 運用・監視

Act 継続的改善

ITILとは

ITILの定義

ITIL（IT Infrastructure Library）は、ITサービスマネジメントのベストプラクティスをまとめた書籍群です。1980年代に英国政府（CCTA）が策定し、現在はAxelosが管理しています。特定のツール・製品に依存しない汎用的なガイドラインであり、世界中の企業・官公庁で採用されています。

バージョンの変遷

高頻度難易度 ★★☆

バージョン	時期	特徴
ITIL v2	2000年代前半	サービスサポートとサービスデリバリの2冊に整理。試験では「v3以前の体系」として参照されることもある
ITIL v3	2007年〜2019年	サービスライフサイクルの概念を導入。5つのプロセス群（SS/SD/ST/SO/CSI）で構成。中小企業診断士の試験はこの体系を中心に出題
ITIL 4	2019年〜現在	アジャイル・DevOps・クラウドへの対応を強化。「サービスバリューシステム（SVS）」と4次元モデルを導入

ITILv3 サービスライフサイクル — 5つのプロセス群

サービス
ストラテジー

サービスポートフォリオ管理
財務管理
需要管理

サービス
デザイン

可用性管理
キャパシティ管理
サービスレベル管理

サービス
トランジション

変更管理
リリース管理
構成管理(CMDB)

サービス
オペレーション

インシデント管理
問題管理
サービスデスク

CSI

継続的
サービス改善

サービス測定
7ステップ改善
サービス報告

プロセス群	主な目的	代表的なプロセス
SS（戦略）	提供するITサービスの方針と目標を決定する	サービスポートフォリオ管理、財務管理、需要管理
SD（設計）	SLA・可用性・キャパシティを設計する	サービスレベル管理（SLM）、可用性管理、キャパシティ管理
ST（移行）	新サービスを本番環境へ安全に展開する	変更管理、リリース管理、構成管理（CMDB）
SO（運用）	日常的な運用と障害対応を行う	インシデント管理、問題管理、サービスデスク
CSI（改善）	サービス品質を継続的に評価・改善する	7ステップ改善プロセス、サービス測定・報告

「サービスオペレーション（SO）の中にインシデント管理と問題管理が両方入っている」と整理できたとき、この2つが混同されやすい理由がようやくわかりました。同じ運用フェーズにあるのに、目的がまったく違うのです。

SLA（サービスレベル合意書）

SLA（Service Level Agreement）とは

ITサービス提供者（プロバイダ）と利用者（顧客）の間で、提供するサービスの品質水準について合意した文書です。サービスデザイン（SD）フェーズで策定され、達成目標値（SLO）・測定方法・未達時のペナルティ等が明記されます。

SLAの記載項目と例

項目	説明	例
可用性	システムが正常稼働している時間の割合	99.9%以上（月間ダウンタイム約44分以内）
応答時間	リクエストへの返答が返るまでの時間	3秒以内（通常業務時間帯）
解決時間	障害発生からサービス復旧までの目標時間（RTO）	4時間以内
サポート時間	問い合わせ・障害対応が可能な時間帯	平日9:00〜18:00
スループット	単位時間あたりの処理件数	1,000トランザクション/秒以上
RPO	復旧時点目標——どの時点のデータまで復元できるかの目標	24時間以内（日次バックアップ相当）

SLA・OLA・UCの違い

SLA（Service Level Agreement）

ITサービス提供者と顧客の間の合意。外向きの約束事。可用性・応答時間・ペナルティ等を規定する。

OLA（Operational Level Agreement）

ITサービス提供者内部（例：開発部門と運用部門）の合意。SLAを達成するための内部取り決め。

UC（Underpinning Contract）

外部ベンダーとの契約。SLAを支えるサプライチェーン側の合意。外部委託先との品質保証を担保する。

主要プロセスを整理する

ITILのサービストランジション（ST）とサービスオペレーション（SO）には、試験で頻繁に問われる5つのプロセスが集中しています。目的・トリガー・成果物を軸に比較することで、混同を防げます。

プロセス	目的	トリガー	主な成果物
インシデント管理	サービスの迅速な復旧	障害発生・サービス低下	インシデントチケット、ワークアラウンド
問題管理	根本原因の特定と再発防止	インシデントの繰り返し発生	既知のエラーDB（KEDB）、根本原因分析レポート
変更管理	変更リスクの制御と承認プロセス	変更要求（RFC）の提出	変更承認記録、変更スケジュール（FSC）
リリース管理	承認済み変更の安全な本番展開	変更管理からの承認後	リリース記録、展開計画書
構成管理	IT資産（CI）の情報を一元管理	随時（CI追加・変更時）	CMDB（構成管理データベース）

インシデント管理 vs 問題管理

試験で最も混同されやすいのがこの2つです。同じ「サービスオペレーション」に含まれながら、目的がまったく異なります。

インシデント管理
今すぐ直す（応急処置）

目的：サービスの迅速な復旧

根本原因の追究より復旧を優先

ワークアラウンド（暫定対処）を活用

対象：予期しない障害・品質低下すべて

成果物：インシデントチケット

問題管理
なぜ起きたかを調べる（根本原因）

目的：根本原因の特定と再発防止

根本原因分析（RCA）を実施

恒久的な解決策を導出する

対象：繰り返し発生するインシデントの原因

成果物：既知のエラーDB（KEDB）

連携の流れ

インシデントが繰り返し発生すると、問題管理に引き継がれます。問題管理が根本原因を特定すると「既知のエラー（Known Error）」として登録され、将来の同種インシデントに素早く対処できる情報資産になります。インシデント管理は対症療法、問題管理は根本治療——この対比が試験でそのまま問われます。

日常の場面で考えると少しわかりやすいかもしれません。社内システムが朝ログインできなくなったとき、IT部門が「再起動で対応」するのはインシデント管理です。翌週また同じことが起きて「なぜ毎週月曜に落ちるのか」を調べ始めたら、それが問題管理に移行した瞬間です。

インシデント管理と問題管理をずっと「同じもの」として読んでいました。「インシデント＝今すぐ動かす、問題＝なぜ動かないかを調べる」という切り口で整理したら、やっと選択肢を迷わなくなったのです。

過去問で確認する

ITILにおけるインシデント管理と問題管理について、次の説明のうち最も適切なものを選ぶ形式の問題が出題されました。インシデント管理の目的を「根本原因の究明」と誤認させる選択肢が含まれるパターンが典型的です。

解法ポイント

インシデント管理の目的は「サービスの迅速な復旧」であり、根本原因の究明は二次的な目的にとどまります。問題管理の目的が「根本原因の特定と再発防止」です。選択肢を絞る際は「目的語」に注目してください。「復旧」か「原因究明」かで2つを識別できます。

SLA・OLA・UCについて、それぞれの合意主体と役割を問う形式で出題されます。「社内部門間の取り決め」と「外部ベンダーとの契約」を入れ替えた選択肢が混在するため、各合意の対象者（誰と誰の間の合意か）を正確に覚える必要があります。

解法ポイント

SLA＝顧客との外向き合意 / OLA＝社内部門間の内部合意 / UC＝外部ベンダーとの契約、という3層構造で整理します。OLAとUCはどちらも「SLAを達成するための下支え」という共通点があり、違いは「社内か社外か」です。

ITILにおける変更管理のプロセスと、CMDB（構成管理データベース）の役割を問う問題です。変更諮問委員会（CAB）の機能や、緊急変更の手続きについて正確な理解が問われます。

解法ポイント

変更管理の目的は「承認されたプロセスで変更を実施し、リスクを最小化すること」です。変更の審査・承認を行う機関が変更諮問委員会（CAB）。緊急変更は通常のCABを省略した緊急CAB（ECAB）で対応します。CMDBはすべての構成アイテム（CI）の情報を一元管理するデータベースで、変更管理・インシデント管理・問題管理の基盤情報を提供します。

U のメモ

ITSMを学んで気づいたのは、これが「技術の話」ではなく「組織の話」だということです。インシデントが起きたとき誰が動くか、変更を承認するのは誰か、SLAをモニタリングするのはどの部門か——こうした役割と責任の設計がITILの中心にあります。診断士試験では「どのプロセスが何を目的とするか」を問う問題が多いため、プロセス名と目的語をセットで覚えることを試しています。