日本版SOX法でプログラム開発に求められるもの：セキュリティツールで作る内部統制（8）（1/3 ページ）

本連載ではこれまで、日本版SOX法対応におけるセキュリティについて解説してきた。今回からは、セキュリティ以外の部分である「プログラム開発」や「プログラム変更」「コンピュータ運用」の3つの領域について説明していく。

[中島 浩光，＠IT]

　本連載ではこれまで、IT全般統制の中でも重要といわれている「セキュリティ」について説明してきました。そして、今回からはセキュリティ以外の部分である、「プログラム開発」や「プログラム変更」「コンピュータ運用」の3つの領域について説明していきます。まず、今回は「プログラム開発」に関して日本版SOX法対応において必要とされることを説明します。

「プログラム開発」と「アプリケーション統制」とは

　まず、日本版SOX法対応におけるプログラム開発の位置付けを考えてみましょう。日本版SOX法は「財務報告の正確性・信頼性の確保」が目的であり、「現在行っている業務プロセス」と「現在利用しているシステム」が内部統制の対象となります。

　「プログラム開発」の領域における統制活動は、これらのシステムの開発過程における統制活動であり、その成果物である業務システムにおける統制活動が、「アプリケーション統制」であると考えればよいでしょう。

　そう考えた場合、財務報告の正確性を確保するのは、結局成果物である「アプリケーション統制」であり、アプリケーション統制がしっかりしていれば、「それを生み出すプロセスでしかないプログラム開発は放っておいてもよいのではないか？」という意見もあるかもしれません。

　しかし、第1回のCOSOフレームワークの説明の中でも触れましたが、「インプットが正しく、正しい手続きでプロセスが実行されれば、アウトプットは正しいはずである」という考えからすると、正しい開発プロセスが実施されてこそ、アウトプット（業務システム）も正しいはずです。逆に、開発プロセスが正しくないのにアウトプット（業務システム）が正しいのは偶然である、ととらえられてもおかしくないのです。つまり、監査人の立場で考えると、開発プロセスが正しくない場合には、業務アプリケーションの機能が正しく実装されている、ということを保証できなくなってしまいます。

プログラム開発の監査では遠い過去を検証するわけではない

　IT全般統制におけるプログラム開発の監査の対象となるプログラムは、あくまで現在利用されている業務システムであると述べました。

　しかし、対象となるプログラムは、場合によっては何年も前に開発されたものかもしれません。その場合、監査では「遠い過去の開発時点におけるプロセス」を検証するのでしょうか。答えは「ノー」です。

　日本版SOX法の内部統制においては、運用状況の評価の対象となる期間は財務報告の対象期間と同じであるため、当該会計年度に発生したプログラム開発のプロセスについて評価・監査を行います。つまり、「プログラム開発」は新規のシステム開発のみではなく、保守や機能追加を含めた開発プロセスを指すのです。

　ただし、プログラム開発を監査する際には開発対象となるシステムの仕様書・設計書をきちんと整備しておく必要があります。米国SOX法対応におけるIT内部統制の監査においてよく起きた問題点として、「設計書と実際のシステムが食い違っている」というものがありました。また、筆者のこれまでの経験上でも、設計書と実際のシステムが食い違っていたケースは多く、仕様書・設計書がない場合もありました。

　そのような場合、やはりあらためて仕様書・設計書を作り直す必要があると思いますが、開発された当時の資料や過去のすべての仕様変更を洗い出すのは、非常に工数が掛かります。また、内部統制においては過去にさかのぼって資料を整理したり、再作成したりすることが求められているわけでありません。

　従って、現状（最新）の仕様書・設計書が必要になるのですが、最新の仕様書・設計書を大ざっぱに表現すると、

最新の仕様書・設計書＝変更前の仕様書・設計書＋変更部分

　となります。「プログラム開発」や「プログラム変更」において必要なのは、変更部分を明記し、その仕様書・設計書が最新のものであるということを明確にしておくことです。変更前の仕様書・設計書（開発初期のものでなくてもよい）をそろえ、その時点から記録管理を行っていけばよいのです。