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

応用情報技術者 2013年 春期 午後12


障害管理のシステム監査に関する次の記述を読んで、設問1〜4に答えよ。

 S社は、ファッション衣類・雑貨の卸売、販売を営む会社である。社内には販売管理、購買管理、店舗運営、人事給与などのシステムがあり、システム開発部が開発・保守を担当し、システム運用部が運用を担当している。  販売管理システムは、大手ベンダのソフトウェアパッケージを採用し、S社の独自要件に対するカスタマイズを加えて、約7年前にリリースされた。ソフトウェアの品質は安定しているが、経年劣化によるハードウェアの故障がこの数年間で増えてきている。そのうち幾つかの障害で復旧対応が遅れ、顧客への納品が遅れたり、業務に支障を来したりしていた。また、一昨年から本格的に開始したインターネット販売が好調で、1年間で取扱データ量が2倍以上に増えた。  S社では、監査部が毎年システム監査を実施している。監査部のT部長は、部下のU君をリーダとする監査チームを作った。U君は、システムの障害管理を重点項目とし、販売管理システムを対象に監査を実施することにした。システム部門であるシステム運用部とシステム開発部を被監査部とし、利用部門の代表として営業部と経理部を調査の対象に加えることにした。U君は、監査の個別計画書を策定し、T部長の承認を受けた。   〔監査チームによる予備調査〕  監査チームは、予備調査として、監査対象の業務やシステムに関する資料を収集し、内容を確認した。次に、被監査部署のシステム運用のコントロールに関する a を作成し、被監査部署及び利用部門に対して回答するように依頼した。  前年度の監査報告書に目を通すと、指摘事項として“販売管理システムにおいて、システム障害の発生件数が増加しており、システムの可用性が低下していると思われる。”と書かれており、それに対する改善勧告として“システム障害の原因の分析・究明を行い、再発防止に努める必要がある。”と書かれていた。U君は、①この指摘事項に対する再発防止策が、この1年で効果的に実施されているかどうかを確認することにした。また、発生したシステム障害の原因の分析・究明、及び再発防止の状況を詳細に確認することにし、監査を進めた。   〔監査で確認した事実〕  監査チームは、一連の監査手続の実施と関連資料の収集によって、次の事実を確認した。  ・システム障害対応手順書や緊急連絡網は明文化され、最新の状態に改訂されていた。  ・表1のとおりに、システム障害の影響度(範囲及び重大性)を段階付けした障害レベルを設定していた。また、システム障害が発生した場合、表1の障害発生時の報告先に速やかに報告することが定められていた。  ・システム障害が発生したときの報告手段は、表1の障害発生時の報告先を宛先とした一斉メール送信であった。さらに、重要な関係者には対面や電話で報告していた。
応用情報技術者試験(平成25年度 午後 問12 表01)
 ・障害報告の発信者が報告時に障害レベルを仮設定し、システム運用部がその後の障害の影響などを考慮し、必要に応じて障害レベルを変更する運用になっていた。  ・経営層へのインタビューによると、システム障害が発生した都度、経過を含めて対応の完了まで全て報告を受けていて、システム全体で毎月10〜20件であった。顧客に影響する障害を減らすことが重要である。顧客に影響しない障害レベルCの障害は、対応が完了した後に報告してくれればよい、という発言が半数であった。  ・事後報告としてシステム障害報告書を作成する手順になっていた。  ・システム運用部が検知したシステム障害は、その都度、システム部門の担当者がシステム障害報告書を漏れなく作成していた。  ・利用部門から発信された障害連絡のうち、システム部門に起因する障害は、システム部門の担当者がシステム障害報告書を作成していた。一方、利用者が設定しているパラメタ類の設定誤りなど、利用部門に起因する障害は、利用部門がシステム障害報告書を作成していた。  ・システム障害報告書を管理しているシステム運用部へのインタビューによると、システム障害報告書に、障害の原因を詳細に分析して記述しているものは全体の5割程度、再発防止策まで記述しているものは全体の2割程度ということであった。  ・システム運用部は、システム障害報告書を基に、表2のとおりに事象別に障害を集計し、分析していた。利用部門に起因する障害は、障害件数の集計対象にはなっていたが、分析はされていなかった。  ・表2を見ると、前年度の障害発生総件数は前々年度に比べて減少しているが、ハードウェア障害件数とバッチ処理の遅延件数は前々年度に比べて増加していた。  ・システム部門へのインタビューによると、ハードウェア障害の主な原因は、ハードウェアの経年劣化による故障であった。バッチ処理の遅延の原因は、②インターネット販売データ量が増加したことが要因だと推測していた
応用情報技術者試験(平成25年度 午後 問12 表02)
〔監査結果の評価〕  監査チームは、これらの事実から指摘事項をまとめ、改善勧告の草案を作成した。  ・障害の発生総件数はこの1年間で減少しているが、システム障害報告書の記述内容やシステム運用部の障害分析報告をみる限りでは、依然としてシステム障害の原因の分析が浅く、部分的なものにとどまっている。障害の引き金となったb原因の特定にとどまらず、c原因を究明し、再発防止策を詳しく定めることが必要である。  ・全てのシステム障害が発生時に速やかに経営層に報告されているが、③経営層は障害報告メールを読まなくなって、重要な障害報告に対する経営層の意思決定が遅れてしまう懸念がある。  ・表2の事象別の障害の集計・分析に関して、障害発生の原因やソフトウェア障害におけるバグの埋込み時期といった視点を追加し、より詳細に分析すべきである。  ・ハードウェア障害とバッチ処理の遅延の増加は、このまま放置すると更なるシステム障害につながる危険性が増す。ハードウェア障害に対しては、既に経営層から今年度中のハードウェア更新計画の承認を得ていることを確認した。バッチ処理の遅延に対しても、具体的な対策の検討が必要である。    監査チームは、監査報告書の裏付けとするために、一連の監査手続の結果とその関連資料を d として作成し、これらを基に監査報告書の作成に着手した。

設問1

本文中のadに入れる適切な字句を答えよ。

模範解答

a:チェックリスト d:監査調書

解説

解答の論理構成

  1. 監査の予備調査フェーズでは、被監査部門が自らの統制状況を自己点検できるよう質問票を作成するのが定石です。本文には
    “次に、被監査部署のシステム運用のコントロールに関する a を作成し、被監査部署及び利用部門に対して回答するように依頼した。”
    とあります。システム監査でこの目的に用いられる正式な文書は「チェックリスト」です。
  2. 監査実施後、監査人は実施手続・収集証拠・判断過程を体系的にまとめます。本文には
    “監査チームは、監査報告書の裏付けとするために、一連の監査手続の結果とその関連資料を d として作成し、これらを基に監査報告書の作成に着手した。”
    と記載されています。監査報告書の裏付けとなる文書群は制度上「監査調書」と呼ばれます。
  3. 以上より
    a=「チェックリスト」
    d=「監査調書」
    が妥当であると結論づけられます。

誤りやすいポイント

  • 質問票やアンケートと混同し、a に「質問書」などと書いてしまう。自己点検を促し統制項目を網羅する正式名称は「チェックリスト」です。
  • d に「監査証跡」や「エビデンス」と解答するミス。証拠そのものを束ね、手続・評価も含め体系化した文書は「監査調書」です。
  • 「監査報告書」と「監査調書」の役割を逆に覚える。報告書は経営層向け、調書は監査人内部の裏付け資料です。

FAQ

Q: チェックリストは誰が回答するのですか?
A: 本文にあるように“被監査部署及び利用部門”が自己点検として回答し、監査人はその回答内容と実地調査結果を突合します。
Q: 監査調書には何を含めれば良いのでしょうか?
A: 監査目的、手続、収集した証拠、評価結果、監査人の判断根拠など、報告書作成を裏付ける全情報を体系立てて整理します。
Q: チェックリスト作成時の着眼点は?
A: 業務フローに沿って統制目的(正確性、完全性、可用性など)を洗い出し、各統制項目が設置・運用されているかを Yes/No で確認できるようにします。

関連キーワード: 内部統制, チェックリスト, 監査調書, 監査証拠, システム監査

設問2

S社におけるシステム障害の分析範囲を広げ、有効な施策を実行できるようにするために、障害管理についてどのような改善をすべきか、30字以内で述べよ。

模範解答

利用部門に起因するシステム障害も分析対象にする。

解説

解答の論理構成

  1. 監査チームが把握した現状
    被監査部署の運用では、
    ― 「利用部門に起因する障害は、障害件数の集計対象にはなっていたが、分析はされていなかった。」
    と【問題文】に明記されています。
  2. 改善目的
    問題文の設問は「システム障害の分析範囲を広げ、有効な施策を実行できるようにする」ことを求めています。
    つまり、これまで分析していない領域を含めて根本原因を探り、再発防止策を立案できる体制にするのが狙いです。
  3. 分析から漏れている領域
    前述の引用からわかるとおり、利用部門が原因の障害は“集計のみ”で“分析なし”という空白領域です。
  4. 論理的帰結
    よって、分析範囲を拡張すべき対象は「利用部門に起因するシステム障害」となります。
  5. 結論
    上記を踏まえた改善案は
    「利用部門に起因するシステム障害も分析対象にする」
    となります。

誤りやすいポイント

  • 「障害件数の集計対象にはなっていた」を見て、既に十分な対策が取られていると勘違いしやすい。集計だけでなく分析が不足している点が問われています。
  • ハードウェアやバッチ遅延の増加に目を奪われ、利用部門の障害を忘れがち。設問は“分析範囲を広げる”視点を重視しています。
  • 「ソフトウェア障害全般を深掘りする」とまとめてしまうと、改善先が具体性を欠き、採点ポイントから外れる恐れがあります。

FAQ

Q: 利用部門に起因する障害とは具体的に何を指しますか?
A: 【問題文】にある「利用者が設定しているパラメタ類の設定誤りなど」が代表例です。システム不具合ではなく運用・操作ミス由来の障害です。
Q: 既に件数は集計しているのに、なぜ分析が必要なのですか?
A: 件数だけでは原因や再発防止策が見えません。分析してこそ「教育」「手順見直し」など具体策を打てるためです。
Q: ハードウェア更新やバッチ対策とどちらを優先すべきですか?
A: 並行対応が望ましいですが、設問は“分析範囲拡大”を問うため、優先順位ではなく分析対象の網羅性を回答する必要があります。

関連キーワード: 原因分析, 再発防止, 運用管理, 障害報告書, KPI

設問3障害の原因分析・究明、及び再発防止について、(1)、(2)に答えよ。

(1)本文中のbcに入れる適切な字句を答えよ。

模範解答

b:直接 c:根本

解説

解答の論理構成

  1. 問題文の該当箇所
    “障害の引き金となったb原因の特定にとどまらず、c原因を究明し、再発防止策を詳しく定めることが必要である。”
    ここで “障害の引き金となった” と “究明” という二つのレベルが対比されています。
  2. “引き金となった” の語感
    事故・障害対応の分野では “trigger(引き金)” は “直接原因” を指します。したがって b には “直接” が入ると考えられます。
  3. “究明” の語感
    “究明” は表面的な原因より深い “根本原因(root cause)” を追究する場面で使われます。よって c には “根本” が最も適切です。
  4. 結論
    b = “直接”
    c = “根本”

誤りやすいポイント

  • “一次原因/二次原因” と混同して “一次” を入れてしまう。一次原因は状況により “直接原因” と一致しない場合があります。
  • “深層原因” などの類義語を選び “根本” を外す。用語集や過去問題で多用されるのは “根本原因(root cause)”。
  • “引き金”=“根本” と逆に読み取ってしまう。文脈上 “引き金” は表層を指しているので注意が必要です。

FAQ

Q: “直接原因” と “根本原因” はどう区別すればいいですか?
A: 障害が起きた瞬間のトリガやミスが “直接原因”、その背後にある組織的・技術的な欠陥が “根本原因” です。
Q: システム監査ではどちらまで追及するべきでしょうか?
A: 監査の目的は再発防止に資する改善を促すことなので、“根本原因” まで突き止めることが推奨されます。
Q: “根本原因分析” に使われる代表的な手法は?
A: 特性要因図、5 Whys、フォールトツリー解析(FTA)などが用いられます。

関連キーワード: 原因分析, 障害管理, システム可用性, 根本原因分析

設問3障害の原因分析・究明、及び再発防止について、(1)、(2)に答えよ。

(2)本文中の下線①について、販売管理システムの可用性を損ねるシステム障害に対する再発防止策の効果を定量的に確認する手段として、最も適切なものを解答群の中から選び、記号で答えよ。
解答群  ア:システム障害報告書上の承認体制と承認状況の確認  イ:システム障害報告書上の障害の原因及び停止時間の記載有無の確認  ウ:前々年度と前年度の稼働率の予測値の比較  エ:前々年度と前年度の事象別障害発生件数とシステム稼働時間の比較  オ:前々年度と前年度の利用部門からの障害報告件数の比較

模範解答

解説

解答の論理構成

  1. 監査チームの目的
    下線①には“①この指摘事項に対する再発防止策が、この1年で効果的に実施されているかどうかを確認すること”とあります。すなわち「再発防止策が販売管理システムの可用性を高めたか」を測定したいのです。
  2. 可用性の低下要因は障害件数の増加
     前年度の監査報告書には“販売管理システムにおいて、システム障害の発生件数が増加しており、システムの可用性が低下している”と記載されています。したがって再発防止策の効果は「障害件数が減ったか」「停止時間が短くなったか」で定量評価できます。
  3. 比較対象となる具体データ
     本文には表2“前年度:今回の監査対象、前々年度:前回の監査対象”として、事象別の障害件数が示されています。さらに注記2ではバッチジョブ数など、システム稼働時間を推定できる情報が与えられています。したがって「前々年度と前年度の事象別障害発生件数とシステム稼働時間」を比較すれば、件数・時間の両面から可用性改善を定量的に検証できます。
  4. 解答選択
     解答群を検討すると
     ・ア、イは“記載有無”や“承認状況”の形式確認であり定量比較になりません。
     ・ウは“稼働率の予測値”同士の比較で、実績ではなく不適切です。
     ・オは“利用部門からの障害報告件数”のみで、障害全体を捉えられません。
     ・エ“前々年度と前年度の事象別障害発生件数とシステム稼働時間の比較”だけが、①が求める可用性を損ねる障害の発生頻度と稼働時間を実データで定量評価できます。
     よって正解は「エ」です。

誤りやすいポイント

  • 「障害件数の比較」だけに着目し、稼働時間を無視してしまう。可用性は「件数×影響時間」で評価する必要があります。
  • 形式チェック(書式・承認欄など)が定量評価になると誤解する。形式の整備と可用性の向上は直接結び付きません。
  • “稼働率の予測値”を実績データより重視して選択してしまう。監査では実績で検証することが基本です。

FAQ

Q: システム稼働時間は表2に直接載っていませんが、どうやって比較するのですか?
A: 各年度の障害レベル別件数と“販売管理システムのバッチジョブ数は約250ジョブ”などの業務量情報から、停止した時間帯・ジョブ影響数を算出し、総稼働時間に対する停止時間割合を求めます。
Q: 利用部門に起因する障害は分析対象外でよいのですか?
A: 可用性向上の観点では全障害を把握すべきですが、再発防止策の効果確認では主としてシステム側原因(ハード・ソフト・バッチ)の変化を比較します。利用部門の誤操作は別の教育施策で管理します。
Q: 「予測値」ではなく「実績値」を使うべき理由は?
A: 再発防止策が“実際に機能したか”を検証するため、客観的な実績値で評価する必要があります。予測値だけでは策の有効性を示せません。

関連キーワード: 可用性, 障害管理, 定量評価, 稼働時間, 影響度

設問4障害報告書の作成に関連して、(1)、(2)に答えよ。

(1)本文中の下線②を裏付けるためにどのような分析を行えばよいか、分析の対象とする項目を含めた分析の視点を、40字以内で述べよ。

模範解答

インターネット販売の取扱データ量とバッチ処理に要する時間の相関

解説

解答の論理構成

  1. 監査チームはバッチ遅延の主因を調査
    引用:「バッチ処理の遅延の原因は、②インターネット販売データ量が増加したことが要因だと推測していた。」
  2. 推測を“裏付ける”には、推測された要因と結果が統計的に結び付く必要がある
    ・要因:インターネット販売の取扱データ量
    ・結果:バッチ処理に要した時間(遅延)
  3. 両者の関係性を把握する代表的手法が「相関分析」
    取扱データ量の増加とバッチ処理時間の増加が比例関係を示せれば、②の推測が実証的に支持される。
  4. したがって「インターネット販売の取扱データ量」と「バッチ処理に要する時間」を同一期間で集計し、相関を確認する分析が最適となる。

誤りやすいポイント

  • 「遅延件数の増減」だけを比較し、処理時間を無視してしまう
  • データ量ではなく「販売金額」など別指標を選んでしまう
  • 相関と因果を混同し、相関分析以外の手法(回帰以外の単純平均比較など)を答えてしまう

FAQ

Q: 相関分析以外の手法でも良いですか?
A: 回帰分析なども本質的には相関を測るため適切ですが、設問は“分析の視点”を問うため、要因と結果を同時に示す「相関」が最も端的です。
Q: 取扱データ量は具体的に何を指しますか?
A: 受注件数、明細行数、ファイルサイズなど、インターネット販売データの量的指標を指します。いずれも期間ごとに集計し、バッチ処理時間と並べて比較します。
Q: 相関が弱かった場合はどうすべきですか?
A: 他要因(バッチ設計、サーバ性能など)を追加して多変量分析を行い、遅延の真因を追究します。

関連キーワード: 相関分析, バッチ処理, データ量増加, 性能劣化, 量的指標

設問4障害報告書の作成に関連して、(1)、(2)に答えよ。

(2)本文中の下線③の事案に対して監査チームが行うべき障害発生時の報告に関する改善助言を、30字以内で述べよ。

模範解答

経営層に報告する対象を障害レベルB以上にする。

解説

解答の論理構成

  1. 事実確認
    • 監査チームは「全てのシステム障害が発生時に速やかに経営層に報告されている」が、下線③のとおり「経営層は障害報告メールを読まなくなって、重要な障害報告に対する経営層の意思決定が遅れてしまう懸念がある」と把握しました。
  2. 経営層のニーズ
    • 経営層インタビューでは「顧客に影響しない障害レベルCの障害は、対応が完了した後に報告してくれればよい」という意見が半数を占めています。
  3. 障害レベル定義の確認
    • 表1によれば、障害レベルB以上は「顧客に重大な影響」又は「業務に支障」を及ぼすため、経営層の迅速な意思決定が必要です。
  4. 改善助言の導出
    • レベルCをリアルタイム報告の対象から外し、レベルB以上だけを即時エスカレーションすれば、メール量が減り重要情報が埋もれません。
  5. 結論
    • よって改善策は「経営層に報告する対象を障害レベルB以上にする。」となります。

誤りやすいポイント

  • 経営層が「半数」しかレベルC即時報告を不要と述べていないので、全件報告を続けるべきと誤解する。実際には意思決定遅延リスクが強調されています。
  • レベルAのみを対象にすると、業務停止レベルのBが漏れる危険がある点を見落としがちです。
  • レベルCをまったく報告しない提案をしてしまう。経営層が求めているのは「完了後に報告」であり、報告自体をなくすことではありません。

FAQ

Q: レベルC障害はいつ経営層へ報告すればよいのですか?
A: 障害対応が完了し内容を整理した後、まとめて報告すれば十分と考えられます。
Q: メール以外の報告方法は必要ありませんか?
A: 緊急度が高いレベルA・Bでは電話や対面を併用し、意思決定を迅速化するのが望ましいです。
Q: 障害レベルの誤判定が心配です。
A: 発信者が仮設定し「システム運用部が必要に応じて変更する」という既存プロセスを厳格に運用し、判定基準を定期的に見直してください。

関連キーワード: 障害管理, エスカレーション, 可用性, 監査証拠
戦国ITクイズ機能

\ せっかくなら /

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

クイズ画面へ遷移する

すぐに利用可能!

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

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