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

解答の論理構成

1. a の判定
   • 【問題文】表2 “問題の解決” には
     “解決策が構成品目の変更を必要とする場合は、a を提出し、変更管理…の対応手順を使って、解決する。”
   • 変更を正式に申請して変更管理プロセスに乗せる文書は ITIL 用語で “Request For Change” です。
   • 解答群で一致するのは “ア：RFC”。
   • RFI は “Request For Information” で目的が異なるため不適切です。
2. b の判定
   • 【問題文】“運用課は解決目標時間を技術課に通知し…適宜運用課と情報を共有し、連携してインシデント対応を行うとの結論が得られ、運用課と技術課で b を取り交わせた。”
   • 部署間で役割・連携方法・目標時間などを文書化し共有するものは、ITIL では “合意文書（Operational Level Agreement など）” と表現されます。
   • 解答群で該当するのは “オ：合意文書”。
   • “契約書” は外部組織との法的契約を示すのが一般的で、内部部署間の取り決めには過剰です。

誤りやすいポイント

• “RFC” と “RFI” はアルファベットが似ているため取り違えやすい。提出して変更を申請するのは “RFC” である点を押さえましょう。
• 部署内連携の文書を “契約書” と考えてしまうミス。内部合意のレベルなら “合意文書” が適切です。
• “傾向分析” をエスカレーション改善策だと思い選択してしまうケース。ここでは文書のやり取りが問われています。

FAQ

解答の論理構成

• 表1“エスカレーション”には
  “解決担当者は、優先度にかかわらず解決目標時間内にインシデントを解決できない可能性があると判断した場合は、運用課長に階層的エスカレーションを行う。”
  と明記されています。
• 物語中でL君は、技術課からの回答を受け取った時点で“インシデント発生から1時間40分”経過し、さらに“回避策の適用には少なくとも30分掛かり、解決目標時間を超過してしまう”と判断していました。
• したがって、解決目標時間“2時間”を守れないと判断した時点で運用課長（J課長）に階層的エスカレーションを行うべきでしたが、L君は実施せず独断で作業を続行しています。
• この行動が“インシデントの対応手順に即していない問題点”であるため、解答は「L君が階層的エスカレーションを行わなかった」となります。

誤りやすいポイント

• 「優先度“中”だからエスカレーションは不要」と誤解し、解決目標時間を超えるかどうかの判断を見落とす。
• 階層的エスカレーションと機能的エスカレーションを混同し、上位者への報告を忘れる。
• 回避策が見つかった時点で手順遵守よりも“早期復旧”を優先し、内部ルールを省略してしまう。

FAQ

解答の論理構成

1. 問題文の指摘
   • J課長は「②表1の手順“エスカレーション”に、優先度が “高” 又は “中” の場合、技術課に機能的エスカレーションを行う前に運用課で実施する手順を追加する」と述べています。
2. 現行手順の弱点
   • 表1“エスカレーション”では、優先度が “高” 又は “中” だと直ちに「技術課に機能的エスカレーション」を行います。
   • しかし表1“解決”(2) には「解決担当者が既知の誤りを調査して回避策を探し…」という有効な手段があり、これは優先度 “低” のときにしか活用されません。
3. 改善の方向性
   • 今回のインシデントは「過去の同じ問題で発生した再発インシデント」であり、既知の誤りを即座に参照すれば時間短縮できたと推測できます。
   • したがって追加すべき手順は、エスカレーション前に「既知の誤りを調査し、回避策を見つける」あるいは「解決担当者だけでインシデントの解決を試みる」ことです。
4. 結論
   • 模範解答と同じく、追加手順は
     「既知の誤りを調査し、回避策を見つける。」
     または
     「解決担当者だけでインシデントの解決を試みる。」
     のいずれかが適切です。

誤りやすいポイント

• 「優先度が“高”“中”なら即エスカレーション」と思い込み、既知の誤りの調査を忘れる。
• 表1“解決”の注記「既知の誤りは、問題管理の活動として、技術課によって記録される」を読み飛ばし、運用課でも参照できる事実を見落とす。
• 追加手順を「技術課に早く連絡する」などと書き、現行と同じ行動を繰り返してしまう。

FAQ

解答の論理構成

1. 本文では、技術課が「③問題管理ファイルから早期に解決できる問題を抽出」するとあります。
2. 早期解決できるとは、すでに「調査と診断」で「(3) 根本原因を特定し、問題の解決策の特定に取り組む」段階が完了し、「問題の解決」で「(1) 特定された解決策を適用」するだけの状態を指します。
3. したがって抽出条件は、表2の字句「根本原因を特定」「問題の解決策の特定」―すなわち“根本原因と解決策が特定”されていること。
4. さらに、まだ「特定された解決策を適用」しておらず、ファイル上は“未解決”である必要があります。
5. 以上より、抽出条件は「根本原因と解決策が特定されている未解決な問題」となります。

誤りやすいポイント

• 「回避策がある問題」を選ぶと、根本原因や解決策が不明のまま放置される可能性があります。
• 「既知の誤り＝解決済み」と誤解しがちですが、既知の誤りは“原因または回避策が分かった段階”で記録されるだけで、解決済みとは限りません。
• 「早期に解決できる」を“優先度が高い”と読み替えてしまうと条件がずれます。優先度とは無関係です。

FAQ

解答の論理構成

1. 課題の把握
   【問題文】には、J課長が「運用課だけで解決できるインシデントを増やしたい」と要望した背景として、
   「優先度“低”の場合において、運用課だけで解決できたインシデントが少なく、早期解決を難しくしている」
   と記載されています。これは“運用課だけでインシデントを解決する割合”が低いことを示します。
2. 改善目標と期待効果
   技術課は改善目標として
   「回避策を策定した日に問題管理ファイルに漏れなく記録する」
   「現在未解決の問題の数を1年後30%削減する」
   を設定しました。これにより、運用課は“既知の誤り”を即座に参照でき、回避策を自力で適用しやすくなります。
3. H部長の助言
   H部長は「これらの改善目標を達成することによって、c割合を増やすことができ、技術課の負担も軽減することができる」と述べています。
   改善目標が達成されれば、エスカレーション件数が減少し、運用課自身で解決できるインシデントが増えるため、技術課の工数が削減される論理が成立します。
4. 結論
   以上より、cに入るのは「運用課だけでインシデントを解決する」が最も適切となります。

誤りやすいポイント

• 「エスカレーション件数の削減」や「未解決問題の削減」など“目的ではなく効果の結果”を答えてしまう。
• “割合”という語からパーセント値や件数を連想し、具体的数値を入れてしまう。
• 技術課の負担軽減に注目しすぎて「技術課の作業時間」など技術課側の指標を入れてしまう。

FAQ

解答の論理構成

1. 問題文では、技術課が「“④プロアクティブな活動”を継続的に行っていくべき」と明記されています。
   引用：
   “技術課は、問題管理として今まで実施していなかった④プロアクティブな活動を継続的に行っていくべきだと考え、改善活動を進めていくことにした。”
2. ITIL などのフレームワークにおけるプロアクティブ問題管理は、主に“インシデントの傾向分析”や“潜在的な原因の排除”といった将来の予防策立案を指します。
3. 解答群を照合すると、
   ・ア：回避策“策定”はインシデント発生後の対処＝リアクティブ活動
   ・イ：“発生したインシデントの傾向を分析して、将来のインシデントを予防する方策”＝典型的なプロアクティブ活動
   ・ウ：レビューは解決策実施後の評価であり、予防ではない
   ・エ：優先度“低”でも即時連絡はリアクティブ側面
   よってプロアクティブ活動に該当するのは “イ” です。

誤りやすいポイント

• 「回避策を策定する」は一見前向きに見えますが、インシデントが“既に発生”した後の対応でありプロアクティブではありません。
• “レビュー”や“連絡フローの迅速化”は重要ですが、目的が“将来の発生を防ぐ”とは限らないため選択肢として不適切です。
• 用語の混同：
  ・リアクティブ問題管理＝起きたインシデントの根本原因除去
  ・プロアクティブ問題管理＝起きていない／再発していない問題を未然に防ぐ

FAQ