解説

• 監査手続の結果をまとめたもの
• 監査報告書の裏付けとなる資料
• 監査報告書の基となる資料

解説

システム部門が作成するもの

・システム運用部で検知したシステム障害
・利用部門から発信された障害連絡のうち、システム部門に起因する障害

利用部門が作成するもの

・利用部門から発信された障害連絡のうち、利用部門に起因する障害

解説

• 〔b，cについて〕
  2つの空欄を含む一文を確認すると、「障害の引き金となったb原因の特定にとどまらず，c原因を究明し，再発防止策を講じることが必要である」と記述されています。
  
  システム障害において、直接的に障害の引き金となった要因を直接原因、本質的に障害発生に起因した要因を根本原因と呼びます。再発防止策では、この根本原因を防ぐための対策を打ち出す必要があります。したがって[b]には「直接」が、[c]には「根本」が入ります。
  
  なお、直接原因と根本原因は各種規格や基準等で明確な定義があるわけではないので、同じ意味を持つ字句なら正解になると思われます。一般的な障害管理の知識から解答する設問と言えるでしょう。一応、IPA「情報処理システム高信頼化教訓集」の中では、直接原因及び根本原因について「問題事象を引き起こした直接の原因（直接原因）を見つけ、さらに直接原因を引き起こした原因を見つけるという手順をくり返し、本質的な原因（根本原因）を見つけ出す」と説明されており、直接と根本の定義を見つけることはできます。
  
  ∴b＝直接
  　c＝根本
  
  
• 再発防止策の効果を確認する手段について、適切なものを選択肢で解答する設問です。時系列がややこしいですが整理すると以下の通りです。

  前年度

  前々年度実績について監査を実施、改善勧告、再発防止策を実施

  今年度

  前年度実績について監査を実施中

  設問文で「下線①について」と記述されているので、下線①を確認すると「この指摘事項に対する再発防止策が，この1年で効果的に実施されているかどうかを確認する」と記述されています。この記述から、前年度に実施した再発防止策の効果が確認できる手段を選択する必要があります。また、下線①の改善勧告は「システムの可用性が低下している」ことに対するものです。よって、可用性が改善されたかどうかを定量的に確認できる指標でなければなりません。
  
  前々年度に比べて、前年度で発生した障害件数が減っていれば、再発防止策の効果があることが確認できます。しかし、これだけでは可用性が向上したかどうかまでは確認できません。可用性は、利用者が必要な時にシステムを利用可能である度合いであり、稼働率がその指標になります。よって、障害件数と稼働率の2点について前々年度と前年度の実績値を確認することで、実施された再発防止策が効果的だったかを確認することになります。
  
  ∴エ：前々年度と前年度の事象別障害発生件数とシステム稼働時間の比較
  
  解答群のその他の記述は以下の点で不適切です。
  • 可用性と関係がなく、再発防止策の効果を定量的に測ることができないので不適切です。
  • 記載の有無を確認しただけでは再発防止策の効果を定量的に測ることができないので不適切です。
  • 予測値ではなく実績値を比較しなければ意味がありません。
  • 正しい。
  • 障害件数の増減だけでは可用性を定量的に測ることはできません。また、障害件数にはシステム運用部で検知したものも当然に含めるべきですから、集計対象を利用部門からの障害報告だけに限定している点でも不適切です。

解説

• 設問中に「下線②を裏付けるために」と記述されているので、下線②を含む一文を確認すると「バッチ処理の遅延の原因は，インターネット販売の取扱データ量が増加したことが要因だと推測していた」と記述されています。これより、バッチ処理の遅延がインターネット販売の取扱データ量増加によるものであるという推測を裏付ける分析を解答する必要があります。
  
  2つ以上の要因があり、その一方の変化がもう一方の変化にどの程度影響を与えているかを分析することを相関分析と言います。本問ではインターネット販売の取扱データ量とバッチ処理の時間の関係性を裏付けたいので、両者の相関関係を調べることになります。両者の相関が強く、インターネット販売の取扱データ量が増えるにつれ、バッチ処理の時間がその分伸びていれば、バッチ処理の遅延がインターネット販売の取扱データ量増加に基因すると言えるでしょうし、そうでなければバッチ処理の時間は別の理由によるものであると結論付けられます。
  
  ∴インターネット販売の取り扱いデータ量とバッチ処理に要する時間の相関
  
  
• 設問中に「下線③の事象に対して」と記述されているので、下線③を含む一文を確認すると「経営層は障害報告メールを読まなくなって，重要な障害報告に対する経営層の意思決定が遅れてしまう懸念がある」と記述されています。
  
  表1で現状の障害報告のフローを確認すると、障害のレベルにかかわらず、経営層に対してシステム発生、経過、対応、完了までを報告するようになっていることがわかります。また、経営層へのインタビューでは「"顧客に影響する障害を減らすことが重要である。顧客に影響しない障害レベルCの障害は，対応が完了した後に報告してくれればよい。"という発言が大半であった」という情報を得ています。
  
  これらの記述から、経営層は現状の粒度での報告は過剰だと考えており、特に障害レベルCの障害についての逐次報告は不要だと考えていることがわかります。このように、不要な報告まで意思決定者に対して行われていると、報告自体の意義が弱くなり、真に必要とされる情報のキャッチや重大な障害についての意思決定が遅くなってしまう弊害があります。この対策としては、経営層が不要だと感じている障害レベルCについてはシステム障害報告書による完了報告だけに留め、障害レベルB以上のみ報告対象とするべきです。
  
  ∴経営層に報告する対象を障害レベルB以上にする