コラム

こんにちは、デジタルビジネスのシステム運営に関するコンサルティングを担当している河村です。
今回は変更管理プロセスをとりあげて書きます。

デジタルビジネスにおける変更対応の重要性：
変更対応は、デジタルビジネスの競争力に直結する特に重要な領域です。他社サービスとの競争に勝つため、カットオーバー後も継続的にサービスのアップデートやインフラの増強が行われ、その頻度と求められるスピードは基幹系システムとは比べられません。
一方で、変更対応に起因するシステム障害が多いのも特徴です。変更管理では、こうしたビジネスにとって有益な変更対応を、トラブルなく実施できるようにコントロールするのですが、ここで基幹系システムに取り入れられている変更管理プロセスをそのままデジタルビジネスのシステム運営に適用してしまうと、ビジネスのスピードや柔軟性が損なわれる可能性が高いです。ビジネスの競争力を損ねるようでは本末転倒ですので、工夫が必要となります。

変更管理とは：
変更管理についてはITIL®で目的や達成目標、活動内容がまとめられていますが、それ以外にもISO20000の要求事項（ITSMS）や、監査対応時の主なチェックポイントなども参考になります。以下にその概要をまとめます。

ITIL®における変更管理
変更とは、ITサービスに影響を及ぼす可能性のあるものを、追加、修正、または削除することを指す
変更管理の目的は、すべての変更のライフサイクルをコントロールし、ITサービスの中断を最小限に抑えながら、有益な変更を実施できるようにすることである
変化する事業要件に対応すると同時に、価値を最大化し、インシデント、中断、手直しを削減する
変更要求の記録から評価、優先度付け、計画、テスト、実施、文書化、レビューまでをコントロールする

ISO20000における変更管理の要求事項の例
変更管理方針を確立し、変更管理が制御している構成アイテムと、サービス又は顧客に重大な影響を及ぼす可能性のある変更を判断する基準を定義しなければならない
変更要求を記録し、分類し、評価し、承認する文書化された手順をもたなければならない
サービス提供者は、緊急変更の定義について文書化し、顧客と合意しなければならない
緊急変更を管理する文書化された手順をもたなければなならない
サービス又はサービスコンポーネントへのすべての変更は、変更要求を用いて提起しなければならない
承認された変更は、開発し試験しなければならない
承認された変更の詳細及びその展開の期日案を含む変更スケジュールを策定し、利害関係者に周知しなければならない
失敗した変更を元に戻す、又は修正するために必要案活動を計画し、可能な場合に試験しなければならない
CMDBの記録は、変更の展開の成功後に更新しなければならい

監査対応時のチェックポイントの例（内部統制におけるIT全般統制、ITガバナンスにおけるシステム監査）

• 規程・手順書・マニュアルなどが策定されているか、CIOやIT部門長による正式な承認を受けているか
• 規程やマニュアルが関係部門に周知・徹底されているか
• 変更依頼書が作成されているか（変更ログはあるが変更作業依頼書がないものはないか）
• 変更依頼書は、依頼部門の承認を受けているか
• 変更依頼書は、IT部門の責任者の承認を受けているか
• 要件定義書と設計書の整合が取れているか。設計書とプログラム機能書の整合性がとれているか
• 変更作業に作業工数や期間が異常にかかっているものがないか
• 本来の担当者以外の者が変更作業を行っていないか
• 変更作業を行っている場所の情報セキュリティが確保されているか
• 変更作業の件数・作業工数・コストなどについて、アプリケーションシステム間で比較して、異常値がないか
• テストや変更内容の事後確認が行われているか
• 変更作業完了報告書は、依頼部門に送付され、依頼部門の責任者の承認を受けているか
• 変更依頼書と変更作業完了報告書の整合性がとれているか

後編に続きます。