PCネットワークの管理活用を考える会／クライアント管理分科会、大阪座長の柳原です。
筆者がこのコラム原稿を書いておりましたら、2月15日に金融庁が企業会計審議会において、上場企業に義務付ける「財務報告にかかる内部統制の評価および監査の基準ならびに財務報告にかかる内部統制の評価および監査に関する実施基準案の設定について（意見書）」を了承した、というニュースが流れました。その半月前、1月末において、公開草案は固まっていましたから、すでに目をとおされた方も多いことでしょう。
今回のコラムでは、情報システムの運用管理を担当している皆さんが、内部統制への対応という大きな仕事に、どのように取り組むべきかを、考えて行きたいと思います。
内部統制への対応問題を考える前に、まず、この10年ほどの間に起こった情報システムに関係する仕事の波を思い出していただきたいと思います。新しい問題に取り組むときは、まず最初に、過去に起こった事象を振り返るべきだからです。まったく同じ事象は存在しませんが、なんらかの教訓は得られるでしょう。
まず、1998年ごろ「西暦2000年問題」（以下Y2Kと呼ぶ）というものがありました。筆者も以前に勤めていた企業内で、この問題に対応した経験があります。企業内でのLANやWindowsなどのコンピュータが普及し始めた頃であり、経営におけるITの重みや、Y2Kへの対応の真剣度は、企業によって大きな差がありました。例えば、インフラ系（鉄道、航空、電力、ガス、電話など）は、Y2K問題を発生することによって、社会的混乱にまで発展しかねません。このため、例えばNTTでは1995年から、システムの改修に着手しています。
このように、早期に対応を始めた企業もあれば、1998年か1999年になって、やっと重い腰をあげるような企業もあります。しかも、そのきっかけとなっているのは、多くは、取引先からのY2K問題に関する問い合わせです。
つまり取引先としては、商品や原料の供給がY2K問題によって滞った場合に、自社の経営に影響が出ることを恐れたわけです。そのため各企業は、「貴社における西暦2000年問題への対応状況のお尋ね」といった内容のレターを、すべての取引先に対して送るようになりました。実際に、筆者の元にもそうしたレターやFAXが山のように届き、対応に手数をとられたことを思い出します。その中には、「供給が滞った場合、その損失を貴社に請求する」といった、脅迫めいたものもありました。同業他社でも、ほとんど同じ事態が起こっていたでしょう。
こうした状況を見ていると、多くの企業の体質が見えてきます。すなわち、Y2Kのように、全社的対応が求められ、かつ、その対応によって自社にとってどのような利益があるのかがよくわからない問題は、他者からの圧力や、同業他社との横並びでしか真剣に考えられない、ということです。
今回の内部統制への対応問題も、似たような様相を呈しています。模範的な企業は既に対応に着手し、2007年4月からの新年度に向けて、たった今、膨大な作業を続けておられるでしょう。しかし、その他の「模範的ではない」企業ではどうなのでしょうか。昨年末あたりから、やっと腰を上げた、というところも少なくないはずです。
そうした「模範的ではない」企業の場合、「世間から後ろ指を指されない必要最低限の対応」で済まそうとするでしょう。内部統制対応の場合は、監査人から見て、大きな指摘を受けないこと、が大前提になると思います。小さな問題を指摘されたとしても、おいおい是正していけばいいのですから。
さて、Y2K問題への対応作業についてお話ししていると、なんだか後ろ向きな気分になってしまいますので、ここからは「IT内部統制」に絞って、もう少し前向きなお話しをしましょう。
筆者は、Y2K問題への対応作業について、こう考えていました。
「Y2Kは企業全体どころか日本全体、世界全体の問題であり、何らかの対処は必ず実行しなければならない。そうならば、その副次効果が自分の担当業務にとって、ひいては自社にとって有利になるように実行しよう」
と。
今や、多くの企業にとって「内部統制への対応」は最優先のテーマの一つです。新・会社法や金融商品取引法などの法的な規制があるという理由だけではありません。業務プロセスや情報システムの構造を透明化することにつながり、結果として業務の効率化や不正の防止、あるいはリスクの見える化を実現できる可能性もあるからです。
たとえば、複数部署にまたがる業務フローを見直そうとしても、普段は関係者の意思統一を計るだけでも大変で、なかなか手をつけられないものです。しかし、今回は「内部統制への対応」という錦の御旗があるのです。見直すべき問題があるのなら、堂々と踏み込むことができるでしょう。
また、昨年までに満足な対策が打てなかった情報漏洩対策や、ID管理やアクセス権の適正化、情報資産管理の見直しなども、今年は実行のチャンスではないでしょうか。
このコラムをお読みになっている情報システムの運用・管理系の皆さんにとっては、上記の企業会計審議会からの実施基準案よりも、経済産業省が公表している「システム管理基準 追補版（財務報告に係るIT統制ガイダンス）（案）」の方がより具体性が高く、参考になるのではないでしょうか。まだお読みになっていない方はぜひ目を通していただきたいと思います。
ここに書かれている内容は、日ごろ、情報システムのあるべき姿を思い描いている方なら、ほとんどが「当たり前」の話なのです。ところが現実には、費用対効果や実行するための工数（人員）の問題から、なおざりになっているものばかりです。今年の内部統制への対応作業は、このような、今までに実行できなかった対応策を実行する場でもあるのです。
昨年から、IT系の展示会開催案内やセミナー案内を見ておりますと、見事に「内部統制への対応」というテーマで埋まっています。多くのSIベンダーやISVにとっては、一昨年まで続いた個人情報保護法対応に続く、大きな商機なのですから当然でしょう。しかし、読者の皆さんはこうした展示会やセミナーに振り回されるのではなく、あくまでも自分のおかれた現実を直視するところから、まず何を始めるべきかを考えてほしいのです。
この現実直視のために役立つ考え方が、「リスク管理」です。今回の内部統制対応は、あくまでも財務報告に直結する業務の統制が最優先ですが、そこに限定したとしても、全ての情報システムと、その入出力に関わる業務全体を一気に見直すことは難しいでしょう。ではどこから手をつければ良いのでしょうか。
この判断を行うには、財務報告の正当性を担保するという、内部統制の目的に対して、どのようなリスクが存在するのか？という観点を持つしかありません。リスクの大きなところから、地道に業務の見直しを進めるしかないのです。
リスク管理の基本は、「リスク分析」と「リスクアセスメント」です。リスク分析によって、リスク因子の存在を特定し、その発生確率と損失の大きさを予測（想定）します。この発生確率と損失の大きさを掛け合わせた値が、リスクの大きさです。この大きさと、そのリスクが企業の財務基盤に与える影響を考慮して、リスク因子への対応優先順位を決めていくことになります。
こうした分析を行っておかないと、対応優先順位を決めた根拠が曖昧になります。これが曖昧であったり恣意的に決めていると、社内への説得や、監査人への説明にも苦慮することになるでしょう。
パーソナルコンピュータとの付き合いは1979年のNEC社製PC-8001から始まっています。
1985年から当時はオフコンと呼ばれていたIBM社のシステム36を使って、機械製造メーカでの社内用生産管理システムの構築に関わりました。言語はRPGでした。
1990年ごろから社内にパソコン通信やLANを導入してきました。この頃からネットワーク上でのコミュニケーションに関わっており、1993年以降はインターネットとWindows NTによる社内業務システムの開発、運用を行ってきました。
1996年からはインターネット上でのコミュニティであるNT-Committee2に参加し、全国各地で勉強会を開催しています。
http://www.hidebohz.com/Meeting/
1997年からはIDGジャパンのWindows NT World誌に「システム管理者の眠れない夜」というコラムの連載を始めました。連載は既に7年目に突入し、誌名は「Windows Server World」に変わっていますが、読者の皆さんに支えられて今でも毎月、締め切りに追われる日々が続いています。
連載から生まれたメーリングリストもあります。ご参加はこちら。お気軽にどうぞ。
Copyright 2007 Hideki Yanagihara All Right Reserved
