戦国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:

問題文を見る
本文中のa、dに入れる適切な字句を答えよ。

模範解答

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

解説

解答の論理構成

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

誤りやすいポイント

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

FAQ

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

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

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

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

模範解答

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

解説

解答の論理構成

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

誤りやすいポイント

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

FAQ

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

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

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

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

問題文を見る
(1)本文中のb、cに入れる適切な字句を答えよ。

模範解答

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)などが用いられます。

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

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

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

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

模範解答

エ

解説

解答の導き方

結論:正解は エ です。以下の手順で導きます。
  1. 監査の目的を確認する
    U君は「この指摘事項に対する再発防止策が、この1年で効果的に実施されているかどうかを確認すること」にした、とあります。つまり監査で求められているのは「再発防止策の効果を定量的に確認すること」です。定量的に確認するためには、数値で比較できる指標(率や時間など)を用いる必要があります。
  2. 問題文から利用できる情報を整理する
    ・「表2のとおりに事象別に障害を集計し、分析していた」とあり、前々年度・前年度の事象別障害件数が得られる。
    ・同時に「1年間で取扱データ量が2倍以上に増えた」と記載があり、業務負荷やデータ量が増加していることが分かる。
    ここから分かるのは、単に障害件数の増減を見るだけでは、業務量や稼働時間の差を考慮していないため「効果」を適切に評価できない、ということです。
  3. 定量的評価に必要な正しい手法を選ぶ基準
    再発防止策の効果を定量的に見るには、障害件数や停止時間といった「発生量」を、観察期間の「システム稼働時間」や業務負荷で正規化して比較する必要があります。具体的な指標例は次の通りです。観察期間の総時間を 、合計停止時間を 、障害件数を とすると、
    • 稼働率(可用性):
    • 障害発生率(単位時間当たり):
    • 平均停止時間(1件当たり):
      これらを前々年度と前年度で比較すれば、業務量や稼働時間の違いを踏まえた評価が可能です。
  4. 選択肢の評価(なぜエが最適か)
    • ア:承認体制と承認状況の確認は統制の有無を示すが、再発防止策の「効果を定量的に確認する」手段ではない。
    • イ:報告書に「障害の原因及び停止時間の記載有無の確認」は、記録の有無を確認するだけで、記載があるか否かのチェックだけでは比較・正規化して効果を評価できない。停止時間が記載されていれば評価に使えるが、選択肢自体は「有無の確認」にとどまるため不十分である。
    • ウ:稼働率の「予測値」の比較は過去の実績に基づく実測ではなく、予測に頼るので定量的な実績比較として適切でない。
    • オ:利用部門からの報告件数のみの比較は、システム側で検知した障害を含まないため全体を評価できない。
    • エ:前々年度と前年度の事象別障害発生件数とシステム稼働時間を比較することは、上で示した や などの定量指標を算出でき、業務量の変化(例:「1年間で取扱データ量が2倍以上に増えた」)を考慮した適切な比較になる。したがって定量的確認手段として最も適切です。
  5. 注記への対応(重要な実務上の留意点)
    問題文の注記「販売管理システムのバッチジョブ数は約250ジョブ」とあるだけでは、システム稼働時間 や停止時間 は算出できません。稼働時間や停止時間は監視ログ、運用記録、ジョブ実行履歴等から取得して算出する必要があります。必要なデータが得られたら上の式で比較すれば、再発防止策の効果を定量的に確認できます。
以上より、正解は エ です。

誤りやすいポイント

  • 障害件数の単純比較に終始し、業務負荷や稼働時間の変化を無視する(「1年間で取扱データ量が2倍以上に増えた」を見落とす)。
  • 報告書の記載の有無(イ)=評価完了と誤認する。記載があっても正規化や比較を行わなければ効果検証にならない。
  • 予測値(ウ)や一部の報告(オ)だけで判断する。実績ベースの観測値で比較することが重要。
  • 「販売管理システムのバッチジョブ数は約250ジョブ」だけで稼働時間が分かると誤解する。ジョブ数は頻度や実行時間を示さないため、稼働ログ等の追加データが必要。
  • 障害を一括して扱い、障害レベル(A/B/C)や原因別(ハードウェア/ソフトウェア/バッチ等)の分解を行わないため、対策の効果を見誤る。

FAQ

Q: 表2の件数だけで効果が分からないのはなぜですか?
A: 件数は絶対値であり、観察期間の稼働時間や業務量が変わると意味が変わります。たとえば業務量が2倍になったのに障害件数が同じなら、単位時間当たりの発生率は改善している可能性があります。正しくは障害発生率(件/稼働時間)や総停止時間/稼働時間で比較します。
Q: 稼働時間 や停止時間 が完全に記録されていない場合はどうするべきですか?
A: まずは監視ログ、運用記録、ジョブ実行履歴等から可能な限り実測値を抽出します。どうしても欠損がある場合は代替指標(トランザクション数やジョブ実行総時間)で補正しつつ、記録不備を監査所見として改善勧告します。
Q: 障害の重大性(A/B/C)はどう扱うべきですか?
A: 障害レベルごとに別個に指標を算出・比較します(例:Aレベルの障害発生率、Aレベルの合計停止時間など)。重大障害の低減が目的であれば、全体よりもレベル別の比較が重要です(表1の障害レベル定義に基づく評価)。

関連キーワード: 可用性、稼働率、ダウンタイム、インシデント率、根本原因分析

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

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

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

模範解答

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

解説

解答の論理構成

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

誤りやすいポイント

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

FAQ

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

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

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

設問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: 発信者が仮設定し「システム運用部が必要に応じて変更する」という既存プロセスを厳格に運用し、判定基準を定期的に見直してください。

関連キーワード: 障害管理, エスカレーション, 可用性, 監査証拠

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

戦国ITクイズ機能

\ せっかくなら /

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

クイズ画面へ遷移する→

すぐに利用可能!

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

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