基本情報技術者 2009年 秋期 午後 問06
インシデント及び問題の管理に関する次の記述を読んで、設問に答えよ。
流通業のF社では、システム部が受注システムを運用している。このシステムは、F社とその関連会社が利用している。
ある日、朝から受注システムが使えないという状況が発生した。これを知った関連会社の社員がF社の担当窓口に問い合わせたところ、受注システムでアプリケーション障害が発生しており、それが関連会社に通報されていないことが分かった。
サービスの回復後にシステム部で通報ミスの原因を調べたところ、障害時の連絡先一覧表が古く、連絡先には関連会社が含まれていないことが分かった。システム部では、インシデント管理及び問題管理のプロセスが有効に機能しなかったことを反省し、リスク管理部の監査担当者の協力を得て、プロセス全体の見直しを実施した。
監査担当者は、見直しで発見された管理上の問題点とそれらに対する改善勧告を表1のようにまとめて、システム部長に報告した。
なお、F社ではインシデントの発生から問題の分析・解決までを、障害管理データベース（以下、DBという）で管理している。DBの項目は、次のとおりである。
① 障害管理番号（連番） ② 障害の発生日時
③ システム名 ④ コンポーネント名
⑤ 障害の状況（文章で記述） ⑥ 解決の方法（文章で記述）
⑦ 解決担当者名 ⑧ 解決日時
管理上の問題点は多数あったが、システム部では、重要と判断した項番1〜3について早急に改善することにした。
設問1：
問題文を見る 次の記述中のに入れる正しい答えを、解答群の中から選べ。
(1) 通報とフォローのプロセスについては、表2の内容で改善することにした。
DBに二つの項目を追加する。まず、障害時に最初に判断すべき項目として、項目aを設け、そのレベルを事前に定義しておく。障害発生時は、そのレベルに応じた通報を行う。また、項目bを設け、これまで重大障害時にホワイトボードなどに記録していた対応状況や回復状況の内容をDBに記録し、システム部員が状況を共有できるようにする。
(2) 解決日時が空欄の問題があることについては、表3の内容で改善することにした。
解決日時が空欄の問題を調査したところ、実際に未解決のものと解決日時の登録漏れとが混在していた。そこで、DBに項目cを設け、これを基準に問題の解決状況を問題管理委員会で毎週フォローする。問題管理委員会は実務担当者で構成し、決定事項をシステム部長に後日報告する。
なお、未解決の問題のうち、長期間残ってしまうdなどは、月1回問題管理委員会で終了扱いとするかどうかを決定する。
また、解決日時の登録漏れの原因として、次のことが分かった。すなわち、解決方針が決まった問題は、問題管理を離れて、その解決のための作業をeのプロセスとして実施している。そのため、DB中の解決日時の更新を、つい忘れてしまう。そこで、問題の解決作業の場合は、該当する障害管理番号をeに引き継いで双方の管理が連動するよう、手続を変更する。
(3) DBの項目と使いやすさについては、表4の内容で改善することにした。
不足項目について、今回は項番1, 2の対応に必要な項目の追加にとどめる。次に、現在のDBの内容の表示順序は、障害管理番号の降順で、重要な問題を見分けにくい。そこで、今回追加する項目を含めて表示の順序を見直し、システム管理者向けに、未解決の問題を重要なものから順に表示するため、fが空欄の問題をaの降順に並べて表示する機能を追加する。
a〜c, fに関する解答群
ア：解決日時
イ：解決方法の詳細（記述形式）
ウ：解決予定日時
エ：障害対応の経緯（追記形式）
オ：障害の影響度
カ：障害の発生日時
dに関する解答群
ア：原因が特定できず、その後再発しない問題
イ：システム部にスキルのある担当者がいないので、解決できない問題
ウ：放置しておいても、業務に大きな支障がない問題
エ：予算不足で、システム変更作業ができない問題
eに関する解答群
ア：キャパシティ管理
イ：構成管理
ウ：サービスレベル管理
エ：変更管理
模範解答
a：オ、b：エ、c：ウ、d：ア、e：エ、f：ア
解説
解答の導き方
この問題では、障害が起きたときの連絡方法、解決状況の確認、記録項目の見直しを考えます。
インシデントとは、システムが使えないなど、利用者に影響する出来事です。インシデント管理では、まず利用者への影響を抑え、サービスを回復させます。一方、問題管理では、障害の原因を調べ、解決や再発防止につなげます。DBはデータベース（Database：情報を蓄積し、必要なときに取り出す仕組み）のことです。
(1) 通報プロセスとDBに追加する項目
表2では、運用責任者が障害のレベルを判断し、レベルに応じて通報先や通報のタイミングを変えます。つまり、障害がどれほど大きな影響を及ぼしているかを判断する必要があります。そこで項目aは「障害の影響度」です。影響度をあらかじめレベル分けしておけば、障害発生時に通報の要否や通報先を決めやすくなります。
次に、問題文には、これまでホワイトボードなどに記録していた「対応状況や回復状況の内容」をDBに記録するとあります。対応の進み具合を時間の経過に沿って追加できる項目が必要です。そのため項目bは「障害対応の経緯（追記形式）」です。解決方法の詳細を一つ記録するだけでなく、対応の進展を順に残し、システム部員が共有できます。
(2) 解決状況を確認するための項目と手続
表3では、問題管理委員会が毎週、その週に解決予定の問題の状況を確認します。確認の基準にするには、問題がいつ解決する予定なのかをDBで把握できる必要があります。したがって項目cは「解決予定日時」です。
ここで、既存の「解決日時」との違いに注意してください。「解決予定日時」は、解決する見込みの日時です。「解決日時」は、実際に解決した日時です。予定を確認し、実際に解決したら解決日時を記録します。
長期間未解決の問題については、月1回、終了扱いにするかどうかを検討します。選択肢の中で終了扱いを検討する状況に合うのは、原因が特定できず、その後再発しない問題です。再発がなく、原因を特定して対処する見通しも立たない場合は、委員会で継続管理が必要かを判断できます。よってdは「原因が特定できず、その後再発しない問題」です。担当者のスキル不足や予算不足は、解決を妨げている要因なので、それだけで終了扱いにするのではなく、対応を検討する必要があります。
また、問題文では、解決方針が決まった後の作業を、問題管理とは別のプロセスで行っているため、DBの解決日時を更新し忘れると説明されています。システムに変更を加える作業を管理するプロセスは「変更管理」です。問題管理の記録と変更管理の作業を結び付けるため、障害管理番号を変更管理に引き継ぎます。したがってeは「変更管理」です。
(3) DBの表示順序
未解決の問題を見分ける基準は、実際に解決した日時です。解決していない問題では、解決日時が空欄になります。そのため、fは「解決日時」です。
さらに、重要な問題を先に確認できるよう、aで判断する「障害の影響度」の高い順に並べます。つまり、解決日時が空欄の問題を取り出し、障害の影響度の降順、すなわち影響度が高いものから表示する仕組みです。
誤りやすいポイント
- 「解決日時」と「解決予定日時」を混同しないようにしましょう。前者は実際に解決した日時、後者は解決する予定の日時です。
- 障害の状況を共有するための項目は、解決方法の詳細ではなく、対応や回復の経過を記録する項目です。
- 未解決の問題を重要度順に表示するときは、障害管理番号や発生日時ではなく、障害の影響度に注目します。
- 解決作業の実施先は変更管理です。問題管理で決めた解決方針に基づいて、システムに変更を加える作業を管理します。
FAQ
Q: 解決日時が空欄なら、必ず未解決ということですか？
A: いいえ。問題文では、実際に未解決のものと、解決日時の登録漏れが混在しています。そのため、予定日や作業の状況も確認し、記録漏れかどうかを見分ける必要があります。
A: いいえ。問題文では、実際に未解決のものと、解決日時の登録漏れが混在しています。そのため、予定日や作業の状況も確認し、記録漏れかどうかを見分ける必要があります。
Q: なぜ障害対応の経緯は「追記形式」なのですか？
A: 対応状況は時間とともに変わるためです。前の記録を残したまま新しい状況を追加すれば、どのように対応が進んだかを後から確認できます。
A: 対応状況は時間とともに変わるためです。前の記録を残したまま新しい状況を追加すれば、どのように対応が進んだかを後から確認できます。
Q: なぜ問題管理と変更管理の記録を連動させるのですか？
A: 解決作業を変更管理で進めるときに、元の問題の記録と結び付けられるからです。これにより、作業が終わった後に問題管理側の解決日時を更新し忘れることを防ぎやすくなります。
A: 解決作業を変更管理で進めるときに、元の問題の記録と結び付けられるからです。これにより、作業が終わった後に問題管理側の解決日時を更新し忘れることを防ぎやすくなります。
関連キーワード: インシデント管理、問題管理、変更管理、障害の影響度、解決予定日時、データベース
