応用情報技術者 2021年 春期 午後 問10

解答の論理構成

1. A社と営業部の間では、【表2】にあるとおり「営業支援サービス」についてSLAを結び、システム部がサービス提供の責任主体です。
   引用：【問題文】「営業支援サービス…A社サービスデスクサービスの提供を開始した。」
2. インシデント処理手順では、解決できないものを外部に出す場合でも、最終的な窓口はA社サービスデスクです。
   引用：【表3】エスカレーション「②開発課又はD社サービスデスクのどちらかをエスカレーション先として決定し…」
3. したがって、D社が技術的にインシデントを“解決”したとしても、利用者（営業部員）に状況を説明し、SLAで合意した品質を保証するのはA社システム部の役割になります。
   ⇒ 選択肢「ウ」がSLAとインシデント管理の原則（単一責任窓口＝SPOC）に合致します。
4. 他の選択肢の検証
   ア：D社は標準機能のリグレッションテストを行いますが、引用：【問題文】「開発課は、アップグレードがアドオン開発した機能に影響を及ぼさないかどうかを調査し、評価する。」―A社自身もテストが必要。
   イ：SaaSはD社の管理領域であり、A社が個々のシステムリソース（CPUやストレージなど）を構成品目として詳細に管理する必要はありません。
   エ：物理リソースはD社が保有するため、A社は減価償却対象を持ちません。
   よって「ウ」が最適解です。

誤りやすいポイント

• 「クラウドだから全部ベンダに丸投げ」と考え、SPOCの責任を忘れる。
• D社がリグレッションテストを実施する記述だけを読んで、アドオン部分の追加テストを見落とす。
• SaaSでもCMDBに詳細ハード情報が必要と思い込み、構成管理スコープを拡大し過ぎる。
• 月額利用料だけで済むのに減価償却を計上するなど、オンプレと混同する。

FAQ

解答の論理構成

1. サービスの総提供時間を特定
   【問題文】では、Eサービスの「サービス提供時間」を「24時間365日（毎週日曜日0:00〜5:00に実施する定期保守1)を除く）」と明記しています。
   ・1か月は30日、1日は1,440分なので、30日全体の時間は
   $30\times 1,440=43,200\text{分}$。
2. 定期保守による除外時間を差し引く
   同じ引用より、毎週日曜日0:00〜5:00の5時間（300分）は稼働率計算の対象外です。
   【小問説明】で「日曜日は月4回」と指定されているので、
   $300\text{分}\times 4=1,200\text{分}$ が定期保守分となります。
3. 稼働率算出用の「総提供時間」を求める
   $43,200\text{分}-1,200\text{分}=42,000\text{分}$
4. 許容停止時間を計算
   【問題文】表1では「サービス稼働率99.5％以上（1か月の停止時間の合計が a 分以内を目標値とする。）」と記載されています。
   稼働率99.5％とは停止率0.5％に相当します。
   $42,000\text{分}\times 0.005=210\text{分}$
5. 四捨五入処理の確認
   計算結果はちょうど210分であり、四捨五入の影響はありません。

誤りやすいポイント

• 定期保守時間を稼働率計算に含めてしまい、$43,200$分の0.5％を取ってしまう。
• 5時間を「5×60＝300分」と変換し忘れる、あるいは日曜日が4回である点を見落とす。
• 99.5％を0.995とするのではなく「0.5％の停止率」で計算する必要があることを混同する。
• 四捨五入指示を確認せず、端数処理を誤る。

FAQ

解答の論理構成

1. 原文では「サービスデスクの業務は、従来複数の組織で実施していた営業部員支援の業務を統合し、bとしてシステム部に置いた。」とあります。
2. 複数組織に散在していた窓口を“統合”して一か所に集約する意味を持つ用語は「SPOC（Single Point Of Contact）」です。
3. 解答群のうち、業務・支援窓口の一本化を示すのは「エ：SPOC」のみです。他の選択肢は下記のとおり該当しません。
   • 「ア：BCP」は事業継続計画、窓口統合と無関係
   • 「イ：BPO」は業務プロセス外部委託の概念
   • 「ウ：PMO」はプロジェクト管理組織
4. 以上より、b には「エ：SPOC」を入れるのが適切です。

誤りやすいポイント

• 「BPO＝外注化」のキーワードだけを見て“複数組織→一括委託”と早合点しやすい。
• 「PMO」を“まとめ役”とイメージして選択してしまうケース。PMO はプロジェクト支援であり問い合わせ窓口ではありません。
• 「SPOC」という略語自体に馴染みが薄く、BCP・BPO など他の有名略語に引きずられる。

FAQ

解答の論理構成

• 【問題文】表3の下線②には「開発課又はD社サービスデスクのどちらかをエスカレーション先として決定」とあります。
• それぞれの担当範囲を確認します。
  • D社サービスデスクの担当範囲は、【問題文】表1注2「Eサービスの問合せとインシデント対応、及び公開しているAPIに関する技術的問題を解決する。A社のアドオン開発分の問合せへの対応は含まない。」
  • 開発課の担当範囲は、【問題文】「販売促進モジュールは…A社固有の機能及び画面をアドオン開発する。システム部の開発費はD社が公開しているAPIを利用してアドオン開発し、開発したソフトウェアを保守する。」
• つまり、
  1. インシデントが“Eサービス標準機能やAPI”に関するもの ⇒ D社サービスデスクへ。
  2. インシデントが“A社のアドオン開発分”に関するもの ⇒ 開発課へ。
• したがって、エスカレーション先を決める際に必要な判断は「そのインシデントがA社アドオン由来かどうか」です。

誤りやすいポイント

• 「緊急度」「影響範囲」など表3の他の分類基準を優先してしまい、根本の“担当範囲”を見落とす。
• D社サービスデスクがAPI関連も扱う点を読み飛ばし、「標準機能だけが対象」と誤解する。
• 開発課が“保守”も担うことを忘れ、「開発だけ」と思い込む。

FAQ

解答の論理構成

1. 問題文の該当箇所
   ― “インシデント管理ファイルの記録を基に、高い頻度で発生した質問及びインシデントの中で、利用者が自分で解決できる内容をまとめた c を社内Webに公開した。”
2. キーワードの抽出
   ・“高い頻度で発生した質問”
   ・“利用者が自分で解決できる内容をまとめた”
   これらは一般に“よくある質問集”を示します。
3. ITサービスマネジメントでの代表的な呼称
   “よくある質問”は “FAQ（Frequently Asked Questions）” と呼ばれます。
4. したがって、c には “FAQ” が入ります。

誤りやすいポイント

• “ナレッジベース”や“マニュアル”と混同する
  → “ナレッジベース”は広範な技術情報を含む場合が多く、頻出質問だけを抽出したものとは目的が異なります。
• “Q&A集”と記述し文字数を超過する
  → ITILや一般用語では “FAQ” が最も標準的で短い表現です。
• “チャットボット”と早合点する
  → チャットボットは 10 月 1 日から導入される別モジュールであり、7 月時点では未導入です。

FAQ

解答の論理構成

1. 【問題文】には、チャットボット導入の目的として
   “チャットボットによって、利用者は、d 以外でも質問に回答してもらうことができる。”
   とあります。ここで [d] に当たるのは、これまで質問対応が受けられた“時間帯”を示す語句です。
2. 質問対応の時間帯が定義されている箇所を探すと、【表2】に
   “A社サービスデスクサービス　サービスレベル項目　サービス提供時間帯　9:00〜17:00（休日、祝日を除く）”
   と明記されています。
3. つまり、従来は“A社サービスデスクサービス”の“サービス提供時間帯”内でしか回答が得られませんでしたが、チャットボット導入によってその制約がなくなる、という文脈が成立します。
4. したがって [d] に入る適切な語句は、【表2】で用いられている“サービス提供時間帯”となります。

誤りやすいポイント

• “サービス提供時間”と混同しやすい
  “サービス提供時間”は24時間365日を示す用語で、時間帯の制限を示していません。
• “サポート時間”など、問題文に存在しない自由語を入れてしまう
  設問は“表1、2又は3中で使用されている字句を使って”と指示しています。
• “営業時間帯”のように表記を変えてしまう
  固有のサービスレベル項目名は原文どおり“サービス提供時間帯”である必要があります。

FAQ

解答の論理構成

1. 【問題文】では、Eサービスのアップグレードに関して
   “アップグレード予定日の4週間前に、D社からアップグレードされる機能及び画面や変更点を記載したリリースノートが発行される。”
   と明記されています。
2. 〔Eサービスのアップグレード対応〕の手順では、
   “開発課は、アップグレードされる機能及び画面について記載された e の中から、A社の業務に関連した機能及び画面を抽出し、影響するモジュールを特定する。”
   とあり、アップグレード内容が書かれた文書を参照していることがわかります。
3. アップグレード内容をまとめた文書として該当するのは、先の引用に登場する“リリースノート”のみです。
4. 以上より、e には “リリースノート” が入ります。

誤りやすいポイント

• “アップグレード手順書”や“変更管理票”など、類似の資料名と混同しやすいです。Eサービス側が公式に発行する文書は【問題文】の “リリースノート” だけである点を押さえることが重要です。
• 〔Eサービスのアップグレード対応〕の箇条書きを先に読んでしまい、資料名を自分で補完してしまうケースがあります。必ず冒頭のアップグレード説明部分を確認しましょう。
• “四半期に一回”のアップグレードスケジュールと合わせて覚えようとして資料名を失念するパターンがあります。

FAQ

解答の論理構成

1. 【問題文】では、アップグレード対応におけるサービスデスクの作業が次のように示されています。

   ・サービスデスクは、e に基づいて開発課と協議し、f を判断する。判断の結果に応じて、サービスデスクは、必要な作業を行う。

2. さらにインシデント管理の説明で、サービスデスクが運用するドキュメントとして

   対応手順書※2 は、インシデントに対応するために実施すべき解決処理の詳細が記載されている手順書
   と定義されています。Eサービスのアップグレードによって機能や画面が変われば、この手順書にも影響が及ぶ可能性があります。

3. つまり、サービスデスクがe（アップグレード内容を示す「リリースノート」）を確認し開発課と協議する目的は、既存の「対応手順書」に修正が必要かどうかを見極めることです。
4. よって、f に入るべき内容は
   「対応手順書の修正が必要かどうか」
   となります。

誤りやすいポイント

• 「利用者への通知内容かどうか」を答えにしてしまうミス
  → 通知は判断後に“必要な作業”として実施されるもので、f そのものではありません。
• 「テスト計画の有無」を選んでしまうミス
  → テストは開発課が中心で実施する活動であり、サービスデスクが協議して即決するチェック項目ではありません。
• 「リリースノート確認の要否」と書くミス
  → リリースノートを確認する作業はすでに前段で行うと定義されており、判断対象はその結果として変更が生じるドキュメント（対応手順書）です。

FAQ