1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ITILの変更管理から始めるEnabling

1
Last updated at Posted at 2025-12-18

はじめに

恒常的な運用保守をプロダクトチームに Enabling するのって難しいですよね。アイデアの一つとして、変更管理を見直すというやり方を提案したいと思います。
自分たちのところでは、通常変更で運用していた一つの作業を標準変更にできると考え、社内フローを改めて見直し、プロダクトチームの作業ハードルを下げ Enabling を加速させました。

この記事では、ITIL の変更管理の基本を解説しつつ、Enabling を進めるための具体的なアプローチをお伝えします。

ITIL とは

ITIL(Information Technology Infrastructure Library)は、IT サービスマネジメントのベストプラクティスをまとめたフレームワークです。イギリス政府機関によって開発され、現在は世界中の組織で IT サービス管理の標準として採用されています。

ITIL では以下のような領域をカバーしています

  • サービス戦略
    • ビジネス目標に沿った IT サービスの計画
  • サービス設計
    • 新規・変更サービスの設計
  • サービス移行
    • サービスの本番環境への移行管理
  • サービス運用
    • 日々のサービス提供と管理
  • 継続的サービス改善
    • サービス品質の継続的な向上

今回フォーカスするのは、サービス移行の中の「変更管理」です。

変更管理とは

変更管理は、IT 環境への変更を体系的に管理するプロセスです。変更によるリスクを最小化しながら、ビジネスニーズに応じた変更を効率的に実施することを目的としています。

変更の種類

ITIL では、変更を以下の 3 種類に分類しています:

1. 標準変更(Standard Change)

  • リスクが低く、手順が確立された変更
  • 事前承認済み(都度の承認不要)
    • 定型的なソフトウェアアップデート、ユーザーアカウントの作成、事前定義されたインフラ変更

2. 通常変更(Normal Change)

  • 標準変更に該当しない一般的な変更
  • 変更諮問委員会などによる承認が必要
    • 新機能のリリース、インフラ構成の変更、新システムの導入

3. 緊急変更(Emergency Change)

  • 緊急性が高く、迅速な対応が必要な変更
  • 緊急変更諮問委員会(ECAB)による迅速な承認
    • 重大な障害の修正、セキュリティパッチの緊急適用

変更管理と Enabling の関係

多くの組織では、プロダクトチームが自律的に作業を進められるよう Enabling を進めています。しかし、厳格な変更管理プロセスがボトルネックになることがあります。

例えば、以下のようなケースが考えられます。

  • 本番環境への小さな設定変更でも CAB 承認が必要
  • 承認待ちで作業が数日間止まる
  • プロダクトチームが「自分たちでは何もできない」と感じてしまう
  • SRE での作業を待とう、となり Enabling が進まない 😢

変更管理を見直して Enabling を加速させる

私が実際に変更管理を見直した際のステップを示します。

1. 現在のボトルネックを特定する

まず、Enabling のボトルネックになっている作業がどの変更の種類に当てはまるかを確認します。

  • 頻繁に発生する作業は何か?
  • その作業は現在どの変更種類として扱われているか?
  • 承認プロセスにどれくらい時間がかかっているか?

2. 変更の種類が適切かどうかを判断する

通常変更として扱っている作業の中に、実は標準変更に分類できるものがないか検討します。

実は以下のような作業はありませんか?

  • 手順が文書化されている
  • リスクが低い(過去の実績で証明されている)
  • 繰り返し発生する
  • 影響範囲が明確で限定的

3. リスク分析を行う

変更の種類を変える場合は、リスク分析を行い本当に問題ないかを判断します。

観点 確認事項
影響範囲 変更が影響を与えるシステム・ユーザーの範囲
過去の実績 同様の変更で問題が発生した履歴
ロールバック 問題発生時の切り戻し手順の有無
監視 変更後の異常検知の仕組み

リスク分析の結果、標準変更として扱えると判断できれば、承認プロセスを簡略化できるでしょう。

4. 手順を整備し標準変更として登録する

標準変更として認定するために、以下を整備します

  • 作業手順書
  • 前提条件と完了条件
  • ロールバック手順
  • 作業のトリガーと実行権限

5. プロダクトチームへ展開する

整備した内容をプロダクトチームに展開します。

まとめ

変更管理はガバナンスを守るためのものですが、適切に運用すれば「チームを縛る足かせ」ではなく「安全に速く進むためのガイドレール」になります。ぜひ皆さんの組織でも、変更管理の見直しを検討してみてください。

参考

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?