フレームワーク活用ガイドひとことで言うと#
ITILは、ITサービスの計画・提供・運用・改善を体系化したベストプラクティス集です。「インシデント管理」「変更管理」「問題管理」「サービスレベル管理」などのプロセスを標準化することで、ITサービスの品質と効率を継続的に向上させます。
用語の定義#
押さえておきたい用語
- サービスバリューシステム（SVS）：ITIL 4の中核概念。需要をきっかけに、組織の活動を通じて価値を生み出す全体の仕組み
- インシデント管理（Incident Management）：ITサービスの中断や品質低下を迅速に復旧させるプロセス。「まず使えるようにする」が目的
- 問題管理（Problem Management）：インシデントの根本原因を特定し、再発を防止するプロセス。インシデント管理とは別のプロセスとして運用される
- 変更管理（Change Management）：ITインフラやサービスへの変更を計画的に実施し、リスクを最小化するプロセス
- サービスレベル合意（SLA）：ITサービスの提供者と利用者の間で合意した品質基準。稼働率、応答時間、復旧時間などの指標で定義する
全体像#
サービス戦略の策定
何を提供するか
→何を提供するか
サービスの設計・構築
SLA・プロセスの整備
→SLA・プロセスの整備
運用とサポート
インシデント・変更管理
→インシデント・変更管理
継続的改善
KPIに基づく品質向上
KPIに基づく品質向上
こんな悩みに効く#
- システム障害のたびに対応が場当たり的で、復旧に時間がかかる
- 変更を加えるたびにトラブルが発生し、「触らぬ神に祟りなし」状態になっている
- IT部門への問い合わせが増える一方で、同じ質問が何度も来る
基本の使い方#
インシデント管理を整備する（最優先）
サービス中断が発生したときの対応フローを標準化します。受付→分類→優先度判定→エスカレーション→復旧→クローズの流れを定義し、ツール（ServiceNow、Jiraなど）で管理します。まず「全インシデントを記録する」習慣を作ることが第一歩です。
問題管理で根本原因を追究する
繰り返し発生するインシデントを問題として登録し、根本原因を調査します。インシデント管理が「消火活動」なら、問題管理は「火の原因を断つ」活動。月次で「繰り返しインシデントTop 5」をレビューし、恒久対策を実施します。
変更管理でリスクを制御する
システムへの変更（パッチ適用、設定変更、リリース）を計画的に管理します。変更要求→影響評価→承認→実施→レビューのフローを確立。リスクの高い変更は変更諮問委員会（CAB）で審議し、テスト環境での検証を必須にします。
SLAを定義して継続的に改善する
ITサービスの品質基準をSLA（サービスレベル合意）として利用部門と合意します。稼働率99.9%、インシデント初期応答30分以内、変更成功率95%以上などの指標を設定し、月次でモニタリングして改善します。
具体例#
中堅企業のITSM導入
製造業（従業員500名、社内システム15種）のIT部門（8名）が、ITIL準拠のITSMを導入。導入前は障害連絡がメール・電話・口頭でバラバラに来て、対応漏れが月5件発生していた。Phase 1:ServiceNowでサービスデスクを構築し、全問い合わせをチケット化。Phase 2:インシデントの優先度基準（P1:全社影響、P2:部門影響、P3:個人影響）を定義。Phase 3:繰り返しインシデントTop 5の問題管理を開始。1年後、インシデントの平均復旧時間が4時間→1.5時間に短縮し、対応漏れがゼロに。IT部門の満足度調査スコアが2.8→4.1（5点満点）に改善した。
SaaS企業の変更管理プロセス構築
BtoB SaaS企業（エンジニア60名、顧客2,000社）が、本番デプロイ後のトラブル頻発を受けて変更管理を導入。導入前は週15回のデプロイのうち2〜3回がロールバックになっていた。変更管理プロセスとして、変更をStandard（定型:自動承認）、Normal（通常:チームリード承認+テスト必須）、Emergency（緊急:事後レビュー付き）の3種に分類。Normalの承認にはテスト結果とロールバック手順の添付を必須化。6か月後、デプロイ回数は15回/週を維持しつつ、ロールバック率が18%→4%に低下。本番障害の月平均件数が8件→2件に減少した。
大学のIT部門のサービスレベル改善
私立大学（学生12,000名、教職員800名）のIT部門（15名）が、学内からの苦情増加を受けてITILベースのサービス改善を実施。まず過去6か月の問い合わせ3,600件を分析し、**42%が「パスワードリセット」「Wi-Fi接続」「印刷トラブル」の3種類に集中していることを発見。FAQとセルフサービスポータルを構築し、この3種類の問い合わせの60%をセルフサービスに誘導。同時にSLAを「問い合わせ受付から初回応答まで4時間以内」と設定し、達成率を月次でモニタリング。SLA達成率が3か月で65%→92%に改善し、学内満足度調査で「ITサポートに満足」の回答が38%→67%**に上昇した。
やりがちな失敗パターン#
| 失敗 | 原因 | 対策 |
|---|---|---|
| ITILのプロセスを全部一度に導入しようとする | 25以上のプラクティスを同時に始め、どれも中途半端になる | まずインシデント管理と変更管理の2つだけ導入し、安定したら順次追加する |
| プロセスが形骸化して「チケットを書く作業」になる | ITILの目的を理解せず、手続きだけが残る | 「なぜこのプロセスが必要か」を全員が理解するまで研修と振り返りを繰り返す |
| ツール先行でプロセスが後回しになる | 高機能なITSMツールを導入したが、プロセスが未定義で使いこなせない | まずプロセスを定義・合意し、それを支援するツールを選定する |
| SLAが厳しすぎて現場が疲弊する | 理想的な数値を設定してしまい、達成できず信頼を失う | 現状の実績データに基づいてSLAを設定し、四半期ごとに段階的に引き上げる |
まとめ#
ITILの価値は「ITサービスを場当たり的ではなく構造的に管理できる」点にあります。全プロセスを完璧に導入する必要はなく、「インシデントを記録する」「変更を計画的に行う」の2つだけでもIT部門の品質は大きく変わります。重要なのはフレームワークに自組織を合わせるのではなく、自組織の課題解決にITILのプラクティスを適用するという姿勢です。