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

システム監査技術者 2018年 午後1 問03


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

 S社は、日用品の卸売会社である。S社では、得意先からのEDI発注への切替要請及び受注業務の効率向上に対応するため、販売管理システムの更新を行うことになった。  これまでのシステム監査では、現在の販売管理システムについて特に指摘事項はなかったが、システムの更新によって新たな情報システムリスクが発生し、コントロールの見直しが必要になることが考えられる。そこで、S社の内部監査部は、販売管理システム更新の要件定義が終わった段階で、システム監査を実施することにした。   〔現在の販売管理業務の概要〕  現在の販売管理業務の概要は、次のとおりである。 (1) 受注  S社では、得意先からファックス又は電子メールで注文を受け付けている。  受注事務担当者は、注文内容を販売管理システムに受注入力する。入力された得意先コード、商品コード、与信限度額、及び在庫引当の可否を販売管理システムで自動チェックする。このとき、在庫不足で注文の全数を引き当てられない場合は、その都度得意先に不足分の納品が遅れることを連絡し、了解を得ている。このように納品が分かれる場合は、販売管理システムには、元となった注文内容を複数の受注データに分割して入力する。販売管理システムによるチェックの結果、エラーがなければ仮受注データとして記録される。  受注責任者が受注の可否を判断して承認入力を行うことによって、受注確定となる。受注確定後は受注内容の変更はできない。  受注処理は、毎日午後4時に締め切られる。その後、受注事務担当者は販売管理システムから受注伝票を出力し、得意先からのファックス又は電子メールの注文内容と照合し、漏れや誤りがないことを確認する。 (2) 出荷  確定した受注データに基づいて、出荷指示データが生成され、納品日・得意先ごとの出荷指示リスト及び納品書が各配送センタにおいて出力される。  配送センタでは、出荷指示リストに基づいて、得意先ごとに商品をそろえるとともに、配送車両の手配を行う。  出荷業務担当者は、出荷当日中に出荷完了入力を行う。何らかの事情で出荷指示どおりに出荷できない場合には、即座に出荷保留入力を行い、受注責任者に連絡する。   〔新しい販売管理業務の概要〕  内部監査部は、予備調査において、新しい販売管理システムの要件定義の責任者に対するヒアリング、及び要件定義書などの関係資料のレビューを行った。その結果、販売管理業務は次のとおり変更される予定であることが分かった。 (1) 受注  主要得意先の一つである大手スーパーマーケットのQ社からの要請によって、Q社からの受注は全てEDIで行う。EDIによる受発注成立の条件は、Q社とのEDI取引契約書に定められている。受注データを毎日午前6時に受信し、新しい販売管理システムで受注内容の自動チェックを行う。エラーとなった受注データは、Q社に受注エラーとして送信される。エラーにならなかった受注データは、受注確定として処理される。  Q社以外の得意先からの受注業務は、現在の販売管理業務の処理と同様とする。ただし、1件当たりの受注金額が10万円未満の受注データについては、受注責任者の承認を不要とし、受注入力が完了した時点で受注確定とする。 (2) 出荷  確定した受注データに基づいて、出荷指示データが生成される。このとき、得意先から指定された納品場所、納品日、及び在庫の状況から、適切な配送センタと出荷日時が自動的に決定され、出荷指示データに付加される。この付加処理は、納品場所、納品日、営業日カレンダ、配送業者、配送所要時間などを設定した配送マスタによって行われる。  出荷日の前日に、各配送センタに出荷指示リスト及び納品書に加えて、現品票が出力される。現品票には、受注番号などを示すQRコードが印刷されており、出荷時にQRコードリーダで読み取って、出荷完了入力が行われる。また、出荷日の当日に、処理された出荷完了処理の内容を一覧にした出荷完了リストが出力される。   〔予備調査結果の検討〕  内部監査部の監査チームリーダのK氏は、本調査の計画を立案するため、監査メンバのN氏、T氏と予備調査結果について検討を行った。そのときの会話(一部)は、次のとおりである。  K氏:EDIによる受注では、受注責任者による承認が行われませんが、問題はないですか。  N氏:Q社とのEDI取引契約書で受発注成立の条件が詳細に定められていて、その条件を満たしている受注は承認されたものとして取り扱うことになっています。したがって、aが受注責任者による承認に代わるコントロールとして機能すると考えられます。  K氏:そうすると、監査手続はどのようにすべきですか。  N氏:bとcとを照合して、EDIによるdを確かめることになります。  K氏:それから、EDI受注以外の受注で1件当たり10万円未満の受注データについては、受注責任者の承認が省略されることになりますが、リスクはないですか。  N氏:少額受注についてはこれまで問題が発生していないことから、リスクは極めて小さいと判断されたのではないでしょうか。また、受注業務の効率向上を図ることも、目的の一つになっています。  T氏:しかし、10万円未満の不適切な受注もあり得るでしょうし、10万円以上の受注の承認を回避するためにeというようなリスクが考えられます。受注業務の効率向上の観点から、1件ごとの承認を省略する場合でも、例えばfといったコントロールが必要なのではないでしょうか。  K氏:出荷完了処理についてですが、出荷業務担当者による手入力からQRコードの読取り入力に変更されます。これに関する要件定義段階での監査では、何を確かめればよいのですか。  T氏:QRコードの読取り漏れは売上計上の誤りに直結するので、要件定義書を査閲しgを監査手続とします。

設問1:

問題文を見る
EDIによる受注において、受注責任者の承認に代わるコントロールとして、本文中のaに入れる字句を30字以内で述べよ。

模範解答

a:販売管理システムによるEDI受注内容のチェック

解説

解答の導き方

  1. まず、通常の受注では、受注責任者が受注の可否を判断して承認入力を行うことで受注確定となります。つまり、受注内容を確認し、受注を認める判断をすることが承認の役割です。
  2. EDIによる受注では、この受注責任者による承認を行いません。その代わりに、Q社とのEDI取引契約書で受発注成立の条件を定めています。契約書は、どのような受注を成立させるかという判定基準になります。
  3. さらに、新しい販売管理システムは、受信した受注内容を自動チェックします。エラーになったデータはQ社に受注エラーとして送信され、エラーにならなかったデータは受注確定として処理されます。このため、受注責任者が個々に確認・承認する代わりに、契約で定めた条件に照らして受注内容を自動判定する仕組みがコントロールとなります。
  4. したがって、aには、受注責任者の承認を代替する仕組みとして、販売管理システムによるEDI受注内容のチェックが入ります。契約書だけでなく、システムが受注内容を実際に確認し、その結果によって受注確定の可否を分ける点が重要です。

誤りやすいポイント

  • EDI取引契約書だけを答えにする
    契約書は受発注成立の条件を定める基準ですが、その条件に合っているかを判定するのは販売管理システムです。承認に代わるコントロールとして問われているのは、システムによるチェックです。
  • EDIで受注データを受信することだけを挙げる
    データを受信するだけでは、受注内容が条件を満たしているか確認できません。自動チェックと、その結果に応じたエラー送信・受注確定の処理までがポイントです。
  • 受注責任者が承認する、と答える
    EDI受注では受注責任者による承認を行わないため、その代替となる仕組みを答える必要があります。

FAQ

Q: EDI取引契約書があれば、システムのチェックは不要ですか。
A: 不要ではありません。契約書は受注成立の条件を定めますが、受信した受注データが条件を満たすかどうかを自動判定する仕組みが必要です。
Q: エラーにならなかった受注データが受注確定になることは、なぜ承認の代わりになるのですか。
A: あらかじめ定めた条件に合う受注だけをシステムが確定させるためです。受注責任者が個々に判断する代わりに、システムのチェック結果で受注可否を決めています。

関連キーワード: EDI、入力チェック、業務処理統制、受注管理

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

この設問をAIに質問する

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

設問2:EDIによる受注データに関する監査手続について、(1)、(2)に答えよ。

設問2(1)

問題文を見る
本文中のb、cに入れる文書名を、本文中の用語を用いてそれぞれ10字以内で答えよ(順不同)。

模範解答

b:EDI取引契約書 c:要件定義書

解説

解答の導き方

この設問では、EDI受注の条件が販売管理システムの自動チェックに適切に反映されているかを確認するため、照合する文書を特定します。
まず、EDIによる受発注成立の条件は「Q社とのEDI取引契約書に定められている」とあります。したがって、契約上、どのような受注を成立させるのかを確認する文書はEDI取引契約書です。
一方、新しい販売管理システムでは、受注データを受信し、受注内容を自動チェックします。このシステムがどのような条件でチェックするかは、要件定義書で確認します。
つまり、契約で定めた受注成立の条件と、システムに設定する自動チェックの要件とを照合する必要があります。したがって、[b]にはEDI取引契約書、[c]には要件定義書が入ります。なお、設問では順不同とされています。

誤りやすいポイント

  • EDIで受信した受注データや受注エラーの送信記録など、処理結果のデータを文書名として挙げてしまうことがあります。この設問で問われているのは、条件を照合するための文書です。
  • 契約書だけを挙げてしまうと、契約条件がシステムの自動チェックに反映されているかを確認できません。システム側の要件を示す要件定義書も必要です。
  • EDI取引契約書と要件定義書の役割を逆に考えないようにします。契約上の条件を定めるのがEDI取引契約書で、その条件をシステム要件として確認するのが要件定義書です。

FAQ

Q: なぜEDI取引契約書だけでは不十分なのですか。
A: 契約に条件が定められていても、それがシステムの自動チェックに反映されているとは限りません。契約上の条件と要件定義書の記載を照合する必要があります。
Q: 要件定義書だけを確認すればよいのではありませんか。
A: 要件定義書に記載されたチェック条件が契約内容と一致するか判断するには、契約上の条件も確認しなければなりません。
Q: 文書を照合する目的は何ですか。
A: EDIによる受注で人の承認を省略する代わりに、契約で定めた受注成立条件がシステムの自動チェックに反映されていることを確かめるためです。

関連キーワード: EDI、要件定義、システム監査、監査手続、内部統制

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

この設問をAIに質問する

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

設問2(2)

問題文を見る
この監査手続で確かめるべき事項として、本文中のdに入れる字句を、40字以内で述べよ。

模範解答

d:受発注成立の条件の全てが受注データのチェック要件として定義されていること

解説

解答の導き方

  1. この設問で問われているのは、EDI受注について、受注責任者の承認に代わるコントロールが要件定義に反映されているかを、監査手続で何によって確かめるかです。
  2. 本文では、EDIによる受発注成立の条件は「Q社とのEDI取引契約書に定められている」とあります。さらに、その条件を満たす受注は承認されたものとして扱うと説明されています。したがって、この契約書に記載された条件が、承認に代わる判断基準になります。
  3. 新しい販売管理システムでは、受注内容を自動チェックし、エラーにならなかった受注データを受注確定として処理します。そのため、契約書で定めた条件がチェック項目に反映されていなければ、条件を満たしていない受注データが、承認なしで確定してしまうおそれがあります。
  4. そこで、EDI取引契約書と要件定義書を照合し、契約書の成立条件が漏れなくシステムのチェック要件に取り込まれているかを確認します。確かめる内容は、受発注成立の条件の全てが受注データのチェック要件として定義されていることです。

誤りやすいポイント

  • EDI取引契約書が存在することだけを確認するのでは不十分です。契約書の条件がシステムのチェック要件に反映されていることまで確かめます。
  • 契約条件の一部だけがチェックされていればよい、と考えないようにします。条件の漏れがあると、その条件に違反する受注データがエラーにならず、受注確定する可能性があります。
  • 実際の受注データが契約条件を満たしているかを確認する手続と、要件定義段階で条件がチェック要件として定義されているかを確認する手続を混同しないようにします。この設問では後者が問われています。

FAQ

Q: なぜ要件定義書を確認するのですか?
A: 受注内容の自動チェックは新しいシステムの機能として実装されるため、契約条件がその機能の要件に含まれているかを確認する必要があるからです。
Q: 契約書と要件定義書の照合では、特に何に注意しますか?
A: 契約書にある受発注成立の条件が、抜けなく受注データのチェック要件になっているかを確認します。一部でも反映されていない条件があると、その条件を満たさない受注が受注確定するおそれがあります。

関連キーワード: EDI、要件定義、システム監査、コントロール

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

この設問をAIに質問する

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

10万円未満の受注について、受注責任者の承認が省略されることによって発生するリスクとコントロールについて、本文中のe、fに入れる字句を、それぞれ40字以内で述べよ。

模範解答

e:1件当たり10万円以上の受注を10万円未満の受注に分割して入力する f:定期的に10万円未満の受注の一覧表を出力し、受注責任者がチェックする

解説

解答の導き方

まず、承認が省略される対象と、その処理方法を確認します。新しい販売管理業務では、Q社以外の受注について「1件当たりの受注金額が10万円未満」の場合、受注責任者の承認を不要とし、受注入力が完了した時点で受注確定になります。つまり、この金額の受注は、受注責任者が個別に確認する前に確定します。
ここから考えられるのは、承認が必要な金額の受注を、承認不要となる金額に分けて入力するリスクです。例えば、1件当たり10万円以上の受注を複数の10万円未満の受注に分割すると、受注責任者の承認を避けられてしまいます。したがって、[e]には、受注を分割して承認を回避するリスクを述べます。
一方、受注業務の効率向上という目的を保ちながら、そのリスクを確認する方法も必要です。個々の受注について承認を求めない場合でも、10万円未満の受注を定期的に一覧にし、受注責任者が確認すれば、承認を避けるために分割された受注などを事後に発見できます。そのため、[f]には、定期的に10万円未満の受注の一覧表を出力し、受注責任者がチェックするコントロールを記述します。

誤りやすいポイント

  • 「少額受注についてはこれまで問題が発生していない」という記述だけで、リスクがないと判断しないようにします。承認を省略する仕組みができると、新たなリスクが生じる可能性があります。
  • リスクを「10万円未満の不適切な受注が発生する」とだけ捉えると、承認省略の仕組みを悪用する具体的な危険を示せません。金額を分割して承認を避ける可能性まで考えます。
  • コントロールを「受注責任者がチェックする」とだけ書くのではなく、何を使って、どのように確認するのかを示します。ここでは、10万円未満の受注一覧を定期的に出力してチェックすることがポイントです。
  • 「全ての受注に承認を求める」とすると、受注業務の効率向上という変更の目的を踏まえたコントロールになりません。承認を省略する一方で、一覧表による確認を行う考え方が重要です。

FAQ

Q: 10万円未満の受注に、1件ずつ承認を求めればリスクを防げませんか。
A: 個別承認はリスクを抑えられますが、承認を省略して受注業務を効率化する目的に合いません。定期的な一覧表の確認によって、承認を省略しつつ不適切な受注を発見する方法を考えます。
Q: 一覧表を確認するときは、何に注意すればよいですか。
A: 10万円未満の受注の中に、承認を避けるために分割されたものがないかなど、受注内容に不自然な点がないかを確認します。
Q: このコントロールは、分割入力を事前に防ぐものですか。
A: 定期的な一覧表の確認は、受注確定後に不適切な受注を発見する事後的なコントロールです。個別承認を省略した場合のリスクを、定期的な確認で補います。

関連キーワード: 承認統制、閾値統制、例外取引監視、事後チェック、受注データ

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

この設問をAIに質問する

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

QRコードによる出荷完了処理が漏れなく行われるようになっているかどうかを確かめる監査手続として、本文中のgに入れる字句を45字以内で述べよ。

模範解答

g:出荷指示リストと出荷完了リストとの突合が行われるようになっていることを確認すること

解説

解答の導き方

この設問で確かめるのは、QRコードを読み取る仕組みそのものではなく、出荷完了処理の入力漏れを見つけられるように設計されているかどうかです。
本文では、確定した受注データから「出荷指示データが生成」され、出荷日の前日に各配送センタへ出荷指示リストが出力されるとあります。出荷指示リストには、出荷すべき内容が示されています。
一方、出荷時には現品票のQRコードを読み取って出荷完了入力を行い、出荷日の当日には「処理された出荷完了処理の内容を一覧にした出荷完了リスト」が出力されます。こちらは、システムに出荷完了として記録された内容を示すものです。
したがって、出荷指示リストに載っているのに出荷完了リストに載っていないものがあれば、出荷完了処理の入力漏れを発見できます。要件定義段階の監査では、この二つのリストを突き合わせる仕組みが要件定義書に盛り込まれているかを確かめます。この考え方から、出荷指示リストと出荷完了リストとの突合が行われる設計になっていることを確認する、という監査手続になります。

誤りやすいポイント

  • QRコードリーダが正しく読み取れるかだけを確認することです。読み取り機能が正常でも、読み取り自体を忘れる可能性は残ります。
  • 出荷指示リストか出荷完了リストの一方だけを確認することです。入力漏れを見つけるには、出荷すべき内容と、完了として記録された内容を比べる必要があります。
  • 要件定義段階の監査で、実際のリストを使った突合結果を確認すると考えることです。この段階では、突合が行われる仕組みが要件として定められているかを確認します。

FAQ

Q: QRコードを読み取る方式に変更すれば、出荷完了処理の漏れは防げますか。
A: QRコードの読み取りは入力を効率化しますが、読み取り忘れまでは防げません。出荷指示リストとの突合によって、処理漏れを発見できるようにする必要があります。
Q: なぜ出荷指示リストと出荷完了リストを比べるのですか。
A: 出荷指示リストは出荷すべき内容、出荷完了リストはシステムに記録された完了内容を示すためです。両者の差から、出荷完了処理がされていないものを見つけられます。
Q: この監査では、実際に突合が行われた記録を確認しますか。
A: 要件定義段階の監査なので、まず要件定義書を査閲し、突合を行う設計になっていることを確認します。

関連キーワード: 出荷管理、完全性、照合、QRコード、監査手続

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

この設問をAIに質問する

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

戦国ITクイズ機能

\ せっかくなら /

システム監査技術者を
クイズ形式で学習しませんか?

クイズ画面へ遷移する→

すぐに利用可能!

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

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