今日、オープニングベルをみていたら、「内部統制報告書」の話がでてきてました。
これは、J-SOX法において、内部統制の監査をする際、経営者サイドで作成する書類のようだ。
くわしくは、ここ（PDF)
Ⅲ．財務報告に係る内部統制の監査（案）
http://www.fsa.go.jp/singi/singi_kigyou/siryou/naibu/20061106/01-03.pdf
それによると、この、内部統制報告書を監査して、内部統制監査報告書を出すようだ。
で、IT部分に関しても監査があるわけなんだが、問題は、１５ページのｃ
（以下斜体は、上記資料から引用）
評価対象となった業務処理統制に係る統制上の要点ごとに、一部の取引を抜き出し（サンプリング）、当該取引に係るシステムへの入力情報とシステムからの出力情報を比較し、予想していた出力情報が得られているかを、例えば、入力データに基づいて、検算を行うこと等により確認する。
これ、業務の書き方によっては、結構わかんないかも。。。
たとえば、UMLで書く場合、業務１つ１つに関しては、アクティビティ図で明らかになる。
でも、ある業務１個をとってきて、この業務の入力は何で、出力は何ですか？と聞かれると、はっきりとは、答えられない場合がある。
具体的に言うと、１つの売り上げデータをとりあげ、その売り上げデータの変遷をたとっていく、つまり、入力から、売り上げ計上されるまでの過程をたどるとした場合、このプロセスは、たどれる。アクティビティ図があるから。。
でも、たとえば、売り上げのスタートラインとなる受注で、どのテーブルに、どのように書き出されていますか？
というのは、たどれないかもしれない。アクティビティ図には、テーブルの書き出し内容まで書かれていない。なので、クラス図を解析することになるが、クラス図をみて、わかるかどうかは。。。さらに、書き出し先まで考えると、それは下流工程になってしまうし。。
つまり、いいたいことは、UMLの場合、アクティビティ図からクラス図に簡単に機械的に落ちるわけでもなく、また、クラス入出力情報がアクティビティ図に反映されないので、業務の流れはアクティビティ図でわかっても、そこから、入出力まで、かんたんにチェックできるかというと。。？？
そーすると、ウィリアムのいたずら提唱の、業務をまとめたシートみたいに、各アクティビティに関して、入出力を明確にし、それを、どんどん落として言って、最後には、そのアクティビティが１つのメソッドになるくらいまでにしていき、それを実装するという形にしたほうが、いいかもしれない。
さっきの例だと、受注の入出力は分かるし、それに対応するプログラムをしりたければ、実装したメソッドに行き着くまで、子アクティビティをどんどん子供のほうに下りていけばいいことになる。
まあ、ウィリアムのいたずら提唱のがいいか悪いかは別として、これ、まじ監査されると、入出力を明らかにするドキュメントが必要になってくるかもしれない。とくに、DBにどうやって格納しているかというドキュメントが。。
アクセス
トータル
ランキング
