SM-H21PM2Q1変更管理プロセスの確実な実施について
あんまり出来がよくない。もっと演習を重ねないと。
小難しく書く必要はないはずなので、もう少し具体的な書き方にしたほうがいいのかな。
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
■サービス又はシステムの名称
生命保険サービス業のイントラネットシステム
■対象とする企業・期間
?企業・機関などの種類・業種
7. サービス業
?企業・機関などの規模
4.1,001 〜 5,000 人
?対象業務の領域
3. 営業・販売 4. 生産 5. 物流
■システムの構成
?システムの形態と規模
1. クライアントサーバシステム ｱ. （サーバ約 30台、クライアント約 1000台）
?ネットワークの範囲
2. 同一企業・同一機関の複数事業所間
?システムの利用者数
5. 301 人〜 1,000 人
■システム運用の規模・形態など
?運用管理及びオペレーション要員数
1.（約 10人）
?運用対象の区分
1.他社システムの運用受託
?運用開始年月
1.（2001年 4月）
■ITサービスマネジメントにおけるあなたの立場
?あなたが所属する企業・機関など
1. ソフトウェア業・情報処理・提供サービス業など
?あなたの担当業務
1. システム管理 2. システム運用
?あなたの役割
1. 部門マネージャ
?あなたの担当期間（2005年 5月）〜（ 年 月）
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
（設問ア）800字以内
１．ＩＴサービスの概要と変更管理プロセス
1.1.私が携わったＩＴサービスの概要
私が携わったＩＴサービスは、生命保険サービスを行うＡ社のイントラネットシステム運用である。Ａ社は全国に10ヶ所の支社を展開し、約1000名の従業員がメールやインターネット、グループウェアなどのサブシステムを利用している。
私はＡ社の情報システム子会社に勤務するＩＴサービスマネージャで、このイントラネットシステムに関する利用者からの変更要求対応、機器の監視、故障対応などの業務を管理している
このシステムは、サーバ約30台、ネットワーク機器約150台により構成され、利用者からの変更要求によりサーバへのアカウント追加やファイアウォールのＩＰアドレス変更などの対応が発生する。
1.2.変更管理プロセス
このシステムに対する変更管理プロセスとして、私の部署では以下のような変更管理ルールを運用している。
?担当者が変更要求を受け付け
?変更内容のレビューによる評価
?変更審査会による変更の商人
?変更状況の管理
上記のような流れで、変更が行われる。?では担当者が関係者を集めてレビュー会を開催し、?では変更管理マネージャにより週に一度、その期間の変更要求を集中的に合議する形で開催される。その後、変更が適切に行われているかどうかを事務局が管理するという流れである。
Ａ社のイントラネットシステムでは利用者が事業を行ううえで重要なコミュニケーション手段となっており、変更の失敗による影響は大きい。そのため、私にとって変更管理プロセスを確実に実施することは重要な使命である。
（設問イ）800字以上1600字以内
２．変更管理プロセスで発生した事象と改善内容
2.1.変更管理プロセスで発生した事象
私がこの業務を担当した当初、変更範囲の特定が不十分なことによるトラブルが多発していた。
具体的には、利用者の部署変更によりファイアウォールの設定を変更したが、サーバ側の設定変更が行われていないためにシステムを利用することができない、などである。
利用者からの変更要求に確実な対応を行えている状況とは言えず、必要以上に時間がかかったり、利用者がビジネスを行う支障になり、クレームになったりしていた。
上記にあげた例では大きな影響は出ていないが、場合によっては事業に重大な影響を及ぼしてしまうことも考えられる。
私は変更管理プロセスを確実に実施するため、プロセスの問題を特定し、改善する必要があると考えた。
2.2.変更管理プロセスの問題点
トラブルの原因は、変更範囲の特定が不十分なことである。この原因の対策としては、変更管理プロセスでは?変更内容のレビューが不十分なためと考えた。
?変更内容のレビューにおいては、担当者の判断で参加する関係者が決定されていたため、関連するサーバやサブシステムの有識者が十分なレビューを行えていない場合があった。
担当者がシステムの全てを理解していれば問題はないが、システムの規模を考えると、全ての担当者がシステムの全てを理解することは難しい。複数のサブシステムにそれぞれ特化した知識を身につけているのが実情である。
2.3.再発を防止するための改善策
そこで私は、変更内容のレビューについてのルールを改定し、変更範囲が十分かどうかの事前チェックを行うことを必須とした。
従来のレビュー会は、担当者が用意した構成図に変更箇所を表示しレビューを行っていたが、改善後は変更の事前チェックリストを用いて、変更が必要な理由と対象範囲が適切か、サブシステムへの影響は考慮されているかどうかのレビューを行う。
更に、変更審査会を行う際に、このチェックリストを審査対象とし、適切なレビューを経て変更範囲が特定されているかどうかを審査することとした。
この施策により、担当者が十分なシステム知識を持っていなくても、ある程度の特定が行えるようになり、また変更の審査においても効率的に、明確なベースラインを持って判断できるようになる。
この改善により、変更範囲が不十分なことによるトラブルは減り、変更要求の対応は安定化した。
（設問ウ）600字以上1200字以内
３．変更管理プロセスの確実な実施
3.1.定期的な確認の方策
変更管理のプロセスは、ルールを決めるだけではなく、そのプロセスが適切に運用されているかどうかを見極め徹底していくことも重要である。
このときに行った改善策も、適切に運用されなくてはトラブルの再発防止につながらず、ＩＴサービスの健全な運用にはつながらない。
そのため、担当者が変更範囲を正しく特定できているかどうか、レビュー時の関連システム数と変更審査会での追加レビューの指摘数をＫＰＩとして定め、モニタリングを行うことにした。
この施策により、当初は変更審査会での指摘が多かったが、次第にレビュー会で十分なレビューが行えるようになっていったことが確認できた。これは担当者のシステム知識が向上したこと、チェックリストを用意したことによりセルフチェックが行えるようになり、事前の準備が適切に行えるようになったことの成果だと評価している。
3.2.今後の課題
現時点での改善は、チェックの徹底によるトラブルの防止までであるが、今後は、変更方法の定型化、マニュアル化による更なる品質の向上を図りたいと考えている。
日々発生する変更要求をそれぞれの担当者がゼロからの対応を行うのではなく、変更方法や影響範囲をある程度テンプレート化しておき、必要に応じてカスタマイズすることで、変更要求へ効率よく対応し、複雑化していくシステムの運用を確実に実施していき、利用者が安心して利用できるＩＴサービスを目指していきたいと考えている。
−以上−
