内部統制（IT全般統制）をコンパクトにする方法 - 内部統制ブログ（フジタヒロキ）

・コンパクトな内部統制が向いている企業とは

僕は内部統制報告制度が始まる前のコンサル時代を含めて10年以上、J-SOXにかかわってきていますが、基本的には内部統制をコンパクトに設計すべきだと思ってるんです。例えばインフラ企業など大企業であれば、経営において事故を起こさないことが最優先されるので、業務を内部統制でガチガチにして、万が一にも事故が起きないようにすることを経営者が望んでいるしそうすべきだと思います。でも、それ以外の事業会社はどうでしょうか。少子化や市場のグローバル化、ITテクノロジーの進化など、これだけ変化の激しいい時代に守りの経営では会社を存続できないはずです。今売上が上がって利益が出ている事業でも、3年後5年後10年後はどうでしょうか。ずっと利益をもたらしてくれる保証などありません。経営者は常に新しい事業のの可能性を探して、投資を進めているはずです。また経営者だけでなく、従業員が仕事の内容や進め方が変化するのが当たり前であるという気持ちを持っていないと、会社として新しい事業への取り組みなど進みません。例えば、便利なクラウドツールを使いたいと従業員が思っても、内部統制や情報セキュリティの規則を理由に使用を許可されなかったら、仕事のやり方を変化させて新しいことに取り組もうなんて思えなくなりますよ。内部統制がガチガチだと、新しいことに挑戦するという気持ちが、社内で生まれなくなっちゃうと思うんですよね。まあ、インフラ企業などの大企業は事故が起きないのが最優先されますので、まあそれで良いんだと思います。でも大企業でも通常の事業会社であればそうはいかないはずです。日本の電機メーカーが凋落していってしまったのは、経営者も社員も、変化を良しとせずに守りに入ってしまったからなのだと思います。

前置きが長くなりました。本題に入ります。内部統制を効率的な必要最小限にする方法を考えてみましょう。経営者評価の範囲を最小にする方法を含みます。私の得意分野であるIT全般統制を対象にします。

私が考えるに、IT全般統制をコンパクトにする方法は、

１　内部統制の対象となる業務システムとその機能を明らかにすること、

２　IT全般統制のリスクを明確にすること

です。

IT全般統制とは何か、新ためて内部統制の実施基準にて確認しましょう。

・内部統制の実施基準

Ⅰ.２.（6）.②.〔ＩＴの統制〕.ロ.ａ．

ＩＴに係る全般統制とは、業務処理統制が有効に機能する環境を保証するための統制活動を意味しており、通常、複数の業務処理統制に関係する方針と手続をいう。

このように定められています。上場会社では、販売プロセスや購買プロセスなど重要な業務プロセスについて、業務記述書、業務フロー図、RCMなどのいわゆる3点セットの文章を作っていますが、この文書中で登場しない業務システムについて、全般統制を経営者評価する必要はありません。なぜなら実施基準にある通り、全般統制は業務処理統制を保証するためにあるからです。

これが意外と見落とされてます、IT全般統制の目的が十分に理解されてないとも言えます。例えば複数の事業を行ってる会社で、業務記述書の作成の対象外になっている事業の販売管理システムが全般統制の対象になっているという場合が結構あります。システムを安定稼働するためにIT全般統制は必要ですが、経営者評価の対象に含める必要は全くありません。今すぐやめましょう。

また、業務フロー図やRCMで、自動化された業務処理統制がなにか、しっかり把握しておくことによって、コンパクトな全般統制の整備が可能になります。なぜなら、業務記述書に出てくる自動化された業務処理統制に関連するIT全般統制だけを経営者評価の対象にすればいいからです。

例えばですが、ソーシャルゲームの事業を行っている会社を例に考えると、通常、業務フロー図やRCMに登場する自動化された業務処理統制は、石の購入処理、ガチャによる石の消費処理、セット販売による石の単価の違いがあればその平均単価計算、石の販売・消費のレポート機能、などです。これら自動化された業務処理統制が継続して機能することを担保するための全般統制が必要です。他方で、具体的にはパズドラのようなパズルゲームを想定します。ゲームの核はパズルですが、それは業務フロー図やRCMに登場しないでしょう。パズルに誤りがあったり、パズルが停止してしまったとしても、機会損失がありますが、財務報告の計算誤りなどは発生しません。なのでパズルに関連した全般統制を経営者評価の対象に含める必要はありません。例えばIT全般統制の開発変更管理の運用テストの実施で、課金のプログラム変更だけをテスト対象にして、ゲームのプログラム変更をテスト対象外することができます。運用テストの母集団をいたずらに広く捉えて沢山のサンプルを抽出するのは、今すぐやめましょう。

（注：私はパズドラを作っているガンホーさんの監査に全く関わったことがないので、想像で書いてます。あくまで例えです。）

２　IT全般統制のリスクを明確にすること

IT全般統制とは、具体的にどういった統制活動でしょうか。

ＩＴ委員会研究報告第46号「重要な虚偽表示リスクと全般統制の評価」を基に考えてみましょう

46号では例として全般統制を4つに分類しています

・システムの運用に係る全般統制

・開発・変更に係る全般統制

・情報セキュリティに係る全般統制

・外部委託業務に係る全般統制

この分類で考えてみましょう

（１）システムの運用に係る全般統制

①~⑤の事例が示されていました。

＞① ジョブスケジュールの登録・変更は、適切な者に承認される。

よくあるやつですね。

この内部統制を行っている会社のシステム構成や想定されるリスクは何でしょうか？

この内部統制はメインフレームの利用を想定してます。メインフレームのバックオフィスの業務システムでは、担当SEが毎月経理の月次決算のカレンダーに合わせて、夜間JOBスケジュールを設定しています。例えば、毎月3営業日が売上伝票の入力締め日なので、その夜に売上の集計処理を走らせ、5営業日が経費関係の伝票の入力の締め日なので、その夜に原価計算のJOBを走らせるなど、ジョブスケジュールの設定を行うのです。この場合、決算の締め日やジョブの前後関係などを誤ってしまうと夜間処理で作成される会計データが想定外の誤った数値になってしまいます。リスクが顕在化してしまいました。だからJOBの変更に関連する内部統制は重要なんです。でも今メインフレームを使っている会社は多くないですよね。これを読んでいる皆さんの会社でもLinuxやWindowsなどオープン系のサーバーを使っていませんか。なのにわざわざ、新しく開発した機能のプログラムとCronについて、開発変更管理のリリース承認とは別に、わざわざジョブスケジュールの登録変更の申請書を書いて、上長に承認を貰って、なんてやっていませんか。無意味なIT全般統制です、今すぐやめましょう。リスクがありません。

システムの運用に係る全般統制の②～⑤と、他のコントロールは次回の記事で考察します。