基本情報技術者過去問題平成21年秋期午後問6(サービスマネジメント)

基本情報技術者過去問題平成21年秋期午後問6

問6　サービスマネジメント

インシデント及び問題の管理に関する次の記述を読んで，設問に答えよ。

　流通業のF社では，システム部が受注システムを運用している。このシステムは，F社とその関連会社が利用している。
　ある日，朝から受注システムが使えないという状況が発生した。これを知った関連会社の社員がF社の担当窓口に問い合わせたところ，受注システムでアプリケーション障害が発生しており，それが関連会社に通報されていないことが分かった。
　サービスの回復後にシステム部で通報ミスの原因を調べたところ，障害時の連絡先一覧表が古く，連絡先には関連会社が含まれていないことが分かった。システム部では，インシデント管理及び問題管理のプロセスが有効に機能しなかったことを反省し，リスク管理部の監査担当者の協力を得て，プロセス全体の見直しを実施した。
　監査担当者は，見直しで発見された管理上の問題点とそれらに対する改善勧告を表1のようにまとめて，システム部長に報告した。
　なお，F社ではインシデントの発生から問題の分析・解決までを，障害管理データベース(以下，DBという)で管理している。DBの項目は，次のとおりである。

　管理上の問題点は多数あったが，システム部では，重要と判断した項番1～3について早急に改善することにした。

設問

記述中の　に入れる正しい答えを，解答群の中から選べ。

通報とフォローのプロセスについては，表2の内容で改善することにした。
　DBに二つの項目を追加する。まず，障害時に最初に判断すべき項目として，項目aを設け，そのレベルを事前に定義しておく。障害発生時は，そのレベルに応じた通報を行う。また，項目bを設け，これまで重大障害時にホワイトボードなどに記録していた対応状況や回復状況の内容をDBに記録し，システム部員が状況を共有できるようにする。
解決日時が空欄の問題があることについては，表3の内容で改善することにした。
　解決日時が空欄の問題を調査したところ，実際に未解決のものと解決日時の登録漏れとが混在していた。そこで，DBに項目cを設け，これを基準に問題の解決状況を問題管理委員会で毎週フォローする。問題管理委員会は実務担当者で構成し，決定事項をシステム部長に後日報告する。
　なお，未解決の問題のうち，長期間残ってしまうdなどは，月1回問題管理委員会で終了扱いとするかどうかを決定する。
　また，解決日時の登録漏れの原因として，次のことが分かった。すなわち，解決方針が決まった問題は，問題管理を離れて，その解決のための作業をeのプロセスとして実施している。そのため，DB中の解決日時の更新を，つい忘れてしまう。そこで，問題の解決作業の場合は，該当する障害管理番号をeに引き継いで双方の管理が連動するよう，手続を変更する。
DBの項目と使いやすさについては，表4の内容で改善することにした。
　不足項目について，今回は項番1，2の対応に必要な項目の追加にとどめる。
　次に，現在のDBの内容の表示順序は，障害管理番号の降順で，重要な問題を見分けにくい。そこで，今回追加する項目を含めて表示の順序を見直し，システム管理者向けに，未解決の問題を重要なものから順に表示するため，fが空欄の問題をaの降順に並べて表示する機能を追加する。

a，b，c，f に関する解答群

解決日時
解決方法の詳細(記述形式)
解決予定日時
障害対応の経緯(追記形式)
障害の影響度
障害の発生日時

d に関する解答群

原因が特定できず，その後再発しない問題
システム部にスキルのある担当者がいないので，解決できない問題
放置しておいても，業務に大きな支障がない問題
予算不足で，システム変更作業ができない問題

e に関する解答群

キャパシティ管理
構成管理
サービスレベル管理
変更管理

解答選択欄

解答

a=オ
b=エ
c=ウ
d=ア
e=エ
f=ア

解説

空欄[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資産を明確化し、これらの維持管理および他のプロセスが効率的なサービスを提供できるように構成情報の提供を行う
サービスレベル管理: サービス利用者とサービス提供者の間でSLA(Service Level Agreement)を締結し、維持管理する
変更管理: 変更による影響度や変更作業の実現可能性を調査した上で、変更を実施するかどうかを決定し、変更スケジュールなどを作成する

∴e＝エ：変更管理

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

∴f＝ア：解決日時

平成21年秋期午後問題一覧

問1　問2　問3　問4　問5　問6　問7　問8　問9　問10　問11　問12　問13　採点講評