平成29年度 秋期 午後Ⅰ

平成29年度 秋期に実施されたITサービスマネージャ試験 午後Ⅰの全3問(記述式)です。事例本文・設問・解答例と解説をそのまま読めます。

この年度を解いてみる

問1 IT サービスの可用性

IT サービスの可用性に関する次の記述を読んで,設問1〜3に答えよ。

U 社は,POS システムを小売業者に販売している電気通信機器メーカである。扱っている POS システムの構成は,表1のとおりである。

機器と説明の2列からなる表。POS レジ:ストアコントローラと接続して単品情報管理を行う端末機であり,精算に必要なプログラム及びデータを保有している。自動で入金・釣銭を管理する自動釣銭機をもち,自動釣銭機が故障すると POS レジも利用不可となる。ストアコントローラ:POS レジの上位コントローラであり,接続している POS レジの状態監視を常時行い,POS レジから 30 分間隔でデータを収集する。他システムとのデータ送受信を行う。
表1 POS システムの構成

POS システムを設置した店舗では,POS システムが提供するサービス(以下,POS サービスという)によって,レジ業務の初心者でも精算ミスが発生せず,かつ,効率的な現金管理が可能である。POS サービスには,レジでの精算待ち時間の短縮が求められており,高い可用性が必要である。

〔Z 社の POS システムの利用〕

Z 社は,全国に 100 店舗をもつ小売業者であり,3 年前に U 社の POS システムを導入した。Z 社の POS システムの利用状況は,次のとおりである。

また,Z 社は U 社との間で POS サービスの SLA を締結している。SLA の可用性については,店舗ごとにサービス稼働率を計算して求める。店舗に POS レジが複数台設置されている場合は,POS レジごとにサービス稼働率を計算した値を設置台数で平均して,店舗のサービス稼働率とする。SLA の抜粋を表2に示す。

種別・サービスレベル項目・サービスレベル目標の3列からなる表。可用性のサービス時間:店舗の営業時間帯(営業日の 7 時から 23 時まで)。可用性のサービス稼働率:月間 99.5%以上。注1)サービスを利用できる確率((計画サービス時間 − 停止時間)÷ 計画サービス時間)。ここで,停止時間は,POS レジが故障したときの POS レジの故障時間を使用する。
表2 POS サービスの SLA(抜粋)

Z 社では,全ての店舗の POS システムの監視を含む保守サービスを,U 社に委託している。U 社では,監視センタから監視システムを利用して POS システムの稼働状況を監視する。全体のシステム構成を図1に,Z 社の各店舗に設置したストアコントローラが POS レジから収集している稼働状況のデータを表3に示す。

U 社と Z 社を IP-VPN で結んだシステム構成図。U 社の監視センタには,ルータ,SW,監視システム,監視端末が順に接続されており,ルータが IP-VPN につながる。Z 社側には店舗1から店舗 m までと本社がある。店舗1には点線で囲まれた POS システムがあり,その中にストアコントローラと POS レジ1から POS レジ n までが入っていて,いずれも SW に接続されている。SW にはルータも接続され,ルータが IP-VPN につながる。本社にはルータ,SW,販売システムが順に接続され,ルータが IP-VPN につながる。SW はレイヤ2スイッチ。
図1 全体のシステム構成
データと内容の2列からなる表。資源の状況:POS レジの CPU 使用率,メモリ使用率及びストレージの使用量。機器の状態:データ収集時点及び障害発生時点における POS レジの詳細な状態情報。故障エラーログ:POS レジ故障に関する情報。稼働履歴情報:レシート印刷,釣銭返却などの履歴情報。詳細な情報を記録しているので,利用頻度に比例してデータ量が増加する。
表3 ストアコントローラが POS レジから収集している稼働状況のデータ

〔U 社の POS システムの保守サービス〕

U 社では,次に示す予防保守及び事後保守の 2 種類の保守サービスを提供している。

(1) 予防保守は,定められた時間計画に従って実施される時間計画保守と,POS システムの監視に基づく状態監視保守に分かれる。さらに,時間計画保守には,次に示す 2 種類の保守がある。

(2) 事後保守は,POS システムに故障が発生し,監視システムで故障を検出した場合に緊急で修理を行う保守である。POS レジに故障が発生した場合の回復手順は,表4のとおりである。

手順と内容の2列からなる表。①検出:POS レジ故障を検出し,インシデントとして記録する。②診断:インシデントを調査し,診断を行う。故障した POS レジの店舗担当者へのヒアリング,POS レジの状況の確認に必要な情報収集,及び故障部位の特定を行う。監視システムの情報収集ツールを利用して診断を行う。③修理:故障した POS レジの店舗に保守員を派遣して,診断で特定した故障部位を修理(交換)する。部品交換が必要な場合は,近隣の部品倉庫から修理に必要な部品を調達する。④復旧:POS レジを復旧させる。POS レジの利用再開に当たってデータの修正が必要な場合は,データの修正を行う。⑤回復:故障した POS レジの店舗担当者に,POS レジが回復しているかを確認する。回復していれば,対応を終了する。注1)POS システムのストアコントローラから,指定する POS レジの情報を収集するプログラムである。収集するデータの種類,期間を指定することができる。
表4 POS レジに故障が発生した場合の回復手順

U 社は,これらの保守サービスのうち,店舗で行う作業を C 社に委託している。C 社では,修理用部品の在庫を確保し,サービス拠点に保守員を配置している。新規に POS サービスを開始する店舗がある場合,U 社は,事前に C 社に連絡する。C 社は,POS システムの設置場所及び機器の設置数に応じて,修理用部品の在庫及び保守員の配置を見直すことにしている。

〔POS システムの監視〕

(1) 予防保守で行う POS システムの監視は,次のとおりである。

(2) 事後保守で行う POS システムの監視は,次のとおりである。

〔Z 社の POS レジ故障の事例〕

ある日,Z 社のある店舗で自動釣銭機が故障し,POS レジを利用できなくなった。この店舗では,POS レジ 1 台で POS システムが運用されていた。U 社のインシデント担当者の V 氏は,表4に示す回復手順に従って①〜⑤の対応を行った。

Z 社の店舗の対応は,当該 POS レジの故障発生から 3 時間後の 24 時に終了した。

〔監視データの分析〕

U 社の IT サービスマネージャの D 氏は,表 4 の各回復手順を短縮するために,故障対応記録と,監視システムに蓄積された過去数年間の監視データを分析した。監視データは膨大なデータ量なので,ビッグデータの解析手法を適用し,今回の故障に関する次の知見を得た。

これらの分析結果から,D 氏は今回と同様の故障が発生する兆候を捉えることができると考えた。そこで,POS レジ故障を未然に防止するために,D 氏は,(ア)ストアコントローラの機能変更(イ)保守サービスの見直しを行うことによって,サービス稼働率を向上できると考えた。

〔修理時間の短縮〕

D 氏は,サービスレベルを維持するために C 社と連携して,修理時間の短縮について,次のような対策を検討した。

出題趣旨(IPA)

企業の業務を支援するITサービスには,少ないサービスの停止時間などの,高い可用性が求められる。本問では,POSシステムを題材に,障害回復手順の整備,修理時間の短縮,予防保守などの観点から,ITサービスの可用性に関する管理能力,障害に対するサービスの回復力を向上させる能力,及び供給者管理の実務能力を問う。

設問と解答例

設問1(1)

SLA に基づく可用性に関して,今回故障した POS レジ故障発生月の当該店舗におけるサービス稼働率を%単位で求め,小数第 2 位を四捨五入して小数第 1 位まで答えよ。ここで,故障発生月の稼働日は 30 日とし,故障発生月には今回の故障だけが発生したものとする。

解答例

  • 99.6
解説

本文の根拠

表2

可用性のサービス時間:店舗の営業時間帯(営業日の 7 時から 23 時まで)。可用性のサービス稼働率:月間 99.5%以上。

表2 注1

サービスを利用できる確率((計画サービス時間 − 停止時間)÷ 計画サービス時間)。ここで,停止時間は,POS レジが故障したときの POS レジの故障時間を使用する。

〔Z 社の POS レジ故障の事例〕

Z 社の店舗の対応は,当該 POS レジの故障発生から 3 時間後の 24 時に終了した。

計画サービス時間から出す。サービス時間は7時から23時までなので1日16時間,稼働日は30日なので 16 × 30 = 480時間。

次に停止時間。故障は21時に発生し,対応が終わったのは24時なので,止まっていたのは3時間である。ただしサービス時間は23時までで,23時から24時はもともとサービスの外にある。数えるのは21時から23時までの2時間だけである。

(480 - 2)÷ 480 = 0.995833…

99.5833…%を小数第2位で四捨五入して99.6%。表2の目標99.5%以上は達成している。

この店舗はPOSレジ1台だけなので,複数台の平均を取る操作は要らない。3時間をそのまま使うと99.4%となって未達成に見えてしまうので,サービス時間の外を切り落とすところが分かれ目になる。

設問1(2) 40字以内

回復手順中の診断時間を短縮するための改善策を,情報の収集に着目して,40 字以内で述べよ。

解答例

  • 情報収集ツールを利用するときに,データの種類と期間を指定する。
解説

本文の根拠

表4 注1

POS システムのストアコントローラから,指定する POS レジの情報を収集するプログラムである。収集するデータの種類,期間を指定することができる。

〔Z 社の POS レジ故障の事例〕

情報収集ツールを利用して,店舗のストアコントローラから当該 POS レジに関する,表3の全てのデータを収集した。当該 POS レジは利用期間が長く,利用頻度も高かったので,通常は 10 分程度で終了する情報収集に 30 分掛かった。

表3

稼働履歴情報:レシート印刷,釣銭返却などの履歴情報。詳細な情報を記録しているので,利用頻度に比例してデータ量が増加する。

V氏は表3の全てのデータを収集した。だから通常10分のところ30分かかった。

実際に診断に使えたのは「機器の状態」と「故障エラーログ」の2つで,本文も「収集したその他のデータには,診断に役立つ情報はなかった」と書いている。とくに稼働履歴情報は利用頻度に比例してデータ量が増えるうえ,このPOSレジは利用頻度が高い。時間がかかった主な原因はここにある。

情報収集ツールは,表4の注1のとおりデータの種類と期間を指定できる。使わずに全部を取ったのが遅れの理由なので,必要な種類と期間だけを指定して取る。

40字。解答例は「情報収集ツールを利用するときに,データの種類と期間を指定する。」で30字。「必要なデータだけ集める」では,どうやって絞るのかが言えていない。ツールに指定の機能があることまで書く。

採点講評(IPA)

設問1(2)は,誤った解答が散見された。故障の切分けに必要な情報を優先して収集することが,診断時間の短縮に直結することに気付いてほしかった。

設問2(1) 50字以内

本文中の下線(ア)で D 氏が考えた機能変更の内容を,50 字以内で述べよ。

解答例

  • 釣銭詰まりの障害が一定回数以上になった場合,予防保守を促すために,その情報を通知情報に加える。
解説

本文の根拠

〔監視データの分析〕

自動釣銭機が故障する前に,店舗で対応可能な釣銭詰まりの障害が頻発している。

〔POS システムの監視〕

通知情報には,POS レジの自動釣銭機の釣銭詰まりなど,故障ではないが店舗で対応可能な軽微な障害に関する機器の状態情報,部品の累積動作時間が一定時間以上,又は累積動作回数が一定回数以上になったことを示す経時保守に必要な情報が含まれる。

〔Z 社の POS レジ故障の事例〕

前日から,釣銭詰まりが複数回発生しており,その都度対応していたが,今回は店舗だけでは対応できない。

分析で分かったのは,自動釣銭機が故障する前に釣銭詰まりが頻発するということである。今回の事例でも前日から複数回起きていた。つまり釣銭詰まりの頻発が,故障の前ぶれになっている。

釣銭詰まりの情報自体は,すでに通知情報に入っている。ただし1件ずつの軽微な障害として上がるだけなので,頻発しているかどうかは見えない。V氏も通知が記録されていることは確認したが,それだけで終わっている。

そこで,経時保守の情報が「累積動作回数が一定回数以上になったこと」を通知する形になっているのにならう。釣銭詰まりも一定回数以上になったら,予防保守を促す情報として通知させる。通知情報を作って送っているのはストアコントローラなので,変えるのはその機能になる。

50字。解答例は「釣銭詰まりの障害が一定回数以上になった場合,予防保守を促すために,その情報を通知情報に加える。」で46字。

採点講評(IPA)

設問2(1)は,正答率が高かった。故障を未然に防止するために,傾向を特定する事前予防的な活動が有効であることは,理解されているようであった。

設問2(2) 30字以内

本文中の下線(イ)で D 氏が考えた見直しの内容を,30 字以内で述べよ。

解答例

  • 硬貨搬送ベルトの点検に経時保守を追加する。
解説

本文の根拠

〔U 社の POS システムの保守サービス〕

定期保守:予定の時間間隔で部品の検査・交換を実施する。

〔U 社の POS システムの保守サービス〕

経時保守:予定の累積動作時間・累積動作回数に達したときに,部品の検査・交換を実施する。POS システムの構成部品には,稼働状況や消耗度合いに応じて交換が必要な部品がある。

〔Z 社の POS レジ故障の事例〕

硬貨搬送ベルトは定期保守で一定期間ごとに交換しているが,当該 POS レジは利用頻度が高く,自動釣銭機の硬貨搬送ベルトが摩耗して破損したことが故障の原因であった。

〔監視データの分析〕

経時保守で交換している部品の故障発生頻度は低い。

硬貨搬送ベルトは定期保守,つまり一定期間ごとに交換している。ところが摩耗の進み方は,経った時間ではなく使った量で決まる。利用頻度の高い店舗では,次の交換日が来る前に寿命が尽きる。今回の故障はこれである。

経時保守なら累積動作時間・累積動作回数で判断するので,よく使う店舗では早く,あまり使わない店舗では遅く交換することになり,利用頻度の差を吸収できる。分析結果にも「経時保守で交換している部品の故障発生頻度は低い」という裏付けがある。

だから硬貨搬送ベルトを経時保守の対象に加える。

30字。解答例は「硬貨搬送ベルトの点検に経時保守を追加する。」で21字。定期保守の間隔を短くする,という答えでは,利用頻度の低い店舗まで無駄に交換することになり,頻度の差そのものは解けない。

採点講評(IPA)

設問2(2)は,構成部品ごとに適切な予防保守を行う必要から,定期保守と経時保守の違いに着目して解答を導き出してほしかった。

設問3(1) 20字以内

本文中の a に入れる適切な内容を,20 字以内で述べよ。

解答例

  • 修理用部品の在庫及び保守員の配置
解説

本文の根拠

〔U 社の POS システムの保守サービス〕

C 社は,POS システムの設置場所及び機器の設置数に応じて,修理用部品の在庫及び保守員の配置を見直すことにしている。

〔修理時間の短縮〕

修理用部品の欠品を防ぐことによって部品手配時間を短縮し,C 社保守員を適正に配置することによって駆け付け時間を短縮することができる。

短縮したいのは部品手配時間と駆け付け時間の2つで,本文がそれぞれの手立てを挙げている。部品の欠品を防ぐことと,保守員を適正に配置することである。

C社はもともと「修理用部品の在庫及び保守員の配置」を見直す仕組みをもっている。ただし見直しの根拠は設置場所と設置数だけだった。そこにU社から利用状況と故障傾向の情報が入るので,どの部品がどこで要りそうかまで踏まえて見直せる。

20字。解答例は「修理用部品の在庫及び保守員の配置」で16字。2つとも挙げる。片方だけでは,短縮したい2つの時間の片方しか手当てできない。

設問3(2) 40字以内

U 社が C 社と目標値を設定するときに考慮すべき内容を,IT サービスマネジメントの視点から,40 字以内で述べよ。

解答例

  • 目標値はZ社のSLAと整合を図り,サービスレベルについてC社と合意する。
解説

本文の根拠

〔Z 社の POS システムの利用〕

Z 社は U 社との間で POS サービスの SLA を締結している。

〔修理時間の短縮〕

修理時間を確実に短縮するために,故障発生時の部品手配時間及び駆け付け時間について,新たにサービスレベルの目標値を設定し,C 社と SLA を締結する。

表2

可用性のサービス稼働率:月間 99.5%以上。

U社はZ社に対して,サービス稼働率を月間99.5%以上と約束している。1か月に許される停止時間の上限は,ここから決まる。

ところが実際に修理するのはC社である。C社の部品手配や駆け付けに時間がかかれば,そのぶん停止時間が延び,U社はZ社との約束を守れない。C社と決める目標値は,Z社との約束を支えるためのものである。

したがって,C社と勝手に決めるのではなく,Z社のSLAから逆算した値を置き,それでよいかをC社と合意する。顧客との約束と供給者との約束をつないでおく,というのがITサービスマネジメントの視点である。

40字。解答例は「目標値はZ社のSLAと整合を図り,サービスレベルについてC社と合意する。」で35字。「短い目標値にする」だけでは,何を根拠にその値なのかが言えていない。

採点講評(IPA)

設問3(2)は,正答率が低かった。サービス提供者は,サービス提供者と顧客との間のSLAを支え,整合を図るため,サービスレベルについて供給者と合意しなければならないことを理解しておいてほしい。

出典:平成29年度 秋期 ITサービスマネージャ試験 午後Ⅰ 問1(表記を一部改変)

問2 問題管理及び変更管理

問題管理及び変更管理に関する次の記述を読んで,設問1〜4に答えよ。

K 社は金融機関である。K 社の情報システム部では,顧客管理システムを運用しており,社内規程のプロセスに従って問題管理及び変更管理を行っている。IT サービスマネージャは情報システム部の E 氏が務めている。

〔K 社の問題管理プロセス〕

K 社の問題管理プロセスの手順は,表1のとおりである。

手順と内容の2列からなる表。(1)識別:次の(a),(b)又は(c)によって問題を識別する。(a) インシデントの未知の根本原因の検知,(b) 根本的な問題を明らかにするインシデントの分析,(c) 供給者(ソフトウェア開発元など)からの問題の通知。(2)記録:日時など関連する問題の詳細を記録する。また,手順(1)識別が(a)の場合(以下,インシデント発生ケースという)は,問題の記録の発端となったインシデントの相互参照などを記録する。(3)優先度の割当て:関連するインシデントがある場合は,関連するインシデントの緊急度及び影響に応じて解決の優先度を割り当てる。関連するインシデントがない場合は,独自に解決の優先度を設定する。優先度は高,又は低のいずれかを割り当てる。(4)分類:インシデントを管理するプロセスで使用しているものと同一の分類基準を利用して問題を分類する。(5)記録の更新:問題の追跡ができるように,問題の進捗状況を捉え,記録を更新する。(6)段階的取扱い:必要な場合は,該当する当事者に対して段階的取扱いを行う。(7)解決:①調査と診断として,問題を調査し,診断する。[ a ] が特定され,問題の解決方法が特定された時点で問題の診断を完了する。②既知の誤りの文書化として,[ a ] が特定されているか,若しくは回避策によってサービスへの影響を低減又は除去する方法がある問題を既知の誤りとして記録する。③問題の解決として,特定された解決方法を適用する。恒久的な解決策が構成品目(以下,CI という)の変更を必要とする場合は,変更管理プロセスに変更要求(以下,RFC という)を提起することによって解決する。(8)終了:解決策の詳細を記録する。全ての処置の完了後,問題解決の有効性を確認する。
表1 K 社の問題管理プロセスの手順

問題管理プロセスにおいて決定した解決策が,CI の変更を必要とする場合は,RFC を起票し,変更管理プロセスに従って処理する。K 社の RFC 管理項目と起票時の記入要領を,表2に示す。

項番・RFC 管理項目・起票時の記入要領の3列からなる表。項番1 変更要求番号:記入しない(RFC の一連番号であり,変更管理マネージャが RFC を受け付けたときに付番する)。項番2 件名:変更の内容が分かる名称を記入する。項番3 起票日:記入しない(RFC の受付年月日であり,変更管理マネージャが RFC を受け付けたときに記入する)。項番4 起票者:RFC を起票した者の所属及び氏名を記入する。項番5 変更対象の CI:変更の対象となる CI を記入する。版など CI の属性が必要な場合は属性情報も記入する。項番6 変更種別:別途,定めている規則に従って,軽微,重要,重大のうちのいずれかを記入する。項番7 変更内容:変更の概要を記入する。項番8 [ b ]:記入要領は網掛けで表示されていない。項番9 事業利益:変更の実施によって得られる事業上の利益を記入する。項番10 優先度:緊急又は通常のどちらかを記入する。項番11 要求納期:変更を実施する期限を記入する。項番12 サービス及び顧客への潜在的影響:変更を実施しない場合のサービス及び顧客への影響を記入する。項番13 リスク:変更を実施することによって発生する可能性があるリスクを記入する。項番14 技術的実現可能性:起票時点において分かる範囲で,変更に必要な資源及びキャパシティを記入する。項番15 工数,費用など財務的な影響:変更に必要な工数,費用などを記入する。項番16 変更の責任者:予定している責任者を記入する。項番17 他の変更との関係:関連する変更がある場合は,該当する変更要求番号を記入する。注記として,網掛けの部分は表示していない。注1)CI の属性は構成管理データベース(以下,CMDB という)に記録されている。
表2 K 社の RFC 管理項目と起票時の記入要領

〔K 社の変更管理プロセス〕

RFC は,変更管理プロセスの手順に従って処理される。K 社の変更管理プロセスの手順(抜粋)は,表3のとおりである。

手順と内容の2列からなる表。(1)RFC の記録と分類:変更管理マネージャが RFC を受け付け,RFC の登録・分類を行う。変更管理マネージャは,E 氏が務める。(2)RFC の評価:指名された代表で組織する変更諮問委員会(以下,CAB という)が,変更の影響について助言する。CAB の詳細は次のとおりである。CAB の構成メンバ(以下,CAB 要員という)は,サービス及び事業環境への影響の範囲に応じて選定され,登録される。情報システム部の場合は,技術的専門分野の要員から CAB 要員の候補者を選定する。CAB は毎週火曜日に定期的に開催するが,RFC の優先度が緊急の場合は RFC の受付から 2 日以内に臨時開催する。CAB の議長は,E 氏が務める。E 氏は(ア)CAB 要員に RFC の内容を事前に送付し,CAB の開催を通知する。(3)RFC の受入れ決定:RFC の受入れ及び承認に関する決定権限をもつ変更決定者を定める。変更種別が重要又は重大の変更決定は情報システム部の部長が行い,それ以外の変更種別の変更決定は E 氏が行う。変更決定者の役割は次のとおりである。変更決定者は CAB に出席し,CAB 要員による評価を考慮して,RFC の受入れを決定する。意思決定では,リスク,サービス及び顧客への潜在的影響,サービスの要求事項,事業利益,技術的実現可能性並びに財務的な影響を考慮する。(4)変更の実施:承認された RFC をリリース及び展開管理プロセスに提供する。変更の展開が成功した後に,[ c ] する。(以下,省略)。(省略)。例1)本年 10 月は,3 日,10 日,17 日,24 日及び 31 日に開催する。
表3 K 社の変更管理プロセスの手順(抜粋)

〔問題管理の現状〕

情報システム部では,問題の記録を問題管理データベース(以下,問題管理 DB という)で管理しており,インシデント発生ケースについての問題の解決状況を示す指標である問題解決率を問題管理会議で毎週確認している。問題解決率は問題の“優先度”ごとに次の式で求める。

問題解決率 = (問題の総件数 − 終了していない問題の件数)÷ 問題の総件数

問題管理会議は実務担当者で構成され,E 氏が議長を務める。E 氏は,問題管理会議の決定事項を情報システム部の部長に報告する。

ある日,E 氏は情報システム部の部長から“‘優先度’が‘低’の問題について,全ての問題を一律に管理するのではなく,早期に解決できる問題又は早期に解決すべき問題が,どれだけ解決できているかを週次で確認したい。問題解決率の算出方法を工夫するように。”と指示された。そこで E 氏は,部長の指示に従って,問題解決率の算出方法を工夫して,d を問題解決率の計算対象から除外する運用を始めることにした。

なお,現在,問題管理 DB に登録されているインシデント発生ケースの問題で,かつ,“優先度”が“低”の問題は 100 件である。そのうち,終了していない問題の状況は,表4のとおりであった。

項番・原因・再発インシデント・問題の件数(件)の4列からなる表。項番1:原因は特定できた,再発インシデントあり,3 件。項番2:原因は特定できた,再発インシデントなし,5 件。項番3:原因は特定できない,再発インシデントあり,2 件。項番4:原因は特定できない,再発インシデントなし,6 件。合計 16 件。注1)問題を起票するきっかけとなったインシデントとは別に,同じ事象が発生したインシデントのことである。
表4 終了していない問題の状況

〔月次集計プログラムの問題とその対応〕

顧客管理システムでは,開発元の Q 社から提供されている月次集計プログラム(以下,P1 という)を使用し,毎月 20 日の夜間バッチジョブで顧客別の月間取引集計処理を行っている。夜間バッチジョブはオンライン処理開始までに終了する必要がある。

本年 10 月 10 日に Q 社から,顧客管理システムの運用を担当している情報システム部の G 氏に対して,“P1 の処理に問題があり,特定の条件において集計データの一部が後続の処理に正しく引き継がれないという不具合が発見された。”という連絡があった。

(1) Q 社の対応

Q 社は,問題が含まれる P1 の版についての情報と,対策済みの P1 の最新版を既に自社の Web サイトに公開していて,速やかな対応を促していた。また,Q 社の Web サイトには,“最新版では対策ロジックの追加に伴い,従来の版よりも処理時間が長くなる場合がある。”という注意書きが掲載されていた。

(2) K 社の対応

G 氏は,CMDB を検索して,P1 は顧客管理システムだけで使用していること,及び現在 K 社で使用している P1 が問題のある版であることを確認した。顧客管理システムでは Q 社が指摘する問題によるインシデントはこれまで発生していなかった。

① 変更計画の立案

G 氏は,Q 社が推奨しているように速やかに対応を行う必要があると判断し,変更管理プロセスに従って,10 月 20 日の集計処理までに対応を完了する変更計画を立てることにした。

G 氏が考えた変更計画の概要は,次のとおりである。

② P1 の最新版への変更

G 氏は P1 を最新版に変更する RFC の起票に取り掛かり,表 2 の記入要領に従って次のように RFC 管理項目を記入し,10 月 11 日に RFC を提起した。

E 氏は,G 氏から提出された RFC の内容を確認し,G 氏に対して“事前に実施する確認テストは,テスト環境でテストデータを用いた機能の確認テストである。稼働環境とは機器の性能及び処理するデータ量が異なるので,(ウ)RFC 管理項目の“リスク”については懸念される内容を記載すべきである。”と指摘した。

出題趣旨(IPA)

ITサービスマネジメントの日常管理を通じて,標準化された問題管理プロセス及び変更管理プロセスを確立することが重要になる。本問では,問題管理における問題解決,変更管理におけるRFCの受入れ,意思決定における考慮点,構成管理プロセスとの連携などを題材に,サービスマネジメントの実務能力について問う。

設問と解答例

設問1(1) 10字以内

表1中の a に入れる適切な字句を,10 字以内で答えよ。

解答例

  • 根本原因
解説

本文の根拠

表1 (1)識別

(a) インシデントの未知の根本原因の検知

表1 (7)解決

②既知の誤りの文書化として,a が特定されているか,若しくは回避策によってサービスへの影響を低減又は除去する方法がある問題を既知の誤りとして記録する。

問題管理が何を探す活動かは,手順(1)の識別に書いてある。「インシデントの未知の根本原因の検知」である。探しているのは根本原因なので,診断が終わる条件もそこになる。

②の既知の誤りの定義からも確かめられる。既知の誤りとは「根本原因が特定されているか,回避策がある問題」のことで,この2つが並ぶ形になっている。

10字。解答例は「根本原因」で4字。「原因」だけでも意味は通るが,本文が使っている語をそのまま当てる。

設問1(2) 10字以内

表2中の b に入れる適切な字句を,K 社の変更管理プロセスの手順を参考にして 10 字以内で答えよ。

解答例(2通り)

  • サービスの要求事項
  • 変更の理由
解説

本文の根拠

表3 (3)RFC の受入れ決定

意思決定では,リスク,サービス及び顧客への潜在的影響,サービスの要求事項,事業利益,技術的実現可能性並びに財務的な影響を考慮する。

表2

項番9 事業利益:変更の実施によって得られる事業上の利益を記入する。

設問が「K社の変更管理プロセスの手順を参考にして」と言っているので,表3の意思決定で考慮する6つを,表2の管理項目と1つずつ突き合わせる。

リスクは項番13,サービス及び顧客への潜在的影響は項番12,事業利益は項番9,技術的実現可能性は項番14,財務的な影響は項番15。

残る「サービスの要求事項」だけ,対応する項番が見当たらない。これが空欄bである。意思決定で考慮するものは,RFCに書いてなければ判断できない,という関係になっている。

10字。解答例は「サービスの要求事項」で9字。変更の理由という形で書いてもよい。

採点講評(IPA)

設問1(2)は,正答率が低かった。表3の変更管理プロセスの手順を読み取って,解答を導き出してほしかった。

設問2(1) 40字以内

表 3 中の下線(ア)において,開催を通知された CAB 要員が開催日時に CAB に参加できない場合がある。このような場合に CAB 要員がとるべき行動を,40 字以内で述べよ。

解答例(2通り)

  • RFCの内容を事前に確認し,リスクアセスメントを行い,結果をCABに提出する。
  • 代理者をCAB要員として登録し,代理者をCABに参加させる。
解説

本文の根拠

表3 (2)RFC の評価

指名された代表で組織する変更諮問委員会(以下,CAB という)が,変更の影響について助言する。

表3 (2)RFC の評価

CAB の構成メンバ(以下,CAB 要員という)は,サービス及び事業環境への影響の範囲に応じて選定され,登録される。

CABの役目は,変更の影響について助言することである。要員が出席できないからといって,その分野の助言が無いまま決めてよいことにはならない。だから欠席そのものではなく,助言をどう届けるかを答える。

道は2つある。1つは,事前に送られているRFCの内容を自分で確認し,リスクの評価結果を書面でCABへ出すこと。下線(ア)でE氏が内容を事前に送っているのは,これができるようにするためでもある。

もう1つは代理者を立てること。ただしCAB要員は「選定され,登録される」ものなので,代理者もCAB要員として登録したうえで出席させる。

40字。解答例は「RFCの内容を事前に確認し,リスクアセスメントを行い,結果をCABに提出する。」で38字。「欠席を連絡する」では,助言が欠けたままになる。

採点講評(IPA)

設問2(1)は,正答率が高かった。CAB要員が開催日時にCABに参加できない場合の対応については,理解されているようであった。

設問2(2) 15字以内

表 3 中の c には,変更の展開が成功した後に,構成管理プロセスで実施する内容が入る。この内容を 15 字以内で答えよ。

解答例

  • CMDBの記録を更新
解説

本文の根拠

表2 注1

CI の属性は構成管理データベース(以下,CMDB という)に記録されている。

〔月次集計プログラムの問題とその対応〕

G 氏は,CMDB を検索して,P1 は顧客管理システムだけで使用していること,及び現在 K 社で使用している P1 が問題のある版であることを確認した。

変更したのはCIである。CIの属性は注1のとおりCMDBに記録されているので,展開が成功したらCMDBの記録を新しい状態に合わせる。

更新しないとどうなるかは,本文の中に実例がある。G氏はCMDBを検索して,いま使っているP1が問題のある版だと確認できた。CMDBが実態とずれていれば,この確認そのものが成り立たず,影響範囲を読み違える。

15字。解答例は「CMDBの記録を更新」で10字。

設問3 30字以内

〔問題管理の現状〕について,d に入れる適切な内容を,表 4 中の字句を用いて 30 字以内で答えよ。

解答例

  • 原因が特定できないで,かつ,再発インシデントなしの問題
解説

本文の根拠

〔問題管理の現状〕

‘優先度’が‘低’の問題について,全ての問題を一律に管理するのではなく,早期に解決できる問題又は早期に解決すべき問題が,どれだけ解決できているかを週次で確認したい。

表4

項番3:原因は特定できない,再発インシデントあり,2 件。項番4:原因は特定できない,再発インシデントなし,6 件。

表4 注1

問題を起票するきっかけとなったインシデントとは別に,同じ事象が発生したインシデントのことである。

部長が残したいと言っているのは2種類である。「早期に解決できる問題」と「早期に解決すべき問題」。表4の2つの軸がそれぞれに対応している。

早期に解決できるのは,原因が特定できている問題(項番1と項番2)。原因が分かっていれば手が打てる。

早期に解決すべきなのは,再発インシデントがある問題(項番1と項番3)。同じ事象がもう起きているので放置できない。

どちらにも当てはまらないのは項番4だけである。原因が分からず,再発もしていない。これを計算対象から外す。該当するのは6件で,分母も分子もそのぶん減る。

30字。解答例は「原因が特定できないで,かつ,再発インシデントなしの問題」で27字。片方の条件だけで切ると,項番3や項番2まで落ちてしまう。「かつ」でつなぐ。

採点講評(IPA)

設問3は,正答率が低かった。原因の特定状況と再発インシデントの有無に焦点を当て,問題の解決状況を実務的に管理することに気付いてほしかった。

設問4(1) 40字以内

本文中の下線(イ)について,RFC 管理項目の“優先度”を“緊急”とした理由を,40 字以内で述べよ。

解答例

  • 速やかにCABを開催し,確認テストに5日の日数を確保する必要があるから
解説

本文の根拠

表3 (2)RFC の評価

CAB は毎週火曜日に定期的に開催するが,RFC の優先度が緊急の場合は RFC の受付から 2 日以内に臨時開催する。

表3

例1)本年 10 月は,3 日,10 日,17 日,24 日及び 31 日に開催する。

〔月次集計プログラムの問題とその対応〕

確認テストは,準備作業,テスト作業,確認作業で構成する。RFC の受入れが決定されてから速やかに確認テストの準備作業を開始する。準備作業に 2 日,テスト作業及び確認作業に 3 日の合計 5 日の日数が必要である。確認テストは,土曜日と日曜日も作業する。

日付を並べて追う。RFCを提起したのは10月11日。変更を終える期限は10月19日。確認テストには5日必要で,土日も作業する。

通常どおりなら,次の定期CABは10月17日である。そこで受入れが決まると,確認テストは18日から22日までかかり,19日には間に合わない。

優先度を緊急にすれば,受付から2日以内に臨時開催される。10月13日までに開かれるので,13日に決まれば14日から18日の5日で終わり,19日に間に合う。

つまり「急いでいるから」ではなく,CABの開催を早めないと期限を守れない,という時間の計算が理由である。

40字。解答例は「速やかにCABを開催し,確認テストに5日の日数を確保する必要があるから」で34字。

設問4(2) 30字以内

本文中の下線(ウ)について,E 氏が懸念した“変更を実施することによって発生する可能性があるリスク”を,30 字以内で述べよ。

解答例

  • 夜間バッチジョブがオンライン処理開始までに終了しない。
解説

本文の根拠

〔月次集計プログラムの問題とその対応〕

毎月 20 日の夜間バッチジョブで顧客別の月間取引集計処理を行っている。夜間バッチジョブはオンライン処理開始までに終了する必要がある。

〔月次集計プログラムの問題とその対応〕

最新版では対策ロジックの追加に伴い,従来の版よりも処理時間が長くなる場合がある。

〔月次集計プログラムの問題とその対応〕

事前に実施する確認テストは,テスト環境でテストデータを用いた機能の確認テストである。稼働環境とは機器の性能及び処理するデータ量が異なるので

Q社の注意書きに「従来の版よりも処理時間が長くなる場合がある」とある。G氏はこれを「リスク:特になし」で通そうとした。

G氏が予定しているのは機能の確認テストだけで,しかもテスト環境である。機器の性能もデータ量も稼働環境とは違うので,本番でどれだけ時間がかかるかは分からない。機能が正しいことを確かめても,処理時間のほうは確かめたことにならない。

本文には,夜間バッチジョブはオンライン処理開始までに終える必要がある,と最初に書いてある。処理時間が延びれば,これに間に合わない。

30字。解答例は「夜間バッチジョブがオンライン処理開始までに終了しない。」で26字。

「処理時間が長くなる」で止めると,システムの中の話で終わってしまう。利用者から見て何が起きるのか——オンライン処理が始められない——まで書く。

採点講評(IPA)

設問4(2)は,夜間バッチジョブの処理時間が長くなるといったシステム処理の事象だけを解答した受験者が多かった。ITサービスマネージャとして,インシデントが発生したときに顧客へ及ぼす影響の視点から,オンライン処理開始に着目し,解答してほしかった。

出典:平成29年度 秋期 ITサービスマネージャ試験 午後Ⅰ 問2(表記を一部改変)

問3 サービスデスク

サービスデスクに関する次の記述を読んで,設問1〜3に答えよ。

P 社は,顧客のサービスデスク機能を受託しているサービス提供者である。現在,P 社の顧客は 10 社である。P 社のサービスデスクを運営している要員は 5 名であり,その内訳は,3 年以上のサービスデスク業務の経験をもつ熟練者が 3 名,1〜2 年のサービスデスク業務の経験をもつ中堅者が 2 名である。

サービスデスクでは,顧客のサービス利用者(以下,利用者という)が使用する PC に関する問合せ及び故障のインシデント(以下,これらをサービス要求という)を受け付け,対応マニュアル,操作マニュアルを参照して,P 社で規定された手順に従って対応を行う。

なお,サービス要求の内容,利用者との対話及び対応の内容は,全て問合せデータベース(以下,問合せ DB という)に記録されている。

〔サービスデスクの概要〕

(1) サービスデスクの SLA を全ての顧客と締結している。SLA の一部を表 1 に示す。

サービスレベル項目とサービスレベル目標の2列からなる表。サービス提供日時のサービス提供日:月曜日から金曜日まで。ただし,祝日及び年末年始(12 月 29 日〜1 月 3 日)を除く。サービス提供日時のサービス提供時間帯:9 時から 17 時まで。ただし,12〜13 時を除く。回答時間:15 分以内(95%)。注1)サービス要求を受け付けて対応を開始してから最終的な回答を終了するまでの経過時間である。ただし,サービス提供時間帯以外は経過時間として計算しない。注2)1 日のサービス要求件数の 95%以上のサービス要求は,経過時間が 15 分以内であることを表す。
表1 サービスデスクの SLA(抜粋)

(2) 利用者からサービスデスクへの問合せ手段は,電話だけである。サービスデスクの電話番号は,利用者が参照できる P 社の Web サイトに掲載されている。

(3) Web サイトには,サービスデスクを利用しなくても利用者自身で解決可能な内容を,FAQ として掲載している。FAQ は,問合せ DB の中から問合せ頻度が高いサービス要求を抽出し,そのうち,使用する PC に関して基礎的な知識しかもたない利用者(以下,初心者という)向けの項目を選定し,サービスデスクで定期的に更新している。

〔FAQ の改善〕

ある日,利用者から“Web サイトに掲載されている FAQ の項目数が少ない”という苦情があった。また,過去にも利用者から同じような苦情があった。そこで,P 社の IT サービスマネージャである M 氏が,Web サイトのアクセス履歴から FAQ の利用状況を調査したところ,FAQ のアクセス数も少ないことが分かった。

M 氏は,このような苦情に対処するために,FAQ の作成方法の改善を検討した。検討の結果,初心者だけではなく,全ての利用者を対象として FAQ の項目を選定し,掲載することにした。その結果,FAQ の項目数は改善前の約 2 倍となった。

〔顧客増加への対応〕

(1) サービスデスクの増員

P 社の計画では,来期から顧客が 7 社増える予定である。そこで,1 年のサービスデスク業務の経験をもつ中堅者を 1 名,及びサービスデスク業務の経験がない未経験者を 4 名,新たに採用し,総勢 10 名の要員でサービスデスクを運営することにした。また,サービスデスクの要員を経験年数で三つのグループに分け,未経験者 4 名のグループ①,中堅者 3 名のグループ②及び熟練者 3 名のグループ③とした。

(2) 自動音声応答システムの導入

サービスデスクでは,業務を効率よく行うために,自動音声応答システム(以下,IVR という)を新たに導入し,音声ガイダンスによる着信先振分けを行うことを決定した。IVR の設定に当たっては,M 氏が中心となって,来期の顧客増加後のサービス要求の想定,IVR の振分け先及び現在の実績を表2にまとめた。ここで,IVR の振分け先は,グループ①〜③で示している。

項番・サービス要求・平均回答時間(分/件)・顧客増加後の想定件数(件/時間)・IVR の振分け先・(参考)現在の実績件数(件/時間)の6列からなる表。項番1 PC 及び周辺機器の故障:5,10,グループ①,5。項番2 パスワード初期化:5,15,グループ①,5。項番3 問合せ(通常):10,13,グループ②,7。項番4 問合せ(緊急):10,12,グループ③,7。注1)問合せ(通常)及び問合せ(緊急)とは,OA 系ソフトウェア,セキュリティソフトウェア,インターネット及び電子メールに関する問合せが該当する。利用者が緊急と判断した場合は問合せ(緊急)を選択し,それ以外は問合せ(通常)を選択する。
表2 顧客増加後のサービス要求の想定,IVR の振分け先及び現在の実績

IVR の音声ガイダンスを次のように設定した。

利用者が IVR の音声ガイダンスに従って数字を入力した場合の振分け先は,図1のとおりである。

枠内に箇条書きで振分け先が並ぶ。“1”を入力した場合,グループ①のサービスデスク要員と通話する。“2”を入力した場合,グループ②のサービスデスク要員と通話する。“3”を入力した場合,グループ③のサービスデスク要員と通話する。
図1 利用者が IVR の音声ガイダンスに従って数字を入力した場合の振分け先

(3) 電子メールに関する問合せに対する手順の追加

利用者から“電子メールに関する問合せに対する回答が分かりにくい”という意見があった。問合せ DB を基に調査したところ,熟練者の回答には問題点はなかったが,中堅者の幾つかの回答には問題点があることが判明した。そこで,次に示す手順を付け加えることにした。

この場合,熟練者の確認作業は 5 分で完了するが,全ての熟練者が他の問合せの対応に当たっているときは,該当する作業が完了するまで中堅者は確認作業の開始を待つ必要がある。

(4) 利用者からの苦情

IVR の導入が完了し,電子メールに関する問合せに対する手順の追加を行った。顧客が 7 社増加してからしばらくして,利用者の一部から,“問合せ(緊急)の場合は,電話がつながりにくくなった”との苦情が寄せられるようになった。そこで,IVR 導入後の 1 時間当たりのサービス要求件数を調査したところ,表3に示す状況であった。

項番・サービス要求・件数(件/時間)・(参考)IVR の振分け先の4列からなる表。項番1 PC 及び周辺機器の故障:10,グループ①。項番2 パスワード初期化:15,グループ①。項番3 問合せ(通常):9,グループ②。項番4 問合せ(緊急):16,グループ③。
表3 IVR 導入後のサービス要求件数

M 氏は,“問合せ(緊急)”の件数が想定よりも多かった原因を利用者からのヒアリングも含めて調査したところ,利用者は,“問合せ(通常)”に該当する内容であっても,なるべく早く対応してほしいという心理から“問合せ(緊急)”を選択していたことが分かった。

また,M 氏は,サービス要求の対応について,対応の開始から終了までの状況を調査し,(ア)表1の SLA に関するリスクの特定を行った

M 氏は,利用者からの苦情に対処するために,早急に対策を実施することにした。

〔対策の実施〕

M 氏が,問合せ内容を解析した結果,問合せの全体件数のうち,OA 系ソフトウェアに関する問合せが 50%程度を占めていることが分かった。具体的には,OA 系ソフトウェアに関する問合せが 1 時間当たり 13 件,それ以外の問合せが 1 時間当たり 12 件であった。また,12 件のうち,電子メールに関する問合せは 1 時間当たり 6 件であった。6 件のうち,グループ②の中堅者が対応した問合せは 1 時間当たり 3 件であった。

そこで,音声ガイダンスを,次のように再設定することにした。

その結果,IVR の振分け先ごとに集計したサービス要求件数がおおむね当初の想定件数となり,電話がつながりにくいという状況は解消できた。

〔標的型攻撃メールの訓練〕

P 社の顧客である H 社では,電子メールの利用者に対して標的型攻撃メールを受信した場合の対応方法などについて教育を行っている。最近になって,標的型攻撃メールによる情報セキュリティインシデントが多くなってきた。そこで,H 社は標的型攻撃メールへの耐性の向上のために,標的型攻撃メールの訓練を実施することになった。具体的には,電子メールの利用者に対して訓練用の標的型攻撃メール(以下,訓練メールという)を送信し,添付ファイルの開封,電子メール本文に記載された URL のクリックなどを行ったかどうかを確認するというものである。

8 月のある日,M 氏は,H 社のセキュリティ管理担当から,訓練計画の説明を受け,訓練実施についての打合せを行った。打合せ結果の概要は次のとおりである。

サービスデスクでは,電子メールの利用者が問合せをしてくる場合に備え,利用者との対話によって,“標的型攻撃メールによるインシデントを切り分ける手順”(以下,切分け手順という)を決めていた。M 氏は,今回の訓練で,サービスデスクが切分け手順に従って,正しく対応できるかを確認する機会になると考えた。

M 氏は,打合せで,H 社の標的型攻撃メールの過去の状況についても確認した。具体的には,サービスデスクで対応した H 社からの標的型攻撃メールに関する問合せが,7 月に 2 件あった。H 社で把握している 7 月の標的型攻撃メールの受信件数を尋ねたところ,10 件であった。そこで,M 氏は,(イ)訓練によってサービスデスクの運営に影響する事象が生じると考え,影響ができるだけ少なくなるように (ウ)H 社のセキュリティ管理担当に要望した

M 氏は,H 社で訓練計画の詳細が確定してから再度,H 社のセキュリティ管理担当から説明を受けることにした。

出題趣旨(IPA)

ITサービスの拡大に伴って,ITサービスと利用者の接点となるサービスデスクの機能は,ますます重要になってくる。本問では,顧客のサービスデスク機能を受託しているサービス提供者を題材に,サービスデスク業務の計画と実施を行うITサービスマネージャを想定して,サービスデスクの組織化に関する能力,利用者に対してFAQなどの支援ツールに関する能力,インシデント及びサービス要求管理プロセスを遂行する能力,情報セキュリティインシデントを想定した訓練に対応する実務能力などを問う。

設問と解答例

設問1(1) 30字以内

サービスデスクにとって期待できる FAQ 利用の効果について,30 字以内で述べよ。

解答例

  • サービス要求件数の削減が期待できる。
解説

本文の根拠

〔サービスデスクの概要〕

Web サイトには,サービスデスクを利用しなくても利用者自身で解決可能な内容を,FAQ として掲載している。

冒頭

サービスデスクでは,顧客のサービス利用者(以下,利用者という)が使用する PC に関する問合せ及び故障のインシデント(以下,これらをサービス要求という)を受け付け

FAQの定義が「サービスデスクを利用しなくても利用者自身で解決可能な内容」である。利用者がFAQで片付けた分だけ,サービスデスクには電話が来ない。

設問が「サービスデスクにとって」と限っているので,利用者が早く解決できるという利点はここでは答えにならない。受ける側で何が変わるかを書く。

30字。解答例は「サービス要求件数の削減が期待できる。」で18字。件数が減れば,1件ずつに使える時間も増え,回答時間のサービスレベル目標にも効いてくる。

採点講評(IPA)

設問1(1)は,誤った解答が散見された。FAQを使って利用者自身で解決することによって,サービスデスクへのサービス要求が減少できることに気付いてほしかった。

設問1(2) 40字以内

実施した改善策が有効であることを確認する方法について,“利用者からの苦情が減少すること”以外の方法を 40 字以内で述べよ。

解答例

  • Webサイトのアクセス履歴で今回作成したFAQが閲覧されていることを確認する。
解説

本文の根拠

〔FAQ の改善〕

M 氏が,Web サイトのアクセス履歴から FAQ の利用状況を調査したところ,FAQ のアクセス数も少ないことが分かった。

〔FAQ の改善〕

初心者だけではなく,全ての利用者を対象として FAQ の項目を選定し,掲載することにした。その結果,FAQ の項目数は改善前の約 2 倍となった。

改善の前に,アクセス履歴を使ってアクセス数が少ないことを確かめている。同じものさしで測り直せば,前後を比べられる。

見るのは,今回新たに足した項目が読まれているかどうかである。今回の改善は「初心者向けだけ」から「全ての利用者向け」へ対象を広げたものなので,そこで足した項目が使われていなければ,項目数を倍にした意味がない。全体のアクセス数だけを見ると,もともとあった項目が伸びただけかもしれず,改善の効果とは言えない。

40字。解答例は「Webサイトのアクセス履歴で今回作成したFAQが閲覧されていることを確認する。」で38字。「今回作成した」を落とさない。

採点講評(IPA)

設問1(2)は,正答率が高かった。アクセス履歴の閲覧件数から改善策が有効であることが確認できることは,理解されているようであった。

設問2(1) 30字以内

本文中の下線(ア)について,特定したリスクを 30 字以内で述べよ。

解答例

  • 表1の回答時間のサービスレベル目標が未達となる。
解説

本文の根拠

表1

回答時間:15 分以内(95%)。

表1 注1

サービス要求を受け付けて対応を開始してから最終的な回答を終了するまでの経過時間である。ただし,サービス提供時間帯以外は経過時間として計算しない。

設問が「表1のSLAに関する」と限っているので,答えは表1に載っている項目から選ぶ。表1にあるのはサービス提供日時と回答時間の2つである。

電話がつながりにくいこと自体は,受け付ける前の話である。注1のとおり回答時間は「対応を開始してから」を数えるので,待たされている間は経過時間に入らない。したがって苦情そのものを書いてもSLAの話にならない。

特定すべきリスクは,回答時間15分以内(95%)が守れなくなることである。

30字。解答例は「表1の回答時間のサービスレベル目標が未達となる。」で24字。

採点講評(IPA)

設問2(1)は,誤った解答が散見された。サービスレベル目標が達成できず顧客に影響が出ることに着目し,解答してほしかった。

設問2(2) 40字以内

M 氏が,(1)に挙げたリスクを特定した理由を,40 字以内で述べよ。

解答例

  • 中堅者の電子メール対応で確認が必要で,かつ,確認待ちも発生するから
解説

本文の根拠

〔顧客増加への対応〕

グループ②の中堅者が受け付ける“問合せ(通常)”のうち,電子メールに関する問合せの場合は,“回答に誤りがないことをグループ③の熟練者に確認してから,利用者に回答すること”

〔顧客増加への対応〕

熟練者の確認作業は 5 分で完了するが,全ての熟練者が他の問合せの対応に当たっているときは,該当する作業が完了するまで中堅者は確認作業の開始を待つ必要がある。

表2

項番3 問合せ(通常):10,13,グループ②,7。

時間を足していく。問合せ(通常)の平均回答時間は表2のとおり10分である。電子メールに関する問合せでは,これに熟練者の確認作業5分が加わって15分になる。目標の15分にちょうど届くだけで,余裕がない。

さらに,熟練者が全員ふさがっていれば,中堅者は確認作業を始められず待つことになる。この待ち時間が乗れば15分を超える。

待ちは起きやすい状況にある。表3では問合せ(緊急)が16件/時間で,想定の12件を上回っている。グループ③の熟練者は自分の問合せ対応に追われていて,確認作業にすぐ入れない。

40字。解答例は「中堅者の電子メール対応で確認が必要で,かつ,確認待ちも発生するから」で32字。

「問合せが想定より多いから」「熟練者の負荷が高いから」だけでは,なぜ15分を超えるのかが言えていない。確認作業そのものと待ちの2つを挙げる。

採点講評(IPA)

設問2(2)は,正答率が低かった。当初の想定よりも問合せ件数が多かったことや熟練者の作業負荷だけに言及した誤った解答が多かった。

設問3(1) 40字以内

本文中の下線(イ)について,サービスデスクの運営に影響する事象を,理由を含めて 40 字以内で述べよ。

解答例

  • 訓練メールに関する問合せ件数が増加することから電話がつながりにくくなる。
解説

本文の根拠

〔標的型攻撃メールの訓練〕

サービスデスクで対応した H 社からの標的型攻撃メールに関する問合せが,7 月に 2 件あった。H 社で把握している 7 月の標的型攻撃メールの受信件数を尋ねたところ,10 件であった。

〔標的型攻撃メールの訓練〕

訓練は,H 社の電子メールの利用者全員(約 100 名)を対象に実施する。

〔標的型攻撃メールの訓練〕

訓練対象者を二つのグループに分け,それぞれ業務閑散月の平日の 10 月 17 日と 10 月 18 日に実施する。

M氏が7月の数字を確かめたのは,問合せが何件来そうかを見積もるためである。受信10件に対して問合せは2件だったので,受け取った人のおよそ2割がサービスデスクに聞いてくる。

訓練では約100名に送り,2日に分けるので1日あたり約50名。同じ割合なら1日に約10件の問合せが来る。7月ひと月ぶんの2件に対して,1日でその5倍である。

サービスデスクはすでに「電話がつながりにくい」という苦情を受けている。そこへ集中すれば,つながりにくさがさらに悪化する。

40字。解答例は「訓練メールに関する問合せ件数が増加することから電話がつながりにくくなる。」で35字。設問が「理由を含めて」と言っているので,件数が増えること(理由)とつながりにくくなること(事象)の両方を書く。

設問3(2) 30字以内

本文中の下線(ウ)について,H 社に要望した内容を,30 字以内で述べよ。

解答例

  • 訓練実施日を増やして,1回の訓練対象者を少なくする。
解説

本文の根拠

〔標的型攻撃メールの訓練〕

電子メールの利用者には,事前に連絡せずに訓練を実施する。

〔標的型攻撃メールの訓練〕

M 氏は,今回の訓練で,サービスデスクが切分け手順に従って,正しく対応できるかを確認する機会になると考えた。

M氏は訓練をやめてほしいわけではない。切分け手順どおりに対応できるかを確かめられる機会だと考えている。だから訓練が成り立つ形のままで,集中だけをほぐす要望にする。

問題は1日に約50名ぶんが集中することなので,実施日を増やして1日あたりの対象者を減らす。日数が増えれば問合せも散り,1件ずつ手順に沿って対応できる。

利用者へ事前に周知するという答えは通らない。「事前に連絡せずに実施する」が訓練の前提で,知らせてしまえば訓練にならないからである。

30字。解答例は「訓練実施日を増やして,1回の訓練対象者を少なくする。」で26字。

採点講評(IPA)

設問3(2)は,事前に周知を行うなどの誤った解答が多かった。サービスデスクとして手順に従った対応ができるかを確認する視点から,解答を導き出してほしかった。

出典:平成29年度 秋期 ITサービスマネージャ試験 午後Ⅰ 問3(表記を一部改変)