変更管理 (ITシステム)

この項目では、ITシステムにおける「変更管理」について説明しています。マネジメントプロセスについては「変革管理」を、ITSMの定義については「変更管理 (ITSM)」をご覧ください。

「バージョン管理」とは異なります。

変更管理、変更制御 (英: change control)は、品質マネジメントシステム（QMS）および情報技術（IT）システム内の製品やシステムへの変更が、管理・調整された上で導入されることを保証するための、公式または非公式^[1]の手順のこと。これにより、不必要な変更が予期せずにシステムに導入されたり、システムに障害が発生したり、ソフトウェアの他のユーザーによって行われた変更が取り消されたりする可能性が低くなる。変更管理手順の目標は、通常、サービスの中断を最小限に抑え、変更取り消しのための活動を削減し、変更の実装に関連するリソースを費用効果の高い方法で利用することである。

変更管理は、IT^[2]、 ソフトウェア開発^[1]、 製薬業界^[3]、 医療機器業界^[4]、 およびその他の工学/製造業界を含むさまざまな業界で行われる^[5] 。 ITおよびソフトウェア業界にとって、変更管理は、より幅広い分野をカバーする「ITSMが定義する変更管理」の主要な側面である。コンピュータおよびネットワーク環境における変更管理の典型的な例は、ソフトウェア製品への更新プログラム適用、新しいオペレーティングシステムのインストール、ネットワークルーティングテーブルのアップグレード、またはそのようなインフラストラクチャをサポートする電力システムの変更である 。

ITILの中でも変更管理に関する記載がある^[6]。

手順

マネジメントプロセスの変更管理、構成管理、およびITシステムにおける変更管理の間には、かなりの重複と混乱がある。以下の定義は、他の定義とも重複するところがある。

変更管理は、以下の6段階のセットとして説明できる。

1. 計画/範囲
2. 評価/分析
3. レビュー/承認
4. ビルド/テスト
5. 実装
6. クローズ

計画/範囲

提案された変更の主要および補助的な詳細を検討する。変更箇所の特定、その所有者、伝達と実行の方法、成功の検証方法、変更の重要性の見積もり、変更によるメリット、ビジネスおよび業界標準への準拠、完了日の目標などを含める必要がある^{[2] [7] [8]}。

評価/分析

次の重要な段階は影響とリスクの評価である。実行されたとき、提案された計画がうまく動かない場合があるかを評価する。この段階では、細部を考慮する必要がある。その後、提案されたそれぞれの変更にリスク評価 (高、中、低) を割り当てる。高リスクの変更には、管理者の承認や利害関係者への通知など、多くの追加手順が必要であるが、低リスクの変更には、プロジェクトマネージャの承認と最小限のドキュメントのみで済む場合がある^{[2] [7] [8]}。 計画/範囲で対処されていない場合、特に重大な最悪のシナリオがあるリスクの高い変更については、変更取消作業の計画を考えておく必要がある。

レビュー/承認

変更管理者、変更管理委員会、運営委員会、またはプロジェクトマネージャのいずれであっても、通常、レビューと承認のプロセスが必要になる。計画/範囲および影響/リスクの評価は、ビジネスの目標、要件、およびリソースのコンテキストで考慮される。たとえば、変更要求が、修正に多大なリソースを必要とする重大度が低く影響が少ない問題に対処していると見なされる場合、要求は優先度が低くなるか、完全に棚上げされる可能性がある。影響力の大きい変更が要求されたが、良い計画がない場合、承認者は、さらなる分析のために完全なビジネスケースを要求することがある^{[1] [2] [7] [8]}。

ビルド/テスト

変更管理要求を進めることが承認された場合、作業チームは、テスト環境または開発環境での小規模な開発プロセスを通じて手順を実行する。これにより、作業チームは、単体テストや回帰テストを通して、段階的な変更を実行してく^{[1] [2] [7]}。 リスクの低い変更については、テストと検証の方法がほとんど発生しない可能性があるが、大きな変更を行うには、実装前にかなりのテストが必要になる。 次に、承認を求め、実装フェーズを実行する日時を要求する。手順をテストできない稀なケースでは、変更/実装時期に対して特別な考慮を払う必要がある。

実装

ほとんどの場合、変更を迅速に進めるための技術的専門知識を備えた特別な実装チームが、変更を実装する。チームは、承認された計画だけでなく、組織の標準、業界の標準、および品質管理の標準にも従って変更を実装する^[7]。 実装プロセスでは、トラブルシューティングの支援を求められる可能性のある利害関係者など、実装チーム外のスタッフの責任範囲も必要になる場合がある^[2]。 実装後、チームは実装後のレビューを実行する。これは、別の利害関係者会議またはプロジェクトの終了手順中に行われる^[1] 。

クローズ

クローズの段階は、変更管理のより困難で重要なフェーズの1つになる可能性がある^[9]。 この最終段階での3つの主要なタスクには、プロジェクトが実際に完了したことの確認、「プロジェクト完了のコンテキストでのプロジェクト計画」の評価、およびプロジェクトの成功の具体的な証拠の提供が含まれる。 最善の努力にもかかわらず、変更管理プロセス中に問題が発生した場合は、将来の変更に学んだ教訓を適用することを目的として、何が起こったかについて事後分析を実行する必要がある^[2]。

規制環境

適正製造規範 (GMP) で規制されている業界では、このトピックは頻繁に遭遇する課題である。この概念を理解のために、さまざまな産業のガイダンスと解説がある^{[10] [11] [12]}。 一般的には、活動は通常、1つ以上の標準作業手順書 (SOP) によって指示される^[13]。 臨床試験の情報技術の観点からは、アメリカ食品医薬品局の文書によって紹介されている^[14]。

関連項目

• ドキュメンテーション
• 識別子
• バージョン管理
• 変更ログ
• 仕様（技術基準）
• 標準化
• スコープ管理
• 変更管理 (マネジメントプロセス)
• 変更管理 (ITSM)