PR

KPMGビジネスアシュアランスの橋本氏は,「記録を残さず,ユーザー部門からの電話1本でシステムを変更しているITエンジニアが少なくない」と指摘する。これは,日本版SOX法対応という観点では大きなリスクと見なされる。

 KPMGビジネスアシュアランスの橋本氏は,「記録を残さず,ユーザー部門からの電話1本でシステムを変更しているITエンジニアが少なくない」と指摘する。これは,日本版SOX法対応という観点では大きなリスクと見なされる(末尾の別掲記事参照)。

証拠書類は少ない枚数で

図5●変更管理で利用する申請書のフォーマット例
図5●変更管理で利用する申請書のフォーマット例
NECネクサソリューションズが顧客に提供している帳票。1枚の紙で変更管理の正しさを証明できる。自社の米SOX法対応で利用したものを汎用化して作成した
[画像のクリックで拡大表示]

 プログラムを修正するときは,システム検討依頼書,その承認記録,プログラム変更仕様書,テスト記録,本番登録申請書,完成・稼働報告,といった一連の書類を残すのが改善の一例になる。こうしたケースで有効なのはワークフロー・ソフトを導入することだろう。だが残された期間が短ければ,ワークフロー・ソフトの導入は時間的・コスト的に現実的ではない。

 短期間では紙を用いた方法になるだろうが,その場合,多種類の申請書をバラバラに管理したのでは手間がかかる。監査人に,「このシステム改修がきちんとした承認を得て行った証拠を出してください」と求められた際に証拠を探すのも大変だ。NECネクサソリューションズの持田敏之氏(コンサルティング部長)は,「変更申請にかかわる書類をできる限り少ない枚数にまとめるのが有効だ」と説明する。

 図5は,NECネクサソリューションズが顧客に提供している変更管理の申請書。米SOX法に対応している同社で利用している帳票を,どの企業でも使えるように修正を加えたものだ。1枚の紙に,変更申請から作業実行,作業内容の承認といった記録を取り,変更管理が正しく行われたことを証明できるようになっている。変更管理の申請書がない,または必要な書類が多種類に分かれている場合,参考にしてはどうだろうか。


緊急時は例外的に処理

 システム障害など緊急時であってもユーザー部門に申請書を記入してもらい,作業内容の承認を上司からもらって作業する必要があるのだろうか。その答えは「NO」である。ファイザーでは,「申請書を記入するどころか,緊急時には最優先で障害復旧に当たることを明確にルール化している」(CIT インフォメーション マネージメント部 情報品質管理課 課長 徳留忍氏)。

 東京ガスの外崎寿昌氏(IT本部 IT活用推進部 IT品質マネジメントグループマネージャー)も,「緊急かつ夜中など承認をもらえない場合は,事後承認を認めている」と語る。ただしファイザーと東京ガスのいずれも,作業終了後は速やかに申請書をユーザーに記入してもらい,ITエンジニアの作業内容を上司に承認してもらうという通常通りの証跡を残すように,こちらもルール化している。

プログラムの差分を自動チェック

 プログラムの修正が正しく行われていることを証明するには,別のアプローチも必要だ。それは,「本番プログラムが変更されたという事実を基に,個々の変更が適切なものだと証明すること」(日立コンサルティング テクニカルディレクター 六角朗氏)。そのためには,本番プログラムの更新ログを取っておかなければならない。だがこの更新ログの取得は意外とやっかいである。Perlなどのプログラムではファイルを上書きするだけで本番プログラムが更新されるからだ。こうした環境でログを取るには,本番プログラムを更新するシェル・スクリプトを用意し,そのスクリプトのなかでログを取るようにするのも一つの方法である。

 米SOX法対応を行った金融業のNISグループは,プログラムの差分チェック用ツールを5カ月で自社開発した(図6)。このツールはプログラムの変更日付とサイズの違いを調べ,変更のあったプログラムのレポートを日次バッチで出力する。修正担当者の上長が変更の申請書と突き合わせてチェックするという流れになる。

図6●変更管理の内容をチェックする対処例
図6●変更管理の内容をチェックする対処例
NISグループは,プログラムの差分チェック用ツールを開発し,不正な修正に気づけるようにしている
[画像のクリックで拡大表示]

 NISグループの高瀬尚彦氏(内部統制部長)は,「プログラム修正があったとしても,人間の目でチェックすると漏れてしまう可能性がある」とツール導入の理由を語る。また,この差分チェック用ツールを導入するに当たり,以前は不定期だったプログラム修正や新機能追加の時期を,週1回の同じ曜日に変更した。これは,「修正されるはずのない曜日に変更があるので,怪しい」といった考えを持てるようにするためだ。

開発や運用を請け負うITベンダーも対策を

 ユーザー企業によっては,システム開発やサーバーの運用をITベンダーに委託している場合があるだろう。このような場合,本文中の(3)(4)のリスク(開発と運用が分離できていない,変更管理ができていない)にどのように対処すればいいのだろうか。KPMGビジネスアシュアランスの橋本氏は,「自社でシステム開発や運用している場合と,基本は変わらない。そのため,開発と運用の分離や,システム改修の作業内容を承認した証跡を残してもらうなど,ユーザー企業の担当者からITベンダーへ要求する必要がある」と語る。

 実際,開発と運用をアウトソーシングしているNISグループは「委託先のNECに作業チェックシートを作成してもらい,それを提出してもらっている。また,作業担当者以外のITエンジニアがマシンルームへ出入りしていないかをチェックするため,ICカード認証による入退室のログを取り,そのログをもらっている」(NISグループ システム企画部長 平哲博氏)という。 上場していないITベンダーも,顧客が上場企業の場合は,同様の法対応を迫られる可能性がある。