データ分析基盤で問題になるIT統制

はじめに

⚠この記事はコース料理の脇に添えてあるパセリ程度と思って楽しんでください。フリじゃないよ。

【本記事は会計系 Advent Calendar 2023における22日目のエントリーです】

　企業経営におけるデータ活用への関心は年々高まっております。それに伴い、データ分析基盤と呼ばれるデータの蓄積→加工→分析を一気通貫で行える仕組みを構築し、各事業部が分析基盤を用いてデータ分析を行うケースが増えております。それは経理業務も同様であり、データ分析基盤に蓄積されたデータを用いて財務会計及び管理会計に役立てるケースも増えてきました。

　しかし、会計にデータ分析基盤を用いるためには、IT統制という壁が立ちはだかります。IT統制と聞くだけでウッとなる人が多いでしょうが、財務報告に用いるためにはここは避けて通れません。大変ではありますが・・・。

　そこで、本稿ではデータ分析基盤の概要と、IT統制との関連の解説を行います。なお、IT統制の詳細についてはNFSQ氏の「詳解: IT統制とIT監査」を参照してください（本当にありがとうございます。おかげで前提知識の解説が相当省けました）。もし時間のある方は、私の記事とNFSQ氏の記事を相互参照するのがおすすめです（勉強になるかもね）。

データ分析基盤とは

データ分析基盤とは、データの収集・統合・蓄積・分析までを一気通貫で行うための基盤です。これを用いることで、元々部門ごとにバラバラに保存されていたデータを一箇所に統合し、使いやすい形に整理することで、ユースケースに合わせたデータを提供することが可能になります。これにより、各事業部が必要な形で一つの情報源を参照することになるため、、部門間の整合性などが担保されるようになります。

データ分析基盤の構成例は以下のようになります。

データレイクに各所から情報を収集し、使いやすい形に整えデータウェアハウスに格納、ユースケースごとにデータマートを作りニーズに合わせてデータを活用していきます。財務会計や管理会計への活用も、データ分析基盤のユースケースの１つとして位置づけられるようになります。

しかし、データ分析基盤をIT統制に用いる際に問題になるのが、IT統制です。IT統制とは、ITの利用から生じるリスクに適切に対応するための内部統制のことであり、IT全般統制、IT業務処理統制（情報処理統制）、IT全社統制から構成されます。これらの詳細についてはNSFQさんの記事を参照いただきたい（本当にありがとうございます。）

なお、「財務報告に係る内部統制の評価及び監査の基準」におけるIT統制の位置付けについては以下の図のように整理されています。

データ分析基盤におけるIT統制をなぜ構築する必要があるのか。それは「財務報告に影響があるため」です。データ分析基盤ではユーザー行動ログなど財務報告に直接関係しないものも扱うこともあります。財務報告に関連しない情報処理プロセスは財務報告に係る内部統制のスコープ外ですが、売上データ等の財務報告に係るデータのプロセスについては、内部統制監査や財務諸表監査のスコープとなるため、IT統制をきちんと構築する必要があります。

こうした背景もあるから、会計データの根拠にシステムを用いる場合は、企画段階から会計人材と一緒に要件等を洗い出すのが望ましいでしょう。

データ分析基盤におけるIT統制の問題点

データ分析基盤を会計に用いるためにはIT統制を構築する必要がある点について解説してきた。本章では、具体的にどのような点を考慮して体制構築をしていくべきかを記載していきます。

データの網羅性

　一番の論点といっても過言ではないのは、データの網羅性です。データ分析基盤は各所からデータを集約することが多いため、データ移行の仕組みが重要になります。その中でも特に、本番環境から分析環境への移行が論点になることが多いです。

　例えば、ツールごとの強みが異なることから、本番環境と分析環境で異なるツールを利用することはよくあります。その場合には、本番環境に蓄積されたデータを分析環境に移行する必要が出てきます。しかし、データ移行の際にデータが網羅的に移行されないと、分析環境上で正しい結果が出力されなくなるため、財務報告に必要な情報の信頼性が担保されないことになります。

　そのことから、データが網羅的に移行されていることを検証するために、データ件数や合計額などのチェック機能を設けるなど、データ移行の有効性を担保するためのプロセスを構築する必要があります。

データ編集に伴う権限（アクセス権）

　データ分析基盤上のデータが不要に変更されないように、職域や職階に見合ったアクセス権を付与する必要があります。特に、DBの削除や変更権限を持つアカウント管理は重要になるため、必要な職位の者にだけ必要な権限を付与することが大事です。例えば、分析担当者はあくまでDBの閲覧権限だけあれば分析可能であるため、下手に編集権限を付与しないようにしなければなりません。

　これらは基本的なことではありますが、会社によっては全員管理者に設定していることもあり得るため、適切に管理を行わないと足元をすくわれます。基本的だけど大事なんだよ。

分析基盤に使うシステム自体の妥当性

　分析基盤をAWSやGCP等のクラウドサービスを用いて構築することが増えているが、クラウドサービス及びその提供会社（受託会社）の信頼性が担保されていない場合には、分析基盤自体の信頼性に疑義が生じる。そのため、分析基盤を構築する会社は、利用しているクラウドサービス提供会社（受託会社）の受託体制を評価する必要がある。それに用いるのがSOC1レポートです。SOC1レポートとは、受託会社の財務報告に係る内部統制を対象に、受託会社の監査人が客観的に評価した報告書を指します（詳細についてはNSFQさんの記事を参照いただきたいです。マジのマジでありがとうございます）。

　受託会社によってはSOCレポートを提供していないケースもあります（AWSやGCPなどの大手は備えていることが多いですが）。SOCレポートがない場合は、SOCレポートを取得する以外の方法で委託先の内部統制を評価するなど、代替的な手続きを実施する必要があります。

個人的見解になりますが、上場企業及びIPO準備会社が財務報告に係るシステムを導入しようとする場合は、SOCレポートを発行しているか否かを判断軸の一つとして入れることが重要です。特に会計ソフトを導入するにあたってはSOCレポートがあることがほぼ必須と思っても過言ではないでしょう。

抽出結果の妥当性

　分析基盤自体の妥当性が十分に担保できたとしても、そこから吐き出されるデータが誤っている場合には、当然財務報告の信頼性に疑義が生じる。そこで必要なのが、抽出結果の妥当性を検証するプロセスです。

　データ分析基盤に集約されたデータは、データアナリスト等がBIツールやSQLなどを用いて加工したうえで利用されます。しかし、もしその出力ロジックが誤っている可能性は当然あり得るわけです。そこで、その誤りを防ぐために、クエリやBIツールのロジックのレビュー、出力結果の妥当性を検証するプロセス、クエリの変更履歴を追うための体制構築が求められます。

「出力ロジックはエンジニアに任せているから正しいはず」と思い込んでいる方もいるかもしれませんが、エンジニアが経理担当者から依頼された通りに書いているだけで、出力される結果に対して責任を負っているとは限りません。したがって、経理人材が自ら数値の妥当性を検証する仕組みを構築することが望ましい。

さいごに

　パセリ程度の記事ですが、最後まで読んで頂きありがとうございました。データ分析基盤はたしかに便利ではありますが、財務報告に係る内部統制については盲点になりやすいため、きちんと専門家がカバーする必要があると考えられます。また、IT統制における検証ポイントはイマイチ掴みづらい所もあるため、本稿を参考にして少しでもイメージを持って頂けると嬉しいです。

　そしてACC_ACに皆様が想像以上に気合を入れててビックリしました。先に書いたほうが楽なやつだったか・・・。

　次回は毛糸さんの記事になりますので、楽しみにしております（圧）。