戦国IT - 情報処理技術者試験の過去問対策サイト
お知らせお問い合わせ料金プラン

応用情報技術者 2009年 春期 午後11


SLA (Service Level Agreement) に関する次の記述を読んで、設問1~4に答えよ。

 T社は、健康食品の製造・販売業を営んでいる。2006年1月にインターネット販売システム(以下、販売システムという)を自社で構築し、システム運用・保守を行ってきた。2008年4月、システムの企画、開発及び保守の業務を自社に残し、システム運用業務をT社に委託した。当時両社は、2009年4月に正式なSLAを締結することを目指して1年間試行することに合意し、表1に示すSLA案を作成した。
応用情報技術者試験(平成21年度 午後 問11 表01)
 “サービスレベルの要求水準” を表2に示す。
応用情報技術者試験(平成21年度 午後 問11 表02)
 業務委託開始から1年を経過した2009年4月に、U社はT社に対し、2008年度システム運用業務の活動実績を次のとおり報告した。
〔2008年度活動実績報告(要旨)〕  ・販売システムへのアクセス件数は、6,500万件であった。  ・オンライン業務サーバは、年間予定稼働時間のうち、36時間サービスを停止した。  ・バッチ処理の平均完了時刻は、2時42分であった。  ・バッチ処理を3時までに完了できなかった日は27日あった。  ・56件のシステム障害が発生した。そのうち、障害発生後10分以内にT社に障害通知できなかった件数は、3件であった。    T社は、U社の活動実績報告を基に、サービスレベルの要求水準に対する達成度の評価を行った。その結果をU社に通知したが、バッチ処理完了時限遵守率の評価について、両社合意に至らなかった。数日後、U社は次のような追加報告を行った。   〔2008年度活動実績追加報告(要旨)〕  ・バッチ処理を3時までに完了できなかった27日のうち、19日はT社提供のプログラム設計不良に起因するもので、8日はU社のオペレーションミスに起因するものであった。  ・バッチ処理の平均完了時刻は、2007年度と比較して平均22分遅かった。また、2時50分を超えて完了した日は、全体の30%を超えていた。  ・障害通知を10分以内にできなかった原因は、次の二つである。   原因①:深夜のバッチ処理での障害発生において、運用オペレータが自分で復旧できると判断し、独自に障害対応オペレーションを試みたが、結局復旧できずに障害通知が遅れたケースが2件あった。運用オペレータは、T社システム担当者の手間を考え、オペレーション手順書には記載されていない手順で障害対応を試みた。   原因②:オペレーション室に張られていた障害連絡網が最新版でなかったので、T社システム担当者になかなか連絡を取れなかったケースが1件あった。後日T社に問い合わせたところ、T社の障害連絡網原本は更新されていたが、T社側でオペレーション室に最新コピー(紙)の配付を漏らしていたことが判明した。障害連絡網の配付方法は特に定められていなかったが、過去に配付が漏れたことは一度もなかった。    T社は、U社の追加報告を考慮した上で再評価を行い、今度はU社と合意した。また、T社は、2009年度の事業見通しを次のように語った。  ・インターネット販売キャンペーンを展開したことによって、2008年度の販売件数は当初予想比3割増となった。2009年度も更に3割増になると見込んでいる。

設問1

T社が、U社に業務委託をする際に、SLAを締結することによって享受できるメリットを、解答群の中から二つ選び、記号で答えよ。
解答群  ア:最重要なコア業務に経営資源が集中できる。  イ:サービス提供者の瑕疵担保責任範囲が限定できる。  ウ:サービスに対する不透明な部分が明確になる。  エ:サービス品質の向上が期待できる。  オ:保守業務における生産性向上が期待できる。

模範解答

ウ、エ

解説

解答の論理構成

  1. SLA は、委託側と受託側が合意したサービス水準を数値で定義し、その達成状況を定期的に評価・報告する契約文書です。問題文には「2009年4月に正式なSLAを締結することを目指して1年間試行することに合意」や、評価指標として
    ・「オンライン業務サーバの可用性」
    ・「バッチ処理完了時限遵守率」
    ・「システム障害通知遵守率」
    が示されています。
    これにより、サービス提供の曖昧さが排除され“何をどこまで求めるのか”が可視化されます。したがって
    ウ:サービスに対する不透明な部分が明確になる
    が該当します。
  2. SLA は目標値を共有することで、受託側に達成義務が課され、未達時には改善活動(是正措置やペナルティ)が発生します。問題文でも「2008年度活動実績報告」に基づき再評価・協議が行われ、達成度が検証されています。数値目標と評価サイクルが定着することで、継続的な改善が促進され、結果としてサービス品質の底上げが期待できます。よって
    エ:サービス品質の向上が期待できる
    が該当します。
  3. 他の選択肢との比較
    ア:経営資源集中は“業務委託”自体のメリットであり、SLAの有無に依存しません。
    イ:SLA は責任範囲を定義しますが、民法上の「瑕疵担保責任」の範囲を狭めるものではありません。
    オ:生産性向上は副次的効果としてあり得るものの、SLA の直接目的ではありません。
以上より、該当する二つは「ウ、エ」です。

誤りやすいポイント

  • 「アウトソーシングのメリット」と「SLA のメリット」を混同しやすい。SLA は委託契約の一部であり、委託自体の便益(コスト削減・リソース集中)は直接問われていない。
  • 「責任範囲=瑕疵担保責任限定」と短絡しやすい。SLA の免責条項は存在しても、法的責任そのものを縮小できるわけではない。
  • 「生産性向上」は測定しづらく、SLA で規定する例は稀。品質指標と誤認しないよう注意。

FAQ

Q: SLA と KPI の違いは何ですか?
A: KPI は目標達成度を測る社内指標も含む広い概念、SLA は委託契約におけるサービス水準を外部と合意したものです。SLA には罰則や改善措置が紐付きます。
Q: SLA を結んでもサービスが改善しないことはありますか?
A: 指標設定が不適切(達成しやす過ぎる・実業務を反映しない)だと形骸化します。適切な測定方法と定期レビューが不可欠です。
Q: 免責条項を入れれば受託側は責任を負わなくてよいのですか?
A: 天災・停電など「不可抗力」は免責しやすいものの、通常の業務瑕疵まで免責することはできません。法的責任は契約とは別に存在します。

関連キーワード: SLA, 可用性, 継続的改善, 品質指標, 免責条項

設問2サービスレベルの評価について、(1)、(2)に答えよ。

(1)表2の項番a, bに関して、評価項目説明及びU社の初回の活動実績報告に基づいて、2008年度の要求水準に対する実績値(%)を求めよ。答えは、小数第2位を四捨五入して有効第1位まで求めよ。

模範解答

a:99.5 b:92.5

解説

解答の論理構成

  1. 対象データの抽出
    • 稼働時間に関する前提
      引用︓「年間予定稼働時間は7,200時間とする。」
      引用︓「1年間のシステム稼働日数を360日とする。」
    • 障害・未達日に関する実績
      引用︓「オンライン業務サーバは、年間予定稼働時間のうち、36時間サービスを停止した。」
      引用︓「バッチ処理を3時までに完了できなかった日は27日あった。」
  2. 項番a「オンライン業務サーバの可用性」
    • 定義︓「年間予定稼働時間のうち、正常に利用できた時間の比率」
    • 正常稼働時間=7,200−36=7,164時間
    • 可用性(%)=7,164 / 7,200 × 100
    • 四捨五入により有効第1位は「99.5」。
  3. 項番b「バッチ処理完了時限遵守率」
    • 定義︓「バッチ処理が3時までに完了できた日数の比率」
    • 遵守日数=360−27=333日
    • 遵守率(%)=333 / 360 × 100
    • 四捨五入により有効第1位は「92.5」。
  4. 結果
    a:99.5
    b:92.5

誤りやすいポイント

  • 「年間予定稼働時間」を 24×365 などで再計算してしまう
    ⟹ 出題は「7,200時間」で固定されている。
  • 「システム稼働日数」を 365 日と誤読し、遵守率を算出
    ⟹ 正しい値は「360日」。
  • バッチ未達「27日」を分子に入れてしまう
    ⟹ 分母は360日、分子は遵守日数333日。
  • 小数第2位での丸めを忘れ、99.42 や 92.50 のまま記載してしまう。

FAQ

Q: 障害停止時間が分散していても計算方法は変わりますか?
A: 変わりません。停止時間を合算し、予定稼働時間から差し引くだけです。
Q: バッチ処理未達が複数原因に分かれている場合、原因別に分母を変える必要はありますか?
A: 今回の設問は原因を問わず「未達日数 27日」をまとめて扱います。原因別分析は次の設問で活用されます。
Q: 四捨五入は第何位で実施しますか?
A: 指示は「小数第2位を四捨五入して有効第1位まで」です。したがって 99.44…→99.4、99.45…→99.5 のように処理します。

関連キーワード: 可用性, 稼働率, バッチ処理, SLA, 遵守率

設問2サービスレベルの評価について、(1)、(2)に答えよ。

(2)表2の項番bに関して、初回報告では要求水準に達していなかったが、追加報告の内容を考慮した結果、要求水準を達成することができた。これを踏まえ、2009年度のSLA締結において要求水準を設定する際に明確にすべき事項を、30字以内で述べよ。

模範解答

「T社の責任に帰すべき障害は、免責事項とすること」 または 「T社が提供する資源の不良に起因するものは免責事項とすること」 または 「U社の責任に帰すべき障害だけを評価対象とすること」

解説

解答の論理構成

  1. 表2の項番b「バッチ処理完了時限遵守率」の要求水準は「95.0%以上」です。
  2. 初回報告では「バッチ処理を3時までに完了できなかった日は27日」で、年間稼働日数360日に対して遵守率は

    となり、要求を満たしませんでした。
  3. 追加報告で「27日のうち、19日はT社提供のプログラム設計不良に起因」「8日はU社のオペレーションミスに起因」と判明しました。
  4. U社責任の8日だけを評価対象にすると、遵守率は

    となり、「95.0%以上」を達成します。
  5. したがって、評価対象に含める障害の範囲(責任帰属)を明文化する必要があります。
  6. 以上から、SLA締結時に明確にすべき事項は「U社の責任に帰すべき障害だけを評価対象とすること」です。

誤りやすいポイント

  • 自然災害等の免責事項は注記に既にあるため、責任帰属の整理と混同しやすい。
  • 単純に日数を除外するだけでなく、計算対象となる分母(360日)を変えてしまう誤計算。
  • 「システム障害通知遵守率」の話と混同して、通知遅延もバッチ遵守率に影響させてしまう。

FAQ

Q: 責任の切り分けはどのように実運用で判断しますか?
A: 障害ごとに「障害原因分析報告書」を作成し、原因が「T社提供リソース」か「U社運用手順」かを両社でレビューして確定します。
Q: 分母の360日を変更して再計算する案は正しいですか?
A: いいえ。年間稼働日数「360日」は前提条件で固定されているので、分母を変えずに評価対象となる“失敗日数”だけを除外します。
Q: 今後同様の論争を避けるために他に必要なことは?
A: 障害分類基準とエビデンス提出期限をSLA本文または運用手順書に明記し、月次レビューで双方が確認する仕組みを設けるのが効果的です。

関連キーワード: 可用性, 免責事項, 責任分担, 運用監視, 稼働率

設問3

表2の項番cに関して、障害通知を10分以内にできなかった原因①、②に対する是正処置としてふさわしいものを、解答群の中から一つずつ選び、記号で答えよ。
原因①に関する解答群  ア:運用オペレータが独自の判断で適切に障害に対応できるように、教育する。  イ:運用オペレータに対し、オペレーション手順書に記載された範囲で業務を行うよう周知徹底する。  ウ:運用オペレータに対し、独自に障害対応オペレーションをしたときはT社に報告することを周知徹底する。  エ:深夜の運用オペレータを増員する。
原因②に関する解答群  ア:オペレーション室に現時点の最新版障害連絡網を配付する。  イ:オペレーション室の障害連絡網を紙ではなく電子媒体に保存する。  ウ:未だT社システム担当者の緊急連絡先を、運用オペレータに教える。  エ:障害連絡網の変更管理ルール(改訂、配付方法など)を定め、周知徹底する。

模範解答

原因①:イ 原因②:エ

解説

解答の論理構成

  1. 要求事項の確認
    表2 項番c は「システム障害通知遵守率」で、評価項目説明は「システム障害発生後10分以内にT社に障害通知できた回数の比率」、要求水準は「100.0%」です。したがって、10分を超える通知遅延は一件も許されません。
  2. 遅延が発生した原因の整理
     追加報告によれば、通知遅延の原因は二つです。
     • 原因①:「運用オペレータが自分で復旧できると判断し、独自に障害対応オペレーションを試みたが、結局復旧できずに障害通知が遅れたケースが2件あった。」
     • 原因②:「オペレーション室に張られていた障害連絡網が最新版でなかったので、T社システム担当者になかなか連絡を取れなかったケースが1件あった。」
  3. 原因①の是正策選定
     遅延の直接要因は「オペレーション手順書には記載されていない手順で障害対応を試みた」ことです。手順書逸脱を防ぐには、手順書の範囲内で業務を行うよう周知徹底させる施策が適切です。
     よって、選択肢イ「運用オペレータに対し、オペレーション手順書に記載された範囲で業務を行うよう周知徹底する。」が妥当です。
  4. 原因②の是正策選定
     遅延は「T社側でオペレーション室に最新コピー(紙)の配付を漏らしていた」ことが根本原因です。一次的に最新版を配付するだけでは再発防止になりません。改訂・配付を含む変更管理プロセスを整備し、ルール化・周知する必要があります。
     よって、選択肢エ「障害連絡網の変更管理ルール(改訂、配付方法など)を定め、周知徹底する。」が妥当です。
  5. まとめ
     ・原因① → イ
     ・原因② → エ

誤りやすいポイント

  • 原因①で「ア」を選んでしまう
    「独自の判断で適切に対応できるよう教育する」とすると、むしろ手順書逸脱を助長します。手順遵守が問題の本質です。
  • 原因②で「ア」を選んでしまう
    現在の最新版を配付しても、次回改訂時に同じ漏れが再発する恐れがあります。プロセスの整備が欠かせません。
  • „通知遅延は3件中1件だけだから許容範囲”と考える
    要求水準は「100.0%」であり、一件でも外れると未達です。割合ではなく絶対達成が求められている点に注意が必要です。

FAQ

Q: 手順書を改訂するよりオペレータを増員した方が早いのでは?
A: 遅延要因は人手不足ではなく手順逸脱です。手順遵守を徹底し、標準化されたプロセスで対応時間を保証する方が効果的です。
Q: 障害連絡網を電子化すれば配付漏れは防げる?
A: 電子化自体は有効ですが、配付・改訂の運用ルールがなければ最新版が共有されないリスクは残ります。変更管理プロセスの確立が必須です。
Q: 手順書逸脱を完全になくすことは難しいのでは?
A: 手順書の定期的見直し、教育、遵守状況の監査を組み合わせることで逸脱リスクを最小化できます。SLAで定めた「100.0%」達成には仕組みと運用の両輪が必要です。

関連キーワード: SLA, 可用性, 運用手順, 変更管理, インシデント管理

設問4

T社の2009年度事業見通しから、表2のサービスレベルの要求水準を維持するための予防処置として有効なものを、解答群の中から二つ選び、記号で答えよ。
解答群  ア:U社への業務委託範囲を拡大する。  イ:SLAに、ペナルティ条項、インセンティブ条項を追加する。  ウ:ジョブ構成見直しなど、バッチ処理時間が短くなる対策を実施する。  エ:ハードウェアの稼働状況を調査し、必要機器の増強を行う。  オ:マシン室分電盤の二重化など、災害対策システムの強化を実施する。

模範解答

ウ、エ

解説

解答の論理構成

  1. 2009年度の負荷増大を把握
    • 2008年度は「当初予想比3割増」
    • 2009年度も「更に3割増になると見込んでいる」
      ⇒ 取引件数は連続して増加し、オンライン処理・バッチ処理ともに処理量が大きくなることが確定的です。
  2. SLAで守るべき主要指標を確認
    • 項番 a「オンライン業務サーバの可用性」要求水準「99.4%以上」
    • 項番 b「バッチ処理完了時限遵守率」要求水準「95.0%以上」
      ⇒ 取引件数が増えると CPU・I/O 負荷上昇による障害/性能劣化、バッチ遅延が発生しやすくなり、a・b の未達リスクが高まります。
  3. 予防処置の適合度を評価
    ア:委託範囲拡大 … 負荷対策とは無関係
    イ:ペナルティ・インセンティブ … “契約上の動機付け”であり技術的な性能確保には直結しない
    ウ:ジョブ構成見直し等でバッチ処理時間短縮 … 項番 b の達成に直接寄与
    エ:ハードウェア増強 … 処理能力を高め、項番 a・b の両方を支援
    オ:分電盤二重化など災害対策 … SLA注記「自然災害、停電など…免責事項」に該当し、サービスレベル算定外
  4. 採択
    上記より、技術的・性能的に有効なのは
    ウ「ジョブ構成見直しなど、バッチ処理時間が短くなる対策を実施する。」
    エ「ハードウェアの稼働状況を調査し、必要機器の増強を行う。」

誤りやすいポイント

  • 「免責事項」があるため、災害対策(オ)はサービスレベル評価に含まれないことを見落とす。
  • ペナルティ条項(イ)は“管理的手段”であり、性能向上策ではないと気付かず選択してしまう。
  • 委託範囲拡大(ア)は責任分界の変更に過ぎず、処理能力を高めるわけではない。

FAQ

Q: なぜ負荷増大で可用性が下がるのですか?
A: アクセスが増えると CPU・メモリ・ディスク I/O が飽和し、レスポンス遅延やアプリケーション障害が発生しやすくなります。結果として「年間予定稼働時間のうち、正常に利用できた時間の比率」が低下します。
Q: バッチ処理はプログラムを直せば良いのでは?
A: プログラム最適化も効果がありますが、件数が急増するとハードウェア性能不足が顕在化します。ジョブ構成・並列実行・ハード増強を組み合わせて総処理時間を短縮するのが実践的です。
Q: 災害対策を行っても意味がないのですか?
A: 無意味ではありませんが、問題文では「自然災害、停電などライフライン障害」は免責と明示されており、SLA達成率の計算対象外です。今回の設問は“サービスレベル維持”が目的なので優先度は下がります。

関連キーワード: 可用性, バッチ処理, サイジング, パフォーマンスチューニング, SLA
戦国ITクイズ機能

\ せっかくなら /

応用情報技術者
クイズ形式で学習しませんか?

クイズ画面へ遷移する

すぐに利用可能!

©︎2026 情報処理技術者試験対策アプリ

このサイトについてプライバシーポリシー利用規約特商法表記開発者について