システム監査がわかりづらい理由と、会社及び監査人が理解すべきこと

はじめに

システム監査というものは会計監査や業務監査において定期的に行われている。

しかし、監査を受ける側としては「何を見たいのかわからない、見るべきポイントがずれている気がする」と思うこともあるし、監査する側としても「被監査部門がどんなツールを使っているのかわからない、統制におけるコントロールを把握していない」と思うこともあるだろう。

そのため、システム監査がなぜ分かりづらいのかについて検討をしてみよう。

システム監査における統制項目の例示

システム監査における監査対象は、監査の目的によって変化するものである。例えば、会計監査及び内部統制監査におけるIT監査の監査項目は以下の通りである。

  • 業務処理統制概要
    • 自動化された業務処理統制
      • マスタ統制
      • 入力チェック統制
      • インターフェイス統制
      • アクセス統制
      • 自動処理・永山統制
      • キーレポート自動作成
    • ITを利用した業務処理統制
  • 全般統制概要
    • システムの開発・保守
      • 開発における稟議や意思決定
      • 変更管理やレビュー体制
      • リリース管理
    • システムの運用・管理
      • マニュアルの整備・運用
      • 想定した利用が担保しているか
      • バックアップ
      • システムトラブル対応
    • システムアクセス統制
      • 権限に合わせたアクセス権の付与
      • モニタリング
    • 外部委託に関する契約管理

システム監査が理解しづらい理由

ここでシステム監査がなぜ理解しづらいのかについて検討してみよう

  1. システムの仕様や中身を理解することが困難であるため 　
    　システム監査を実施するためには、先程説明した全般統制及び業務処理統制について理解をする必要がある。しかし、各プロセスの内容は広範であり、被監査会社においても担当者が分かれていることがあるから、担当者レベルで全体を理解していないケースも起こりうる。 　また、システムの内容を理解するためには業務に対する理解・システムに関する基本的な知識を理解する場合が考えられる。それぞれの例示は以下の通りである。
    1. 業務に対する理解
      • 顧客の流入から販売までの一連の流れ
      • 業務における処理分岐の必要性
      • 業務において求められるデータ・出力されるデータの流れ
      • それらに対する利用部門レベルでの運用方法
      • 組織図や職務分掌の理解
    2. システムに関する基本的な知識
      • データベースやアプリケーションの知識
      • 開発等に利用しているツールの理解や機能
      • セキュリティ上求められる要件等
  2. 監査人と会社の前提が揃っていないため 　
    　システム監査を実施する前提として、監査人はシステムに対する体系的な理解を前提として、組織文化等の個別事情を踏まえて監査を実施する必要がある。 　しかし、現実において個別事情を理解せずにフレームワークに当てはめる、そもそも当てはめるべき前提が間違っているケースがあるため、それにより、ヒアリングでピントがズレた質問をする等といった問題が発生することがある。例えば、アジャイル開発を実施しているベンチャー企業に対してウォーターフォール前提のヒアリングを実施して、要件定義書や網羅的な文書化を求めるケースなどがこれに該当する。 　また、GitHubやAWSといったシステム開発の場面で一般的に利用されるツールへの理解が足らず、それらの説明を監査人が会社に対して求めるケースも散見される。そのため、監査人は一般的に利用されるツールに関する理解をする必要がある。
  3. 統制行為に対する会社と監査人の認識のギャップ
    　システム監査における監査項目は、監査の目的により異なる。例えば、システム監査においては以下のような目的がある。
    1. 財務諸表監査・内部統制監査におけるIT監査
      • 財務諸表監査及び内部統制監査の一環で行われる
      • 上記目的に関係しない部分は監査対象にならない
    2. It監査の目的
      • ITの有効性の確保・向上
      • ITの効率性の確保・向上
      • ITの安全性の確保・向上
      • 法律・社内ルール等への準拠性の確保

        すなわち、システム監査の目的によって監査項目が異なることを理解したうえで監査対応を行う必要がある点に留意が必要である。 また、監査におけるギャップとしては以下のようなものが考えられる
    • 実態を重視する会社と、証憑を重視するクライアント
      　監査においては第三者が業務の有効性等を評価するものであるため、監査意見のための監査証拠はヒアリングのみならず、外部証憑に頼る必要がある。しかし、会社は実務上証拠を残さない場合がある（特にスタートアップの場合は人員が少ないためよりその傾向が大きいと思われる）。 　業務が属人化していることからプロセスの証憑を残さず阿吽の呼吸になりがちな傾向・ドキュメントを残さないことで必要な情報や意思決定のログが残っていない場合がある。監査のためにドキュメントを作るのではなく、メンバーへの情報共有や作業ログとして業務プロセスに組み込む形式で運用を行うことが求められることを検討してほしい。
    • 現場における重要事項と、監査における重要事項
      　監査テーマは監査の目的や経営者の興味により変わるものであるが、これらは必ずしも現場が重要視している項目とずれることも考えられる。例えば、開発現場で重要な点とシステム監査で重要な点は以下が挙げられる。
      • 開発現場で重要なこと
        • 機能開発
        • 作業における進捗管理
        • テストの効率化
        • 省エネなアカウント管理
      • 監査において重要な項目
        • 機能開発における意思決定プロセスとログ
        • コードの変更及びデプロイ管理
        • テストの記録
        • アカウントのコントロール

会社とシステム監査人が互いに行うべきこと

上記の通り、システム監査において会社と監査人との間の認識のギャップが一番の問題点であることは理解できたであろう。それでは、お互いがギャップを埋めるために必要な点は何かを考えてみよう。

会社側

  • 監査上求められている要点を理解する 　監査を受ける際には、様々な資料を準備する必要があるうえに当たり前のことをイチから説明しないといけないこともあり、非常に面倒に感じることもあるだろう。適切な指摘や業務改善案を受けられる場合には被監査会社にとって有効であり、適切な改善内容を業務に組み込むことが出来るのであれば、さらなる業務の効果及び効率のアップに繋がるだろう。
  • エビデンスを残すことの重要性を認識する 　監査に置いて多くのエビデンスの提出を求められることがあるが、そのドキュメントの保存が社内コミュニケーションの効率化・暗黙知の形式知化に繋がる。そのため、監査のためのドキュメントではなく日常業務の記録や知識の共有のためのドキュメント記録を日常の業務ルーティンに含める必要がある。しかし、ドキュメントを残すことは非常に面倒になることがあるが、それは変更管理ツールのGitHubやチケット管理ツールのJIRAといったものを日常に組み込みながら記録を残すことを行うべきであろう。

システム監査人

  • 幅広いサービスやツール・開発手法の理解 　システム監査人の監査は指摘事項を行うのみならず、その先の業務改善に繋がる指導を実施することが、結果的に被監査会社のためになるだろう。しかし、会社のサービスや利用ツールを理解せずに頭ごなしに指導を行っても、会社の業務改善には繋がらず十分な指導的機能を発揮することが出来ないだろう。そのため、会社の利用しているツールや最新の開発トレンド、システム統制上の統制項目を解決するための手段を知ることで、より効果的な指導をすることができるだろう。 　また、クライアントが実際の開発ツールに対する理解、プログラミングやSQLを実際に書いてみることにより実務に即した監査を実施することができるだろう。
  • 開発形態と業種の違いを理解する 　昔のシステム開発においてはウォーターフォールが中心であった。そのことから、システム監査においてもウォーターフォール前提に立った監査を実施することが多い。しかし、現代の会社（特にスタートアップにおいては）アジャイル開発を実施することもあるため、無理にウォーターフォール前提での監査を行うギャップが生まれてしまう場合がある。そのため、会社がクライアントの開発形態を理解して監査を必要があるだろう。

最後に

システム監査に関する会社と監査人のギャップについての私見を述べてみた。
システム監査は時代や開発スタイルによってあるべきが変化していくものだと考えられるだろう。

おすすめ記事

一覧へ