2008年のJ-SOXの適用から5年が経過した。これまで、地域金融機関や保険会社に対して、IT全般統制・IT業務処理統制の環境整備、評価支援を中心とした内部統制プロジェクトを実施してきたが、同じ業態・規模・組織でも、その取り組み結果が「洗練された統制環境となり、経営陣が内部統制に充分にコミットできている会社」と「形式論と現場責任が前面に押し出され、経営陣が内部統制に充分にコミットできていない会社」に大きく二分されているように感じる。

　図1は、簡易な自己チェックリストである。内部統制に関するプロジェクトを進める際、当社では、このリストに基づき、各クライアント企業の自己診断から支援を始めることが多い。

図1：簡易自己チェックリスト

（出所：NTTデータ経営研究所にて作成）

　申し上げるまでもなく、「はい」と「いいえ」の左右で成功と失敗に別れている。多くの方は「いいえ」に多くの◯が付いたのではないだろうか？　そして、◯を付けながら「そんなに上手く行くわけがない」「これは理想に過ぎない」と呟かれたのではないだろうか？

　内部統制の成功と失敗を分けるメカニズムは、実は非常に単純なもので、ほんの少しのさじ加減で成功にも失敗にも転ぶ。図2は、先ほどの図1の自己チェックリストを「成功パターン」と「失敗パターン」に分けて再構成したもので、チェックリストではバイアスを避けるために敢えてバラバラな記述をしたが、ここに挙げたポイントが、実は内部統制のP-D-C-Aサイクル（＝環境整備→実施→評価→見直し）に相対しているのだ。

図2：簡易自己チェックリストの項目の再構成図

（出所：NTTデータ経営研究所にて作成）

　このサイクルは、文末にそれぞれ「ので」を付けると読み易く、因果関係に裏付けられたストーリーとなる。つまり、成功も失敗も実は「見える化」ができたかどうかで決してしまうという、とてもシンプルなメカニズムとなっている。

　見える化とは、読んで字の如く「目には見えないものを数値で表す」「数値で表せないものでも、ある尺度を設けて共通認識とする」「概念でしかないものを図で表す」など、複数の意味合いがある。内部統制における見える化とは、「業務プロセスを意味のあるアクティビティに分解すること」「アクティビティに潜むリスクを明らかにすること」「リスクに対するコントロールがどんなアクションであるかを明らかにすること」であると言えるだろう。

　さて、この定義には実は大きな問題がある。それは、「目に見えない概念を、個人の解釈の余地が残る文字で表したこと」である。文字による定義は、読んだ人の個々の経験や知見によって認識が異なる可能性が避けられない。

　この認識のズレが、フローチャートや業務記述書の記述粒度の差＝見える化の精度の差となって出てくる。さらに厄介なことには、フローチャートや業務記述書は、一見しただけでは記述粒度に差があることがわからないのだ。これが内部統制の見える化が不完全になってしまうメカニズムである。実際、見える化に問題を抱えた企業は、内部統制の文書化マニュアルや規程類、リスクの定義が文章だけで構成されているケースが多い。

　図解と言っても、特別に難しいものではなく、マトリクスと言い換えることができるほどの簡単なものである。図3をご覧いただきたい。これは、当社にて、IT全般統制のフレームワークを一般化して考えた構造化モデルである。

図3：IT全般統制の一般的なフレームワーク

（出所：NTTデータ経営研究所にて作成）

　【万能薬①】は、統制対象プロセスを「業務」と「システム資源」で見える化した統制対象定義モデル、【万能薬②】は、【万能薬①】で定義された各プロセスのステップを「部門」と「役職」で見える化したコントロール定義モデルである。この2つの万能薬を雛型とすることにより、認識を統一化し、バラつきを無くすことが可能となる。

　金融機関に多く見られる課題と、それに対する対策＝処方箋をご紹介したいと思う。

【多く見られる課題】

• ① 業務記述書、フローチャートの記載粒度がバラバラ
• ② キーリスクの選定基準がバラバラ
• ③ キーコントロールの設定基準がバラバラ
• ④ 外部委託先における実際の業務プロセスが不明瞭
• ⑤ システム運用に関わるミスが多発
  　（統制が有効であれば、起こり得ないようなシステム障害など）

• ・「業務」や「システムリソース」毎にリスクやコントロールが分離されていない。
  
  • ⇒「業務」や「システムリソース」によって、想定されるリスクや対応策は異なるはずであるが、分離されていないため、担当者によって、何を統制対象とするか、どの様なリスクが想定されるかの認識に差異が生じる。
• ・リスク設定やコントロール設定の基準が無い。
  
  • ⇒担当者の業務経験・内部統制の業務経験・性格等によって、設定が必要と考えるリスクやコントロールのレベルに差異が生じる。

• STEP1：
  システム環境（プログラムやデータベースなどのライブラリ）と運用マニュアルなどから、統制対象モデルとキーコントロール設定モデルの仮説を作成。
  （図3は、この仮説になる）
• STEP2：
  これらモデルを執行部門の役職者・担当者を集めて説明。あくまでたたき台として、これを改善するという目的で議論・批判をいただく。
  （実は、これは批判的な目で見ていただくことで構造を頭に焼き付けて貰うことが狙い）
• STEP3：
  STEP2で出た意見を取り込み、それぞれのモデルを修正して開示。
  （修正義務は負わせない。あくまで執行部門としての自主に任せる）

　上記3つのSTEPを実施することで、今後のウォークスルーテストはほぼすべての統制対象プロセスの見える化が一気に進むのではないだろうか。キーコントロールのスリム化も可能である。監査部門も執行部門も「漏れが怖い」ため、重厚なリスク・コントロール定義をしてしまいがちであるが、会社としての標準系が「図解」されただけで、適切な判断ができるようになる。

　図解による構造化は、物事をシンプルにする力がある。皆様にも是非お試しいただければ幸いである。