解説

空欄[a]、[b]、[c]はDBに新たに設ける項目なので、解答群のうち既に項目として存在している「解決日時」と「障害の発生日時」は除外して考えることができます。

〔aについて〕
問題文中の以下の記述がヒントになっています。

• 障害時に最初に判断する
• [a]のレベルを運用責任者が判断し、レベルに応じた通報を行う

これらの記述から発生したインシデントに対する優先度または重大性を表す項目であるとわかります。サービスマネジメントシステムへの要求事項をまとめたJIS Q 20000-1:2012では、インシデントおよびサービス要求に対する処理手順を、①記録、②優先度割当て、③分類、④記録の更新、⑤段階的取扱い、⑥解決、⑦終了としており、障害発生の初期段階に行うこととして優先度割当てを挙げています。優先度はインシデントの影響及び緊急度（インパクト）に応じて決めるので、[a]で定義するレベルは「障害の影響度」が適切です。

∴a＝オ：障害の影響度

〔bについて〕
項目[b]は、「これまでホワイドボードなどに記録していた対応状況や回復状況の内容」を記録するためのものです。記録したいのが文章形式のデータであることから、解答群のうち「解決方法の詳細(記述形式)」または「障害対応の経緯(追記形式)」の2つに絞られます。記録したいのは、刻々と変わる障害時の状況であって、解決方法ではありませんから「障害対応の経緯(追記形式)」が適切です。

∴b＝エ：障害対応の経緯(追記形式)

〔cについて〕
表3では、解決日時が空欄であることの改善内容として「毎週の問題管理委員会でその週に解決予定の問題の解決状況を確認する」とあります。現状でのDB項目には、解決日時しかなくいつ解決する予定であるかを確認できる項目がないので、どのインシデントが今週解決予定なのかがわかりません。これでは改善内容にある問題管理委員会でのフォローは困難です。項目[c]はこの問題の解消のために設ける項目ですから、「解決予定日時」が適切です。

∴c＝ウ：解決予定日時

〔dについて〕
長期間残ってしまう未解決問題で、終了扱いにできるものを選択します。

• 正しい。1回限り起きた原因不明の問題で、同じ問題が長い間発生していないときは、偶発的な発生と考えられるので、業務への影響度等を考慮して終了扱いにすることも検討すべきです。
• 解決のためのスキルが特定されているということは、原因がある程度判明している問題ということになります。担当者のスキル不足が問題ならば、外部組織の技術を確保して解決することを検討すべきです。
• 業務に大きな支障はなくても小さな支障がある問題ですので、原因が特定されているのであれば計画的に改善を進めるべきです。
• 予算が確保できれば解決できる問題ですので、終了扱いにすべきではありません。

∴d＝ア：原因が特定できず，その後再発しない問題

〔eについて〕
問題管理でインシデントの恒久的な解決策が決定されると、その解決策は、変更要求(RFC)の発行という形で変更管理のプロセスに引き継がれ、その後は変更管理のプロセスが変更完了までを管理することになります。問題管理にはこの変更作業の進捗を監視し、変更完了を受けて問題のクローズを記録する役割がありますが、変更管理との連絡が疎かになっていると、変更完了が伝わらず、未解決のままになってしまうことがあります。

問題管理から解決のための作業を引き続ぐプロセスが問われているので、[e]には「変更管理」が入ります。

ちなみに解答群の各プロセス担う役割は次の通りです。

キャパシティ管理

サービス利用者が要求するサービスレベルに対し、システムに将来必要とされるリソースを管理する

構成管理

ITサービスを構成する全てのIT資産を明確化し、これらの維持管理および他のプロセスが効率的なサービスを提供できるように構成情報の提供を行う

サービスレベル管理

サービス利用者とサービス提供者の間でSLA(Service Level Agreement)を締結し、維持管理する

変更管理

変更による影響度や変更作業の実現可能性を調査した上で、変更を実施するかどうかを決定し、変更スケジュールなどを作成する

∴e＝エ：変更管理

〔fについて〕
必要とされる表示機能は「未解決の問題を重要なものから順に表示する」機能です。表1の項番2には「問題の解決が完了していないことを示す，解決日時が空欄のものが多数ある」とあり、解決日時を参照することで未解決問題であるかどうかを判定できることがわかります。よって、未解決問題のみを表示するには、「解決日時」が空欄になっているレコードを選択すればよいと考えられます。

∴f＝ア：解決日時