「長年の付き合いの中で培った信頼関係の下、明らかな問題があったアプリケーションの変更は必ずしも書面のやりとりはしていなかった」。NISグループの高瀬副本部長は、20年以上運用を委託しているNECとの関係を、こう打ち明ける。こうした“日本的な関係”は、SOX法対応としては「変更管理に対する統制の整備ができていない」とみなされる可能性が高い。

　特に社内では、使い勝手や性能を向上させるため、ユーザー部門から依頼がなくてもシステム部門の独自判断で改修に踏み切るケースがある。新日本監査法人の中山代表社員は、「システム部門からユーザー部門に変更を提案し、ユーザー部門から依頼を出してもらうべき」と強調する。

　システム変更はすべて紙ベースでやっているという企業も、それで終わりではない。キヤノンでは以前から紙の依頼書をベースにシステムを変更していたが、米SOX法対応のために新たにワークフロー・システムを構築した。ユーザー部門の上長の承認も必要で、それがなければ変更依頼を受け付けない。もちろん、紙ベースでも統制の整備上は問題ない。しかし紙は紛失の可能性があり、「網羅性が証明しづらかった」（金土課長）。ライブラリのログで変更履歴が100件あった場合、100件の依頼書があることを示す必要があるからだ。

　保守作業の一環で年末に実施するDBの圧縮について、ユーザーの承認を得ていなかったのがアドバンテストだ。監査人は、「責任があいまいになっている。ユーザー部門の承認は必要ではないか」と指摘。最終的には「保守の範囲内ということで、ユーザー部門の承認は得なくてよい」と決め、規定に書き加えた。「網羅性を高めるためには、詳細な規定を作る必要がある」（二井室長）。

委託先の監査が負担に

　前出したNISグループも、NECとの間で業務プロセスを明確化し、指示を書面で交わすだけでなく、「誰が承認したか」という責任の所在を明確にした（図9）。例えば、システム変更時は事前にテスト項目表を作成。項目表とテスト結果と照合した後に、今度は現行のプログラムとリリースの差分を確認する、といった手順を明らかにした。

図9●NISグループは変更管理のフローを明確化するため外部委託先（NEC）とのやりとりを見直した
図9●NISグループは変更管理のフローを明確化するため外部委託先（NEC）とのやりとりを見直した
[画像のクリックで拡大表示]

　NISグループ、NECともに文書作成と承認作業の負荷が増えたため、システム・リリースの仕組みも変えた。完成のたび随時リリースしていたのを、週に1度としたのだ。これらは、品質の向上につながったという。米SOX法対応前と比較して、NEC側の作業が原因で発生するバグが「3分の1程度に減った」（平哲博システム企画部長）のだ。リリースを週1回にしたことでテスト期間を確実に確保できるようになったためである。なお、作業量増に伴う委託料の変更については、「現在、交渉中だが、本来必要な業務ではないかと言っている」（高瀬副本部長）。

　プログラムの変更作業を外部へ委託している京セラは、「外部委託先における開発者担当者と本番移行への担当者を分けるように」と、監査人から指摘された。移行作業を自社で行えばいいが、それでは「外部委託のメリットがなくなる」（藤田部長）。そこで、本番環境へのアクセス・ログを取得し、外部委託先のアクセス状況を確認することで代替した。

　日米ともSOX法対応では、委託先の内部統制が有効かどうかの監査は、委託元が実施する。アドバンテストは米SOX法対応のため、ホスティングを依頼しているデータセンターへの監査を年1回から年2回に増やした。NISグループも、「通常の監査とは別の費用を支払い」（高瀬副本部長）、委託先に対する外部監査を実施している。

　こうした手間を省くため米SOX法では、「SAS70」を委託先から受け取ればよいとしている。SAS70は、委託業務において内部統制の整備・運用状況が有効であることを示す文書。J-SOXでは、「監査基準委員会報告書18号」がそれに該当する。NISグループもアドバンテストも、委託先にSAS70の取得を依頼したが、初年度は間に合わなかったという。