平成29年度秋期 ITサービスマネージャ 午後Ⅰ 問2

判断に用いる前提を確かめる

検討を始めるときは、判断の根拠にする前提の範囲を確かめましょう。与えられた条件と、自分の経験から補った想定が混ざっていないかを意識すると、知識を当てはめる前の整理がしやすくなります。

この問題で問われていること

この話題を考える際は、何を前提として判断しようとしているかに注目してください。判断に関係しそうな情報でも、その場で与えられた条件に基づくものか、自分が追加した想定なのかを区別して整理しましょう。

視点

普段の経験から思い浮かぶ状況が、今回の判断にも当てはまるとは限りません。判断の根拠を整理するときは、与えられた条件に含まれる前提と、自分で補った想定を区別しましょう。

確認ポイント

• 判断に用いる前提を明確にしたか
• 与えられた条件と自分の想定を区別したか
• 明示されていない条件を補っていないか

解説

問題管理、変更管理、構成管理の連携を、K社の規程と変更事例から読み取る問題です。原因調査、RFCの評価情報、問題解決率の対象、変更期限から逆算した緊急性、オンライン処理への影響を結び付けて説明することが要点です。

問題の全体像

金融機関のK社は、顧客管理システムの問題管理と変更管理を社内規程に従って行っています。前半では原因調査、RFCの記入項目、CABによる評価、展開後の構成情報更新を扱い、後半では問題解決率の見直しと月次集計プログラムP1の変更を扱います。公式の出題趣旨では、問題解決、RFCの受入れ、意思決定での考慮点、構成管理との連携を通じた実務能力が問われています。各プロセスの役割を理解し、事例の期限やサービスへの影響に結び付けることが重要です。

設問1(1)

表1の手順(7)では、空欄aと解決方法が特定された時点で診断を完了するとされています。また、同じaが特定されている問題などを「既知の誤り」として記録します。表1の識別手順にも「インシデントの未知の根本原因の検知」とあるので、調査で明らかにする対象は問題を引き起こした根本原因です。公式解答例では「根本原因」とされています。この4字で、二つの空欄に共通する内容を10字以内で表せます。

設問1(2)

表2だけで空欄bを推測せず、指定された表3の手順(3)を確認します。変更の意思決定では、リスク、サービス及び顧客への潜在的影響、サービスの要求事項、事業利益、技術的実現可能性、財務的な影響を考慮します。このうち、表2には「サービスの要求事項」に対応する項目が見当たりません。公式解答例では「サービスの要求事項」と「変更の理由」が示されています。答案では、例えば9字の「サービスの要求事項」とすれば、変更の判断に必要な情報を10字以内で示せます。採点講評でも、表3の手順を読み取って解答を導くことが求められています。

設問2(1)

表3の手順(2)では、CABが変更の影響について助言し、E氏がRFCの内容を事前に送付するとされています。欠席する場合も、自分の専門分野から必要な評価を提供することが重要です。公式解答例では、事前にRFCを確認してリスクアセスメントの結果をCABに提出する方法と、代理者をCAB要員として登録して参加させる方法が示されています。40字以内の答案例は「RFCを事前確認し、リスクアセスメント結果をCABに提出する。」です。代理者による方法なら「代理者をCAB要員として登録し、CABに参加させる。」とまとめられます。単に欠席を連絡するだけでは、変更評価への貢献が表せません。

設問2(2)

設問は、変更の展開が成功した後に構成管理プロセスで行う内容を問うています。表2の注記には、CIの属性がCMDBに記録されているとあります。変更によってプログラムの版などが変わったら、その実際の状態を構成情報に反映する必要があります。公式解答例では「CMDBの記録を更新」とされています。15字以内の答案はこの表現で足り、後ろの「する」にもつながります。実際、G氏はCMDBを検索してP1の使用先と版を確認しており、変更後も正しい判断ができるよう記録を更新します。

設問3

部長が確認したいのは、優先度が低い問題のうち「早期に解決できる問題」又は「早期に解決すべき問題」の解決状況です。表4では、原因が特定できた問題は解決に向けた調査が進んでおり、再発インシデントがある問題は繰り返す影響への対応が必要です。これに対して、原因が特定できず、再発インシデントもない問題を計算対象から除外します。公式解答例では「原因が特定できないで、かつ、再発インシデントなしの問題」とされ、30字以内に収まります。「かつ」によって両方の条件を満たす問題と示すことが要点です。対象は表4の項番4の6件なので、総件数は94件、未終了件数は10件となり、解決率は84÷94で約89.4％です。除外した問題を解決済みと扱うのではなく、計算対象から外します。採点講評でも、原因の特定状況と再発の有無に着目した実務的な管理が求められています。

設問4(1)

RFCを提起したのは10月11日で、変更期限は10月19日です。表3によると通常のCABは毎週火曜日に開催され、次の定例開催日は10月17日です。一方、確認テストはRFCの受入れ決定後に開始し、土日も作業して合計5日を必要とします。17日の定例CABを待つと、19日までに必要な日数を確保できません。優先度が緊急なら受付から2日以内に臨時CABが開催されるため、受入れを早める必要があります。公式解答例では、速やかなCAB開催によって確認テストの5日を確保することが理由です。40字以内なら「速やかにCABを開催し、確認テストに5日間を確保するため。」とまとめられます。

設問4(2)

Q社は、最新版では対策ロジックの追加によって処理時間が長くなる場合があると注意しています。K社の事前テストは機能確認が目的で、稼働環境とは機器の性能とデータ量が異なるため、正しい処理結果を確認しても、本番での処理時間まで保証できません。本文の「夜間バッチジョブはオンライン処理開始までに終了する必要がある」と結び付けて考えます。公式解答例では「夜間バッチジョブがオンライン処理開始までに終了しない。」とされ、30字以内に収まります。採点講評では、処理時間が長くなるという事象だけでなく、顧客への影響の観点からオンライン処理開始に着目することが求められています。

学習のポイント

表同士の対応から必要な管理項目を導き、作業日数から変更の緊急性を判断する練習をしましょう。リスクは処理時間の増加だけでなく、サービスへの影響まで具体化することが重点です。