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

解答の導き方

1. 現在の手続では、申請が多い場合に、職場ごとの担当者が申請一覧表を作成し、利用者の上長が一覧表を承認できます。つまり、多数の申請を一件ずつ承認しなくて済む仕組みがあります。
2. 一方、新システムでは利用者が自分で申請し、「利用者の上長が申請を承認」する流れです。本文では、新システムは「申請ごとの承認」とされているため、申請が多い場合、上長の承認作業が増える可能性があります。
3. 新システムには、定型サービスチームのリーダーが申請を一覧画面で承認する機能が予定されています。ただし、この機能の利用者として示されているのは定型サービスチームのリーダーであり、利用者の上長ではありません。したがって、この機能があるだけでは上長の負担を軽減できるとは限りません。
4. そこでT氏が確認すべきなのは、一覧画面で承認する機能を利用者の上長にも提供することを検討しているかどうかです。解答では、機能の提供先が利用者の上長であることと、その機能について提供を検討しているかを明確にします。

誤りやすいポイント

• 定型サービスチームのリーダー向けに一覧承認機能が予定されていることだけで、利用者の上長の負担も解消されると判断しないようにします。承認する人が異なります。
• 新システムで上長の承認がなくなるかどうかを答える問題ではありません。利用者の上長による承認を維持しながら、承認作業の負担を軽減できるかを確認します。
• 「一覧画面で承認できる機能」だけでなく、その機能を誰に提供するのかも解答に含めます。

FAQ

解答の導き方

誤りやすいポイント

• 新システムの説明にある「リーダーが承認する」だけを見て、必要な承認がそろっていると判断しないようにします。現在の手順には、条件によって部長の承認も必要とあります。
• 部長への回付を、すべての見積りに対して行うと考えないようにします。部長の承認が必要なのは、必要リソースが一定規模を超える場合です。
• 部長への通知だけではなく、承認が必要な見積りを部長が審査・承認する手順として考えます。

FAQ

解答の導き方

誤りやすいポイント

• 「担当者に更新権限を与える」だけでは不十分です。誰が更新できるかだけでなく、改定時にどのように作業するかを定めることが問われています。
• 定期更新だけに注目しないようにします。半年の間に改定があった場合は各定型サービスチームが更新するため、その場合の扱いも必要です。
• 仕様だけでなく、利用料単価も対象です。利用料単価は請求明細の作成に使われるため、更新漏れや誤りが請求に影響します。

FAQ

解答の導き方

1. まず、請求明細がどのように作られるかを確認します。本文には、毎月末に「サービス申請のデータに基づき」、サービスコードが一致する定型サービスマスターの利用料単価を使って各社への請求明細を作成するとあります。つまり、申請データとマスターのサービスコードが一致して初めて、請求明細を作成できます。
2. 次に、サービスコードが一致しない場合の処理を確認します。不一致の申請はエラーとなり、リストが出力されます。しかし、リストが出力されるだけでは、エラーになった申請が請求明細に反映されるとは限りません。
3. そのため、エラーに対処する部署や処理方法が明確でなく、エラーが適切に処理されないと、申請されたサービスの利用料が請求明細に反映されない可能性があります。したがって、懸念されるのはITサービス利用料の請求漏れです。

誤りやすいポイント

• エラーリストが出力されることを、エラーが自動的に解消されることと取り違えないようにします。出力後に誰がどのように対処するかが重要です。
• サービスコードの不一致から、直ちに利用料単価の誤りだけを考えないようにします。この問題では、請求明細の作成対象から外れ、請求漏れが生じるリスクが問われています。
• リスクを「処理が遅れる」などの一般的な表現にせず、請求処理にどのような影響があるかまで具体化します。

FAQ

解答の導き方

1. まず、監査で確かめるべきことは、締切日の変更を新システムの導入と同時に行うのではなく、運用が定着してから行うことを検討したかどうかです。T氏も「新システム導入後に運用が定着してから締切日を変更することを検討したかどうかを確認します」と述べています。
2. その確認が必要な理由は、本文に「新システム導入と同時に締切日を変更するので、開発とテストの作業量が多く、かなり厳しい日程」とあるからです。新システム導入と業務上の変更が重なると、移行時の問題が起きる可能性が高まるため、締切日の変更時期を分けることが検討されたかを確かめます。
3. ここでは、検討の有無を裏付ける資料を確認する監査手続が適切です。締切日の変更は経理部と協議しているため、その協議の議事録を閲覧すれば、変更時期や、新システムの運用定着後に変更する案が検討されたかを確認できます。したがって、監査手続は「締切日の変更についての経理部との協議の議事録を閲覧すること」となります。

誤りやすいポイント

• 新システムの開発・テストの進捗だけを調べても、締切日の変更時期を分ける案が検討されたかは確認できません。
• 経理部に口頭で尋ねるだけでなく、協議内容を記録した議事録を確認することが、検討の経緯を裏付ける手続になります。
• 問われているのは、締切日を変更すべきかどうかの判断そのものではなく、運用が定着してから変更することを検討したかどうかの確認です。

FAQ

解答の導き方

1. 確認するのは、定型サービスのリードタイムの目標を、利用者にも分かる形で示しているかどうかです。本文では、主要な定型サービスについて「現在よりも短縮する予定」であり、導入企画書案には目標が記載されているとあります。しかし、目標が企画書にあるだけでは、利用者が申請時に確認できるとは限りません。
2. 新システムでは、利用者は「サービスカタログの内容を確認した上で」申請画面に入力します。また、サービスカタログにはサービスの仕様などを記載するとされています。このため、利用者が申請前に確認するサービスカタログに目標を示せば、申請するサービスのリードタイムを利用者にも明確にできます。
3. したがって、T氏が確認するのは、定型サービスのサービスカタログにリードタイムの目標が明記される予定かどうかです。

誤りやすいポイント

• 目標が導入企画書案に記載されていることだけを確認対象にしないようにします。問われているのは、利用者にも目標が明確になるかどうかです。
• 目標を記載する場所を、申請画面やサービス利用者マニュアルと取り違えないようにします。本文では、利用者は申請前にサービスカタログを確認します。
• リードタイムを短縮する目標の設定そのものではなく、その目標を利用者が申請前に確認できる状態にすることがポイントです。

FAQ