日本版SOX法・徹底解析

アビームコンサルティング

フェロー

徳田 弘昭

http://itpro.nikkeibp.co.jp/article/COLUMN/20090507/329663/

　この文をお読みの皆さんは，「IT統制」あるいは「システム統制」という言葉に対して，どのような印象をお持ちでしょうか。いわゆるJ-SOX（日本版SOX法）をきっかけに内部統制の一環としてIT統制をとらえている方も多いでしょう。

　IT統制の目的は，J-SOXへの対応にとどまりません。もっと広く，情報システムにかかわるトラブルを防いだり，システムを真の意味でビジネスを支える道具として利用できるようにすることも大きな狙いです。

　ところが「IT統制とは何か」を解説した書籍や記事は数多く見かけますが，経済的で，かつ実務で使える形で，IT統制を整備・運用するための具体策を示したものは，筆者の知る限りほとんど存在しません。

既存の仕組みを使って「経済的」に進める

　特に重要なのは「経済的」という観点です。未曽有の不況が続くなか，多くの企業がIT投資を抑制しているのが現状でしょう。この経済状況がすぐに回復するとは思えません。いかにムダなく，余計なコストや手間をかけずにIT統制を実現するか。この点が非常に大きなポイントになります。

　内部統制についても同じことが言えます。J-SOXに対応する際に，「新たに内部統制の仕組みを導入する」という考え方で作業を進める企業が多いようです。しかし，内部統制は本来，明示されているかはともかく，企業や組織には例外なく導入されているものです。例えば，「小切手帳を所有しているのは社長だけ」「配達員には集金をさせない」といったことは，典型的な内部統制です。

　しかも，J-SOXが求めるような「勘定や拠点によって絞り込まれた財務報告の信頼性を高めるための統制」だけが内部統制ではないのは，皆さんもよくご存じでしょう。内部統制は本来，もっと多面的なものです。

　内部統制の事実上の国際標準であるCOSOフレームワークでは，内部統制の目的として「財務報告の信頼性」に加えて，「業務の有効性と効率性」と「コンプライアンス（法令順守）」を挙げています。J-SOXの「基準（正式名は「財務報告に係る内部統制の評価及び監査の基準」）」では，さらに「資産の保全」を挙げています。

　これらの目的にかなうように内部統制をゼロから整備しようとすると，膨大な手間とコストがかかってしまいます。これまでの内部統制の仕組みをできるだけ生かしつつ，見直しを図ることで，J-SOXへの対応といった特定の目的に対応できるようにする。このアプローチが現実的でしょう。

　筆者はこれまで約35年の間，IT戦略の設定からアプリケーションの開発，ソフトウエア管理用ツールの開発，システム監査まで，IT統制にかかわる様々な経験を積んできました。この連載では筆者の経験を基に，経済的で，かつ実務に使えるIT統制の進め方を解説していきたいと思います。

　今回と次回では，IT統制にかかわる現状や問題点を整理します。第3回から具体的なIT統制の整備方法を説明したいと思います。

システム・トラブルが減らない理由

　景気がどうであれ，情報システムにかかわるトラブルが後を絶たない状況は変わりません。最近では，社会保険庁が2009年4月3日に送付を始めた「ねんきん定期便」のうち，計3万1650人分に記載ミスが発覚しました。原因はプログラムの誤りだといいます（関連記事）。ほかにも，東京証券取引所やANA（全日本空輸）などの大規模なシステム障害も記憶に新しいでしょう。

　情報システムを実現するための技術が高度化しているにもかかわらず，なぜシステム・トラブルは減らないのでしょうか。いくつかの理由が挙げられます。

(1)機能が高度化・複雑化しており，全体像を把握しにくい

　情報システムの機能は高度化・複雑化しており，全体像が把握しにくくなっています。これがトラブルにつながる大きな要因となっています。

　機能が高度化・複雑化しているという傾向は情報システムに限りません。自動車からスペースシャトル，建築物まで，多くの製造物・制作物に当てはまります。昨今の世界不況につながったサブプライムや金融商品も，基となっている理論が複雑で全体像が見えにくい点は同じです。情報システムはこの傾向が特に顕著だと言えます。

(2)中身が見えない

　情報システムは機能が高度化・複雑化していることに加えて，「中身が見えない」という特徴があります。ソフトウエアの占める割合が圧倒的に大きいからです。ソースコードを見れば中身を確認できますが，多くの人が理解できるわけではありません。このため，品質の欠陥があっても，つい気付かずに放置してしまう可能性が生じてしまいます。

(3)標準が粗い

　情報システムの世界でも，もちろん標準が存在します。しかし，機械製品や建築物に関する標準に比較すると，標準化の水準は圧倒的に遅れています。特にソフトウエアの作成方法そのものが変化・進化しているので，標準の安定性を欠いたり，あいまいで抽象的な標準しか作成できないのです。

(4)エラーの発生を完全には回避できない

　情報システムでは，バグ（不具合）の発生を完全に回避することはできません。パッケージ・ソフトの購入契約書には，ほぼ例外なく「…の責任はソフトウエア制作者には一切無い」といった主旨の文言が含まれているのは，このためです。

　情報システムの規模が巨大化するにつれて，以上の4点はより顕著になります。そうなると，システムのトラブルを回避するのは一層困難になってしまいます。

　しかし，情報システムの重要性が高まっている現状では，システム・トラブルが社会全体に及ぼす影響の大きさは無視できません。先に挙げた情報システムの特徴を踏まえつつ，「システムを“見える化”して全体像を理解しやすくした上で，システムに発生し得るトラブルを予見し，事前に適切な対策を実施できるようにする」アプローチが必要になります。それが，この連載の主題であるIT統制の役割です。

統制サイクルの問題点

　IT統制に限らず，統制活動はいわゆるPDCA（Plan-Do-Check-Action）の繰り返しで進めます。この連載では統制サイクルと呼ぶことにします（図1）。

図1●統制サイクル

　太線矢印が統制サイクルを，破線矢印が情報の利用をそれぞれ表します。経営管理の場合には，経営計画や予算を立てる(P) --> それに従って企業活動を実施(D) --> 実績を把握して計画や予算との差異を分析(C) --> 翌期の改善に生かす(A)となります。IT統制の場合には，システムの計画策定・設計(P) --> システムを構築・運用(D) --> システムの処理が計画通りかを確認(C) --> システムを修整(A)などとなります。

　統制上の問題点は，この統制サイクルのいずれか，あるいはサイクル全体に原因があります。原因は一つでなく，複合された形で表れるのが普通です。先ほどの図1に問題点を重ね合わせたのが図2です。

図2●統制サイクルにおける問題点

　ここで挙げた問題点を簡単に説明しましょう。

(1)IT投資効果が把握できない

　システム導入後の実績に関する情報に問題があり，計画段階での導入効果予測と照らし合わせた評価ができない。

(2)仕様が正しく伝わらない

　設計者から開発担当者に対し，システムの仕様が正確に伝わらない。また、システムの運用担当者や利用者に，システムの仕様や操作の意味が正確に伝わっていない。このため，運用作業や利用の操作が，マニュアルの記述だけに頼ったものにとどまっている。

(3)退職でノウハウが欠落

　システムのノウハウを持つ保守担当者の退職あるいは異動により，システム変更に支障をきたしている。ノウハウをうまく引き継げなかったのが理由である。

(4)IT統制方針に確信が持てない

　経営層や実務担当者がビジネスにかかわる統制やIT統制サイクル全般を的確に理解できていない。このため，IT統制の方針に確信が持てずにいる。

(5)必要な情報を提供していない

　情報システムが経営層の意思決定に必要な情報を提供していない。経営層が具体的な管理モデル（どのような基準やルールに基づいて意思決定を下すか，そのためにどのような情報が必要か）を作り，システム担当者に伝えていないと，この問題が生じる。

(6)保守担当者の権限が限られている

　保守・運用担当者の作業を操作マニュアルの範囲内に強要し，総合的な判断業務を禁じるケースがある。特に「内部統制の強化」という名の下に，この傾向は強まりつつある。この場合，トラブル発生時に応用のきく対応策を採れない恐れがある。

(7)統制の品質維持・向上にコストがかかる

　ISOやCMMIといった国際標準に基づいて情報システムの品質を維持・向上させようとして，目標が高すぎてコストが膨大になってしまう。実現させるための環境と道具が整備されていない点も一因である。

(8)経営陣がITの進化に無理解

　次から次に出てくる新たなITの技術やキーワードに経営陣が付いていけない。あるいは，その重要性を理解しようとしない。

　こうした問題点は，統制サイクルに対する無理解から生じる場合もあるでしょう。あるいは，統制サイクルは理解していても，それを的確に維持・向上するための方策を知らないために放置されているケースもあります。

管理モデルを明確にし，実績を把握する仕組みを作る

　統制サイクルの問題点をどう解決していけばよいのでしょうか。具体策は次回以降の連載で説明することにして，ここでは解決のためのポイントを二つ挙げておきます。

　一つめは，管理モデルを確立することです。先ほども少し触れましたが　統制サイクルを実行するためには必ず，その規範となる基準やルールが存在します。その基準やルールに基づいて，意思決定を下していきます。これが管理モデルです。

　例えば，「来期の目標営業利益をxx億円」と設定する場合には，企業会計原則の損益計算という管理モデルにしたがって目標を算出し，それを統制の規範とします。この規範に対する実績を把握することで，統制活動を実施できることになります。

　二つめは，実績情報を的確に把握することです。管理モデルを確立したら，それぞれの規範の具体的な情報と，それに対する実績情報を的確に把握しなければなりません。加えて，そのためのコストが統制による効果に見合うことが大切です。実績を把握する仕組みは極力自動化すべきでしょう。

　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

　次回は，ビジネスシステムの階層から見た場合の統制の問題点を整理します。

徳田 弘昭（とくだ ひろあき）

アビームコンサルティング

フェロー

総合商社を経て大手監査法人に入所。コンサルティング部門立ち上げ，システム子会社立ち上げなどの後，グループの組織再編に伴い現アビームコンサルティングに異動。2008年からフェロー。経営管理，業務改革，連結会計，決算制度，情報システム戦略，情報システム構築，開発プロセス改善，システム能力評価，リスク管理などのコンサルティングを担当。

　[2009/05/12]