操作手順書があって、業務手順書がないわけ

 システム開発を行うと操作手順書は作っても、業務手順書を作るケースは多くない。システムの操作ができれば業務が行えるかというとそんなことはない。RDBが主流のデータベースになって、ソフトウェア開発の仕方は、まずデータベース設計を行い、それからデータベースを操作するプログラムを作成するようになった。プログラム名や画面名を見ればそのことはよくわかる。注文情報管理画面(注文情報の登録、更新、削除)や在庫情報管理画面(在庫情報の登録、更新、削除)などである。業務としては、受注業務、注文内容変更、注文取消し、入庫、出庫などである。
 システムのアクセスログを取ろうとすると、データベースへのアクセスログは簡単に取れるが、それは何の業務に基づくログであるかがわからない。したがってアクセスログはプログラムのそれぞれで意味をもたせて出力をしなければならなくなる。
 これまでDOAやOOAのアプローチでシステム開発をすることが期間を短くしたり、品質の確保に大いに貢献してきたわけであるが、それは業務を行うということをシステムを操作する人に押し付けてきたことにつながっている。日本版SOX法への対応で浮かび上がってくるのは、業務もシステムの中に組み込まなければならないということである。注文情報の変更がなぜされたのは、注文内容が変わったのか、入力ミスであったのか、承認されたかということを業務プロセスとして認識しなければならないのである。きちんと業務プロセスをモデリングし、システムに埋め込むためにはどうしてもワークフローが必要になってくる。
 日本版SOX法はソフトウェアの開発の仕方を根本的に変えてしまうことになる。