ITサービスマネージャ 2018年 午後1 問02

解答の導き方

誤りやすいポイント

• 在庫管理ファイルを先に修正してからプログラムをデプロイする順序にすると、稼働中の不具合プログラムが誤りを再発させるおそれがあります。
• デプロイの前にLBを閉塞すれば、その閉塞がデプロイ後も維持されると思い込まないようにします。AP展開ツールは、デプロイ後にLBの閉塞を解除します。
• この設問では、単にサービスを止めるかどうかではなく、誤りを再発させるプログラムを先に置き換えることと、データ修正時に通信を止めることの両方がポイントです。

FAQ

解答の導き方

1. 変更前の計画では、作業開始は10月4日（木）22時でした。本文には「東京本社の22時は欧州支社では14時」とあり、この時刻は欧州支社の業務時間帯に当たります。サービス利用者が受注管理サービスを利用している時間帯に作業すると、業務に影響するおそれがあります。
2. Y氏が提言した10月4日（木）20時は、欧州支社の1時間の休憩時間帯の開始時刻に当たります。したがって、22時開始の計画を20時開始に変更することで、欧州支社の利用者がサービスを使う時間帯への影響を抑えようとしたと分かります。
3. 問われている理由は、緊急対応だから早めたということではなく、欧州支社の利用者がサービスを利用している時間帯を避け、業務への影響を小さくするためです。

誤りやすいポイント

• 東京本社の時刻だけを見て、22時なら利用者が少ないと判断しないようにします。本文では、東京本社の22時が欧州支社の14時に当たると説明されています。
• 「インシデントが発生したので、緊急に作業を始めるため」とだけ答えるのは不十分です。問われているのは、開始時刻の変更によってサービス利用者への影響を抑える理由です。
• 20時に変更すれば影響が完全になくなる、と断定しないようにします。理由は、休憩時間帯に合わせて業務への影響を少なくすることです。

FAQ

解答の導き方

1. 業務ルール変更のテスト対象を確認します。
   業務ルール変更計画では、請求プログラムと共通プログラムを修正し、変更諮問委員会で承認される前にテストを完了しています。このテストは、インシデント対応でプログラムを修正する前の状態を対象にしています。
2. インシデント対応で変更されたプログラムを確認します。
   10月4日のインシデントでは、売上プログラムと共通プログラムの不具合が修正され、稼働環境にデプロイされました。業務ルール変更計画の対象にも共通プログラムが含まれているため、先に完了したテストの内容は、修正後の共通プログラムを反映していません。そのため、業務ルール変更計画について追加の修正やテストを行うには、テスト環境を最新の状態にする必要があります。
3. どの環境に配置するかを判断します。
   図1では、テスト用サーバに開発環境と保守環境があります。開発環境は適応保守で修正したプログラムのテストに使われます。今回、開発課が業務ルール変更計画に関するテストを続けられるようにするので、修正後のプログラムは開発環境に配置します。

誤りやすいポイント

• インシデントの不具合対応が是正保守だからといって、今回も保守環境に配置すると考えないようにします。ここで問われているのは、インシデント対応後に、業務ルール変更計画のテストを続けられるようにする作業です。
• 業務ルール変更計画に共通プログラムが含まれることを見落とすと、インシデント対応後にテスト環境を更新する必要性に気付きにくくなります。
• 配置する対象を共通プログラムだけに限定しないようにします。インシデント対応で修正した対象は売上プログラムと共通プログラムの両方です。

FAQ

解答の導き方

1. まず、業務ルール変更計画で変更するプログラムを確認します。システム開発課の調査では「請求プログラム及び共通プログラムの修正が必要」と分かっており、これらのPGは10月3日（水）の変更諮問委員会で承認される前にテストを完了しています。
2. その後、10月4日（木）のインシデント調査で「売上プログラム及び共通プログラムに不具合」が見つかり、システム開発課が修正しています。この修正は、業務ルール変更計画のPGをテストした後に行われたものです。
3. 業務ルール変更計画では、10月12日（金）に請求プログラムと共通プログラムを稼働環境へデプロイします。したがって、計画時点でテスト済みの共通プログラムをそのまま使うと、後から修正された不具合の内容が反映されません。
4. そこで、業務ルール変更計画の共通プログラムにも、インシデント対応で行った不具合修正を反映させる必要があります。これが、下線（ウ）で追加すべき修正です。

誤りやすいポイント

• 業務ルール変更計画の変更内容だけを考え、後から行われた共通プログラムの不具合修正を見落とすことがあります。
• インシデントでは売上プログラムも修正していますが、業務ルール変更計画でデプロイする対象は請求プログラムと共通プログラムです。両方の計画で関係する共通プログラムへの修正反映がポイントです。
• すでにテスト済みのPGであっても、その後にプログラムの修正が加わった場合は、変更内容を反映したうえで改めて確認する必要があります。

FAQ

解答の導き方

1. 問われているのは、10月3日（水）の変更諮問委員会で承認されたときにテストを完了していたPGに対し、後から何を追加でテストするかです。つまり、業務ルール変更のテストを一から説明するのではなく、その後の変更に応じて必要になるテストを考えます。
2. 10月4日（木）のインシデント対応では、売上プログラム及び共通プログラムの不具合が修正されています。したがって、10月3日（水）にテスト済みだったPGと、後の修正を反映したPGは同じ状態ではありません。以前のテスト結果だけでは、修正後のPGに問題がないとは判断できません。
3. 表1には、システム開発課が「PGを更新したことによって想定外の影響が出ていないかどうかを確認するためのテスト」を行うとあります。今回は、不具合修正によって、修正箇所以外の機能にも予期しない影響が出ていないかを確かめるテストが必要です。
4. したがって、追加でテストする内容は、不具合を修正したことによる想定外の影響の有無を確認することです。

誤りやすいポイント

• 不具合を修正した箇所が正常に動くかどうかだけを答えると、修正の影響が他の機能に及んでいないかという観点が抜けます。
• 10月3日（水）に完了していた業務ルール変更のテストを、追加テストの内容として答えるのは適切ではありません。追加の修正後に必要なテストを答えます。
• 在庫管理ファイルの誤り修正作業の確認と、PGを更新したことによる想定外の影響の確認は別の観点です。ここでは後者が問われています。

FAQ