ITILのプロセス一覧をわかりやすく整理

ITILのプロセスとは、ITサービスの企画から運用までを体系的に進めるために整理された一連の活動群を指します。本記事では、ITIL v3のサービスライフサイクル5段階とプロセスの対応関係、実務で頻繁に話題になる4つの主要プロセスの役割、プロセス間の連携、そして中小規模組織がITILを導入する際にどこから着手すべきかを整理して解説します。

ITILプロセスの全体像

ITILのプロセスとは、ITIL v3までの体系でサービスライフサイクルの各段階に割り当てられた、特定の目的を達成するための一連の活動のまとまりを指します。

ITIL4では体系そのものが刷新され、v3までプロセスと呼ばれていた活動は、一般管理(ビジネスマネジメント)14・サービスマネジメント17・技術管理3の合計34の「プラクティス」という単位に再編されています(出典:LMIS「最新版ITIL 4を活用したITサービスマネジメント変革とは？～ITIL 4概要～」)。ただし案件の現場では、v3の時代に整備された体制がそのまま運用されているケースも多く、「インシデント管理プロセス」「変更管理プロセス」のようにプロセスという呼び方が今も広く使われています。本記事でも実務での通りやすさを優先し、v3のプロセスという単位を軸に整理します。ITIL全体の成り立ちやバージョン変遷はITIL全体像を先に確認すると理解がスムーズになります。

サービスライフサイクルとの対応

ITIL v3のプロセスは、サービスストラテジ・サービスデザイン・サービストランジション・サービスオペレーション・継続的サービス改善という5つのライフサイクル段階のいずれかに位置づけられています。

各段階に含まれる代表的なプロセスを数えると、サービスストラテジに5つ、サービスデザインに8つ、サービストランジションに7つ、サービスオペレーションに5つが挙げられ、ここに段階を横断する継続的サービス改善の改善サイクルが加わります(出典:ManageEngine「ITILとは？導入メリットや注意点を知り、自社のITSMを成功させる！」)。次の表に、各段階の目的と代表的なプロセスをまとめました。

この5段階は、順番に一度だけ進む工程ではありません。運用段階で得た気づきをストラテジやデザインへ継続的にフィードバックする循環構造になっている点が、実務で押さえておきたいポイントです。

主要プロセスの一覧と役割

実務で最も話題になるプロセスは、サービストランジションの変更管理・構成管理と、サービスオペレーションのインシデント管理・問題管理の4つです。

この4つは、日々の運用改善サイクルの骨格を成すプロセスであり、「まずこの4つを押さえておけば案件での会話についていける」という声がよく聞かれます。以下では、それぞれの目的と役割の違いを整理します。

インシデント管理・問題管理・変更管理・構成管理

インシデント管理は、サービス提供中に発生した障害やトラブルへの対応を担い、業務への影響を最小限に抑えて可能な限り早く復旧させることを目的としたプロセスです。これに対し問題管理は、個別のインシデントの奥にある根本原因を特定し、再発を防ぐための恒久対策につなげる役割を担っており、両者は復旧のスピードを優先するか原因究明を優先するかで役割が明確に分かれています(出典:Wave PC Mate「インシデント管理とは？ITILに基づいた適切な運用方法、早期解決や再発防止のポイント」)。障害発生時の具体的な対応の流れは、インシデント管理の実務を扱った記事もあわせて参考にすると理解が深まります。

変更管理は、システムやサービスへの変更が計画どおりにリスクを抑えて実施されるよう管理するプロセスです。変更要求(RFC)を受け付けたうえで、変更マネージャーやCAB(変更諮問委員会)による承認を経て実施し、実施後に結果をレビューするという流れが基本形になります(出典:ManageEngine「変更管理とは？ITILに準拠した変更プロセスと短期間での実装法」)。構成管理は、ハードウェアやソフトウェアなど個々の構成アイテム(CI)とその関係性をCMDB(構成管理データベース)で一元管理するプロセスで、変更管理が変更の影響範囲を判断する際の基礎情報としても使われます(出典:ニュートン・コンサルティング「構成管理｜サイバー/デジタルリスクNavi[用語集]」)。

プロセス間の連携で押さえるべき点

インシデント管理・問題管理・変更管理・構成管理の4つは独立して動くのではなく、一連の流れの中でお互いの情報を受け渡しながら機能します。

あるシステムで障害が発生した場面を例に流れを整理すると、次のようになります。まずインシデント管理でチケットを起票し、暫定的な復旧を優先して対応します。復旧後、同種の障害が繰り返し起きていないかを問題管理で分析し、根本原因が設定ミスや構成の不整合にあると判明した場合は、恒久対策として変更管理にRFC(変更要求)を申請します。変更が承認されて実施されたら、変更対象の構成アイテムの情報を構成管理のCMDBに反映し、次にインシデントが起きた際に同じ構成情報を参照できるようにします。

この流れの中で構成管理は、変更管理が変更の影響範囲を判断したり、リリース管理が実施計画を立てたりする際の基礎情報としても参照されており、単独のプロセスとしてではなく他のプロセスを支える土台として機能します(出典:ニュートン・コンサルティング「構成管理｜サイバー/デジタルリスクNavi[用語集]」)。CMDBの情報が古いまま放置されると、変更の影響範囲を見誤ったり、インシデント発生時に対象システムの構成を正しく把握できなかったりするおそれがあります。4プロセスの連携を機能させる前提として、構成情報の更新を運用ルールにあらかじめ組み込んでおくことが重要です。

中小規模組織でのITIL導入時の取捨選択

中小規模組織がITILを導入する際は、5段階すべてのプロセスを一度に整備しようとせず、影響範囲が大きいインシデント管理と変更管理から着手するのが現実的です。

コンサルタントの歩み編集部が、ITSM関連のPMO案件や情報システム部門の立て直しに関わった独立コンサルタント複数名に取材したところ、最初に整備すべきプロセスとして挙がる回答の多くはインシデント管理と変更管理でした。理由として、障害対応の遅れや無秩序な変更が業務影響として最も表面化しやすく、経営層への説明もしやすいことが挙げられていました。構成管理やサービスレベル管理は、対象範囲を絞ったうえでCMDBの維持コストが運用体制に見合う規模になってから拡張するという段階的な進め方が実務的だという声が多く聞かれます。

ITSM関連のPMO/PM案件に携わる独立コンサルタントの多くは、こうした段階導入の設計や優先順位づけを支援する役回りで案件に参画します。大手企業は与信や機密保持の観点から個人と直接契約しないケースが多く、エージェント2〜3社に登録し前職からのリファラルと組み合わせて案件に参画するのが実務上の基本ルートとされています(出典:ドメイン知識ベース「案件獲得の基本ルート（大手企業とは直契約よりエージェント経由）」)。

まとめ

ITILのプロセスは、v3の体系ではサービスライフサイクルの5段階に整理され、実務ではインシデント管理・問題管理・変更管理・構成管理の4つがとくに頻繁に話題になります。これらは独立したチェックリストではなく、障害対応から恒久対策の検討、変更の実施、構成情報の更新までがひとつながりになった運用サイクルとして機能する点を押さえておくことが大切です。中小規模組織でITILを導入する場合も、全プロセスを一度に整備しようとせず、影響範囲の大きいインシデント管理と変更管理から着手し、構成管理などは体制が整ってから段階的に広げていく進め方が現実的です。本記事は2026年9月時点の情報に基づいています。

出典・参考情報

1. LMIS「最新版ITIL 4を活用したITサービスマネジメント変革とは？～ITIL 4概要～」（2026-09-09参照）
2. ManageEngine「ITILとは？導入メリットや注意点を知り、自社のITSMを成功させる！」（2026-09-09参照）
3. Wave PC Mate「インシデント管理とは？ITILに基づいた適切な運用方法、早期解決や再発防止のポイント」（2026-09-09参照）
4. ManageEngine「変更管理とは？ITILに準拠した変更プロセスと短期間での実装法」（2026-09-09参照）
5. ニュートン・コンサルティング「構成管理｜サイバー/デジタルリスクNavi[用語集]」（2026-09-09参照）

本記事は2026年9月時点の情報に基づいています。