応用情報技術者 2017年 春期 午後 問10
サービスマネジメントにおけるマネジメントプロセスとサービスデスクの運用に関する次の記述を読んで、設問1〜4に答えよ。
K社は、5年前に関西で創業した流通業の会社で、国内に本社と8か所の支店をもっている。K社の情報システム部は、受注機能と配送管理機能を備えた流通業務システムを開発し、流通業務サービスとして社内に提供している。K社の社員は、1人に1台与えられたPCを使って流通業務サービスを利用している。
〔サービスデスクの運用〕
流通業務サービスの提供に当たって、情報システム部に所属する、本サービスに精通した4人のメンバから成るサービスデスクを組織し、利用者からのインシデントの解決依頼やサービス要求を受け付けた。K社では、ITサービスに対する計画外の中断やITサービスの品質の低下をインシデントと定義している。二つ以上のインシデントの根本原因をaと呼び、“根本原因が特定されているが、若しくは回避策によってサービスへの影響を低減又は除去する方法があるa”をbと呼んでいる。
サービスデスクのメンバは、依頼内容や対応状況を、表計算ソフトを使って一つのインシデント管理ファイルに記録していた。インシデント管理ファイルはファイルサーバ上にあって、メンバ全員で利用されていた。インシデント管理ファイルに更新要求がある場合、表計算ソフトはファイルに対して排他ロックを施すアクセス制御を行って、整合性を確保している。
一つのインシデントに対するサービスデスクの対応が1回で終わらずに、利用者が再度サービスデスクに問い合わせる場合がある。メンバが個別に同じ件に対応していたので、最初に対応したメンバ名や日時を利用者がサービスデスクに伝える必要があり、利用者から“組織として対応してほしい”との要求があった。
〔マネジメントプロセス及びツールの整備〕
利用者からの要求を受けて、ITサービスマネージャである情報システム部のA氏は“インシデント及びサービス要求管理プロセス”の整備と、プロセスを支援するツールの整備を行った。
整備された、インシデントに関する対応手順を表1に示す。

インシデント管理ファイルを用いたサービスデスク業務の運用には、次のような不都合があった。
・誰がいつファイルを更新したかの履歴管理ができない。
・メンバが誤ってファイルを削除してしまった場合、直近のバックアップからデータを復元する作業を行う必要があり、バックアップ時点以降の情報が失われる。
また、表計算ソフトのアクセス制御方式の制約から、①サービスデスク業務に支障を来す事象が発生していたので、RDBMSを用いてインシデント管理を運用するように変更した。
〔インシデント事例〕
K社では、セキュリティパッチ(以下、パッチという)をPCに展開する場合、自動で行う設定にしていた。ある日、“業務時間中にPCでパッチが自動的に展開された。パッチの展開が完了するまでは、PCの応答が遅くなり業務に支障がある。”といったインシデントが多くの利用者に発生した。対応を行ったサービスデスクのメソバは、インシデント管理担当として、本インシデントに対して②ある作業を実施することによって、インシデントを速やかに解決し、業務を再開させた。
また、別の利用者から“OSアップデートの終了後、流通業務サービスの一部の入力画面が正常に利用できない。”とのクレームを受けた。情報システム部で問題管理を担当している Z 氏が、OS アップデートに関するインシデントの根本原因を究明することになった。当該 PCの設定を調べたところ、パッチだけでなく、OS アップデートが OS メーカーから配信されたとき、自動的にこれを展開する設定となっていた。そこで、直ちにこの設定を止めることとした。
さらに、Z 氏が過去 1年間に発生した OS アップデートに関わるインシデントの状況を調査したところ、流通業務サービスの一部の機能が正常に利用できない事象が数回あったことを確認できた。そこで、OS メーカーから OS アップデートが配信されたときは、利用者の PCに展開する前に、情報システム部で③ある作業を実施することをルールとして定めた。
問題管理担当の業務として、このように日頃から、発生するインシデントの内容や状況を把握してインシデントのc分析を行い、インシデントの発生を事前予防的に防止する活動が必要となる。
〔マネジメントプロセスの改善〕
サービスデスクへの問合せには、流通業務サービスに関するものだけでなく、PCに関するものもあった。しかし、PCのハードウェア障害については、情報システム部の PC担当要員が対応する規定となっており、サービスデスクは対応していなかった。そのため、PCのハードウェア障害でサービスデスクに問い合わせた利用者は、PC担当要員に連絡し直す必要があった。利用者からは、“内容に応じて連絡先を選別しなければならないのは大変なので改善してほしい。”と情報システム部に要望があった。
そこで A氏は、窓口を一体化し、利用者からの全てのインシデントをサービスデスクで受付ける提案を情報システム部長に行った。提案の内容は、“サービスデスクは、流通業務サービスに関するインシデントについてはサービスデスク内で対応し、サービスデスクのメンバでは解決できない PCのハードウェア障害に関するインシデントについては、サービスデスクで受付けた後、dを行う。”といったものである。この提案は情報システム部長によって承認され、利用者に通知された後、実施されている。
また、情報システム部長は、管理項目を設けてサービスマネジメントの活動を管理するよう A氏に指示した。A氏は、“インシデント及びサービス要求管理プロセス”の CSF(重要成功要因)として “インシデントをできるだけ迅速に解消し、業務への影響を最小限にする。” を挙げ、④この CSF に対応した KPI(重要業績評価指標)を設定して活動を管理することにした。
設問1:〔サービスデスクの運用〕について、(1)、(2)に答えよ。
(1)K社の定義するインシデントに該当する事象はどれか。解答群の中から選び、記号で答えよ。
解答群
ア:サービス提供時間帯の停電による流通業務サービスの中断
イ:流通業務サービスのサービス提供時間帯の変更依頼
ウ:流通業務サービスの新規利用者の登録依頼
エ:利用者が定期的に行うパスワードの変更
模範解答
ア
解説
解答の論理構成
-
インシデントの定義を確認
【問題文】には
“K社では、ITサービスに対する計画外の中断やITサービスの品質の低下をインシデントと定義している。”
と明記されています。キーワードは「計画外の中断」「品質の低下」です。 -
各選択肢を定義と照合
- ア:サービス提供時間帯に停電が発生し、流通業務サービスが中断する事象。
→ 「計画外の中断」に該当。 - イ:サービス提供時間帯の変更依頼。
→ あらかじめ利用者が申請する「変更」であり計画外ではない。 - ウ:新規利用者の登録依頼。
→ 新しい利用者を追加する「サービス要求」であり、中断や品質低下ではない。 - エ:利用者が定期的に行うパスワード変更。
→ 定期的=計画的な作業であり、インシデントではない。
- ア:サービス提供時間帯に停電が発生し、流通業務サービスが中断する事象。
-
結論
「計画外の中断」に合致するのはアのみ。したがって答えはアです。
誤りやすいポイント
- 「サービス要求」と「インシデント」の区別を忘れがち
変更依頼や新規登録をインシデントと誤認すると誤答します。 - 「計画外」かどうかの判断を見落とす
定期的・事前申請済みの作業はインシデントではありません。 - 「品質低下」だけに気を取られ、「中断」を見逃す
中断もインシデント要件に含まれることを忘れないようにしましょう。
FAQ
Q: 「品質の低下」の具体例にはどのようなものがありますか?
A: 応答時間の遅延や表示崩れなど、サービスが動いてはいるが期待する性能を満たさないケースが該当します。
A: 応答時間の遅延や表示崩れなど、サービスが動いてはいるが期待する性能を満たさないケースが該当します。
Q: サービス提供時間外の障害はインシデントになりますか?
A: 提供時間外でも、次の提供時間に影響する恐れがあればインシデント扱いにするのが一般的です。
A: 提供時間外でも、次の提供時間に影響する恐れがあればインシデント扱いにするのが一般的です。
Q: 「サービス要求」はインシデント管理で扱わないのですか?
A: 多くのフレームワークではインシデント管理プロセスに付随して受付けますが、対応手順や優先度はインシデントと区別して管理します。
A: 多くのフレームワークではインシデント管理プロセスに付随して受付けますが、対応手順や優先度はインシデントと区別して管理します。
関連キーワード: インシデント管理, サービス要求, 中断, 品質低下, 優先度
設問1:〔サービスデスクの運用〕について、(1)、(2)に答えよ。
(2)本文中のa、bに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア:インシデントの制限
イ:既知の誤り
ウ:既知の制限
エ:変更
オ:未解決の誤り
カ:問題
模範解答
a:カ
b:イ
解説
解答の論理構成
-
【問題文】には
“二つ以上のインシデントの根本原因をaと呼び、“根本原因が特定されているが、若しくは回避策によってサービスへの影響を低減又は除去する方法があるa”をbと呼んでいる。”
とあります。 -
ITサービスマネジメント(ITIL)では、
• 複数インシデントの共通根本原因を「問題(Problem)」、
• 根本原因が判明しワークアラウンドが確立された問題を「既知の誤り(Known Error)」
と定義しています。 -
解答群を照合すると
• 「問題」は “カ:問題”、
• 「既知の誤り」は “イ:既知の誤り”
が該当します。 -
よって
a=“カ:問題”、b=“イ:既知の誤り” となります。
誤りやすいポイント
- 「インシデントの制限」や「未解決の誤り」を選びがちです。根本原因が未確定か確定か、ワークアラウンドの有無に注目しましょう。
- “変更”はチェンジマネジメントの語であり、問題管理プロセスの用語ではありません。
- 「既知の制限(ウ)」は ITIL 用語にないため選択肢として不自然です。
FAQ
Q: 「既知の誤り」と「問題」は同時に登録されるのですか?
A: まず「問題」を登録し、根本原因またはワークアラウンドが判明した時点で「既知の誤り」として再分類します。
A: まず「問題」を登録し、根本原因またはワークアラウンドが判明した時点で「既知の誤り」として再分類します。
Q: 「ワークアラウンド」とは何ですか?
A: 恒久対策が完了するまでサービスへの影響を最小化する暫定的な対処策です。既知の誤りに必ず紐付きます。
A: 恒久対策が完了するまでサービスへの影響を最小化する暫定的な対処策です。既知の誤りに必ず紐付きます。
Q: インシデントをすべて「既知の誤り」にすれば早く解決できますか?
A: ワークアラウンドがなければ「既知の誤り」とは呼べません。分類の誤用は管理品質を低下させるので注意が必要です。
A: ワークアラウンドがなければ「既知の誤り」とは呼べません。分類の誤用は管理品質を低下させるので注意が必要です。
関連キーワード: インシデント管理, 問題管理, 既知の誤り, ワークアラウンド, ITIL
設問2:
〔マネジメントプロセス及びツールの整備〕について、本文中の下線①の事象の内容を、30字以内で具体的に述べよ。
模範解答
複数のメンバが同時にファイルを更新できない。
解説
解答の論理構成
- 問題文は、現行運用の特徴として
「“インシデント管理ファイルに更新要求がある場合、表計算ソフトはファイルに対して排他ロックを施すアクセス制御を行って、整合性を確保している。”」と述べています。 - 排他ロックが掛かると、同じファイルを複数人が同時に書き換えることができません。
- 実際にサービスデスクでは「メンバ全員で利用されていた」ため、同時編集が必要になる場面が多々あります。
- したがって「表計算ソフトのアクセス制御方式の制約」→「①サービスデスク業務に支障を来す事象」とは、
“複数のメンバが同時にファイルを更新できない” ことだと論理的に帰結します。
誤りやすいポイント
- 「削除ミスによる復元作業」を答えてしまう
これは別の不都合として列挙されており、①の直接原因ではありません。 - 「誰が更新したか履歴が残らない」と解釈する
履歴管理の欠如も列挙事項ですが、①は排他ロックに起因する同時更新不可問題です。 - “閲覧”不可と誤認する
ロック対象は書込みであり、読み取りは可能です。書込み競合の問題である点に注意しましょう。
FAQ
Q: なぜ排他ロック方式がサービスデスクに不向きなのですか?
A: インシデント受付はリアルタイムで発生します。排他ロック方式では、一人が編集中の間、他のメンバは書込み待ちとなり、受付・更新が滞るためです。
A: インシデント受付はリアルタイムで発生します。排他ロック方式では、一人が編集中の間、他のメンバは書込み待ちとなり、受付・更新が滞るためです。
Q: RDBMS へ移行すると何が改善されるのですか?
A: RDBMS は行レベルロックやトランザクション管理により、多数のユーザが同時にデータを追加・更新しても整合性を保持できます。同時処理性能と履歴管理機能の双方を強化できます。
A: RDBMS は行レベルロックやトランザクション管理により、多数のユーザが同時にデータを追加・更新しても整合性を保持できます。同時処理性能と履歴管理機能の双方を強化できます。
Q: 同時更新を避ける別の方法はありますか?
A: バージョン管理付きのスプレッドシート、Web フォーム経由の入力なども考えられますが、大量データと複雑な検索・分析を行う場合は RDBMS が一般的です。
A: バージョン管理付きのスプレッドシート、Web フォーム経由の入力なども考えられますが、大量データと複雑な検索・分析を行う場合は RDBMS が一般的です。
関連キーワード: 排他ロック, 同時更新, トランザクション, データ整合性, アクセス制御
設問3:〔インシデント事例〕について、(1)〜(3)に答えよ。
(1)本文中の下線②の作業として適切な内容を解答群の中から選び、記号で答えよ。
解答群
ア:原因を調査するために情報システム部の技術者を派遣する。
イ:障害の発生を防止するために全社のPCを順次点検する。
ウ:パッチの展開を中断する。
エ:利用者が業務を手作業に切り換える。
模範解答
ウ
解説
解答の論理構成
- 事象の整理
- 【問題文】では、PCに「“パッチが自動的に展開された。パッチの展開が完了するまでは、PCの応答が遅くなり業務に支障がある。”」というインシデントが多数発生したと記述されています。
- インシデント対応の目的
- インシデント対応では、CSF “インシデントをできるだけ迅速に解消し、業務への影響を最小限にする。” が強調されています。したがって、今回も「業務を速やかに再開させる」ことが最優先です。
- 各選択肢の検討
- ア「原因を調査するために情報システム部の技術者を派遣する。」
→ 原因調査は重要ですが、調査完了までPCの負荷は続くため“速やか”な解決になりません。 - イ「障害の発生を防止するために全社のPCを順次点検する。」
→ 順次点検は長時間を要し、今まさにパッチが走っているPCの負荷を解除できません。 - エ「利用者が業務を手作業に切り換える。」
→ 手作業は回避策ではありますがPCの負荷問題自体は残り、業務を“再開”させたとは言い難いです。 - ウ「パッチの展開を中断する。」
→ パッチ処理を止めれば CPU・ディスク負荷が直ちに軽減され、PC応答が回復します。結果として【問題文】の「インシデントを速やかに解決し、業務を再開させた。」に合致します。
- ア「原因を調査するために情報システム部の技術者を派遣する。」
- 結論
- 以上より、下線②に入る“ある作業”は「パッチの展開を中断する」、すなわち解答群「ウ」が妥当です。
誤りやすいポイント
- 「原因調査=最優先」と誤解し、選択肢アを選ぶ。インシデント管理では“影響低減の即応”が先です。
- パッチ適用自体を安全面から止めてはいけないと思い込み、選択肢ウを避けてしまう。緊急時は一時停止も許容されます。
- 手作業への切替え(エ)が“業務継続”と読めるため選びやすいが、今回の業務はPC操作が前提であり手作業は実質的な停止に近い点を見落としがちです。
FAQ
Q: パッチを中断するとセキュリティリスクは発生しませんか?
A: 長期的にはリスクが残ります。しかし【問題文】が求めるのは“速やかな業務再開”です。中断後に業務時間外で計画展開すればリスクと業務影響の両方を最小化できます。
A: 長期的にはリスクが残ります。しかし【問題文】が求めるのは“速やかな業務再開”です。中断後に業務時間外で計画展開すればリスクと業務影響の両方を最小化できます。
Q: なぜサービスデスクだけで判断して中断できたのですか?
A: 【問題文】に「サービスデスクのメンバは、本サービスに精通した4人」とあるため、緊急対応の権限が委譲されている前提です。
A: 【問題文】に「サービスデスクのメンバは、本サービスに精通した4人」とあるため、緊急対応の権限が委譲されている前提です。
Q: 調査や恒久対策はいつ行うのですか?
A: 本設問は“インシデント解決”フェーズです。恒久対策は後続の問題管理プロセスで実施し、【問題文】でもZ氏が「OS アップデートに関するインシデントの根本原因を究明」しています。
A: 本設問は“インシデント解決”フェーズです。恒久対策は後続の問題管理プロセスで実施し、【問題文】でもZ氏が「OS アップデートに関するインシデントの根本原因を究明」しています。
関連キーワード: インシデント管理, 優先度設定, 暫定対処, 影響低減, 問題管理
設問3:〔インシデント事例〕について、(1)〜(3)に答えよ。
(2)本文中の下線③の作業として、OSのアップデートを利用者のPCに展開する前に、情報システム部で実施しておくべき作業の内容を40字以内で述べよ。
模範解答
OSのアップデートを展開しても流通業務サービスに影響がないことを試験する。
解説
解答の論理構成
- 原因の把握
- 本文には、OSアップデートが自動展開された結果、
“流通業務サービスの一部の入力画面が正常に利用できない。”
という障害が起きたと明記されています。
- 本文には、OSアップデートが自動展開された結果、
- 自動展開の停止
- 問題管理担当の Z 氏は “直ちにこの設定を止める” としています。
つまり、無検証での自動アップデートがリスク要因だと判断しました。
- 問題管理担当の Z 氏は “直ちにこの設定を止める” としています。
- 再発防止策としての③の作業
- “OS メーカーから OS アップデートが配信されたときは、利用者の PCに展開する前に、情報システム部で③ある作業を実施することをルールとして定めた。”
とあることから、③は利用者 PC へ配布する“前”に行う確認作業です。
- “OS メーカーから OS アップデートが配信されたときは、利用者の PCに展開する前に、情報システム部で③ある作業を実施することをルールとして定めた。”
- 作業内容の導出
- 目的は “流通業務サービスの一部の機能が正常に利用できない事象” を防止すること。
- よって、アップデートを適用しても自社サービスに悪影響が出ないかどうかを事前に“試験”することが合理的結論となります。
以上より、③に入る作業は
“OSのアップデートを展開しても流通業務サービスに影響がないことを試験する。”
が妥当です。
“OSのアップデートを展開しても流通業務サービスに影響がないことを試験する。”
が妥当です。
誤りやすいポイント
- “アップデートを検証環境でテストする”ことを、「展開後に確認」と誤読しがちです。本文は“展開する前に”と強調しています。
- “パッチ”と“OSアップデート”を混同すると、③の対象作業をパッチ検証と勘違いする恐れがあります。③はあくまでも“OSアップデート”です。
- “設定を止める”だけが対策だと早合点し、追加の検証工程を見落とすケースがあります。
FAQ
Q: 事前試験はテスト PC だけでよいのですか?
A: 原文は試験方法の詳細を指定していませんが、一般にはテストPCや検証環境でアップデートを適用し、自社サービスが正常動作するかを確認します。
A: 原文は試験方法の詳細を指定していませんが、一般にはテストPCや検証環境でアップデートを適用し、自社サービスが正常動作するかを確認します。
Q: パッチの場合も同じプロセスを適用すべきでしょうか?
A: セキュリティパッチは緊急性が高いため、本番即時適用を選択する場合があります。ただし重要な業務システムへの影響度合いを考慮し、可能な範囲で事前試験を行うことが望ましいです。
A: セキュリティパッチは緊急性が高いため、本番即時適用を選択する場合があります。ただし重要な業務システムへの影響度合いを考慮し、可能な範囲で事前試験を行うことが望ましいです。
Q: 問題管理と変更管理はどう役割分担するのですか?
A: 問題管理は根本原因の究明と恒久対策の立案までを担い、変更管理はその対策(今回なら検証付きアップデート手順)を実際に実装・展開する際の承認とコントロールを行います。
A: 問題管理は根本原因の究明と恒久対策の立案までを担い、変更管理はその対策(今回なら検証付きアップデート手順)を実際に実装・展開する際の承認とコントロールを行います。
関連キーワード: インシデント管理, 問題管理, パッチ管理, 変更管理, 事前検証
設問3:〔インシデント事例〕について、(1)〜(3)に答えよ。
(3)本文中のcに入れる適切な字句を5字以内で答えよ。
模範解答
c:傾向
解説
解答の論理構成
- 問題文には、問題管理担当の業務として「発生するインシデントの内容や状況を把握してインシデントのc分析を行い、インシデントの発生を事前予防的に防止する活動」が必要であると記載されています。
- ITIL では、問題管理がインシデントを再発防止・予防するために行う分析として “Trend Analysis(傾向分析)” を定義しています。
- さらに本文には、Z 氏が「過去 1 年間に発生した OS アップデートに関わるインシデントの状況を調査した」とあり、これはインシデントの発生パターンを時系列で追い、今後の予防策を検討する典型的な“傾向”の把握です。
- 以上より、c に入る語として最も妥当なのは「傾向」であり、模範解答も「傾向」と示されています。
誤りやすいポイント
- 「根本原因分析(RCA)」と混同しやすい
インシデントの根本原因そのものを突き止める活動は“根本原因分析”ですが、本設問は継続的にデータを蓄積し統計的に見る“傾向分析”を問うています。 - “統計” “分析”といった単語をそのまま埋めてしまう
文脈上、「インシデントの**分析」とだけ読むと“統計分析”“原因分析”といった語も連想されます。本文が示す「事前予防的に防止する」目的と ITIL 用語を結び付けることが重要です。
FAQ
Q: 傾向分析と根本原因分析はどう違いますか?
A: 傾向分析はインシデントの発生数や内容を時系列・カテゴリ別に集計し、将来起こりそうな問題を予測する活動です。一方、根本原因分析は既に発生した重大な問題の“原因そのもの”を突き止め再発防止策を決定する活動です。
A: 傾向分析はインシデントの発生数や内容を時系列・カテゴリ別に集計し、将来起こりそうな問題を予測する活動です。一方、根本原因分析は既に発生した重大な問題の“原因そのもの”を突き止め再発防止策を決定する活動です。
Q: 問題管理とインシデント管理の違いは?
A: インシデント管理はサービスを早期復旧させることが目的で、暫定回避策でも構いません。問題管理はインシデントの根本原因を除去し、再発を防止することが目的です。
A: インシデント管理はサービスを早期復旧させることが目的で、暫定回避策でも構いません。問題管理はインシデントの根本原因を除去し、再発を防止することが目的です。
Q: 「過去 1 年間」など期間を区切って調査するのはなぜですか?
A: 十分なデータ量を確保しつつ最新の環境変化を反映できる期間を設定することで、傾向分析の精度を高め、的確な予防策を策定できるためです。
A: 十分なデータ量を確保しつつ最新の環境変化を反映できる期間を設定することで、傾向分析の精度を高め、的確な予防策を策定できるためです。
関連キーワード: 傾向分析, 問題管理, インシデント管理, 予防保守
設問4:〔マネジメントプロセスの改善〕について、(1)、(2)に答えよ。
(1)本文中のdに入れる適切な字句を表1から選び、10字以内で答えよ。
模範解答
d:段階的取扱い
解説
解答の論理構成
-
【問題文】では、A 氏の提案として
“サービスデスクのメンバでは解決できない PCのハードウェア障害に関するインシデントについては、サービスデスクで受付けた後、dを行う。”
と記載されています。ここで求められるのは「サービスデスクで解決できない場合に取るべき行動」を示す語句です。 -
表1 における該当手順を確認すると
“段階的取扱い:サービスデスクのメンバだけで解決できないインシデントは、決められた専門部署に調査を依頼する。”
と明記されています。 -
【問題文】の状況──「PCのハードウェア障害」はサービスデスクの専門外であり、専門部署(PC担当要員)に対応を引き継ぐ必要がある──は、表1 の “段階的取扱い” の説明と完全に一致します。
-
よって、d に入る適切な字句は “段階的取扱い” となります。
誤りやすいポイント
- “分類” や “優先度の割当て” といった表1 の他手順と混同してしまう。これらは解決の前準備であり、専門部署へ依頼する処理ではありません。
- “解決” を選んでしまうミス。解決はあくまでも対処方法が決まっている場合に行う手順であり、解決できないケースではない点に注意が必要です。
- “段階的取扱い” の意味を「段取りを決める」と誤解するケース。実際には「エスカレーション(専門部署に調査依頼)」を指しています。
FAQ
Q: “段階的取扱い” は具体的にどのような行動を指すのですか?
A: サービスデスクで解決不能なインシデントを、あらかじめ決められた専門部署へエスカレーションし、調査や対応を依頼する行動を意味します。
A: サービスデスクで解決不能なインシデントを、あらかじめ決められた専門部署へエスカレーションし、調査や対応を依頼する行動を意味します。
Q: なぜ“解決”ではなく“段階的取扱い”なのですか?
A: “解決”はサービスデスクが対処手順書や専門部署からの回答を基に処置を終えるフェーズです。一方、今回のケースは「サービスデスクで解決できない」状況なので、まず専門部署へ依頼する“段階的取扱い”が正しい流れとなります。
A: “解決”はサービスデスクが対処手順書や専門部署からの回答を基に処置を終えるフェーズです。一方、今回のケースは「サービスデスクで解決できない」状況なので、まず専門部署へ依頼する“段階的取扱い”が正しい流れとなります。
Q: “段階的取扱い” を実行した後のサービスデスクの役割は?
A: 専門部署からの調査結果を受け取り、利用者への報告・最終的な“解決”・“終了”までのプロセスを追跡・管理する役割を担います。
A: 専門部署からの調査結果を受け取り、利用者への報告・最終的な“解決”・“終了”までのプロセスを追跡・管理する役割を担います。
関連キーワード: インシデント管理, サービスデスク, エスカレーション, CSF, KPI
設問4:〔マネジメントプロセスの改善〕について、(1)、(2)に答えよ。
(2)本文中の下線④のKPIとしてふさわしいものを解答群の中から二つ選び、記号で答えよ。
解答群
ア:インシデントの解決に掛かった優先度別の平均所要時間
イ:業務に影響を与えることなく解決したインシデントの数
ウ:繰り返されるインシデントの数
エ:流通業務サービスの問題解決に掛かった平均費用
模範解答
ア、イ
解説
解答の論理構成
- 【問題文】では、情報システム部の A 氏が CSF として
“インシデントをできるだけ迅速に解消し、業務への影響を最小限にする。”
を掲げたと明記されています。 - KPI は CSF の達成度を定量的に測る指標であるため、
①「迅速に解消」…インシデント対応のスピードを測る指標
②「業務への影響を最小限」…影響を受けずに済んだ件数や割合を測る指標
の二系統が求められます。 - 解答群を照合すると
・ア「インシデントの解決に掛かった優先度別の平均所要時間」は①に該当。
・イ「業務に影響を与えることなく解決したインシデントの数」は②に該当。
・ウ「繰り返されるインシデントの数」は再発防止の観点であり、今回の CSF には直接ひも付きません。
・エ「流通業務サービスの問題解決に掛かった平均費用」は費用効率の指標であり、CSF の主旨とずれます。 - したがって KPI として適切なのは
ア、イ
誤りやすいポイント
- 「繰り返されるインシデントの数」を選びがちですが、CSF に“再発防止”という文言はありません。
- 費用系指標(エ)は ITIL でも別の視点(コスト最適化)の KPI に分類されるため、スピード&影響最小化を目的とする CSF とは一致しません。
- KPI は“測定できる数値”でなければならないため、「平均所要時間」「件数」といった具体的な形を確認しましょう。
FAQ
Q: 「平均所要時間」の“優先度別”は必須ですか?
A: はい。高優先度インシデントの早期解決が特に重要なため、優先度別に分けて測定することでボトルネックを把握できます。
A: はい。高優先度インシデントの早期解決が特に重要なため、優先度別に分けて測定することでボトルネックを把握できます。
Q: 「業務に影響を与えることなく解決したインシデントの数」はどのように把握しますか?
A: インシデント記録に“業務影響有無”のフラグを設け、影響なし=0分の停止時間として集計します。
A: インシデント記録に“業務影響有無”のフラグを設け、影響なし=0分の停止時間として集計します。
Q: KPI は何個設定すればよいですか?
A: ITIL では CSF 一つに対し複数 KPI を設けるのが一般的です。今回のように速度と影響の2系統を置くと、バランス良く管理できます。
A: ITIL では CSF 一つに対し複数 KPI を設けるのが一般的です。今回のように速度と影響の2系統を置くと、バランス良く管理できます。
関連キーワード: CSF, KPI, インシデント管理, 平均解決時間, サービス品質


