- 製品機能
- ヘルプデスク
- インシデント管理
- ナレッジ管理
- セルフサービスポータル
- レポート
- 資産管理
- 購買管理
- 契約管理
- 構成管理データベース(CMDB)
- 問題管理
- 変更管理
- リリース管理
- サービス要求管理
- プロジェクト管理
- サービスレベル(SLA)管理
- 自動化・カスタマイズ
- ファシリティマネジメント
- その他機能
- 製品連携
- ManageEngine 製品連携
- Active Directoryアカウント管理
- Active Directoryとのシングルサインオン
- Microsoft Teams 連携
- 製品情報
- ITSMとは
- GDPR対策方法について
- 製品資料・導入事例
- 動作環境
- リリース情報一覧
- サービス形態/Editionの比較
- サポート
変更管理とは?
変更管理とは、変更によるリスクの認識や、標準化された手順による変更の実施により、ITサービスの中断を最小限に抑えながら、有益な変更を実施できるよう管理することです。
変更管理プロセスにおける「変更」とは、ITサービスを構成する要素に何らかの変更を加えることを意味します。OSのアップデートやPCの入れ替えはもちろんですが、サービスデスクのスタッフの変更も、変更管理の対象となります。
変更管理の対象となるもの
- OSのアップデート
- ハードウェアの追加や入れ替え
- セキュリティパッチの適用
- 新しいプロセスや仕組みの導入
- 文書の適用
- 担当者・担当業務の変更
- プロセスや手順の廃止 など
例えば、社内のネットワーク機器の一部を入れ替える場合、十分なリスク調査をしないまま導入してしまうと、ウイルス感染や通信速度低下が起きる可能性があります。あるいはサービスデスクのスタッフが配置転換した場合、関係部署への共有漏れや承認の遅れによって、インシデントに迅速に対応できない事態が想定されます。たとえ小さな変更でも、様々な要因が重なることで大きな混乱につながる恐れがあるのです。
適切な変更管理が実施されていれば、このようなビジネスへの影響を避けることができます。なお、ITサービスに影響を及ぼす可能性の低いルーチン化された作業は、変更管理の対象に含まれません。例えばプリンターの用紙切れに伴う用紙の補充などは対象外です。
目次
ITILに準拠した変更管理とは?
ITIL®(Information Technology Infrastructure Library)とは、ITサービスを安定かつ効率的に運用するためのベストプラクティスを体系化したフレームワークです。ITILでは、変更管理の目的を「リスクを最小限に抑えつつ、サービス品質を維持し、有益な変更を円滑に実施すること」としています。具体的には、変更要求(RFC)の受付から影響範囲の分析、変更諮問委員会(CAB)による承認、実装、レビュー、クローズまでの一連のプロセスと役割分担を明確に定義することで、属人的な意思決定や情報共有の遅れを防止します。
例えば、ネットワーク機器の入れ替えやスタッフの配置転換などの変更が、ITIL準拠で管理される場合、CABメンバーがリスクと影響度を客観的に評価し、最適な実施時期や手順を検討します。こうしたプロセスの標準化によって、変更実装時の手戻りやサービス障害を最小限に抑えることができます。
ITILに準拠した変更管理は、上記で述べた「変更管理の基本的な考え方」をさらに体系立て、透明性の高いワークフローを実践するための指針になります。
変更管理の目的
ITILのフレームワークから見た変更管理の目的は、「リスク低減とサービス品質の維持」と解説しましたが、たとえば、RFC(変更要求)からレビュー・クローズまでの一連の管理を一貫して行うことで、予期せぬ障害やダウンタイムを最小化し、ITサービスへの悪影響を防ぐことができます。変更管理の目的は、わかりやすく次の3つに集約して捉えることもできます
- 変更により障害が起きた際に、発生個所や原因の特定をするために変更履歴を残す
- 変更によるダウンタイムを最小限に抑える
- 想定外の範囲に変更が波及しないように制御する
また、変更管理プロセスにおける注意点として、
- そもそも変更が本当に必要なのか?
- 類似の変更がないか?
- 変更による影響範囲の評価や、変更の計画・実行は誰が行うのか?
- 指揮系統が複数乱立していないか?
など、想定外の事態や混乱が発生しないように、すべての変更をきちんと管理する必要があります。
ITILにおける変更管理プロセスの流れ
上記の変更管理プロセスにおける注意点に留意するうえでも、標準化されたプロセスに沿った管理が求められます。ITILでは、以下のように変更管理プロセスの流れを体系的に定義しています。
ITIL 4における変更管理のプロセス
1.変更要求の受付(RFC:Request for Change)
変更の目的・範囲・リスクなどを明確化し、正式にリクエスト(要求)を登録。
2.評価・承認(Assessment & Approval)
CAB(Change Advisory Board)による影響分析や優先度判定、ビジネスリスクの評価を経て承認可否を決定。
3.実装(Implementation)
スケジュールに従って変更を実装し、関連部署やユーザーへの影響をモニタリング。
4.レビュー・クローズ(Review &Closure)
変更結果を検証し、問題点や改善点を特定。必要に応じて知識ベースを更新し、手順を最適化。
変更管理のよくある課題
変更管理はITサービスマネジメントにおいて重要なプロセスに位置付けられていますが、以下のような理由から確実な変更管理を実施できていない組織は少なくありません。
・非効率で属人的な承認方法
変更管理プロセスには、CABメンバー(変更諮問委員会)による変更計画の承認、その後の変更マネージャーによる承認と、数段階の承認作業が含まれます。変更の可否だけではなく、変更実施時期や優先順位付けなど重要な決定も承認項目に含まれますが、従来の属人的な方法で実施すると、情報共有の遅れなどが起こりやすくなります。
・変更の方法/手法を標準化できていない
部署や担当者によって変更管理の手法が異なり、変更のたびに毎回異なった手法・方法が用いられる場合には、変更に割く時間もコストも高くなってしまいます。
・組織のサイロ化による影響
セキュリティリスクにあまりにも慎重になり過ぎることで、部署ごとにシステムがサイロ化され、その結果、意思決定に遅れが生じ、変更の実施に時間やコストを必要とする場合があります。
ツールで短期間に実現できる変更管理プロセス
ServiceDesk Plusは変更管理プロセスだけではなく、インシデントや問題管理の実装が簡単にはじめられるツールです。クラウド版も選べていつでも気楽に試せる上、管理者にとってもユーザーにとってもわかりやすいシンプルな管理画面をノーコードで構築することができます。

上記のフロー図のように、ServiceDesk Plusでは、変更管理プロセスに則った変更を実施できるよう、変更タイプ・CAB・変更の役割・変更ステージ・変更テンプレート・変更ワークフローなどの変更管理機能を搭載しています。
ServiceDesk Plusの変更ライフサイクル
ServiceDesk Plusの変更ライフサイクルは、以下の図の6段階に分かれています。
【tips ①】変更プロセスの時間軸に沿って、最大6つの段階の設定と、各段階での活動を定義でき、自社の実情に即した変更管理を実施できます。
【tips ②】関係者に変更のステータスを知らせる自動通知メール機能を備えています。それぞれの段階を進行するにあたり、承認済み(Approved)、却下(Rejected)、情報の要求(Request for Information)などのステータスで進捗を把握できます。
ステージ1:要求提起(Submission) | 【変更リクエスト(RFC)の作成】 変更は、変更に伴うコストとリスク、変更の適用範囲、他の変更との関係に応じて種類分けされます。 ServiceDesk Plusでは、3つ変更タイプ(標準的な変更、緊急の変更、 通常の変更)が用意されているほか、必要に応じて組織固有の変更タイプを追加できます。 さらに変更カレンダー上で識別しやすいよう、それぞれの変更タイプにはコードカラーを設定できます。 |
---|---|
ステージ2:計画(Planning) | 【変更の計画とアセスメント(事前影響評価)の実施】 ITサービスに与えるインパクト、変更実施プラン、万が一問題が発生してしまった場合の復旧プラン、変更作業により発生するダウンタイム時間などをここで検討します。 |
ステージ3:承認(Approval) | 【変更マネージャ、または、CAB(変更諮問委員会)メンバーに対して承認を依頼】 承認者は、「変更の目的、内容、手順が妥当であるか」を評価、判断します。 CABは、変更承認者の意思決定を支援し、変更のアセスメントや優先度付において変更管理をサポートします。多くの場合、CABのメンバーは、変更におけるビジネス部門とIT部門の利害関係者のニーズ全般を明確に把握している人々で構成されます。 |
ステージ4:構築(Implementation) | 【スケジュールに合わせ、変更を実施】 変更実装は、タスク単位で手順を管理・進捗を管理します。 |
ステージ5:レビュー(Review) | 【レビューの実施】 承認された内容で変更が正常に行われたか、レビューします。 |
ステージ6:クローズ(Closure) | 【クローズ】 クローズします。 |
製品画面など、詳細につきましては変更管理機能ページをご参照ください。
なぜ変更管理が必要なのか
ITサービスは常に更新されていきます。先進のセキュリティツールの導入やコストの見直し、新しいサービスの導入など、ITサービスは常により良いものへと改善されていきます。つまりビジネスが継続する限り、適切で確実な変更管理も常に必要となってきます。
適切な変更管理がもたらすメリット
- 変更時のトラブルやITサービスの中断を減らすことができる
- 先進のITサービスを常に維持することで、ユーザーからの信頼が高まる
- 組織的なセキュリティ対策を実施しやすい
- 承認プロセスを整えることで、インシデントへの対応力を高める
- 部署を超えて組織全体のコミュニケーションを深める
- 変更方法を標準化することで時間やコストを抑える
- 変更によるダウンタイムを最小限に抑える など
変更管理とリリース管理の関連性
変更管理とは、ITサービスの中断を最小限に抑えながら、有益な変更を実施できるよう管理することです。一方でリリース管理とは、ITサービスを無事に本番環境に展開するための計画・スケジューリングを含めた管理のことです。
例えば、新しいセキュリティソフトを導入する場合、①本当にそのソフトが必要かどうかを判断し、②導入に問題やリスクがないかを調査し、③ソフトを導入する部署やPC、導入予定時期などを決め、④その変更計画をCABメンバーや変更マネージャが承認・レビューする。これらは変更管理のプロセスに該当します。
その後、変更管理において導入が承認されたセキュリティソフトを、ITサービスの品質を保ったままどのように導入するかを管理していくのがリリース管理です。⑥導入の具体的な計画を立て、⑦テストを実施し、⑧そのレビューを踏まえたリリースの準備、⑨実際に該当部署やPCへのリリース。このプロセスがリリース管理に該当します。
どちらもITサービスマネジメントにおける重要なプロセスですが、変更管理はビジネスに与える変更のインパクトを正確に判断・調整し、リリース管理はその変更が確実にスムーズに実施できることを目的にしています。一方で計画・承認・レビューとプロセスの種類が似ている面も多く、確実に整理して取り組まなければ、現場に混乱を生じさせる可能性もあります。
このような点からも、確実な変更管理を実施するには、ITSMツール/変更管理ツールを利用した変更管理をお勧めいたします。