(2)システム設計時の考慮は必須！
日本版SOX法では、単に正しい財務諸表を作りあげることを求められているだけではなく、
財務諸表を作るプロセスにおいて、
(1)不正・ミスが発生しない体制・プロセスを作りあげること
(2)作り上げた体制・プロセスで適切に財務諸表が作られていることを外部に証明すること
の２点が必要となります。
(1)については、前回の後半に、購買部門の例を書いたので多少イメージは持って頂いているかと思います。前回挙げたのは業務上のルールの話。これをシステム化しようとした場合には、申請・承認の流れや、承認できる条件の設定等をシステムに盛りこんでいくことになります。一部を切り出して話をすると、例えば以下のような感じです。
・営業部門からの発注依頼にもとづき、購買部門の担当者がシステムへ入力
・発注金額が５００万円以上であったため、システム上で部長へ申請
・部長がシステムへログインし、承認
ここまでが統制の取れた業務を設計し、システムの設計に反映すべし、ということです。
さらに、「ミス・不正が発生しない仕組み」というときに、上で書いた業務面だけでなく、IT面も明確にする必要があります。上の例でいうと、
○前任の購買部長が他部署へ移動した際、即座に権限が失効しているか？
○悪意を持った開発者が承認フローを故意に変更できないようになっているか？
というような点への対応もふくめ、「ミス・不正が発生しない仕組み」ができているという主張ができるわけです。
１ヶ月ほど前でしたか、日経新聞の社員がインサイダー取引で逮捕されましたが、上場に関する機密情報は、限定されたIDを持った人しか見られないようになっていましたが、そのIDの管理が非常にいい加減であったため、あのような事態が発生してしまっています。
このように、ユーザーアカウントの運用やプログラム変更プロセスまでも含め、ただしい財務諸表を作るための業務と見られてしまうため、業務設計・システム設計においては十分な考慮が必要となるのです。
次に、(2)「外部へ証明する」について、説明します。
これはとにかく、証拠となる記録を残しておくことに尽きます。購買部門での業務面でいうと、営業部門からの依頼書、部長による承認結果などが実データと関連付けられて管理されており、監査の際等に取り出せる状態になっていることが求められます。
ユーザーアカウントの運用に関しては、例えば、ユーザーアカウントの変更履歴などが証拠になるでしょう。つまり、このような証拠が何か、を識別し、それらをいつでも取り出せるようにしておくような設計が求められるのです。
以上をまとめると、日本版SOX法の対象となる企業のSIに係る場合、
○業務面・IT面の両面において、不正・ミスが発生しそうなポイントを網羅的に把握し、その対策を考慮した業務設計・システム設計をしていくこと。
○ミス・不正がなく業務がまわっていることを外部に証明するために必要な証拠とは何かを考慮し、適切な証拠が残せるようシステムを設計していくこと。
が求められるのです。
言ってしまえば、今回のコラムの冒頭に書いた「企業からのRFPに日本版SOX法に対応していること」という要件はこの２点をちゃんとしてくださいね、というようにも言い換えられます。
今回書いたことは、これまで詳細設計・開発・テストなどのフェーズを中心に活躍されている方にはあまりなじみがないかもしれません。とはいえ、より上流工程での活躍を目指しているのであれば、今回書いたようなポイントを理解することが皆さんの競争力を高めることになりますので、是非頑張って勉強してください。
次回（最終回）は、その勉強法をご紹介します。ご期待ください。
|
