応用情報技術者 2011年 秋期 午後 問12

解答の論理構成

1. a を特定
   • 購買申請の直前に「登録取引先から見積書を取った後、購買システムに…」とあります。
   • (4) 発注では「購買課は購買の申請とaを照合し…」と記載されています。
   • 申請内容と照合して妥当性を確認する文書は、直前の工程で取得した「見積書」しかありません。
     ⇒ a：見積書
2. b を特定
   • (4) 発注の最後に「取引先にファックスで発注書を送付するとともに、写しを申請部署と経理課に送る」とあります。
   • (5) 物品の検収では「申請部署は、取引先から物品が届くと、b（写し）の内容と照合して…」とあります。
   • 検収時に参照する “写し” は、直前に配付された「発注書」の写しです。
     ⇒ b：発注書
3. c を特定
   • (5) 物品の検収で「検収した内容が記された検収書が作成される。…写しを経理課に送る」とあります。
   • (6) 請求書の検証では「経理課は請求書、b（写し）及びc（写し）を確認し…」とあります。
   • 経理課が受領しているもう一つの写しは、検収後に発行された「検収書」です。
     ⇒ c：検収書

誤りやすいポイント

• 見積書と発注書を取り違え、a と b を逆にしてしまう。
• 検収書を「納品書」と混同し、c を誤答する。
• “写し” の送付先（申請部署・経理課）を読み飛ばし、どの部門がどの書類を保有しているか把握できないまま解答してしまう。

FAQ

解答の論理構成

1. 監査指摘の背景
   【問題文】には「夜間バッチ処理のジョブの開始・終了をチェックするだけでなく、ファイル転送の誤りがなかったかどうかをチェックするべきである。」とあります。つまり、転送ジョブ自体は正常終了しても、実データが欠落・破棄されているリスクが残っています。
2. 必要となる統制目的
   求められるのは「ファイル転送の誤りを検出」する統制であり、暗号化やデータ分析ではなく、転送結果が完全であるか（完全性）の確認が中心です。
3. 各選択肢の検討
   • ア：『送信ファイルと受信ファイルのデータ件数を比較する。』
     送信側と受信側の件数を突合すれば、途中で破棄・欠落したレコードの有無を即座に検知できます。完全性検証としてシンプルかつ有効です。
   • イ：『データの暗号化を行う。』
     機密性の確保が目的であり、件数欠落は検知できません。
   • ウ：『データマイニングを行う。』
     大量データから傾向を抽出する分析手法であり、転送エラー検出とは無関係です。
   • エ：『ファイル転送の前にパリティビットを付加し、受信時にこれをチェックする。』
     1ビット誤り検出には有効ですが、文字コード変換で「該当レコードは破棄」されるという【問題文】の状況では件数欠落までは分かりません。
4. 結論
   欠落レコード検出という目的に最も合致するのは「ア」です。

誤りやすいポイント

• パリティビット（エ）が万能と思い込み、件数欠落にも対応できると誤解する。
• 「暗号化＝安全」と短絡してイを選ぶが、完全性検証とは目的が異なる。
• データマイニング（ウ）を高度な対策と過大評価し、基本的な件数照合を軽視する。
• ジョブ正常終了＝転送成功と早合点し、データ内容の完全性確認を行わない点を見落とす。

FAQ

解答の論理構成

1. 事象の発生タイミングを確認
   • 監査結果で問題となったのは「承認量を超える数量の物品が検収され、購入金額が承認された申請金額を超過する」という点です。【問題文】「申請部署が取引先に対して口頭発注を行うことが原因で、承認量を超える数量の物品が検収され…」と記載されています。
   • つまり“検収”時点で過剰数量が初めてシステムに入力され、後続の「請求書の検証」で金額超過が判明している構図です。
2. 抑止すべきポイントを特定
   • 口頭発注を禁止しても、物理的に届いた数量が多ければ検収担当は入力せざるを得ません。
   • よって、システム側で「承認された数量・金額を超えてはいけない」というチェックを掛けるのは、超過数量が入力される“検収”画面が最適です。
3. 他工程では不十分
   • 「発注」工程（エ）で超過チェックを行っても、口頭発注→未承認分納のルートは依然として残り、実際に届いた物の入力時に超過が発生します。
   • 「請求書の検証」（カ）では既に金額超過が起きた後であり、「防止」ではなく「発見」になってしまいます。
4. 結論
   • 以上より、金額超過を事前に防ぐ機能は「物品の検収」（オ）に組み込むのが最も効果的です。

誤りやすいポイント

• 請求書チェック（カ）を選ぶと「発見」タイミングと「防止」タイミングを混同して失点しやすいです。
• 発注工程（エ）を選ぶ受験者が多いですが、問題文は「申請部署が取引先に対して口頭発注を行うこと」が原因と明示しており、発注書を出しても口頭分を防げない点を見落としやすいです。
• 「購買の申請」（ウ）でのチェックは既に行われているため、ここに追加しても二重管理になるだけで根本解決になりません。

FAQ

解答の論理構成

• まず購買規程には、 「実際の購入金額が承認された申請金額を超える場合、購買の再申請・再承認が必要である」
  と明記されています。
• ところが監査結果では、 「購入金額が承認された申請金額を超過するという事象が、請求書の検証時に多く発生している」
  と指摘されています。これは請求書確認という最終段階で初めて超過が発覚するため、再申請の手間と支払遅延を招いています。
• そこで本文は、 「請求書の検証の前にこのような①金額超過を防止するシステム機能を追加すべきである」
  と要求しています。
• 超過発生の主因は、検収入力後に合算金額が確定することにあります。したがって検収時点またはその直後に「承認額との突合 → 超過なら差戻し」という流れを自動化すれば、再申請手続きを確実に起動できます。
• 以上より、追加すべき機能は
  「承認額を超えた場合に購買の申請を差し戻す機能」
  となります。購買システムが自動判定し、承認ワークフローを再開させることで金額超過を事前に食い止められます。

誤りやすいポイント

• 「検収時ではなく請求書検証時に差戻す」と解答してしまう
  → 問題は“請求書の検証の前”に超過を防止する機能を求めています。
• 「数量チェック」とだけ書く
  → 金額超過が論点。数量は分納などで変動するためシステムはチェックしていないと本文にあります。
• 「再申請・再承認を自動実行する」と書く
  → 自動実行までは求められておらず、差戻して利用者に再申請を促すことが趣旨です。

FAQ

解答の論理構成

1. 現状の業務担当を確認
   ・取引先登録について【問題文】には
   「経理課担当者が、取引先の会社名・銀行口座・支払条件などの情報を取引先マスタに仮入力する。経理課長が承認すると、仮入力した情報が取引先マスタに反映される。」
   とあり、実務担当は「経理課」です。
2. 職務分離方針と例外規定を確認
   ・方針全文は【問題文】
   「購買に関する各業務を兼任することはできない。ただし、…
   　a) 発注を行う部署は、取引先審査と取引先登録の業務を兼任できる。」
   によって、発注部署（＝購買課）が「取引先登録」を兼任してよいと規定しています。
3. 違反箇所の抽出
   ・発注を担当するのは【問題文】「購買課は…発注書を出力した後、取引先にファックスで発注書を送付」と明示されており、発注部署＝購買課です。
   ・しかし実際の「取引先登録」は経理課が実施しており、例外規定の「発注を行う部署」である購買課ではありません。
   ⇒ 職務分離方針に違反。
4. 是正策（移管）の決定
   ・例外規定に合わせるには「取引先登録」を発注部署である購買課へ集約するのが妥当。
   ・したがって、 移管元：経理課（ア）
   移管先：購買課（イ）
   業務　：取引先登録（イ）
   が正解となります。

誤りやすいポイント

• 「取引先登録」を誰が担当すべきかを「経理関連だから経理課」と早合点しやすい。例外規定 a) を見落とすと誤答になります。
• 「取引先審査」と「取引先登録」をセットで移管と考えがちですが、審査はすでに購買課長が担当しており移管対象外です。
• 「発注部署＝購買課」の判断を逆に取ってしまい、移管方向を反対に選んでしまうケースも頻発します。

FAQ

解答の論理構成

1. まず現状のアクセス権管理体制を確認します。問題文には
   「“特権アカウント”の新規登録、変更、削除については、システム課長の承認を必要としている」
   とあります。
2. さらに同じ段落で
   「システム課長は、特権アカウントをもったユーザリストとアクセスログを…確認している」
   と記載されています。
3. つまり、特権アカウントを“管理（登録・変更・削除の承認）”する権限と、“行使状況をモニタリング”する権限の双方が システム課長一人に集中しています。
4. 権限と監視が同一人物に集中すると、自らの不正操作を自らのチェックで隠蔽できるため、抑止力が働かず不正を発見できないおそれが生じます。
5. 以上より、模範解答は「特権アカウントの管理と行使の権限が同一人に付与されているから」となります。

誤りやすいポイント

• 「四半期ごとに出力して確認している」点だけを見て十分と判断し、職務分離の欠如に気付かない。
• アカウント数が「合計3人」であることを問題視し、人数の多寡が論点だと誤解する。
• 「承認」と「利用」が同一人物にあることではなく、同じ部署にあることが問題だと読み違える。

FAQ