ITサービスマネージャ 2017年 午後1 問02
問題管理及び変更管理に関する次の記述を読んで、設問1～4に答えよ。
K社は金融機関である。K社の情報システム部では、顧客管理システムを運用しており、社内規程のプロセスに従って問題管理及び変更管理を行っている。ITサービスマネージャは情報システム部のE氏が務めている。
〔K社の問題管理プロセス〕
K社の問題管理プロセスの手順は、表1のとおりである。
問題管理プロセスにおいて決定した解決策が、CIの変更を必要とする場合は、RFCを起票し、変更管理プロセスに従って処理する。K社のRFC管理項目と起票時の記入要領を、表2に示す。
〔K社の変更管理プロセス〕
RFCは、変更管理プロセスの手順に従って処理される。K社の変更管理プロセスの手順（抜粋）は、表3のとおりである。
〔問題管理の現状〕
情報システム部では、問題の記録を問題管理データベース（以下、問題管理DBという）で管理しており、インシデント発生ケースについての問題の解決状況を示す指標である問題解決率を問題管理会議で毎週確認している。問題解決率は問題の“優先度”ごとに次の式で求める。
問題解決率＝（問題の総件数−終了していない問題の件数）÷問題の総件数
問題管理会議は実務担当者で構成され、E氏が議長を務める。E氏は、問題管理会議の決定事項を情報システム部の部長に報告する。
ある日、E氏は情報システム部の部長から““優先度”が“低”の問題について、全ての問題を一律に管理するのではなく、早期に解決できる問題又は早期に解決すべき問題が、どれだけ解決できているかを週次で確認したい。問題解決率の算出方法を工夫するように。”と指示された。そこでE氏は、部長の指示に従って、問題解決率の算出方法を工夫して、dを問題解決率の計算対象から除外する運用を始めることにした。
なお、現在、問題管理DBに登録されているインシデント発生ケースの問題で、かつ、“優先度”が“低”の問題は100件である。そのうち、終了していない問題の状況は、表4のとおりであった。
〔月次集計プログラムの問題とその対応〕
顧客管理システムでは、開発元のQ社から提供されている月次集計プログラム（以下、P1という）を使用し、毎月20日の夜間バッチジョブで顧客別の月間取引集計処理を行っている。夜間バッチジョブはオンライン処理開始までに終了する必要がある。
本年10月10日にQ社から、顧客管理システムの運用を担当している情報システム部のG氏に対して、“P1の処理に問題があり、特定の条件において集計データの一部が後続の処理に正しく引き継がれないという不具合が発見された。”という連絡があった。
(1) Q社の対応
Q社は、問題が含まれるP1の版についての情報と、対策済みのP1の最新版を既に自社のWebサイトに公開していて、速やかな対応を促していた。また、Q社のWebサイトには、“最新版では対策ロジックの追加に伴い、従来の版よりも処理時間が長くなる場合がある。”という注意書きが掲載されていた。
(2) K社の対応
G氏は、CMDBを検索して、P1は顧客管理システムだけで使用していること、及び現在K社で使用しているP1が問題のある版であることを確認した。顧客管理システムではQ社が指摘する問題によるインシデントはこれまで発生していなかった。
① 変更計画の立案
G氏は、Q社が推奨しているように速やかに対応を行う必要があると判断し、変更管理プロセスに従って、10月20日の集計処理までに対応を完了する変更計画を立てることにした。
G氏が考えた変更計画の概要は、次のとおりである。
・10月19日までにP1を最新版に変更する。
・対策済みのP1の最新版を稼働環境に展開する前に、K社のテスト環境でテストデータを用いて機能の確認テストを行う。
・確認テストは、準備作業、テスト作業、確認作業で構成する。RFCの受入れが決定されてから速やかに確認テストの準備作業を開始する。準備作業に2日、テスト作業及び確認作業に3日の合計5日の日数が必要である。確認テストは、土曜日と日曜日も作業する。
② P1の最新版への変更
G氏はP1を最新版に変更するRFCの起票に取り掛かり、表2の記入要領に従って次のようにRFC管理項目を記入し、10月11日にRFCを提起した。
・RFC管理項目の（イ）“優先度”については“緊急”と記入した。
・RFC管理項目の“リスク”についてはP1の最新版の機能の確認テストを実施し、処理結果が正しいかどうかを確認するので、“特になし”とした。
E氏は、G氏から提出されたRFCの内容を確認し、G氏に対して“事前に実施する確認テストは、テスト環境でテストデータを用いた機能の確認テストである。稼働環境とは機器の性能及び処理するデータ量が異なるので、（ウ）RFC管理項目の“リスク”については懸念される内容を記載すべきである。”と指摘した。
設問1：〔K社の問題管理プロセス〕について、(1)、(2)に答えよ。
設問1（1）
問題文を見る表1中のaに入れる適切な字句を、10字以内で答えよ。
模範解答
根本原因
解説
解答の導き方
-
a は、問題管理プロセスの「解決」にある「調査と診断」と「既知の誤りの文書化」の両方に使われています。まず、それぞれの記述から、空欄に入る内容の条件を確認します。
-
「調査と診断」では、a が特定され、さらに問題の解決方法が特定された時点で、問題の診断を完了するとあります。つまり、空欄には、問題の原因を明らかにする対象が入ります。
-
「既知の誤りの文書化」では、a が特定されている問題を既知の誤りとして記録するとあります。この記述も、問題の解決方法そのものではなく、問題を引き起こしている原因を特定することを示しています。
-
問題管理では、インシデントの症状だけでなく、その背後にある根本的な原因を調査します。したがって、a に入るのは「根本原因」です。
誤りやすいポイント
- 「解決方法」と混同しないようにします。本文では、原因の特定と解決方法の特定を別々に記述しています。
- 「回避策」も空欄には入りません。回避策は、既知の誤りとして記録するもう一つの条件として、原因の特定とは別に示されています。
- インシデントの発生状況や症状ではなく、問題の根本にある原因を問われています。
FAQ
Q: 原因が特定できていなくても、既知の誤りとして記録できますか？
A: 本文では、原因が特定されている場合のほか、回避策によってサービスへの影響を低減又は除去する方法がある場合も、既知の誤りとして記録するとしています。
A: 本文では、原因が特定されている場合のほか、回避策によってサービスへの影響を低減又は除去する方法がある場合も、既知の誤りとして記録するとしています。
Q: なぜ「解決方法」ではなく、原因を表す語が入るのですか？
A: 「調査と診断」では、原因と解決方法の両方が特定された時点で診断を完了すると記されています。したがって、解決方法とは別に特定する原因が空欄に入ります。
A: 「調査と診断」では、原因と解決方法の両方が特定された時点で診断を完了すると記されています。したがって、解決方法とは別に特定する原因が空欄に入ります。
関連キーワード: 問題管理、根本原因、既知の誤り、回避策、インシデント
設問1（2）
問題文を見る表2中のbに入れる適切な字句を、K社の変更管理プロセスの手順を参考にして10字以内で答えよ。
模範解答
・サービスの要求事項
・変更の理由
解説
解答の導き方
表3では、変更決定者が「リスク、サービス及び顧客への潜在的影響、サービスの要求事項、事業利益、技術的実現可能性並びに財務的な影響」を考慮するとあります。このうち、リスク、影響、事業利益、技術的実現可能性、財務的な影響は、表2の管理項目にすでに対応する項目があります。一方、「サービスの要求事項」に対応する項目は、表2に見当たりません。
したがって、空欄には、変更がサービスのどの要求事項に関係するのかを記録する項目が入ると考えられます。模範解答にある「サービスの要求事項」は、表3の評価内容と直接対応します。また、変更がなぜ必要なのかを記録する「変更の理由」も、変更の必要性を判断するための情報として適切です。
誤りやすいポイント
- 表2の「事業利益」と、変更を行う必要性や理由を混同しないようにします。事業利益は変更によって得られる利益であり、変更が必要になった理由とは別の観点です。
- 表2には「サービス及び顧客への潜在的影響」がありますが、これは変更を実施しない場合の影響です。「サービスの要求事項」と同じ意味ではありません。
- 表3にある評価項目を見落とし、表2の既存項目と重複する内容を空欄に入れないようにします。
FAQ
Q: 「サービスの要求事項」と「変更の理由」は、両方を記入するという意味ですか？
A: いいえ。この設問の空欄に対する解答として、どちらかの表現が示されています。
A: いいえ。この設問の空欄に対する解答として、どちらかの表現が示されています。
Q: 「サービス及び顧客への潜在的影響」では、なぜ代用できないのですか？
A: 表2では、変更を実施しない場合にサービスや顧客へ及ぶ影響を記入します。一方、サービスの要求事項は、変更の受入れを判断するときに確認する要求内容です。
A: 表2では、変更を実施しない場合にサービスや顧客へ及ぶ影響を記入します。一方、サービスの要求事項は、変更の受入れを判断するときに確認する要求内容です。
Q: 変更の理由には、どのような内容を記録しますか？
A: 変更を求める背景や、変更が必要となった事情など、RFCを提起する理由を記録します。
A: 変更を求める背景や、変更が必要となった事情など、RFCを提起する理由を記録します。
関連キーワード: RFC、変更管理、変更要求、サービス要求事項、事業利益
設問2：〔K社の変更管理プロセス〕について、(1)、(2)に答えよ。
設問2（1）
問題文を見る表3中の下線（ア）において、開催を通知されたCAB要員が開催日時にCABに参加できない場合がある。このような場合にCAB要員がとるべき行動を、40字以内で述べよ。
模範解答
・RFCの内容を事前に確認し、リスクアセスメントを行い、結果をCABに提出する。
・代理者をCAB要員として登録し、代理者をCABに参加させる。
解説
解答の導き方
設問は、RFCの内容を事前に送付されたCAB要員が、開催日時に参加できない場合の行動を問うています。欠席しても、RFCの影響評価に関するCABの助言が得られるようにするにはどうすればよいかを考えます。
表3では、CABは「変更の影響について助言する」とされています。また、変更決定者は、CAB要員による評価を考慮してRFCの受入れを決定します。したがって、CAB要員が欠席して評価が得られないままにならないよう、欠席者自身が事前にRFCを確認してリスクアセスメントを行い、その結果をCABに提出する方法があります。
別の方法として、CABの評価に必要な要員を確保するため、代理者をCAB要員として登録し、その代理者に参加してもらうこともできます。表3には、CAB要員は影響の範囲に応じて選定され、登録されるとあります。そのため、代理者を参加させる場合も、CAB要員として登録しておくことがポイントです。
誤りやすいポイント
- 欠席することだけを伝えるのでは、CABによる評価を補えません。事前に評価結果を提出するか、代理者に参加してもらう必要があります。
- RFCの内容を事前に確認するだけで終わらず、リスクアセスメントの結果をCABに提出するところまで示します。
- 代理者を参加させる場合は、単に同僚に出席を頼むのではなく、代理者をCAB要員として登録する点が重要です。
FAQ
Q: 欠席するCAB要員が事前に行うのは、RFCの内容確認だけですか？
A: 内容を確認したうえでリスクアセスメントを行い、その結果をCABに提出します。
A: 内容を確認したうえでリスクアセスメントを行い、その結果をCABに提出します。
Q: 代理者は、登録されていなくても参加できますか？
A: 表3ではCAB要員を選定して登録するとされています。模範解答では、代理者をCAB要員として登録してから参加させる方法が示されています。
A: 表3ではCAB要員を選定して登録するとされています。模範解答では、代理者をCAB要員として登録してから参加させる方法が示されています。
Q: どちらの対応を選べばよいですか？
A: 欠席者が事前に評価結果を提出する方法と、登録した代理者に参加してもらう方法があります。いずれも、CABの評価を確保するための対応です。
A: 欠席者が事前に評価結果を提出する方法と、登録した代理者に参加してもらう方法があります。いずれも、CABの評価を確保するための対応です。
関連キーワード: 変更管理、変更諮問委員会、リスクアセスメント、RFC、代理者
設問2（2）
問題文を見る表3中のcには、変更の展開が成功した後に、構成管理プロセスで実施する内容が入る。この内容を15字以内で答えよ。
模範解答
CMDBの記録を更新
解説
解答の導き方
-
表3の手順(4)には、承認されたRFCをリリース及び展開管理プロセスに提供し、「変更の展開が成功した後に、cする」とあります。したがって、変更の展開が成功した後に行う処理が問われています。
-
変更によって構成品目（CI）の状態や属性が変わるため、構成管理の記録も実際の状態に合わせる必要があります。表2には、CIの属性がCMDBに記録されているとあります。このことから、展開後にCMDBの記録を更新する処理が適切です。
-
以上より、cには「CMDBの記録を更新」が入ります。変更が成功したことを確認してから記録を更新する点が重要です。
誤りやすいポイント
- 変更の計画や承認の時点でCMDBを更新すると考えないようにします。変更後の実際の構成を記録するため、展開の成功後に更新します。
- RFCの記録を更新することと、構成管理プロセスでCMDBの記録を更新することを混同しないようにします。
- 変更の実施そのものではなく、変更後の構成情報を管理記録に反映する処理が問われています。
FAQ
Q: なぜ変更の展開が成功した後にCMDBを更新するのですか？
A: 展開が成功して初めて、CIの実際の状態が変更後の状態になったと判断できるためです。
A: 展開が成功して初めて、CIの実際の状態が変更後の状態になったと判断できるためです。
Q: CMDBには何を記録しますか？
A: CIの属性など、構成品目に関する情報を記録します。変更後は、実際の構成と記録が一致するように更新します。
A: CIの属性など、構成品目に関する情報を記録します。変更後は、実際の構成と記録が一致するように更新します。
関連キーワード: 構成管理、CMDB、構成品目、変更管理、変更要求
設問3：
問題文を見る〔問題管理の現状〕について、dに入れる適切な内容を、表4中の字句を用いて30字以内で答えよ。
模範解答
原因が特定できないで、かつ、再発インシデントなしの問題
解説
解答の導き方
-
今回の工夫で測りたいのは、“優先度”が“低”の問題全体の解決状況ではなく、「早期に解決できる問題又は早期に解決すべき問題」がどれだけ解決できているかです。したがって、早期解決の対象とはいえない問題を計算対象から外します。
-
表4では、終了していない問題を「原因」が「特定できた」か「特定できない」か、また「再発インシデント」が「あり」か「なし」かで分けています。この二つの観点から、早期に対応する必要性を考えます。
-
「原因」が「特定できた」問題は、原因に対する解決策を検討できるため、早期に解決できる可能性があります。また、原因が「特定できない」場合でも、「再発インシデント」が「あり」なら、同じ事象が再び起きているため、早期に原因調査や対応を行う必要があります。
-
一方、「原因」が「特定できない」うえに「再発インシデント」が「なし」の問題は、原因の特定ができておらず、再発によって早期対応を求められている状況でもありません。この分類の問題を計算対象から外すと、部長が求める「早期に解決できる問題又は早期に解決すべき問題」の解決状況を確認できます。
誤りやすいポイント
- 「再発インシデント」が「なし」の問題を、すべて除外するのは誤りです。「原因」が「特定できた」問題は、再発がなくても早期に解決できる可能性があります。
- 「原因」が「特定できない」問題を、すべて除外するのも誤りです。「再発インシデント」が「あり」の場合は、繰り返し発生しているため早期対応の対象です。
- 「原因」と「再発インシデント」の片方だけで判断せず、表4の二つの項目を組み合わせて対象を選びます。
FAQ
Q: 原因が特定できない問題は、なぜ一律に除外しないのですか。
A: 再発インシデントがある問題は、同じ事象が再び発生しているため、早期に原因調査や対応を行うべきだからです。
A: 再発インシデントがある問題は、同じ事象が再び発生しているため、早期に原因調査や対応を行うべきだからです。
Q: 原因が特定できた問題は、再発インシデントがなくても計算対象に残すのですか。
A: はい。原因が分かっていれば解決策を検討しやすく、早期に解決できる問題に当たるためです。
A: はい。原因が分かっていれば解決策を検討しやすく、早期に解決できる問題に当たるためです。
Q: 除外するのは、未終了の問題だけですか。
A: 計算対象から除外する問題の分類を答える設問です。表4に示された未終了の問題だけに限定するのではなく、該当する分類の問題を計算対象から外します。
A: 計算対象から除外する問題の分類を答える設問です。表4に示された未終了の問題だけに限定するのではなく、該当する分類の問題を計算対象から外します。
関連キーワード: 問題管理、問題解決率、根本原因、再発インシデント、優先度、指標設計
設問4：〔月次集計プログラムの問題とその対応〕について、(1)、(2)に答えよ。
設問4（1）
問題文を見る本文中の下線（イ）について、RFC管理項目の“優先度”を“緊急”とした理由を、40字以内で述べよ。
模範解答
速やかにCABを開催し、確認テストに5日の日数を確保する必要があるから
解説
解答の導き方
-
変更は「10月19日までにP1を最新版に変更する」計画です。これは、10月20日の集計処理に間に合わせるためです。
-
RFCは10月11日に提起されています。表3では、CABは毎週火曜日に定期開催され、本年10月の開催日は10月17日などとされています。通常の開催を待つと、RFCの評価と受入れ決定が10月17日になります。
-
しかし、受入れ決定後には確認テストが必要です。準備作業に2日、テスト作業と確認作業に3日かかり、合計5日です。10月17日の定例開催を待ってからでは、10月19日までにこの確認テストを終えて変更する時間が足りません。
-
RFCの優先度を「緊急」とすれば、表3の手順に従い、RFCの受付から2日以内にCABを臨時開催できます。定例開催を待たずに受入れ決定を早め、5日間の確認テストを確保するために、優先度を「緊急」としたと判断できます。
誤りやすいポイント
- 「緊急」とする理由を、問題の重大さだけで説明しないようにします。この設問では、変更期限までにCABの評価と5日間の確認テストを行えるかがポイントです。
- 土曜日と日曜日も確認テストを行う計画ですが、必要な作業日数がなくなるわけではありません。定例開催を待つと時間が不足する点に注意します。
- 変更の「優先度」と「変更種別」は別の項目です。ここで問われているのは、RFC管理項目の「優先度」を「緊急」とした理由です。
FAQ
Q: なぜ定例CABでは間に合わないのですか？
A: RFCを10月11日に提起しても、次の定例開催は10月17日です。そこから受入れ決定後の5日間の確認テストを行うと、10月19日までの変更完了が困難になるためです。
A: RFCを10月11日に提起しても、次の定例開催は10月17日です。そこから受入れ決定後の5日間の確認テストを行うと、10月19日までの変更完了が困難になるためです。
Q: 「緊急」にすれば確認テストを省略できますか？
A: いいえ。本文の計画では、確認テストに5日必要です。「緊急」とすることでCABの臨時開催を可能にし、テストを含む変更作業の時間を確保します。
A: いいえ。本文の計画では、確認テストに5日必要です。「緊急」とすることでCABの臨時開催を可能にし、テストを含む変更作業の時間を確保します。
Q: 土曜日と日曜日にテストを行えることは、優先度の判断に関係しますか？
A: 関係しますが、週末も作業できるからといって5日間の作業が不要になるわけではありません。定例CABを待つと、週末を含めても期限までの余裕が足りないことが判断の要点です。
A: 関係しますが、週末も作業できるからといって5日間の作業が不要になるわけではありません。定例CABを待つと、週末を含めても期限までの余裕が足りないことが判断の要点です。
関連キーワード: 変更管理、変更要求、変更諮問委員会、優先度、確認テスト
設問4（2）
問題文を見る本文中の下線（ウ）について、E氏が懸念した“変更を実施することによって発生する可能性があるリスク”を、30字以内で述べよ。
模範解答
夜間バッチジョブがオンライン処理開始までに終了しない。
解説
解答の導き方
設問で問われているのは、変更を実施することで発生する可能性のあるリスクです。変更後の機能に不具合があるかどうかだけでなく、変更によって運用にどのような影響が起こり得るかを考えます。
まず、Q社のWebサイトには、最新版では「従来の版よりも処理時間が長くなる場合がある」とあります。したがって、最新版への変更後に処理時間が増える可能性があります。
一方、変更計画にある確認テストは、テスト環境でテストデータを使って機能を確認するものです。E氏が指摘したように、テスト環境と稼働環境では機器の性能や処理するデータ量が異なります。そのため、機能が正しく動くことを確認できても、稼働環境での処理時間が十分短いことまでは確認できません。
さらに、顧客別の月間取引集計処理を行う夜間バッチジョブは、オンライン処理開始までに終了する必要があります。処理時間が延びた結果、この期限を過ぎる可能性があることが、変更に伴うリスクです。
誤りやすいポイント
- 変更前から存在する問題である「集計データの一部が後続の処理に正しく引き継がれない」ことを、今回問われているリスクとして答えないようにします。
- 「処理時間が長くなる可能性がある」だけでは、運用上どのような影響があるかが示せていません。夜間バッチジョブの終了期限との関係まで考えます。
- 機能の確認テストを実施するからリスクはない、と判断しないようにします。テスト環境と稼働環境の条件が異なるため、処理時間に関する懸念は残ります。
FAQ
Q: なぜ、処理時間が延びること自体ではなく、夜間バッチジョブへの影響を答えるのですか？
A: 問われているのは変更によって発生する可能性のあるリスクです。処理時間の延長が、オンライン処理開始までに終了するという運用上の要件にどう影響するかまで述べる必要があります。
A: 問われているのは変更によって発生する可能性のあるリスクです。処理時間の延長が、オンライン処理開始までに終了するという運用上の要件にどう影響するかまで述べる必要があります。
Q: 機能の確認テストでは、今回のリスクを確認できないのですか？
A: 機能が正しいかは確認できますが、テスト環境と稼働環境で機器の性能やデータ量が異なるため、稼働環境で期限内に処理が終わるかまでは確認できない可能性があります。
A: 機能が正しいかは確認できますが、テスト環境と稼働環境で機器の性能やデータ量が異なるため、稼働環境で期限内に処理が終わるかまでは確認できない可能性があります。
Q: 変更しない場合の影響も、今回のリスクに含めますか？
A: 今回は変更を実施することによって発生する可能性のあるリスクが問われています。変更しない場合の影響とは区別して考えます。
A: 今回は変更を実施することによって発生する可能性のあるリスクが問われています。変更しない場合の影響とは区別して考えます。
関連キーワード: リスク評価、性能試験、バッチ処理、処理時間、変更管理
