「18年前から運用している販売システムのテストを、すべてやり直した」。リコーは、システムのロジックや変更管理の実施状況を証明するためにこれだけの手間をかけざるを得なかった。
同社は予備監査で、変更管理が正しく行われ、システムのロジックに間違いがないことの証明を求められた。テスト仕様書とテスト結果、そして結果に基づいてどのような判断をしたか、といった文書などだ。だが、18年間のすべての変更履歴など残っていない。そこで、現行のシステムが正しいことをテストすることで、代替としたのだ。
具体的にはトランザクション・データを作成し、ロジックが正しいかをチェック。バッチ処理についてはエラー・データを用意し、バッチ1つひとつについてエラーを検出できるか、までをテストした。ただし、こうした手間は初年度のみ。IT/S本部IT/S企画室の小島章IT/Sプロセス革新グループリーダーは、「今後は差分の証拠だけを用意すればいい」と胸をなでおろす。
「実際に正しく動作しているにもかかわらず、いざ評価・監査になると証明できない」という例はほかにもある。
NTTドコモ監査部の飛澤敏史グローバル監査担当課長（SOX法対応）は、「設計書には当たり前の仕様が記述していないことに困った」と振り返る。例えば「二重入力を防ぐための仕組みを入れる」こと。評価・監査において監査人は、設計書を見ながらシステムの仕様を確認する。設計書に記述がなければ「データの二重入力をチェックする機能がない」と判断しかねない。結局NTTドコモは、「システムの処理の流れを示したフロー図を提示することでカバーした」（飛澤担当課長）。
同社がもう1つ、内部統制の有効性の証明に困ったのが、システム間のインタフェースが正しく機能しているかの証明だった（図11）。基幹系システムはすべて、リアルタイムで連携している。そのため、バッチ処理のように「100件のデータを送り、100件のデータを受け取っている」といった明確な証明を見せることができない。
 |
| 図11●システム間のインタフェースが正確に動作していることの証明が必要になる 自社開発のシステムをリアルタイムで連携しているNTTドコモは証明に苦労した [画像のクリックで拡大表示] |
そこで、「送信側のシステムはすべてのデータを送信している。受信側はすべてのデータを受信している」ことを証明することで代替とした。ただし、リアルタイムでシステムが稼働しているため、テストは簡単ではなかった。「リリースとリリースの合間を見つけ、本番環境と同じテスト環境を用意してテストを実施した」（監査部の鈴木一寿システム監査担当部長）。
