IPA インシデント・問題・変更管理・サービスデスク — 頻出論点と過去問

頻出論点

1. この分野は何か

利用者から使えないという連絡が入ってから、サービスを戻し、原因を突き止め、直したものを本番に入れて構成の記録を更新するまでを、どのプロセスが受け持つかで学ぶ分野です。その入口に立つのがサービスデスクで、受けた連絡を記録し、自分で解けないものを専門の担当へ渡します。

2. 実際の出題のされ方

各管理プロセスの目的や具体的な作業の対応付けは、幅広い区分で問われています。インシデント管理や問題管理の説明、管理プロセスの説明と名前の組、テストを終えたサーバを本番に組み入れる作業のプロセスを選ぶ問題は、ITパスポートにあります。共有ディスクの容量不足という一つの事象への対応を、三つの管理のどれに当たるかで分ける事例問題も、同じ区分で出ました。

問題管理の目的や活動を選ぶ形は応用情報技術者の午前に出ており、情報処理安全確保支援士の午前IIにも同じ形があります。

利用者の窓口になるサービスデスクの役割や改善策も、ITパスポートを中心に繰り返し問われています。サービスデスクについて適切な記述を選ぶ問題、二次サポートへ解決を委ねる用語を選ぶ問題、業務改善として適切な記述を選ぶ問題のほか、窓口を評価するKPIのうち値が小さい方が良いものの組合せを選ぶ問題が出ました。さらに、過去のインシデントのFAQ化、チャットボット、会話認識によるオペレータ支援システムといった仕組みの導入効果を問う問題や、メールの自動割当てツールによる割当て時間の削減率を求める計算問題も出ています。

JIS Q 20000-1やITILの個別プロセスの要求事項と仕組みを選ぶ問題が、ITサービスマネージャの午前IIで出題されています。リリース及び展開管理の要求事項として適切なものと、イベント管理が受け持つ活動を選ぶ問題があります。インシデント・モデルを定義する利点、構成ベースラインで可能になること、構成コントロールが不適切なときに起きる事象、サービスデスクにWFMシステムを入れる目的を選ぶ問題も出ています。

3. 学習のポイント

インシデント管理は、サービスが使える状態に戻れば一区切りになるプロセスです。これに対して問題管理は、同じ中断を起こしている原因に手が打たれるまで続きます。

変更を本番に入れる作業と、入れたものの状態を記録しておく作業は、別のプロセスが受け持ちます。

窓口のKPIには値が大きいほど良いものと小さいほど良いものがあり、どちらになるかは、その指標が何を数えているかで決まります。

4. 間違えやすいところ

サービスデスクについて適切な記述を選ぶ問題では、受入テストの最中に利用者が見つけた不具合を受け付ける窓口とする誤答肢がありました。そうした受付は、システムがまだ稼働する前の開発側の仕事です。

問題管理の活動を選ぶ問題では、同じインシデントを起こさないために、問題は根本原因を突き止めて必ず恒久的に解決するとした誤答肢がありました。費用や技術の制約から、恒久的な解決をせずに回避策を示すだけで終える場合もあります。

リリース及び展開管理の要求事項では、「稼働環境へのリリースの展開後，影響を受けたCIのベースラインをとる」とする誤答肢がありました。展開した後にとったベースラインには、変更前の状態が残っていないので、うまくいかなかったときに戻す先になりません。

会話認識によって回答候補をオペレータの画面に表示する支援システムの効果として、電話による問合せに24時間対応できるとする誤った記述がありました。この仕組みは人間のオペレータが応対する際の手助けをするものであり、プログラム自身が顧客に自動応答するわけではないため、無人で24時間対応できるようにはなりません。