応用情報技術者 2019年 春期 午後 問10

解答の論理構成

1. 表1の構造を確認
   • 【問題文】には、表1の左端に種別を示す列があり、そこに a とあります。
   • 同列には「サービス提供時間帯」「サービス稼働率」という項目が続き、目標値に「毎日 8:00～22:00」「99.9%以上」と記載されています。
2. “サービス提供時間帯”“サービス稼働率”は何を測るか
   • どちらも「サービスが使えるかどうか」を示す尺度で、一般にＳＬＡでいう “Availability（可用性）” に相当します。
   • 解答群のうち “可用性” に対応するのは「ウ：可用性」です。
     ⇒ a ＝ ウ：可用性
3. b の文脈を確認
   • 表1では「重大インシデントの b」に対して目標値「2時間以内」が設定されています。
   • 【問題文】注記には「インシデントを受け付けてから最終的なインシデントの解決を A社販売部門に連絡するまでの経過時間」と明記されています。
   • これは「障害を認識してから復旧完了までに要した時間」＝“Time to Resolution（解決時間）” を表します。
   • 解答群で該当するのは「イ：解決時間」です。
     ⇒ b ＝ イ：解決時間

誤りやすいポイント

• “サービス稼働率”と聞いて「信頼性」や「平均故障間動作時間（ＭＴＢＦ）」と混同しやすい
• “2時間以内”を「平均修復時間（ＭＴＴＲ）」と考えて「カ：平均修復時間」を選びがちだが、表1の説明は “販売部門に連絡するまで” とゴールを厳密に定義しており、平均ではなく個々のインシデントの完了リミットを示す
• 種別欄に一度に2行が含まれているので「信頼性」の括りと読み間違えやすい

FAQ

解答の論理構成

• 【問題文】表2「インシデント処理手順」のcの行には
  “・インシデントの内容に応じて、専門知識をもったA社IT部門の技術者などに、cを行う。”
  と示されています。
• ここで行うべき作業は、一次対応者が解決できないインシデントを専門家へ引き上げ、より高度な対処を図るプロセスです。
• ITサービスマネジメントの標準的な用語では、この引き上げを “エスカレーション” と呼び、日本語訳は “段階的取扱い” が正式訳として用いられています。
• 専門知識を持つ技術者へ対応を「段階」的に「取扱う」ことが表現されており、文脈とも合致するため、cには「段階的取扱い」が入ります。

誤りやすいポイント

• “エスカレーション” とカタカナでそのまま書いてしまう。設問は日本語での記入を求めており不正解になります。
• “対応依頼” “技術者連絡” など一般語を入れる。いずれも ITサービスマネジメントの正式用語である “段階的取扱い” とは異なります。
• 「専門知識をもった～」の部分だけを読み、“調査依頼” と誤記。処理手順としては「依頼」でなく「取扱い」が適切です。

FAQ

解答の論理構成

1. 【問題文】には次の記述があります。
   ・「表2の手順“記録”における、B社の役割として、dを行うこととする。」
   ・「表2の手順“優先度の割当て”における優先度の割当てでは、A社IT部門が行い、割当て結果を e に伝える。」
2. 手順“記録”はインシデントを受け付け、内容をインシデント管理簿に記録する工程です。
   • インシデントの一次受付をB社が担当することになったため、A社側の関係者へ速やかに報告しなければ次工程に進めません。
   • したがってB社の作業は「A社IT部門への連絡」が最も自然です。
   • 解答群で該当するのは「イ：A社IT部門への連絡」。
     → [d] ＝ イ
3. 手順“優先度の割当て”ではA社IT部門が優先度を決定します。
   • 優先度が決まったら実際に運用を行うB社が復旧作業の指示を受ける必要があります。
   • よって通知先は「B社」です。
   • 解答群で該当するのは「オ：B社」。
     → [e] ＝ オ
4. 以上より、最終解答は
   • d：イ
   • e：オ

誤りやすいポイント

• 「連絡」か「部門」かの取り違え
  「ア：A社IT部門」と「イ：A社IT部門への連絡」を混同しやすいですが、記述では“B社の役割”と明示しているため、B社自身ではなくB社が行う“行為”を選ぶ必要があります。
• 優先度通知の宛先
  優先度を決定した主体と通知先を同一視してしまい、[e]に「ア：A社IT部門」を選んでしまうミスが散見されます。通知は外部委託先であるB社へ行う点を見落とさないことが重要です。
• “販売部門”との混同
  SLA の顧客が A社販売部門であるため、インシデント報告先として “販売部門”を選びたくなりますが、問題文では販売部門は復旧プロセスに直接関与しないことが示唆されています。

FAQ

解答の論理構成

1. 問題文には「B社は “PaaS の安定運用の必要性から、PaaS のサービス停止を伴う変更作業を行う。その場合、事前に計画停止の予定通知を行うこととする。” と明記されています。
2. さらに「サービスレベル項目として、B社が保守を行うための 計画停止予定通知日 を追加」し、通知を「計画停止実施予定日の 7 日前まで」と定めています。
3. これらの記述は、停止を伴う変更を行っても、A社販売部門向けに合意済みの「サービス稼働率 99.9%以上」などの社内SLAを損なわないようにする意図を示しています。
4. したがって、計画停止予定通知日を追加する目的は「停止を伴う保守でもサービス可用性を維持すること」、すなわち「サービス可用性を維持して変更作業を行う必要があるから」と結論づけられます。

誤りやすいポイント

• 「7 日前」という日数だけを書き、目的を示さない答案
• 「B社内部の作業効率化」のように、A社への影響を無視した理由
• 「計画停止時間を確定させるため」など通知手続きのみを主語にして可用性維持の観点を落とすミス

FAQ

解答の論理構成

1. A社とB社の役割分担を確認
   【問題文】には「業務アプリ保守及びインシデント管理などのサービスマネジメント業務は、引き続きA社IT部門が担当する。」とあります。
   つまり“業務アプリ”に関する作業・責任はアウトソースの対象外で、B社ではなくA社が担います。
2. SLA に追加された除外規定を確認
   同じく【問題文】には「②A 社と B社の SLA の対象から除外するインシデント」を決める、と明記されています。
   除外するのは「B社の責任では A 社と合意する B社の目標値を遵守できない項目がある」場合のインシデントです。
3. “B社の責任ではない”範囲を特定
   B社は PaaS 基盤を運用しますが、アプリケーション部分は「業務アプリ保守…は、引き続きA社IT部門が担当」とあるため、業務アプリに起因する障害はB社責任外です。
4. 結論
   よって、除外するインシデントは「業務アプリに起因するインシデント」となり、設問の要求（下線②で除外するインシデントを20字以内で述べる）に合致します。

誤りやすいポイント

• PaaS基盤で発生するハードウェア障害を除外と勘違いする
  → ハードウェアはB社が担当するため除外対象ではありません。
• ネットワーク障害を除外と誤認する
  → 問題文にネットワークはB社責任外とは記載されていません。
• 「不可抗力（天災等）」と混同する
  → それは既に表1注記2で社内SLAの除外として定義済みです。

FAQ

解答の論理構成

1. 出題箇所の確認
   【問題文】では、③必要な活動を「キャパシティ管理に関わる」と明示しています。
   引用：「そこで、A社 IT部門は、キャパシティ管理に関わる③必要な活動を行い、B社にリソース増強要求を提出することとした。」
2. キャパシティ管理で先に行うべき作業
   キャパシティ管理は ITIL などで「ビジネス需要の予測 → 必要リソース量の算出 → 供給計画」という流れを取ります。
   引用：「新商品の販売開始後、販売量の大幅な増加が予測されている。」
   まず需要（販売量）を把握し、それがシステム負荷・リソース需要にどう影響するかを定量化する必要があります。
3. 活動の実体
   ①販売部門が持つ販売量予測を入手
   ②予測値を処理量・データ量へ換算
   ③CPU・メモリ・ストレージなどリソース単位で要求量を整理
   これにより B社へ「増強要求」を根拠付きで提示できます。
4. 解答の導出
   以上より、③で求められるのは「販売量予測を基に必要リソースを取りまとめる」活動であり、模範解答は
   「販売部門の販売量予測に基づきリソースの要求量をまとめる。」
   となります。

誤りやすいポイント

• 「リソース増強要求の提出」そのものを答えてしまう
  → 既に【問題文】で「提出することとした」と書かれているため、③はその前段階の活動です。
• キャパシティ監視（現在値のモニタリング）と混同する
  → 問題は将来の販売増加に備える計画作業を問うています。
• 「性能測定」「チューニング」など運用フェーズの作業を挙げる
  → 需要予測に基づくリソース算定が先です。

FAQ