内部統制という用語がＩＴの世界でも頻繁に使われるようになってきました。 「統制」という硬いニュアンスの言葉も、原語を辿れば「コントロール」です。
つまり、内部統制というのは内部をコントロールすることです。
意志通りに社内をコントロールするためには、経営陣はどこで誰が何を行っているかを正確に把握していなければなりません。それが内部統制です。経営陣は、企業活動の結果に対して説明責任を果すことができます。
ＩＴサービスマネジメントの世界でも、どこで何が起こっているかを把握する 必要があります。現在の状態をきちんと把握することができなければ、サービスの 品質をコントロールすることはできないからです。それでは、サービスとインフラストラクチャを統制しているのはどのプロセスでしょうか？それは、今回のテーマである変更管理になります。
インフラストラクチャの追加・削除・変更はすべて変更管理の認可が必要です。サービスの導入や機能追加・変更・削除もすべて変更管理の認可が必要です。変更管理は、変更要求の受け入れ、変更要求の評価、変更の認可、変更の監視、導入後のレビューといった一連の活動を通して、インフラストラクチャやサービスに秩序を与えています。
変更には利害関係が付き物です。変更によって業務を改善したい人もいれば、その変更が直接あるいは間接的に自分の業務に関わってくる人もいます。そういった個々の利害関係から距離を置いて、組織として変更のリスクと利益を判断し、サービスに悪影響を与えない、迅速な変更を遂行する責任を持っているのが変更管理なのです。
変更管理とリリース管理は、同じ時間軸で活動しているため混乱しがちな概念です。 リリース管理は変更の品質に責任を持っているという意味において利害関係者の１つです。 該当する変更が品質の面で問題があり、稼働環境に悪影響を与える可能性がある場合には、そのリスクを指摘して変更の品質を高めなければなりません。
変更管理も変更の品質に注目することはもちろんですが、同時に他の利害関係者の意見にも耳を傾ける必要があります。顧客や開発責任者には別の主張があるかもしれません。 あらゆる利害関係者の声を聞き、あるいは議論を交わしながら、最終的には自らの責任で変更に対する組織としての判断を下すプロセスが変更管理なのです。
変更で影響を受けるすべての関係者からの意見やアドバイスを通じ、変更のリスクを認識し、組織として変更の是非を判断し、インフラストラクチャとサービスをコントロールする。ここに、変更管理の内部統制における価値があります。
