前回は、当該の活動で重点的に対応（再構築）するプロセスとして選定した業務プロセスのひとつ、「アクセス管理プロセス」の概要を紹介しました。今回は、同様に選定し、設計する業務プロセスのひとつ、「変更管理プロセス」の概要を紹介します。
このプロセスの特徴は、変更を管理する対象物の種類が多いことです。変更管理プロセスを設計するにあたっての宿命的な要件は、変更の対象物と、その構成がどのように管理されているかということです。あるべきは、全ての対象物が一元化されたリポジトリ（repository）で、その構成が管理されている状態かと思いますが、どうでしょうか？　・・なかなか実態としては”まだ、そこまでは”という事が多いのではないでしょうか。
　当該の変更管理プロセスは、組織単位が担う対象物に対応したリポジトリ（repository）で、IT部門全体のリソースの構成は”　組織間の連係　”によって成立するという実態をベースにして設計しています。
この構成管理の実態から考慮することは、変更管理プロセスに上述の”　組織間の連係　”（コミュニケーションの機能）」を担わせることです。問題管理プロセスなどの構成管理と連係する他の管理プロセスについても同様の対応が必要になりますが、プロセスを自動化（IT化）すれば、成果に差が出る訳ではありません。結果として、構成管理の管理レベルを変更管理などの他の管理プロセスが補完することになります。
　もうひとつの考慮点は、当該プロセスの実装方法です。まず、優先するひとつの組織を対象にして、全体のモデル(雛型)を設計し実装します。そして、このモデル（雛型）を順次に、他の組織に提示していきます。順次に部分調整を施しながら横展開し、実装していきます。横展開の完了によって、標準プロセスが完成します。（今回、以降に例示する「変更管理プロセス」は、当該の横展開する前のモデルです。）
　優先して実装する組織の管理する変更対象物は、「適用業務システム」と「システム制御パラメータ、サービスパラメータ」および「データ」です。「システム基盤（ネットワークを含むハードウエア）」、「オペレーションシステムなどのソフトウエア」や「システムライブラリー等々」や「ＩＴ運用に関わる手続きや標準ドキュメント」や「運用設備等々」、これらの管理すべき変更の対象物は、前述の「横展開」によって、その種類を追加していきます。段階的に管理の対象物を増やしても、当該のプロセスを構成する機能が変化する訳ではありません。現場レベルの部分的な調整で実装できるモデルとしています。

目次

1.コントロール目標と成果指標

2.管理プロセスの概要

1.コントロール目標と成果指標

　当該の「変更管理プロセス」は、IT運用の安定したサービスを維持するために、当該の「変更管理プロセス」は、IT運用の安定したサービスを維持するために、

　 ＊　適用業務システム
　 ＊　システム制御パラメータ、サービスパラメータ
　 ＊　データ
　 ＊　システム基盤（ネットワークを含むハードウエア）
　 ＊　オペレーションシステムなどのソフトウエア、システムライブラリー
　 ＊　ＩＴ運用に関わる手続きや標準ドキュメント
　 ＊　運用設備

・・等々の変更（保守）を標準化した方法で適正に管理する。その結果として、IT運用サービスのインテグリティ（完全性）を損なうリスクを低減する。

適用業務システムとデータ、これを運用するシステム基盤およびパラメータに対する、すべての変更に関する手続きを標準化し、その変更手続きの結果と変更内容を記録する。
変更要求がシステムおよびIT運用に及ぼす影響度合を定義（標準化）し、その影響度合から、個々の変更要求に対する実施の可否を判断する。
変更要求のビジネスにおける重要度を定義（標準化）し、その重要度から個々の変更実施の優先度を判断する。
変更要求の実施に要する工数を見積もり、上述の影響度合および重要度合を勘案し、その作業の実施を計画する。計画に際して必要な（経済的で有効な）代替手段（方法）、あるいは変更要求の再検討を提案する。
上記（２）（３）（４）のプロセスは、組織的に必要な承認行為により、そのプロセスを制御する。
障害の回避や回復、防止・予防措置など、インシデント管理や問題管理プロセスで発生する緊急の変更要求も含めて、例外なく、すべての要求を対象にし管理する。
変更作業を実施した後、必要なテストと検収を行う。テストと検収の結果を、求めに応じて閲覧できるリポジトリに保存する。
「変更の実施」と「本番運用への移行業務」は、職務として分離する。
マネジメントサイクルとして、常に継続的な改善を行う。
変更管理のインテグリティ（完全性）を確実にするために、IT部門を統括するマネージャー（CIO）のレビューとモニタリングのプロセスを確立する。

＜　成果指標　＞

　上述のコントロール目標の達成状況を測定します。成果指標は当該のアクセス管理プロセスの中で測定し、IT部門の目標管理プロセス（システム）で管理されます。

権限プロファイル設定の要件を満たさないシステムの数
アカウントの実査（実地棚卸）の結果、検出された差異件数
不正の予兆を検知したアクセスの件数
「影響度レベル=大」の不正アクセス（セキュリティインシデント）の件数

 

2.管理プロセスの概要

　上述のコントロール目標に適応した「変更管理プロセス」を再設計します。以下に、その概要を示します。

《　0.00　変更管理プロセス　》

　ここで紹介する変更管理プロセスは、次の４つの業務(上図)で構成されています。それは、管理対象に対する変更要求を、標準化された手続きで処理するプロセスです。

　　1.00　変更の要求
　　2.00　要求の調整
　　3.00　変更の実施と本番適用
　　4.00　レビュー

 

　変更要求を「標準化された手続きで処理する管理プロセス」がないと、システムの利活用部門は、〈　変更要求がＩＴ部門に受け入れられたかどうか　〉、〈　その変更要求はいつ処理されるのか　〉、〈　システムの担当部署によって対応が異なる　〉、〈　知らないうちに業務手順が変わっている　〉等々の、必要のないストレスを抱えることになります。また、ＩＴ運用部門においても、〈　変更の度にトラブルが発生する　〉、〈　再処理に手間と時間がかかる　〉、〈　誰が変更したのか　〉、〈　その変更を許可したのは誰か　〉等々、不必要な作業工数が増加し、管理不全の状態に陥る恐れがあります。
　当該の変更作業とその管理業務は、システムの保守と運用を担う部門にとって、質量ともに大きな比重を占める定常的な業務です。したがって、標準化された変更管理プロセスを確立することは、組織全体の生産性をアップさせることになります。これはJ-SOXの適用に関わりなく優先度の高い、最も重要な課題と言えます。

　余談です。
　（当該の管理プロセスのバックグランドで機能する業務プロセスを補足します。）

当該の管理プロセスでは、「IT部門のマーケティング機能」を考慮しています。これは今まで、あまり意識することが少なかった機能かも知れません。経営戦略とIT投資の関係が強まる中で、その役割を担うIT部門の「マーケティング機能」は今後、その重要度を増すものと思います。今回、考慮している「マーケティング機能」を簡単に説明すると、「システム利用部門（事業推進部門および管理部門）や経営者を顧客と置き換えたマーケティング活動」ということになるでしょうか。

 

 

 

考慮しているのは、次の２点です。

　ひとつは、運用サービスの満足度を調査（マーケットリサーチ）することです。調査には、「運用する情報システム」の有用性や、「当該の変更管理業務」のインテグリティ（完全性）対する満足度を含みます。調査結果をシステムおよびサービスの改善に結びつけること、提起される問題を迅速に解決すること、利用部門とその解決策を共有すること、それらを計画的に行う「活動」の仕組み（プロセス）を構築します。

　もうひとつは、パフォーマンスです。調査から改善活動のプロセスには、顧客（システムの利活用者や経営者等）の参加を促します。調査はもちろんですが、調査結果のヒヤリング、改善策を一緒に考える等々、実績のフィードバック～評価まで、一連のプロセスの中で主要な役割を担って頂きます。調査結果のヒヤリングの一環として、システムの利活用者にＩＴリテラシーに関わる教育をしたり、今後のビジネスに有効なITのトレンドや個別の技術情報を発信したりします。

　これは、ご存じの「システム管理者感謝の日」の理念にも通じるものがあります。重要な仕事を担っている割には感謝されない、「システム管理者」のパフォーマンスとしても有効かと思います。少なくとも、「利活用部門と協働する活動」によって、今までと異なるパフォーマンスエリアが拡大します。経営者の関心も、より高まります。

 

《　1.00　変更の要求　》

当該のプロセス（上図）は、変更の要求受け付けて、その内容を記録する業務で、次の３つの要素で構成されています。（　変更を要求する部門と変更を受付ける窓口の明確化が必須の要件です。　）

１.10　申請書の作成
　変更の要求内容を変更申請書に記入し、変更の受付窓口に提出します。変更の要求元を次の２つとします。

システムオーナー部門（システム利用部門を統括する管理部門）
インシデント管理および問題管理プロセスにより発生した変更要求でシステム保守あるいは運用のシステム管理者
　変更申請書の記入内容は次のとおりです。（申請書の宛先はIT部門のマネージャー宛てとします）
　 ＊　システムオーナー部門名(要求元)と担当者および責任者名
　 ＊　システム保守、運用部門名（要求先）とシステム担当者名
　 ＊　問題報告書の番号（インシデント管理および問題管理プロセスにより発生した変更要求の場合に記入します）
　 ＊　変更を要求した日
　 ＊　変更の実施を希望する日
　 ＊　変更要求の対象物（システム名等）と変更件名
　 ＊　変更の要求内容と内容を補足する添付資料の有無
　 ＊　変更の目的と変更が必要になった理由
　 ＊　変更によって得られる利益（効果）

1.20　申請の受付と内容の確認
　受付窓口は変更申請書を受付けて、上述（１.10　申請書の作成）の記入内容を確認し検証します。不備があれば訂正を依頼します。特に要求元の責任者の承認がないものは無効とします。

1.30　要求内容の記録
　受付け窓口は、検証済の上述（１.10　申請書の作成）の記入内容をシステム的な文書（データベース）に記録します。システム化（自動化）されたプロセスでは、「１.10　申請書の作成」で要求内容が記録されることになります。

　変更申請書の新たな記入内容は次のとおりです。

　 ＊　「変更申請書」の番号（自動的に付与します）

 

《　2.00　要求の調整　》

当該のプロセス（上図）は、変更要求を実現するための技術的な検討、および変更に要するコストと効果を算定（見積）し、実施の可否を判断する業務で、次の８つの要素で構成されています。実施の可否判断の根拠として、定義された「変更の緊急性」および「変更による影響度合」から変更の重要度を提示します。

2.10　緊急度の判定
　システム管理者は、定義された緊急度のレベルを判定し記録します。

〈　例：緊急度のレベル定義　〉

緊急レベル：　管理者が承認する、直ちに問題解決を要するもの
（インシデント管理および問題管理プロセスにより発生した変更要求で緊急に現状を回復しなければならない要求など）
高レベル　：　ビジネス環境の変化などにより対応期日が設けられているもの
中レベル　：　日常的に発生する変更要求で対応期日の調整ができるもの
低レベル　：　緊急性もなく影響度の少ないもの

2.20　技術面の検討
　システム管理者は、変更の対象を特定して、その区分を記録します。そして、変更の仕様を含む技術面の検証をします。

　〈　例：変更の対象区分　〉

区分１：　システム基盤（プラットフォーム）

ソフトウエア
ハードウエア
ネットワーク
保守、運用設備
その他
区分２：　適用業務システム

プログラム
パラメータ
データ
その他
※　上記の区分に対応するドキュメント（設計書、仕様書、各種の体系図／関連図／構成図、データ定義および運用マニュアル等々）も変更の対象物です。これらは、「構成管理プロセス」でコントロールされます。

　変更申請書の新たな記入内容は次のとおりです。

　 ＊　変更区分
　 ＊　所見（技術面）

2.30　業務面の検討
システム管理者は、変更に関わる業務面の検討をし、その結果を記録します。

変更申請書の新たな記入内容は次のとおりです。

　 ＊　所見（業務面）
　 ＊　変更の結果が及ぼす影響の範囲
　 ＊　変更に必要な工数の見積り
　 ＊　変更の要する費用（初期費用と運用費用）
　 ＊　変更によって得られる効果
　 ＊　スケジュール（実施期限）
　 ＊　変更仕様の代替案

2.40　実施の可否判断
　システムの保守、運用を担う責任者（システム管理者の上長）は、「2.10　緊急度の判定」「2.20　技術面の検討」「2.30　業務面の検討」の結果から重要度合を判定します。重要度の判定が、１および２の場合はIT部門のマネージャー、以外は当該の責任者が実施可否の裁定をします。否の場合は延期または再検討、または中止のいずれかを選択し、その理由を明記します。そのうえで、要求元（システムオーナー部門）の担当者および責任者の承諾を求めます。要求元の異議がある場合は、その内容を明記し実施可否の調整をします。（実際は前工程のプロセス、それぞれの要素業務の中で調整されます。したがって、当該の可否判断の多くは、結果として記録すると言うことになります。）

　変更申請書の新たな記入内容は次のとおりです。

　 ＊　重要度
　 ＊　システム管理者のサイン
　 ＊　責任者のサイン
　 ＊　IT部門のマネージャーのサイン（影響度＝１　or　２）
　 ＊　実施可あるいは、延期、再検討、中止のサインとその理由
　 ＊　要求元（システムオーナー部門）の担当者および責任者のサイン
　 ＊　同上の承認あるいは異議の表明

〈　例：重要度の定義　〉

重要度１：　緊急度＝緊急。対外的に影響を与える可能性がある。変更の作業工数３人月以上。復帰手順が複雑で回復時間1時間以上。
重要度２：　緊急度＝高。複数の利用部門および不特定多数の利用者に影響を与える可能性がある。変更の作業工数は２人月以上３人月以内。回復時間は30分以上1時間以内。
重要度３：　緊急度＝高以下、複数の利用部門（利用者は限定的）に影響を与える可能性がある。作業工数は1人月以上２人月以内。回復時間が30分以内。
重要度４：　緊急度＝中以下、限定的または単一の利用部門に影響を与える可能性がある。作業工数は１.0人月以内。回復時間は30分以内。
重要度５：　緊急度＝低。影響はほとんどない。

 

《　3.00　変更の実施と本番適用　》

当該のプロセス（上図）は、変更実施の許可を得た変更要求を実施し、その結果を本番に適用する業務で、次の５つの要素で構成されています。内部統制上、要素業務である「変更の実施」と「変更の本番適用」を分離し、それぞれに担当を割り当てること、それぞれに責任者の承認を求めること、テスト仕様とテスト結果は閲覧可能な状態で保存すること、などが求められます。（「変更の本番適用」は、前回の「アクセス管理プロセス」で記述する特殊権限を持つIT運用のシステム管理者が担当することになります。）

3.10　作業手順の作成
　システム管理者は、変更仕様書およびテスト仕様書の作成とその実施手順を作成します。実施手順には変更が不成立の場合に必要な復帰手順を含みます。作業の実施には、責任者の承認（重要度＝５以外）が必要です。

3.20　作業の実施
　システム担当者は作成した作業手順に基づいて作業を実施します。システム管理者は手順外の作業が発生したら、手順の確認と手順と工数の調整をします。システム管理者は、作業の結果を確認し記録します。

3.30　作業結果のテスト
　システム管理者は作成した手順に基づいてテストを実施します。テスト結果が求める結果と異なる場合は、差異の原因を調査し問題を解決します。必要であれば、作成した復帰手順に基づく処理をします。変更結果の本番適用には、テスト結果の記録を責任者に示して、承認を得る必要（すべての変更作業）があります。

3.40　変更の本番適用
　IT運用のシステム管理者（特殊のアクセス権限を保有）は作成した手順に基づいて、変更結果をテスト環境から本番環境に移行します。責任者は移行結果を確認し承認します。

3.50　完了の報告
　システム責任者は変更の結果が本番に適用されたことを確認し、変更要求元（システムオーナー部門）の担当者および責任者に要求された変更の完了（適用年月日も含む）を連絡します。（問題報告書の番号が記入されているものは、インシデント管理および問題管理プロセスにより発生した変更要求です。）

　変更申請書の新たな記入内容は次のとおりです。

　 ＊　変更ドキュメントと、その保管場所
　 ＊　変更に要した作業工数（実績）
　 ＊　保守実施担当者／システム管理者のサインと実施完了日
　 ＊　同上、責任者の承認サイン
　 ＊　本番適用者（IT運用のシステム管理者）のサインと適用日
　 ＊　同上、責任者の承認サイン
　 ＊　完了の報告をする者（IT保守、運用部門の責任者）のサイン
　 ＊　同上、報告年月日
　 ＊　官僚の報告を受ける者（システムオーナー部門の責任者）のサイン
　 ＊　同上、承認年月日

《　4.00　マネジメントレビュー　》

当該のプロセス（上図）は、変更管理業務の継続的な改善を促します。当該のプロセスの成否は、IT部門を統括するマネージャーの関わり（役割）の強弱が大きく影響します。「IT運用のインテグリティ（完全性）を損なうリスクを低減する」ことに加えて、前述の「マーケティング機能」を発揮することによって、マネージャーの関わり度合をより高め、継続的な改善のプロセスを確立します。当該の業務プロセスは、次の４つの要素で構成されています。

4.10　計画／実績のデータ収集
　定期的（月末）に管理データを収集します。計画データは、「目標管理システム」より入手します。入手するデータは期初に設定した当該の業務に関わる「課題」と「成果目標の値」です。
　実績データは、処理した「変更申請書」に加えて、「インシデント＆問題管理プロセス」、「アクセス管理プロセス」、「利用者満足度調査」などより入手します。
　「インシデント＆問題管理プロセス」から入手するデータは、前述の＜　成果指標　＞として定義した「変更を起因とするインシデントの発生件数」や、「回復に費やした時間」、「再処理（運用）件数と時間」などです。
　「アクセス管理プロセス」から入手するデータは、前述の《　3.00　変更の実施と本番適用　》の「3.40　変更の本番適用」におけるアクセスログ情報です。
　「利用者満足度調査」から入手するデータは、保守・運用サービスの品質および提供システムの有効性に関わる利用者の満足度（レベル）データです。

4.20　データの分析
　収集したデータを元に、当該業務の管理レベルおよび目標達成度を自己評価し、傾向の分析などから提起される問題の解決策や、次のステージに向けた新たな課題の設定、および実行計画を策定します。

4.30　管理レポートの作成
　上述「4.20データの分析」結果をレポートにまとめます。レポートは次の2種類です。

　 ＊　月単位（期中の実績／進捗状況の報告）
　 ＊　６ケ月単位（期の実績／次期、活動計画の立案）

4.40　マネジメントレビュー
　IT部門を統括するマネージャーは定期的に管理レポートに基づく報告を受けます。レビューは、冒頭に記述の「コントロール目標と成果指標」を中心に、その達成度を評価するものです。

　評価の対象を要約すると

　 ＊　必要な変更が適正に実施され管理されているか
　 ＊　利用部門に対するサービスが維持されているか
　 ＊　提供している適用業務システムは有効に機能しているか
と言うようなことになります。

　そして期末には、期中に提起された問題の解決策と、次のステージに向けた新たな課題の実行計画を審査し、次期の改善活動をキックオフします。

 

　
　次回は、「　重点対応プロセスの参照モデル　《　その3：問題管理プロセス　》　」と題して、当該の活動において選定した「重点対応プロセス（重点的に再構築するプロセス）」の一つ、「問題管理（インシデント管理を含む）プロセス」を参照のモデルとして紹介します。