応用情報技術者 2013年 秋期 午後 問10

解答の論理構成

1. 表1の該当箇所を確認します。
   ― 原文：「業務システム：システムのa、信頼性、bに関する項目」
   ここでは “信頼性” の前後に、サービスレベルを構成する代表的な 3 要素を並べています。IT サービス管理の定番セットは
   ・可用性 (Availability)
   ・信頼性 (Reliability)
   ・性能 (Performance)
   であるため、a と b の候補は「可用性」「性能」に絞られます。
2. 表2で a が分類名として再登場します。
   ― 原文：「分類　a」
   同じ行の評価項目を確認すると、 ― 原文：「d（X 社営業日とする。また、計画停止時間を除く。）」
   さらに下の行に「サービス稼働率 99.9％」が並んでいます。
   これらはシステムが“使用可能かどうか”を示す指標であり、ITIL などでも可用性指標に分類されます。したがって a は「可用性」と判断できます。
3. 表1の残りの空欄 b には、まだ使われていない「性能」を当てはめると、 ― 原文：「可用性、信頼性、性能」
   という三位一体の並びが完成します。
4. 結論
   a：可用性
   b：性能

誤りやすいポイント

• 「稼働率 99.9％＝信頼性」と誤解し、a を “信頼性” としてしまう。稼働率は“利用できるか”という可用性指標です。
• “性能” を “応答時間” のみと捉え、可用性との対比を見落とす。表2の「オンライン応答時間」は b の配下項目です。
• 「可用性」と「稼働率」を同義と考え、両者を別々の指標として扱う出題意図を読み間違える。SLA では稼働率が可用性を測る代表指標の一つです。

FAQ

解答の論理構成

1. 表2の“分類”列
   • aの直下に並ぶサービスレベル項目は
     「c」「計画停止」「サービス稼働率」「e」の4つです。
   • いずれも“いつ使えるか”に関する指標であり、可用性（Availability）カテゴリに相当します。
2. cに当てはめる語句の検討
   • cの評価項目として d（X 社営業日とする。また、計画停止時間を除く。） と書かれています。
   • これは“システムを提供する時間帯”を示しており、SLA で一般的に「サービス時間」または「提供時間帯」と呼ばれる項目です。
3. dの出典確認
   • 本文には「受注管理システムの稼働時間は、X社の営業日の営業時間に合わせて8:00～18:00とする。」と明記されています。
   • よって dには原文をそのまま「8:00～18:00」を記述するのが適切です。
4. 解答群との照合
   • c候補のうち“サービス時間”に合致するのは「ウ：サービス時間」のみです。
5. 結論
   • c＝「ウ：サービス時間」
   • d＝「8:00～18:00」

誤りやすいポイント

• “c”を「エ：障害時の対応」と勘違い
  → 評価項目が時間帯を示しているため不適切です。
• “d”に“X社営業日”という文言まで含めてしまう
  → SLA の評価値は具体的な値「8:00～18:00」を書き、前提条件は注記に任せます。
• “稼働率”と“サービス時間”を混同
  → 稼働率は「何％稼働したか」、サービス時間は「いつ稼働するか」です。

FAQ

解答の論理構成

1. 受注管理システムには、障害時の業務継続手段として
   “営業時間外の緊急の受注や、営業時間内のシステム障害に備えて、現行と同様なファックスによる受注連絡に切り替えての運用も可能とする。”
   との記述があります。これは可用性を高めるための“代替手段”を示しています。
2. 表2では分類［　a　］が可用性に相当し、その下にサービスレベル項目を並べています。可用性に関する項目の一つとして“障害時の対応”を設定し、評価項目として“ファックスによる受注連絡への切替え”を盛り込めば、上記の業務継続策を具体的に測定できます。
3. 解答群の中で可用性に関するサービスレベル項目は“エ：障害時の対応”だけです。他の選択肢は機密管理・バックアップ保存期間など別カテゴリに該当します。
4. よって
   ・［　e　］には“エ：障害時の対応”
   ・［　f　］には“ファックスによる受注連絡への切替え”
   をそれぞれ充当するのが最も整合的です。

誤りやすいポイント

• “バックアップデータ保存期間”や“機密管理”を可用性項目と誤認しやすい。これらはデータ管理やセキュリティの分類に入る。
• Fax切替えを“サポート”項目と誤読し、［　b　］側へ入れてしまう。Fax運用は障害時に業務を継続させる仕組みであり、可用性に直結する。
• “努力目標型”と“目標保証型”の区別を忘れ、障害時対応を努力目標型にしてしまう。本文は“目標保証型”と明記。

FAQ

解答の論理構成

1. 監視すべき指標
   表2の評価項目に「“受注データへの利用者からの最大アクセス件数”＝“36,000 件／日（受注登録、受注変更、受注取消、受注検索の合計）”」とあります。
2. 現状のログ取得範囲
   問題文には「“更新履歴には、利用者による受注登録、受注変更、受注取消、及び生産管理システムとのデータ連携の履歴が含まれる。受注データへのアクセスについて、これ以外の履歴は取得しない。”」と記載されています。
3. 不足している機能
   “受注検索”は最大アクセス件数のカウント対象にもかかわらず、上記の履歴には含まれていません。したがって、検索件数を測定できないままでは下線①の指摘どおり達成度を評価できません。
4. 追加すべき機能
   検索操作をログとして残す機能を追加すれば、4 種類合計のアクセス件数を正確に把握でき、SLA で合意した 36,000 件／日の達成状況を定量的に評価できます。
5. 結論
   不足しているのは「受注検索」に対するアクセスログ取得機能であり、具体的な答えは「受注検索時の参照履歴の取得」です。

誤りやすいポイント

• 「更新履歴」がある＝すべてのアクセスが計測できると思い込む
  実際は登録・変更・取消のみで検索は対象外です。
• 「平均復旧時間」「サービス稼働率」など他の項目に気を取られ、アクセス件数の測定方法を見落とす。
• “参照”ではなく“更新”と表現してしまう
  検索は参照操作なので「参照履歴」と明記する必要があります。

FAQ

解答の論理構成

1. 目標保証型と努力目標型の違い
   【問題文】では、 「目標保証型では、情報システム部は取り決めたサービスレベルを保証する義務がある。一方、努力目標型では、取り決めたサービスレベルは努力目標にとどまり、サービスレベルの達成、維持に向けて継続的な改善努力を行うことで、情報システム部と利用部門とが合意する。」
   と定義されています。保証できるかどうかが判断基準です。
2. 支店・営業所の応答時間が不安定である事実
   【問題文】には、 「インターネットを介した支店・営業所と本社ビルとの通信は1～2秒を想定しているが、受入れテストにおいては、これが2秒を超え、オンライン応答時間が3秒を超えてしまう事例が確認されている。」
   とあります。すでにテスト段階で目標を超過しており、保証が困難であることが判明しています。
3. 改善に向けた“合意”内容
   続けて、 「営業部門からは、支店・営業所におけるオンライン応答時間の目標値を3秒以内にすることが要求されている。インターネットを介したデータ通信の性能改善については、情報システム部が改善に向けた対策に取り組んでいくことで、営業部門と合意している。」
   と記述されています。ここでは“目標値”と“改善に向けた対策”という表現に留まっており、保証するとは述べられていません。
4. 従って努力目標型が妥当
   外部インターネット回線の品質は情報システム部単独では制御できず、現状では“保証”できないため、この項目を努力目標型に変更するのが論理的帰結です。
5. 結論
   努力目標型とすべきサービスレベル項目は「支店・営業所からのオンライン応答時間」です。

誤りやすいポイント

• 本社側でのオンライン応答時間「1 秒」と混同し、いずれも保証できると勘違いする。
• 目標値＝保証値だと早合点し、「目標」という語だけで目標保証型と判断してしまう。
• 外部ネットワーク要因を軽視し、社内システム部門が全てをコントロールできると考える。

FAQ

解答の論理構成

• 【問題文】では、支店・営業所の PC からサーバへは「インターネット」を経由すると説明され、その性能について
  「インターネットを介したデータ通信を含む場合のオンライン応答時間は、社外ネットワークの状況によって影響を受ける。」
  と明記されています。
• さらに受入れテスト結果として
  「これが2秒を超え、オンライン応答時間が3秒を超えてしまう事例が確認されている。」
  とあり、実際に目標値を超過するケースが発生しています。
• 社外ネットワーク（インターネット）は X 社の管理外であり、情報システム部が直接制御・保証できません。したがって「3 秒以内」という絶対保証は困難で、努力目標に留めるべき項目です。
• 以上より、目標が保証できない理由は
  「オンライン応答時間は、社外ネットワークの状況によって影響を受けるから」
  となります。

誤りやすいポイント

• 自社サーバの性能が十分なら応答時間も保証できると短絡的に考えてしまい、ネットワーク区分（社内／社外）を見落とす。
• 「目標保証型」と「努力目標型」を混同し、管理外要因まで保証対象に含めてしまう。
• テストで一度でも 3 秒を切れば保証可能と判断し、実運用でのばらつきを想定しない。

FAQ