H29　SM　PM1-1　問題管理及び変更管理

概要図

　K社は金融機関である。K社の情報システム部では、顧客管理システムを運用しており、社内規定のプロセスに従って問題管理及び変更管理を行っている。ITサービスマネージャは情報システム部のE氏が務めている。

K社の問題管理プロセス

　K社の問題管理プロセスの手順は以下の通りである。
（1）識別：Aインシデントの未知の根本原因の特定、B根本的な問題を明らかにするインシデントの分析C供給者（ソフトウェア開発元など）からの問題の通知　
（2）記録：日時など関連する問題の詳細を記録する。また、手順（1）識別がAの場合（以下、インシデント発生ケース）は、問題の記録の発端となったインシデントの相互参照などを記録する。
（3）優先度の割当て：関連するインシデントがある場合は、関連するインシデントの緊急度及び影響に応じて解決の優先度を割り当てる。関連するインシデントがない場合は、独自に解決の優先度を設定する。優先度は高、又は低のいずれかを割り当てる。
（4）分類：インシデントを管理するプロセスで使用しているものと同一の分類基準を利用して問題を分類する。
（5）記録の更新：問題の追跡ができるように、問題の進捗状況を捉え、記録を更新する。
（6）段階的取り扱い：必要な場合は、該当する当事者に対して段階的取り扱いを行う。
（7）解決：①問題を調査し、診断する。（問1：根本原因）が特定され、問題の解決方法が特定された時点で問題の診断を完了する。
②既知の誤りの文書化：根本原因が特定されているか、若しくは回避策によってサービスの影響を低減又は除去する方法がある問題を既知の誤りとして記録する。
③問題の解決：特定された解決方法を適用する。恒久的な解決方法が構成品目（以下、CIという）の変更を必要とする場合は、変更管理プロセスに変更要求(以下、RFCという)を提起することによって解決する。
（8）終了：解決策の詳細を記録する。全ての処置の完了後、問題解決の有効性を確認する。
　問題管理プロセスにおいて決定した解決策が、CIの変更を必要とする場合は、RFCを起票し、変更管理プロセスに従って処理する。K社のRFC管理項目と起票時の記入要領を以下に示す。

（問1-2：サービスの要求事項 or 変更の理由）

K社の変更管理プロセス

　RFCは、変更管理プロセスの手順に従って処理される。K社の変更管理プロセスの手順は、以下のとおりです。
（1）RFCの記録と分類：変更管理マネージャがRFCを受け付け、RFCの登録・分類を行う。変更管理マネージャは、E氏が務める。
（2）RFCの評価：指名された代表で組織する変更諮問委員会（以下、CABという）が、変更の影響について助言する。CABの詳細は次の通りである。CABの構成メンバ（以下、CAB要員という）は、サービス及び事業環境の範囲に応じて選定され、登録される。情報システム部の場合は、技術的専門分野の要員からＣＡＢ要員の候補者を選定する。CABは毎週火曜日に定期的に開催するが、RFCの優先度が緊急の場合はRFCの受付けから二日以内に臨時開催する。CABの議長は、E氏が務める。E氏はCAB要員にRFCの内容を事前に送付し、CABの開催を通知する。また、CABに参加できない場合、CAB要員は（問2-1：RFCの内容を事前に確認し、リスクアセスメントを行い、結果をCABに提出する or 代理者をCAB要員として登録し、代理者をCABに参加させる）
（3）RFCの受入れ決定：RFCの受入れ及び承認に関する決定権限をもつ変更決定者を定める。変更種別が重要または重大の変更決定は情報システム部の部長が行い、それ以外の変更種別の変更決定はE氏が行う。変更決定者の役割は次の通りである。変更決定者はCABに出席し、CAB要員による評価を考慮して、RFCの受入れを決定する。意思決定では、リスク、サービス及び顧客への存在的影響、サービスの要求事項、事業利益、技術的実現可能性並びに財務的な影響を考慮する。
（4）変更の実施：承認されたRFCをリリース及び展開管理プロセスに提供する。変更の展開が成功した後に、（問2-2：CMDBの記録を更新する）

問題管理の現状

　情報システム部では、問題の記録を問題管理データベース（以下、問題管理DBという）を管理しており、インシデント発生ケースについての問題
の解決状況を示す指標である問題解決率を問題管理会議で毎週確認している。問題解決率は問題の優先度ごとに次の式で求める。
　問題の解決率＝（問題の総件数-終了していない問題の件数）÷問題の総件数
　問題管理会議は実務担当者で構成され、E氏が議長を務める。E氏は、問題管理会議の決定事項を情報システム部の部長に報告する。
　ある日、E氏は情報システム部の部長から優先度が低の問題について、全ての問題を一律に管理するのではなく、早期に解決できる問題又は早期に課解決すべき問題が、どれだけ解決できているかを週次で確認したい。問題解決方法の算出方法を工夫するように、と指示を受けた。そこでE氏は、部長の指示に従って、問題解決率の算出方法を工夫して（以下の表を参照して問2-2：原因が特定できないで、かつ再発インシデントがなしの問題）を問題解決率から除外する運用を始めることにした。
　なお、現在、問題管理DBに登録されているインシデント発生ケースの問題で、かつ優先度が低の問題は100件である。そのうち終了していない問題の現状は以下のとおりである。

月次集計プログラムの問題とその対応

　顧客管理システムでは、開発元のQ社から提供されている月次集計プログラム（以下、P1という）を使用し、毎月20日の夜間バッチジョブで顧客別の月間取引集計処理を行っている。夜間バッチジョブはオンライン処理開始までに終了必要がある。
　本年10/10にQ社から、顧客管理システムの運用を担当している情報システム部のG氏に対して「P1の処理に問題があり、特定の条件において集計データの一部が後続の処理に正しく引き継がれないという不具合が発見された」という連絡があった。
（1）Q社の対応
　Q社は、問題が含まれるP1の版についての情報と、対策済のP1の最新版
を既に自社のWEBサイトに公開していて、速やかな対応を促していた。また、Q社のWEBサイトには「最新版の対策ロジックの追加に伴い、従来の版よりも処理時間が長くなる場合がある」という注意書きが掲載されていた。
　G氏は、CMDBを検索して、Ｐ1は顧客管理システムだけで使用していること、及び現在Ｋ社で使用しているP1が問題の版であることを確認した。顧客管理システムではQ社が指摘する問題によるインシデントはこれまで発生していなかった。
①変更計画の立案
　G氏は、Q社が推奨しているように速やかに対応を行う必要があると判断し、変更管理プロセスに従って、10/20の集計処理までに対応を完了する変更計画を立てることにした。
　G氏が考えた変更計画の概要は、次のとおりである。
・10/19までにP1を最新版にする。
・対策済のP1の最新版を稼働環境に展開する前に、K社のテスト環境でテストデータを用いて機能の確認テストを行う。
・確認テストは、準備作業、テスト作業、確認作業で構成する。RFCの受入れが決定されてから速やかに確認テストの準備作業を開始する。準備作業に2日、テスト作業及び確認作業に3日の合計5日の日数が必要である。確認テストは、土曜日と日曜日にも作業する。
②P1の最近版への変更
　G氏はP1を最新版に変更するRFCの起票に取り掛かり、記入要綱に従って次のようにRFC管理項目を記入し、10/11にRFCを提起した。
・RFC管理項目の優先度について（速やかにCABを開催し、確認テストに5日の日数を確保する必要があるから）緊急と記入した。
・RFCの管理項目のリスクについてはP1の最近版の機能の確認テストを実施、処理結果が正しいかどうかを確認するので、特になしとした。
　E氏は、G氏から提出されたRFCの内容を確認し、G氏に対して
「事前に実施する確認テストは、テスト環境でテストデータを用いた機能の確認テストである。稼働環境とは機器の性能及び処理するデータ量が異なるので、RFC管理項目のリスクについては懸念される内容（問4-2：夜間バッチジョブがオンライン処理開始までに終了しない）を記載すべきである」と指摘した。