変更管理とは?
変更管理とは、変更によるリスクの認識や、標準化された手順による変更の実施により、ITサービスの中断を最小限に抑えながら、有益な変更を実施できるよう管理することです。
変更管理プロセスにおける「変更」とは、ITサービスを構成する要素に何らかの変更を加えることを意味します。OSのアップデートやPCの入れ替えはもちろんですが、サービスデスクのスタッフの変更も、変更管理の対象となります。
変更管理の対象となるもの
- OSのアップデート
- ハードウェアの追加や入れ替え
- セキュリティパッチの適用
- 新しいプロセスや仕組みの導入
- 文書の適用
- 担当者・担当業務の変更
- プロセスや手順の廃止 など
例えば、社内のネットワーク機器の一部を入れ替える場合、十分なリスク調査をしないまま導入することで、ウイルス感染や通信速度低下が起きる可能性があります。あるいはサービスデスクのスタッフが変更した場合、関係部署への共有漏れや承認の遅れによって、インシデントに迅速に対応できない事態が想定されます。たとえ小さな変更でも、様々な要因が重なることで大きな混乱につながる恐れがあるのです。
適切な変更管理が実施されていれば、このようなビジネスへの影響を避けることができます。なお、ITサービスに影響を及ぼす可能性の低いルーチン化された作業は、変更管理の対象に含まれません。例えばプリンターの用紙切れに伴う用紙の補充などは対象外です。
変更管理の目的
変更管理の目的は、大きく次の3つがあります。
- 変更により障害が起きた際に、発生個所や原因の特定をするために変更履歴を残す
- 変更によるダウンタイムを最小限に抑える
- 変更対象外のシステムをコントロールする
また、変更管理プロセスにおける注意点として、
- そもそも変更が本当に必要なのか?
- 類似の変更がないか?
- 変更による影響範囲の評価や、変更の計画・実行は誰が行うのか?
- 指揮系統が複数存在しないか?
など、想定外の事態や混乱が発生しないように、すべての変更をきちんと管理する必要があります。
変更管理のよくある課題
変更管理はITサービスマネジメントにおいて重要なプロセスに位置付けられていますが、以下のような理由から確実な変更管理を実施できていない組織は少なくありません。
・非効率で属人的な承認方法
変更管理プロセスには、CABメンバー(変更諮問委員会)による変更計画の承認、その後の変更マネージャーによる承認と、数段階の承認作業が含まれます。変更の可否だけではなく、変更実施時期や優先順位付けなど重要な決定も承認項目に含まれますが、従来の属人的な方法で実施すると、情報共有の遅れなどが起こりやすくなります。
・変更の方法/手法を標準化できていない
部署や担当者によって変更管理の手法が異なり、変更のたびに毎回異なった手法・方法が用いられる場合には、変更に割く時間もコストも高くなってしまいます。
・組織のサイロ化による影響
セキュリティリスクにあまりにも慎重になり過ぎることで、部署ごとにシステムがサイロ化され、その結果、意思決定に遅れが生じ、変更の実施に時間やコストを必要とする場合があります。
なぜ変更管理が必要なのか
上記のような課題を抱えたままでは、変更のたびに予期せぬトラブルやITサービスの中断が懸念されます。その結果、ユーザーからの信頼をなくし利益の損失を招く事態になりかねません。
また、ITサービスは常に更新されていきます。先進のセキュリティツールの導入やコストの見直し、新しいサービスの導入など、ITサービスは常により良いものへと改善されていきます。つまりビジネスが継続する限り、適切で確実な変更管理も常に必要となってきます。
適切な変更管理がもたらすメリット
- 変更時のトラブルやITサービスの中断を減らすことができる
- 先進のITサービスを常に維持することで、ユーザーからの信頼が高まる
- 組織的なセキュリティ対策を実施しやすい
- 承認プロセスを整えることで、インシデントへの対応力を高める
- 部署を超えて組織全体のコミュニケーションを深める
- 変更方法を標準化することで時間やコストを抑える
- 変更によるダウンタイムを最小限に抑える など
変更管理とリリース管理の関連性
変更管理とは、ITサービスの中断を最小限に抑えながら、有益な変更を実施できるよう管理することです。一方でリリース管理とは、ITサービスを無事に本番環境に展開するための計画・スケジューリングを含めた管理のことです。
例えば、新しいセキュリティソフトを導入する場合、①本当にそのソフトが必要かどうかを判断し、②導入に問題やリスクがないかを調査し、③ソフトを導入する部署やPC、導入予定時期などを決め、④その変更計画をCABメンバーや変更マネージャが承認・レビューする。これらは変更管理のプロセスに該当します。
その後、変更管理において導入が承認されたセキュリティソフトを、ITサービスの品質を保ったままどのように導入するかを管理していくのがリリース管理です。⑥導入の具体的な計画を立て、⑦テストを実施し、⑧そのレビューを踏まえたリリースの準備、⑨実際に該当部署やPCへのリリース。このプロセスがリリース管理に該当します。
どちらもITサービスマネジメントにおける重要なプロセスですが、変更管理はビジネスに与える変更のインパクトを正確に判断・調整し、リリース管理はその変更が確実にスムーズに実施できることを目的にしています。一方で計画・承認・レビューとプロセスの種類が似ている面も多く、確実に整理して取り組まなければ、現場に混乱を生じさせる可能性もあります。
このような点からも、確実な変更管理を実施するには、ITSMツール/変更管理ツールを利用した変更管理をお勧めいたします。
ツールで短期間に実現できる変更管理プロセス
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) | 【クローズ】 クローズします。 |
製品画面など、詳細につきましては変更管理機能ページをご参照ください。