コラム
デジタルビジネスのサービス品質改善のための変更管理のポイント（後編）
2016年11月30日
著者： 河村 拓
小学生時代をアメリカ合衆国カルフォルニア州で過ごす。慶應義塾大学総合政策学部を卒業し、2009年4月に株式会社ビーエスピーに入社。提案から要件定義、設計、実装までを、プロジェクトマネージャーまたはPMOとしてワンストップで担当。複数サービス・部門・企業を横断したプロセス標準化やシステム共通化のプロジェクトを、手戻りなくスケジュール通り遂行する業務改革ノウハウに強みを持つ。
こんにちは、デジタルビジネスのシステム運営に関するコンサルティングを担当している河村です。前編に続き、変更管理プロセスを実施する際のポイントについて書きます。
影響度に応じて管理レベルを分ける：
特に注意したいポイントです。システム変更はトラブルと隣り合わせなため、厳重なチェック体制と手順に従った作業が求められます。しかし、すべての変更作業に最高レベルの管理を行うのは過剰対応であり、効率性の面で適切とは言えません。変更のスピード低下や、変更サイクルの長期化を招けば、事業の競争力を阻害する要因になりえます。
重要なのは、変更作業ごとに影響度を考慮した管理レベル (変更区分) を設定し、影響度 (トラブルのリスク) の低い変更作業は、チェック項目の簡素化や承認者レベルの緩和を行い、適切なスピードと管理負荷を保つことです。
ITIL®では、変更管理のレベルを「標準変更」「緊急変更」「通常変更」に分けています。以下で、それぞれの定義を解説します。
①標準変更：リスクが低く、事前に申請があり承認されている変更作業。比較的よく発生し作業指示書に従って対応できる変更が該当する。標準プロセスを整備することがポイントになる。
②緊急変更：可能な限り迅速に対応しなければならない変更が該当する。重大なインシデントの解決、セキュリティに関わる対応等がある。
③通常変更：標準変更、緊急変更以外のすべてが該当する。変更の頻度に応じて標準変更の区分で管理できるように整備することで管理コストを削減することにつながる。
影響範囲に応じて、適切なレビュアーを召集する：
変更に起因するトラブルは、影響範囲・検証範囲の考慮漏れが原因になりがちです。これらを正確に把握するには、最新の構成情報と、適切なレビュアーによる分析が重要です。事業における影響範囲とITにおける検証範囲は一致しないことがありますので、レビュアーには利害関係者のニーズを明確に理解できる人達をアサインする必要があります。
KPIでパフォーマンスチェック：
定義したプロセスフローや基準が有効的・効率的に機能しているかどうかを評価し、改善を推進することが、継続的なプロセスの強化につながります。例えば以下のKPIを設定し、ツールから実績データをとれるようにするとよいでしょう。
- 変更に起因するミスの数（多いなら、プロセスの見直しや、担当者への教育が必要）
- 変更のリードタイム（ビジネススピードに影響）
- 変更の件数（サービスに対してどれだけ有益な変更を行えたかの指標）
