米国で上場する電子部品大手のTDKは、2002年から米国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）の例[画像のクリックで拡大表示] |
|
次に、約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法対応のため各種報告書を作成・保存[画像のクリックで拡大表示] |
|
二つ目がアクセス権限管理の徹底だ。商品マスターなど金銭にかかわるデータの変更については、ソフトウエアを修正し、「単価だけ」など最低限の変更しかできないようにした。さらに、現場側にアクセス権限についての意識を喚起して、担当替えなどをこまめに申請するよう促した。それでも徹底されない場合に備え、アクセス用ID（識別符号）の棚卸しを半年～1年に1度実施する。
三つ目はエビデンス（証拠）の保存。これについては、「本来の業務とは別に、監査対応のためにやらなければならない」（経営監査部の秋山薫担当部長）。
例えば、セキュリティ上のトラブルが発生した場合は、きちんと対応した証拠として「セキュリティ事件・事故報告書」を作る（図3）。パスワードを忘れて繰り返しログインに失敗したなど、問題の予兆にすぎない場合でも書類にする。こうした報告書類を新たに多数作った。「規則に関する教育研修などを行う場合も、理解度テストをして結果を残すことを徹底していった」（同）。
（次回へ）
