応用情報技術者 2021年 秋期 午後 問11
システム構築プロジェクトの監査に関する次の記述を読んで、設問1~6に答えよ。
クレジットカード会社のU社では、顧客利便性の向上、コストの削減などを目的として、インターネットを通じて各種情報を顧客に提供するシステムの構築プロジェクト(以下、本プロジェクトという)を推進している。U社の内部監査部長は、年度監査計画に基づき、システム監査チームに対して、本プロジェクトの各段階の適切性を監査するよう指示した。
〔要件定義段階の監査で把握した事項〕
システム監査チームは、要件定義段階の監査をX年5月に行い、本プロジェクトに関して、次のことを把握した。
なお、監査の結果、監査報告書に記載すべき重要な指摘事項はなかった。
(1) 要件の区分
要件は、機能要件、セキュリティ要件、運用要件などに区分される。
(2) 機能要件
従来、クレジットカード利用明細などの顧客向けの情報(以下、カード利用情報という)は、基幹系システムで作成して出力し、広告用パンフレットなどとともに、顧客宛に送付していた。本プロジェクトでは、カード利用情報、広告情報などを顧客が Webブラウザで閲覧できるよう、情報系システムを開発するとともに、基幹系システムを改修する。
(3) セキュリティ要件
情報系システム及び基幹系システムの基本設計で定めるセキュリティ対策は、U社の情報セキュリティ対策基準に準拠する。
(4) 要件の管理
要件定義段階で未確定の要件(以下、未確定要件という)は、課題管理表に記載し、確定するまで管理する。未確定要件は、基本設計の開始日から2か月以内に確定させる予定である。
(5) 本プロジェクトの運営体制
本プロジェクトの重要事項を決定する会議体であるプロジェクト運営委員会は、U社のシステム部の部長を議長とし、業務管理部、顧客サービス部などユーザ部門の各部長、及びプロジェクトマネージャのV氏で構成される。プロジェクト運営委員会は月1回の定例開催に加えて、必要に応じて臨時に開催される。
(6) 本プロジェクトに適用されるプロジェクト標準
本プロジェクトには、U社のプロジェクト標準が適用される。プロジェクト標準の一部を表1に示す。

〔基本設計段階の予備調査で把握した事項〕
システム監査チームは、要件定義段階の監査に続いて、基本設計段階の監査を行うこととした。まず、予備調査をX年8月下旬に行い、プロジェクト計画書の確認などによって、次のことを把握した。
(1) 基本設計は、X年7月1日に開始した。
(2) 基本設計検討会は、V氏を議長とし、システム部及びユーザ部門の各部を代表する部員で構成される。基本設計検討会の議事録には、開催日時、出席者、検討事項、検討結果などが記載される。
(3) 機能設計では、Webページの構成、情報系システムと基幹系システムとのインタフェースなどを検討し、その結果を基本設計書に記載する。予備調査の時点では、機能設計に関する複数のタスクが未完了であった。
(4) セキュリティ設計では、アクセスの制御、データの暗号化などを検討し、その結果を基本設計書に記載する。
(5) 要件対照表は、X年8月31日までに作成を完了する予定である。
(6) プロジェクト運営委員会は、プロジェクト標準の内容を充足していることを確認して、X年10月31日に基本設計の終了を承認する予定である。
〔システム監査チームの検討〕
システム監査チームは、基本設計段階の監査について、予備調査の結果を踏まえて、本調査をX年9月10日~14日と計画した。また、監査結果に基づいて基本設計を見直すことができるよう、監査結果報告をX年aと計画した。システム監査チームが検討した監査要点及び監査手続の一部を表2に示す。

〔内部監査部長の指示〕
内部監査部長は、システム監査チームが検討した監査スケジュール、監査要点及び監査手続をレビューし、次のとおり指示した。
(1) 表2項番1の監査手続だけでは、監査要点を確かめるための十分な監査証拠を入手できないので、追加の監査手続を検討すること。
なお、要件対照表には多数の要件ID及び設計IDが記載されているが、監査要員、監査時間などには制約があるので、効率的な監査手続とすること。
(2) 〔基本設計段階の予備調査で把握した事項〕の(3)を考慮すると、表2項番2の監査手続では、監査要点を確かめるための十分な監査証拠を入手できない可能性がある。その場合に備えて、追加の監査手続を検討すること。
(3) 〔要件定義段階の監査で把握した事項〕の(4)を考慮して、本プロジェクトの未確定要件に関して、表2項番1~3の監査手続以外に、追加の監査手続を検討すること。
システム監査チームは、内部監査部長の指示を受けて、表3のとおり追加の監査手続を策定して、内部監査部長の承認を得た。


設問1:
〔システム監査チームの検討〕に記述中のaに入れる最も適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア:9月9日
イ:9月30日
ウ:10月31日
エ:11月1日
模範解答
a:イ
解説
解答の論理構成
- 監査報告書は、プロジェクトが“基本設計”を確定させる前に提示される必要があります。
【問題文】「監査結果に基づいて基本設計を見直すことができるよう、監査結果報告をX年aと計画した。」 - 基本設計が確定するタイミングは、【問題文】「プロジェクト運営委員会は…X年10月31日に基本設計の終了を承認する予定である。」と明示されています。
- したがって、監査報告書の提出日は“X年10月31日”より前でなければ、レビュー・修正の時間を確保できません。
- 候補日を検討すると
・「ア:9月9日」は本調査開始前(9月10日〜14日)なので不適切。
・「ウ:10月31日」「エ:11月1日」は承認日以降または当日で、修正期間が取れません。
・「イ:9月30日」は本調査終了(9月14日)後であり、承認予定日(10月31日)まで約1か月の修正期間を確保できます。 - よって最も適切なのは「イ:9月30日」と判断します。
誤りやすいポイント
- “監査報告書は承認日までに提出すれば良い”と考え、「ウ:10月31日」を選ぶミス
- 本調査期間を見落とし、「ア:9月9日」を選択する早とちり
- 承認後の修正は原則不可能である点を見逃し、「エ:11月1日」を選ぶ後追い発想
FAQ
Q: 監査報告書は必ず1か月前に提出しなければならないのでしょうか?
A: 厳密な日数規定はありませんが、【問題文】のように「見直すことができるよう」と明示されている場合、修正作業に十分な期間を確保するのが監査の目的に合致します。
A: 厳密な日数規定はありませんが、【問題文】のように「見直すことができるよう」と明示されている場合、修正作業に十分な期間を確保するのが監査の目的に合致します。
Q: 本調査から報告書提出まで約2週間(9月14日→9月30日)は短くないですか?
A: システム監査では簡潔なチェックリスト形式やサンプリング手続を使うことで、短期間で報告書をまとめるケースは一般的です。本問でも追加の監査手続が効率化を指示しています。
A: システム監査では簡潔なチェックリスト形式やサンプリング手続を使うことで、短期間で報告書をまとめるケースは一般的です。本問でも追加の監査手続が効率化を指示しています。
Q: 承認予定日が延期されたら監査報告の提出日も変更しますか?
A: 通常は変更します。監査報告がプロジェクトの重要なマイルストーンに連動するため、スケジュール変更時には監査計画も見直します。
A: 通常は変更します。監査報告がプロジェクトの重要なマイルストーンに連動するため、スケジュール変更時には監査計画も見直します。
関連キーワード: システム監査、監査報告書、プロジェクト運営、進捗管理、監査スケジューリング
設問2:
表2項番2に記述中のbに入れる適切な字句を、15字以内で答えよ。
模範解答
b:基本設計検討会の議事録
解説
解答の論理構成
-
監査手続の目的
表2 項番2は「基本設計検討会での検討結果に基づき、機能が設計されていること」を確認するものです。したがって、監査では「検討結果」を示す証拠と「機能設計」を示す証拠を突き合わせる必要があります。 -
検討結果を示す一次情報
予備調査で把握した事項の(2)に「基本設計検討会の議事録には、開催日時、出席者、検討事項、検討結果などが記載される。」と明記されています。ここで「検討結果」が記録されるのは議事録のみです。 -
監査手続の対比
表2 項番2の文面には「基本設計書の“機能設計”の内容が、基本設計検討会での検討結果と整合していることを確認する。」とあります。よって閲覧すべき資料は
・基本設計書(機能設計)
・検討結果が載った資料
の2点となります。 -
適切な資料の決定
検討結果を含む資料として該当するのは「基本設計検討会の議事録」です。以上より b には「基本設計検討会の議事録」が入ることが論理的に導かれます。
誤りやすいポイント
- 「要件対照表」や「タスク管理表」と混同する
⇒ これらは要件整合性や進捗確認の資料であり、検討会の“結果”を直接示すものではありません。 - 「基本設計検討会資料」「配付資料」など曖昧な表現を選ぶ
⇒ 問題文は「議事録」に具体的に言及しているため、曖昧な表現では不正確です。 - 「検討会議事録」と略称で書く
⇒ 原文の固有表現「基本設計検討会の議事録」を正確に引用する必要があります。
FAQ
Q: なぜ議事録が監査証拠として重要なのですか?
A: 議事録には「検討事項」と「検討結果」が公式に記録されており、後から設計内容が会議決定通りかを検証できる唯一の一次資料だからです。
A: 議事録には「検討事項」と「検討結果」が公式に記録されており、後から設計内容が会議決定通りかを検証できる唯一の一次資料だからです。
Q: 「タスク管理表」を見るだけでは不十分なのですか?
A: タスク管理表は進捗状況を把握するためのもので、検討結果の詳細は含まれていません。整合性確認には議事録が必要です。
A: タスク管理表は進捗状況を把握するためのもので、検討結果の詳細は含まれていません。整合性確認には議事録が必要です。
関連キーワード: 議事録、監査手続、設計レビュー、要件対照表
設問3:
表2項番3に記述中のcに入れる適切な字句を、15字以内で答えよ。
模範解答
c:情報セキュリティ対策基準
解説
解答の論理構成
- 【問題文】の表2項番3には
“基本設計書及びcを閲覧して、基本設計書の“セキュリティ設計”の内容が、セキュリティ要件を充足していることを確認する。”
とあります。 - ここで参照すべき “セキュリティ要件” がどこに定義されているかを探します。
- 【要件定義段階の監査で把握した事項】(3) には
“情報系システム及び基幹系システムの基本設計で定めるセキュリティ対策は、U社の情報セキュリティ対策基準に準拠する。”
と明記されています。 - つまり、セキュリティ設計が要件を満たしているかを確認するには “U社の情報セキュリティ対策基準” と照合する必要があります。
- よって c に入る文言は
情報セキュリティ対策基準
誤りやすいポイント
- “セキュリティ要件” と “情報セキュリティ対策基準” を混同し、前者を c に入れてしまう。要件そのものではなく、要件の基準を示す文書を参照する点に注意が必要です。
- “社内セキュリティポリシー” や “セキュリティ設計書” など類似名称の資料を選択してしまう。問題文で正式名称が引用されているため、語句を一字一句変えずに記述することが要求されます。
- “セキュリティ対策基準” と短縮形で書き、社名 “U社” を省略してしまう。固有名詞は原文を厳密に写す必要があります。
FAQ
Q: セキュリティ対策基準とセキュリティポリシーは同じものですか?
A: 一般にはポリシーが上位概念で、基準は具体的な対策や要件を列挙した下位文書です。本問では “情報セキュリティ対策基準” が具体的な参照対象です。
A: 一般にはポリシーが上位概念で、基準は具体的な対策や要件を列挙した下位文書です。本問では “情報セキュリティ対策基準” が具体的な参照対象です。
Q: 監査で基準を閲覧する際、どのような点をチェックすべきですか?
A: 設計書に記載されたアクセス制御、暗号化方式、認証手段などが “情報セキュリティ対策基準” の要求レベルと一致しているかを突合します。
A: 設計書に記載されたアクセス制御、暗号化方式、認証手段などが “情報セキュリティ対策基準” の要求レベルと一致しているかを突合します。
Q: “セキュリティ設計” が未完成の場合でも監査は実施しますか?
A: 可能です。進捗状況を確認し、未完了タスクが基準遵守に影響しないか、完了予定と管理方法を追加手続で確かめます。
A: 可能です。進捗状況を確認し、未完了タスクが基準遵守に影響しないか、完了予定と管理方法を追加手続で確かめます。
関連キーワード: システム監査、セキュリティ要件、設計レビュー、内部統制
設問4:表3項番1について、(1)、(2)に答えよ。
(1)dに入れる適切な字句を、5字以内で答えよ。
模範解答
d:母集団
解説
解答の論理構成
- 監査チームは内部監査部長の指示(表3項番1)に従い、効率的に監査証拠を入手するため「サンプリング」を採用しています。
- 表3の抜粋「要件対照表に記載されている全ての要件IDをdとして、要件IDをサンプリングする。」を読むと、サンプリングの対象となる集合は「要件対照表に記載されている全ての要件ID」です。
- 統計・監査の用語では、サンプリング対象となる全件集合を「母集団」と呼びます。
- したがって、dに入る適切な語は「母集団」となります。
誤りやすいポイント
- 「抽出対象」「全件リスト」など一般語で置き換えてしまい、専門用語「母集団」を思い出せない。
- 「サンプリング=標本抽出」に意識が向き、標本(サンプル)と母集団を取り違える。
- 監査文脈であっても統計用語がそのまま使われる点を見落とす。
FAQ
Q: 監査でサンプリングを行う理由は何ですか?
A: 監査時間・要員に制約がある中で、効率的に妥当な結論を得るためです。母集団から統計的またはリスクベースで標本を抽出します。
A: 監査時間・要員に制約がある中で、効率的に妥当な結論を得るためです。母集団から統計的またはリスクベースで標本を抽出します。
Q: 母集団を誤って限定するとどんなリスクがありますか?
A: 必要な項目がサンプルに含まれず、重大な不整合や不備を見逃すリスクが高まります。
A: 必要な項目がサンプルに含まれず、重大な不整合や不備を見逃すリスクが高まります。
Q: サンプリング手法はどのように選定しますか?
A: 監査目的・母集団の件数・リスク評価に基づき、無作為抽出・系統抽出などから選択します。
A: 監査目的・母集団の件数・リスク評価に基づき、無作為抽出・系統抽出などから選択します。
関連キーワード: 監査証拠、サンプリング、母集団、監査手続、リスク評価
設問4:表3項番1について、(1)、(2)に答えよ。
(2)eに入れる適切な字句を10字以内で答えよ。
模範解答
e:基本設計書の内容
解説
解答の論理構成
- 追加の監査手続(表3項番1)は、要件対照表に列挙された「要件ID」と、それに対応する「設計ID」の内容が一致しているかをサンプリングで確かめる手続です。
- 「設計ID」がどこに書かれているかは、【問題文】の「表1 プロジェクト標準(一部)」の記述が根拠です。
- 【問題文】引用
- 「・基本設計書は、機能設計、セキュリティ設計、運用設計などで構成される。」
- 「・検討した各設計内容に設計IDを付与し、基本設計書に記載する。」
- 「・要件IDと設計IDを対応付けた表(以下、要件対照表という)を作成し、基本設計書に添付する。」
以上から、設計IDの具体的な中身は「基本設計書」に存在すると分かります。
- 【問題文】引用
- したがって、サンプリングした要件IDに対応する設計IDの内容を確認する資料は「基本設計書」であり、eに入るべき語は「基本設計書の内容」となります。
誤りやすいポイント
- 「設計ID=設計検討会議事録」と誤解する
設計IDは議事録ではなく「基本設計書」に付与される点を取り違えやすいです。 - 「要件対照表そのもの」に設計内容が書かれていると勘違い
要件対照表は対応付けを示すだけで、詳細な設計内容は「基本設計書」に記載されています。 - 「要件定義書の抜粋」で済むと思い込む
監査対象は“要件”と“設計”の対応です。設計側の根拠資料が必須である点を見落としがちです。
FAQ
Q: 要件対照表だけでは設計内容を確認できないのですか?
A: 要件対照表は対応関係を示す一覧であり、設計詳細は載っていません。設計内容は「基本設計書」で確認します。
A: 要件対照表は対応関係を示す一覧であり、設計詳細は載っていません。設計内容は「基本設計書」で確認します。
Q: 設計IDが「基本設計書」にある根拠は?
A: 【問題文】「検討した各設計内容に設計IDを付与し、基本設計書に記載する。」と明記されています。
A: 【問題文】「検討した各設計内容に設計IDを付与し、基本設計書に記載する。」と明記されています。
Q: サンプリング対象資料は何になりますか?
A: 要件IDは「要件対照表」から抽出し、設計内容は「基本設計書」から確認します。
A: 要件IDは「要件対照表」から抽出し、設計内容は「基本設計書」から確認します。
関連キーワード: 監査証拠、要件対照表、サンプリング、基本設計書、設計ID
設問5:
表3項番2に記述中のfに入れる適切な字句を、10字以内で答えよ。
模範解答
f:タスク管理表
解説
解答の論理構成
- 追加の監査手続の目的
表3項番2では、未完了が懸念される“機能設計”タスクに対し「基本設計書の『機能設計』の内容を記載する時期」を把握することが目的です。 - 監査人が参照すべき文書を特定
監査でタスクの完了予定や進捗を確認する場合、プロジェクト標準に定義された進捗管理ツールを使うのが自然です。
表1の「進捗管理」には、 「プロジェクトの各段階のタスクの進捗状況は、タスク管理表に記載し、タスクが完了するまで管理する。」
と明記されています。
したがって、タスクの完了予定日は“タスク管理表”に載っていると判断できます。 - f の文脈確認
表3項番2の記述は、 「fを閲覧して、機能設計のタスクにおいて、基本設計書の『機能設計』の内容を記載する時期を確認する。」
となっており、「タスクの時期」を確認する文書は“タスク管理表”が最も適切です。 - 結論
よって f に入る字句は「タスク管理表」となります。
誤りやすいポイント
- 「議事録」や「要件対照表」と混同する
議事録には検討内容はあっても“記載時期”や“予定日”は載りません。 - 「計画書」を選んでしまう
プロジェクト計画書は初期計画を示す文書で、最新の進捗を反映しないケースがあります。 - 表1の引用を見落とす
進捗管理の方法が明示されているので、表1を読み飛ばすと誤答につながります。
FAQ
Q: 議事録でもタスクの完了予定を確認できるのでは?
A: 議事録は検討内容の記録が主目的で、進捗や予定を一元管理する文書としては“タスク管理表”が公式に定義されています。
A: 議事録は検討内容の記録が主目的で、進捗や予定を一元管理する文書としては“タスク管理表”が公式に定義されています。
Q: タスク管理表には具体的にどのような項目が載るのですか?
A: 一般的にはタスクID、担当者、開始日、終了予定日、進捗率、ステータスなどが載り、今回の監査では「終了予定日(記載時期)」が重要です。
A: 一般的にはタスクID、担当者、開始日、終了予定日、進捗率、ステータスなどが載り、今回の監査では「終了予定日(記載時期)」が重要です。
Q: タスク管理表が更新されていない場合は監査ではどう対応しますか?
A: 更新遅延自体が統制不備となるため、原因調査と是正勧告を行い、最新情報を別途ヒアリングで確認します。
A: 更新遅延自体が統制不備となるため、原因調査と是正勧告を行い、最新情報を別途ヒアリングで確認します。
関連キーワード: 進捗管理、タスク管理表、サンプリング、基本設計、監査手続
設問6:
表3項番3に記述中のgに入れる適切な字句を、20字以内で答えよ。
模範解答
g:全ての要件が確定していること
解説
解答の論理構成
-
追加監査手続の目的
内部監査部長は「〔要件定義段階の監査で把握した事項〕の(4)」を踏まえ、未確定要件に対する監査も指示しました。ここでの原文は
「未確定要件は、課題管理表に記載し、確定するまで管理する。」
です。したがって、監査人は課題管理表を使って要件の確定状況を確認する必要があります。 -
監査で確認すべきポイント
同じく原文には「未確定要件は、基本設計の開始日から2か月以内に確定させる予定である。」と明示されており、要件が全て確定しているかどうかが重要なチェック項目です。 -
空欄gを含む手続
表3項番3では
「課題管理表を閲覧して、gを確認する。」
とあります。課題管理表を閲覧する目的は、「未確定要件」がまだ残っていないかを確かめることです。 -
結論
以上より、監査人が課題管理表で確認すべき事項は「全ての要件が確定していること」となります。
誤りやすいポイント
- 「未確定要件の数」や「確定予定日」だけを答えてしまう。監査目的は要件が残っているか否かの確認であり、数や日付の報告では不十分です。
- 「課題管理表=進捗管理表」と混同し、タスクの完了状況を書いてしまう。設問は要件確定の有無を問うています。
- 「要件定義書と一致していること」と答えてしまうケース。これは表3項番1の手続に該当し、項番3の趣旨とは異なります。
FAQ
Q: 「要件が確定している」とはどの段階を指しますか?
A: 課題管理表に記載された未確定要件が全て解決済みとなり、確定フラグやステータスが完了に更新されている状態を指します。
A: 課題管理表に記載された未確定要件が全て解決済みとなり、確定フラグやステータスが完了に更新されている状態を指します。
Q: もし未確定要件が残っていた場合、監査人はどう報告しますか?
A: 報告書で未確定要件の存在と数、リスク(設計変更や遅延の可能性)を明示し、プロジェクト運営委員会へ改善を勧告します。
A: 報告書で未確定要件の存在と数、リスク(設計変更や遅延の可能性)を明示し、プロジェクト運営委員会へ改善を勧告します。
Q: 要件定義段階で確定期限を過ぎている場合、重大指摘になりますか?
A: プロジェクトスケジュールや影響範囲によりますが、期限超過は計画逸脱に該当し、監査上の重要指摘になる可能性が高いです。
A: プロジェクトスケジュールや影響範囲によりますが、期限超過は計画逸脱に該当し、監査上の重要指摘になる可能性が高いです。
関連キーワード: 要件管理、課題管理表、監査手続、監査証拠、サンプリング


