内部統制プロジェクトを進めるにあたって、重要な当事者は経営者、内部監査人、構築運用者、外部監査人である。しかしさらにその先の切り口として、構築運用者の中にシステム部門と経理（ユーザ）部門との関係がある。
一概には言えないかもしれないが、システム部門と経理部門は｢仲が悪い｣。経理部門は相次ぐ制度改正や決算早期化、不正対策、経営者の複雑化する管理会計要求、相次ぐ組織改編への対応などでシステムに更なる高度な機能を期待しているが、得てして｢うちのシステムは古い、使いづらい」とぼやく。一方システム部門は、「ユーザ要求が出なければ開発のしようがない」「ユーザはシステムの使い方が分かっていない」という。 もっと経理の勉強をしてシステムに活かせというのは経理部門の主張であり、もっとITの活用方法を考えて仕様要求を出せというのはシステム部門の主張で、どちらが正しいというわけではなく、これはそういうものだと受け止めざるを得ない。ところが、この状態が内部統制監査が始まると大変なことになる可能性がある。
例えば、IT業務処理統制に不備があった場合、ユーザは「それはシステムの不備ですね」と受け止める。しかし、システム部門は「当初から仕様になかったので業務側の運用でカバーすべきだ」と考える。制度は一定レベルのシステム整備を要求しているわけではないから、部分的にシステムの欠陥があることはそれ自体不備であったとしても、内部統制に重要な問題があるかどうかという判断とは一線を画する。内部統制の有効性は、最終的にリスクがユーザ部門による運用でどうカバーしているか（フェイルセイフの仕組）というところも含めて、判断される。しかし、システム部門とユーザ部門との連携が悪いと、フェイルセイフが機能せずに、結果的には、業務全体としてみたときには、なんらの統制手続によってもリスクがカバーされていないという状況になり得るのだ。
財務報告に係る内部統制という観点から、リスクを分析把握して、会社全体としてどういう形でリスクをカバーするかという全体設計ができるのは、実はユーザ部門でもシステム部門でもない。そういった「組織の壁」を抱えている組織は、内部監査部門が「なんらリスクがカバーされていない状態にある」と経営者に対してきちんと報告し、経営レベルでの対応を求める必要がある。内部監査部門が経営監査としての機能を発揮できる一つの好例だろう。
そういった組織風土自体を変えていかないと問題は解決しないという意味では、これは統制活動レベルの問題ではなく統制環境レベルの問題として捉えるべきという言い方もできる。
Tags: IT統制