Contents
  1. テーマ：建築家ではなく「防災アドバイザー」であれ
  2. 【練習問題】パート1 セクションA-6-b

テーマ：建築家ではなく「防災アドバイザー」であれ

新しいITシステムを開発・導入することは、家を建てることに似ています。 家が完成してから「耐震強度が足りないから基礎をやり直そう」とすると、莫大な費用と時間がかかります。設計図を書いている段階で指摘すれば、消しゴム一つで直せます。

内部監査人がシステムの「設計・開発」段階に関与することは、組織にとって最もコスト対効果の高い予防的活動（アドバイザリー業務）の一つです。 しかし、ここには最大の落とし穴があります。それは「監査人が作り手になってしまう（独立性の喪失）」ことです。

1. なぜ「開発段階」に関与すべきなのか？

システム開発ライフサイクル（SDLC）の初期段階に監査人が関与するメリットは以下の通りです。

  1. 手戻りの防止： 運用開始後にセキュリティホールや統制の不備が見つかるよりも、設計段階で修正する方がコストははるかに安く済みます。
  2. 適切なコントロールの組み込み： 「後付け」のコントロールは使い勝手が悪くなりがちです。最初から業務フローに統合された（Built-in）コントロールを提案できます。
  3. プロジェクト・リスクの低減： プロジェクト自体が予算超過や納期遅延に陥っていないか、第三者の視点でモニタリングできます。

2. 内部監査人が「やるべきこと（Role）」

アドバイザリー業務として、監査人は以下の役割を果たします。あくまで「相談役」や「審査員」の立場です。

  • 要件定義のレビュー：
    • 「監査証跡（ログ）を残す機能はありますか？」「パスワードの強度は十分ですか？」といったセキュリティ・統制要件が漏れていないか確認する。
  • テスト計画の確認：
    • ユーザー受入テスト（UAT）のシナリオが、すべてのリスクケースを網羅しているか助言する。
  • 会議への参加：
    • プロジェクト会議にオブザーバー（議決権なし）として参加し、リスク管理の観点から助言を行う。

3. 内部監査人が「やってはいけないこと（Prohibition）」

ここが試験の最重要ポイントです。監査人は、将来そのシステムを「監査」する立場になります。自分で作ったものを自分で監査することはできません（自己監査の禁止）。 したがって、「経営責任（Management Responsibility）」に該当する以下の行為は厳禁です。

  • × 設計・コーディングを行う：
    • 「私がプログラムを書いておきました」はアウトです。
  • × ベンダーを選定する：
    • 「A社に発注しましょう」と決めるのは経営陣の仕事です。
  • × 「本稼働（Go-Live）」を承認する：
    • 「システムをリリースして良し」というハンコを押すのは、システムオーナーやプロジェクト責任者です。監査人は「テスト結果を見る限り、重大な不備はありません」という意見を言うまでです。

4. 継続的監査（Continuous Auditing）のアプローチ

大規模なシステム開発では、開発の節目（マイルストーン）ごとに監査人がチェックを行うアプローチが有効です。 これを「完了後監査」に対して「並行監査（Concurrent Audit）」と呼ぶこともあります。

  • メリット： 問題をリアルタイムで発見できる。
  • 注意点： チームの一員になりすぎて、客観性を失わないようにする（プロジェクト・チームとのなれ合いを防ぐ）。

まとめ

セクションA-6-bのポイントは、「手は出さず、口を出す」です。

  • If 監査人が設計段階で「ここに窓を作ると泥棒が入りますよ」と助言する → 〇 適切なアドバイザリー。
  • If 監査人が「ここに窓を作って承認した」 → × 独立性の侵害。

家を建てる際、監査人は「建築家（設計者）」でも「現場監督（責任者）」でもなく、図面を見て安全性をチェックする「防災アドバイザー」の立ち位置を守ってください。

【練習問題】パート1 セクションA-6-b

Q1. 組織が新しい基幹会計システムを開発中である。内部監査部門長（CAE）は、このプロジェクトに対してアドバイザリー業務を提供することに合意した。この業務における内部監査人の役割として、GIASに基づき許可されるものはどれか。

A. システムのユーザーマニュアルを作成し、従業員への操作トレーニングを実施する。

B. 新システムの仕様書をレビューし、適切なコントロール（入力チェック機能や承認フローなど）が組み込まれているかを確認して助言する。

C. 外部のシステム開発ベンダーを選定するための最終決定会議に参加し、投票権を行使する。

D. システムの受入テスト（UAT）が完了した後、本稼働（Go-Live）の最終承認署名を行う。

【解答・解説】

正解と解説を表示

正解（B）： システムの設計・開発段階における内部監査人の適切な役割は、コントロールやセキュリティの要件が満たされているかをレビューし、推奨事項（助言）を提供することです。これは「予防的コントロール」として機能します。

不正解（A）： マニュアル作成は運用業務の一部であり、経営責任に近い行為です（軽微な支援なら許容される場合もありますが、Bの方がより適切かつ主要な役割です）。

不正解（C）： ベンダー選定の「決定（投票）」は経営責任であり、独立性を損ないます。

不正解（D）： 本稼働の承認はシステムオーナー（経営陣）の責任です。

Q2. システム開発ライフサイクル（SDLC）の初期段階（設計フェーズなど）から内部監査人が関与することの最大の利点（メリット）はどれか。

A. 監査人がプログラミングを手伝うことで、開発期間を短縮できる。

B. システムが完成した後に監査を行う必要がなくなり、監査コストをゼロにできる。

C. 統制の不備やセキュリティ上の欠陥を早期に発見・修正することで、稼働後の改修コストやリスクを大幅に低減できる。

D. 開発チームのメンバーと親密になることで、将来の監査において不正を見逃してもらいやすくなる。

【解答・解説】

正解と解説を表示

正解（C）： システム開発において、欠陥の修正コストは工程が進むほど指数関数的に増加します。設計段階での監査人の関与は、コントロールを「後付け」するのではなく「作り込む（Built-in）」ことを可能にし、コスト効率と有効性を最大化します。

不正解（A）： 監査人はプログラミング（実行）を行ってはいけません。

不正解（B）： 稼働後も「実際に設計通り動いているか」を確認するアシュアランス監査は必要です。

不正解（D）： 親密になりすぎて客観性を失うことはリスク（独立性の毀損）であり、利点ではありません。

Q3. 内部監査人は、過去に自身が「設計段階でのアドバイザリー業務」に関与したシステムの「稼働後のアシュアランス監査（運用評価）」を担当することになった。この状況における独立性と客観性に関する記述として、最も適切なものはどれか。

A. 過去に関与したシステムであっても、当時「経営責任（決定・承認）」を負っていない限り、アシュアランス業務を行うことは可能である。ただし、客観性に対する潜在的なバイアスには注意が必要である。

B. いかなる形であれ開発に関与した監査人は、永久にそのシステムの監査を行ってはならない。

C. 自分で助言したシステムであるため、中身を熟知しており、客観性の問題は生じない。

D. 以前のアドバイザリー業務で発見された不備は、今回のアシュアランス業務では指摘してはならない。

【解答・解説】

正解と解説を表示

正解（A）： アドバイザリー業務において「助言」に留まり、「決定」を行っていなければ、独立性は侵害されていないとみなされます。したがって、同一の監査人が後の監査を行うことは禁止されていません。しかし、「自分の助言は正しかった」と思い込むバイアスのリスクはあるため、慎重な配慮（または別の監査人の起用）が推奨されるケースもあります。

不正解（B）： 「永久に禁止」は厳しすぎます。適切な期間（例：1年）や役割分担があれば可能です。

不正解（C）： 熟知していることは利点ですが、「自己レビュー」に近い状況になるため、客観性が損なわれるリスクは逆に高まります。

不正解（D）： 不備があれば、過去の経緯に関わらず指摘・報告する義務があります。