PR

 米国で上場する電子部品大手のTDKは、2002年から米国SOX法に沿った内部統制の整備を始めた。社内の業務プロセスを分析。財務報告を狂わせたり、不正が行われたりするリスクを洗い出し、それに対する対応を文書化したり、実際に文書通りに業務が行われているかを確認した。

統制対象と統制のポイント[画像のクリックで拡大表示]
統制対象と統制のポイント
図1●TDKにおける内部統制強化のための「SOXプロジェクト」の概要[画像のクリックで拡大表示]
図1●TDKにおける内部統制強化のための「SOXプロジェクト」の概要

 3月期決算のTDKの場合、2006年4月から始まる2007年3月期からSOX法の本格適用を受ける。米当局は外国企業のSOX法適用を当初より1年延期したが、「今期が本番のつもりで取り組んでいた」(経営監査部の四居(よつい)治担当部長)と準備に自信を見せる。

 内部統制強化は、組織横断の「SOXプロジェクト」として推進した。経営監査部、経理部、法務部、情報システム部など13人が参加。加えて、内部統制分野が専門のプロティビティ ジャパンのコンサルタントが入った。

 「SOX法はできたばかりの法律。様々な基準が明文化されていないこともある。分からないことが多いので、最初からプロに入ってもらうことにした」(四居担当部長)。

 一般にSOX法対応は膨大な手間がかかるといわれる。「従来は、万が一財務諸表に間違いがあれば訂正すればよかったが、SOX法では間違わない業務プロセスが求められる。プロの会計士の監査手続きに近いことまで、会社側でやるよう求められるのが大変だ」(同)。

文書化で不正リスクを洗い出す

 TDKの場合、文書化の対象にした業務プロセス数は約250。1プロセス当たりの文書はA4判で10~20枚に及ぶ。

 まず、文書化を行う範囲を特定するための分析(スコーピング)に取り組んだ。「売上高」や「売掛金」など財務諸表の各科目の数字が、社内のどの業務プロセス(部署)から作られているかを表にまとめた。業務プロセスは「開発」や「販売」、「資金管理」など12の大分類に分け、「売上高なら販売業務から作られる」といった具合に分析作業を進めた。

 業務手順は拠点・グループ会社によって違うこともある。販売業務であれば売上高の一定割合以上を占める拠点を選ぶなど、財務諸表の数字に与える影響の大きさによって対象を絞り込んだ。

図2●情報システム部のリスク・コントロール・マトリクス(RCM)の例[画像のクリックで拡大表示]
図2●情報システム部のリスク・コントロール・マトリクス(RCM)の例

 次に、約250プロセスのそれぞれについて、業務手順を図式化した「フローチャート」と「業務手順書」、業務の中で財務諸表の誤りや不正を招く「リスク」とその対策である「コントロール(管理策)」を洗い出して書き込んだ「リスク・コントロール・マトリクス(RCM、図2)」という三つの文書を作成した。

 例えば、販売の業務プロセスなら、リスクとして「出荷が済んでいないのに売上高が計上されるかもしれない」、コントロールとして「製品を積んだトラックが出発した時点で出荷確認ボタンを押す」などが考えられる。

 ただし、チェックばかりが増えれば手間がかかる。「現場の個々の処理レベルでコントロールを設けると効率は下がる。いかに最小の労力でリスクを抑えるかが腕の見せ所だ」(四居担当部長)。現場が入力・記入した数字がそのまま会計に反映されるようなケースを除いて、個々の処理を直接チェックするのではなく、なるべく事後の監査などで誤りや不正を発見できるよう工夫した。

 情報システム部門でもSOX法対応が必要になる。財務報告に必要なデータの多くは情報システムに入っているため、その運用・管理体制が問われるからだ。

システム部門はCOBIT採用

 TDKは欧米で有名なシステム活用・管理の基準「COBIT」を採用した。「COBITの基準は厳しく、SOX法対象企業でも採用企業は多くない。TDKは高い目標を設定したといえる」(プロティビティ ジャパンの担当者)。

 COBITにおける管理プロセスのうち、「アプリケーション開発」「運用管理」「障害管理」「情報セキュリティ管理」「ネットワーク管理」の五つを文書化の対象とした。販売など他業務と同様に、RCMなどの文書を作成し、リスクとそれに対する管理策をまとめた。

 TDKは並行して国内基準であるISMS(情報セキュリティ・マネジメント・システム)の認証取得も目指し、2005年12月に取得している。「COBITとISMSでは要求事項が似ていることに気づいた。ISMSのほうが関連資料も多く基準が分かりやすいため、ISMSの管理策をSOX法対応にも多数取り入れた」(情報システム部の山口知昭部長)。

 RCM文書では、例えば、「情報セキュリティ管理」について、リスクとして「基本方針が徹底されず、具体的な対策が実行されないこと」、管理策として「基本方針を教育研修を通して周知徹底している」といったことが書かれている。規程を作って、それに従うように研修やチェック策を講じるという内容自体は、SOX法特有のものではなく、「ITガバナンス」を意識している企業では当たり前のものも多い。

開発・運用の分離にこだわらず

 TDKも従来からITガバナンス向上に取り組んでいたが、SOX法対応のために重視した点が三つある。

 一つ目は拠点への展開。もともと本社ではCOBIT準拠の規程類があったが、SOX法対応では、「世界中に約30ある拠点ごとに、事情に応じた規程類を整備する必要がある」(情報システム部システム開発部の横山欽也部長)。担当者は出張で国内外を飛び回ることになった。

 一般に、不正などの防止のため「情報システムの開発と運用は、別々の人が担当すべきだ」といわれるが、システム要員が数人の拠点もある。その場合は、兼務を認める代わりに、作業記録を厳密に残してもらい、事後的に不正がないかどうかを監査する「発見的コントロール」の考え方を採用。運用をデータセンターに集約するといった極端な施策は取らなかった。

図3●SOX法対応のため各種報告書を作成・保存[画像のクリックで拡大表示]
図3●SOX法対応のため各種報告書を作成・保存

 二つ目がアクセス権限管理の徹底だ。商品マスターなど金銭にかかわるデータの変更については、ソフトウエアを修正し、「単価だけ」など最低限の変更しかできないようにした。さらに、現場側にアクセス権限についての意識を喚起して、担当替えなどをこまめに申請するよう促した。それでも徹底されない場合に備え、アクセス用ID(識別符号)の棚卸しを半年~1年に1度実施する。

 三つ目はエビデンス(証拠)の保存。これについては、「本来の業務とは別に、監査対応のためにやらなければならない」(経営監査部の秋山薫担当部長)。

 例えば、セキュリティ上のトラブルが発生した場合は、きちんと対応した証拠として「セキュリティ事件・事故報告書」を作る(図3)。パスワードを忘れて繰り返しログインに失敗したなど、問題の予兆にすぎない場合でも書類にする。こうした報告書類を新たに多数作った。「規則に関する教育研修などを行う場合も、理解度テストをして結果を残すことを徹底していった」(同)。

次回へ