[https://www.youtube.com/watch?v=nIMfQIIUfM4:embed:cite]
本問は、販売管理システム更新の要件定義完了時点において、業務変更に伴う情報システムリスクを洗い出し、それに対応するコントロールが要件として適切に定義されているか、さらにそれを監査人がどのような監査手続で確かめるかを問う構成です。特に、従来の人手承認や手入力に依存していた統制を、EDIや自動チェック、QR読取りに置き換える場面で、統制の抜けや迂回が起きないように設計されているかが核になります。 設問1は、EDI取引への切替により「受注責任者の承認」という人手統制をそのまま適用しにくくなる前提で、代替コントロールとして何を置くべきかを問うています。契約書で受発注成立条件が明確化されている以上、判断を人に戻すのではなく、販売管理システムがその成立条件を満たしているかを受注時点で自動的にチェックする統制に置き換えるのが自然です。したがって空欄aは、販売管理システムによるEDI受注内容のチェック、すなわち契約条件に基づく受注データの自動検証を指す表現になります。 設問2は、監査手続として何を何と照合し、何を確かめるのかを問うています。ここでの監査の狙いは、契約で定めた成立条件が、要件定義のチェック要件に漏れなく落とし込まれているかの確認です。照合する書類としては、基準となるEDI取引契約書と、それをシステム要件に具体化した要件定義書を用いるのが適切です。確かめる事項dは、受発注成立条件の全てが受注データのチェック要件として定義されていること、言い換えると契約条件と要件定義の対応関係が網羅的であり、欠落がないことになります。本文中の用語を使う指示があるため、文書名や条件の言い回しは、契約書・要件定義書・受発注成立条件といった本文の語彙でまとめるのが安全です。 設問3は、少額受注について承認を省略するという運用変更が、どのような不正・誤謬リスクを誘発し得るか、またそれをどう抑止・検知するかを問うています。10万円未満を承認不要にすると、承認が必要な10万円以上の受注を、10万円未満に分割して入力することで承認を回避できるリスクが生じます。したがってeは、1件当たり10万円以上の受注を10万円未満の受注に分割して入力する、といった承認回避の具体的態様になります。これに対するコントロールfは、承認を戻すのではなく、承認省略によって生じた「分割入力の温床」を狙って検知できる仕組みを置くのが要点です。例えば、定期的に10万円未満の受注の一覧表を出力し、受注責任者が分割の疑いがないかをチェックするという事後モニタリングは、リスクと対になった補完統制として説明しやすく、設問の意図にも合致します。ここで評価が分かれやすいのは、単に「一覧を確認する」だけではなく、なぜその一覧が分割入力の検知につながるのか、つまり承認を回避しようとする行為の発生点を捉える統制であることを答案に滲ませられるかです。 設問4は、QRコード読取りによる出荷完了処理という入力方式の変更に対して、読取り漏れが売上計上漏れや出荷実績の欠落につながるという完全性リスクをどう扱うかを問うています。監査手続gとしては、出荷指示を出したデータと、出荷完了として記録された実績データを突合し、差異が発生した場合に検知できる仕組みが要件定義に含まれていることを確認する、という形が筋が通ります。単に「出荷指示リストを見る」ではなく、「出荷指示リストと出荷完了リストを突合し、未完了が残らないことを確認できる」まで書いて、監査の観点と監査技法（突合）をセットで示すことが得点上の要点になります。 全体を通して、要件定義段階の監査である以上、監査人が直接「運用実績の誤り」を探すのではなく、リスクを抑止・検知するためのコントロールが要件として具体化され、抜けや迂回が生じにくい設計になっているかを、文書照合や定義内容の確認によって確かめる姿勢が問われています。EDIの自動チェックは契約条件の実装漏れが最大リスクになり、少額承認省略は閾値の悪用（分割入力）が最大リスクになり、QR読取りは入力漏れの検知が最大リスクになるため、それぞれの「起きやすい失敗形」を想定し、それに刺さる統制と監査手続を対応付けて書けるかが勝負所です。
