IT統制がわかりにくい本当の理由｜会計担当者とエンジニアの「すれ違い」を解説

はじめに

「IT統制の本を買って、3ページで挫折したことがある。全然わからない。」知り合いのエンジニアや会計士によく言われた言葉である。

「ITGC「ITAC」「FISC」「監査基準委員会報告書315」「SOC」……用語が多すぎるし、何のための知識なのかがわからない。

ただ、これはあなたの理解力の問題ではない。IT統制がわかりにくいのには、構造的な理由がある。

「難しい」と感じるのは、2つの職種が同時に詰まっているから

IT統制を勉強しなければならない人には、大きく2種類いる。それは、①経理担当者・内部統制担当者、②システム担当者である。

それぞれが

①経理担当者・内部統制担当者の壁

経理担当者・内部統制担当者の壁は以下のとおりである。

AWSってなに？サーバー？VPN？WAF？
GitHubって何なの？ブランチ？ソースデータ？
バッチ処理の要否は？緊急のメンテナンス対応は？
COBIT？FISC？内部統制基準？どれを読めばいいの

②エンジニア・情報システム担当者の壁

エンジニアや情シス担当者の壁は以下である

監査人はソースコードを見ないの？じゃあ何を気にしているの？
セキュリティはどのレベルまで見るの？
「仕様書を出して」と言われるが、うちはアジャイル開発なんだけど
AWSで自動バックアップを取っているのにダメなの？
アクセスコントロール？うちは小規模組織なのにどうなの？

同じテーマについて、真逆の方向から詰まっている。これが「IT統制がわかりにくい」の正体だ。

市場に出ている本や研修は、どちらか一方にしか向いていない。だから両者とも「なんとなくわからないまま」になる。

監査人が見たいのは「財務諸表の数字が正しく作られる仕組みがあるか」

ここが最も重要な誤解だと思っている。

エンジニアから「監査人が何を気にしているのかよくわからない」という声をよく聞く。

結論から言うと、監査人が見たいのは、財務諸表の数字が正しいかどうかだ。

売上の根拠資料がどこかのシステムで集計されて、仕訳として計上される。監査人が気にするのは「その集計システムから吐き出される数値が妥当か？粉飾のために改ざんなどをされない開発体制か？運用体制やセキュリティが万全か？」ということだ。

セキュリティ専門家が気にする「攻撃に強いか」ではなく、「財務データが改ざんされないか・意図しない誤りが混入しないか」を重点的に見ている。

この観点はエンジニアからしたら馴染みがないため、監査法人との面談に連れて行かれても「何を気にしてるんだ？」となってしまう。

IT統制には3種類ある

IT統制という言葉が難しいもうひとつの理由は、複数の概念を一つの言葉でまとめているからだ。

財務報告に関わるIT統制は、大きく3つに分かれる。

① IT全社的統制

ITに関する会社全体の方針・体制のこと。CISOはいるか、情報セキュリティポリシーはあるか、といった組織としての土台を見る。

② IT全般統制（ITGC）

このシリーズのメインテーマ。個々のシステムが適切に開発・運用されているかを見る。以下の4つに分かれる。

分類	中身
開発・変更・保守管理	システムの変更が承認されたプロセスで行われているか
運用管理	バッチ処理やバックアップ、インシデント対応の運用が正しく動いているか
アクセス管理	誰がどのシステムに入れるか、適切な権限付与がされているか
外部委託管理	クラウドやSaaSのリスクが管理されているか

③ 情報処理統制（IT業務処理統制）

業務アプリの中でデータが正確に処理されているかを見る。「売上データが会計システムに漏れなく連携されているか」といった話だ。

例えば売上集計ロジックが誤っており、売上が過大計上されることを防ぐことになっていく。

この3つの中で、IT全般統制は土台にあたる。土台が崩れていると、上に何を積んでも意味がない。

会計担当者へ：ツールの名前じゃなく「目的」で理解する

GitHubやAWSといったツールの細かい用途までは覚える必要がない。まずは「このツールは何のためにあるのか」だけを理解して説明すれば十分だ。

以下は

ツール	ツールの用途	IT統制で気にすること
GitHub	ソースコード管理・変更レビュー	コードの変更が承認なしに本番に反映されていないか
GitHub Actions / CircleCI	CI/CD（テスト自動化・デプロイ）	テストをパスしないとデプロイできない仕組みになっているか
Jira / Backlog	タスク・要件管理	変更の要件が記録されてコードと紐付いているか
AWS	クラウドインフラ（サーバー・DB・ストレージ）	インフラの操作権限は管理されているか。バックアップは取れているか
Datadog / CloudWatch	監視・アラート	バッチエラーや異常が自動検知・通知される仕組みになっているか
digdag / Airflow	バッチ処理・ジョブスケジューラー	バッチの実行ログが記録され、失敗時に検知できるか
Google Workspace / Microsoft 365	グループウェア・ID管理	アカウントの付与・削除が適切に管理されているか
Terraform / CloudFormation	インフラのコード管理（IaC）	インフラ変更がコードレビューを経て適用されているか

これだけ知っていれば、現場で「このログを見せてください」と言えるようになる。

エンジニアへ：監査人が見たいのは「証跡の存在」

監査人はコードの品質を評価しているわけではなく。「決められたプロセスが守られているという証拠」が欲しいのである。

そのため、以下のような証跡があれば、統制が有効と説明できるようになるだろう

ルールが文書化されている（「本番変更はPRレビュー必須」という規則）
ルールに沿って動いた証跡が残っている（PRのログ、承認記録）
例外があれば記録されている（緊急対応した場合の記録）

「仕様書がないアジャイル開発はダメ」ということはない。きちんと仕様等が何らかの形で残っており、メンバー同士の合意が取れており、証跡としてGitHubのPRとJiraのチケット等が紐付いていれば、「この変更はこの要件のためだった」という証跡になる。監査人が求めているのは書類の形式ではなく、プロセスの透明性だ。