WEBマガジン
「これからの内部監査部門に期待される役割」～システム監査の有効性を高めていくために～（第3回）」
2013.12.17 さくら情報システム株式会社 河野 謙一郎
本稿では， システム監査の黎明期から現在までを振り返り， これからの内部監査部門に期待される役割について考察してみたいと思います。 ただし， 本稿は， 我が国の IT 化が進展してきた現場で経験し， 感じてきたことを実務者の視点で整理したものです。 信頼のおける資料や十分な量のデータに裏付けられた学術的な分析の結果ではないこと， また， 筆者の思い込みや記憶違いに由来する誤りが含まれている場合があることを， あらかじめお断りしておきます。
前回まで， 情報技術 （IT： Information Technology） の発展とシステム監査の変遷を振り返ってみてきました。 今回は， 現代のシステム監査について， その目的や形態の視点から整理し， 今後， 内部監査としてのシステム監査の位置付けと期待される役割を探っていきます。
2. 保証監査と助言監査
最初は， システム監査の目的という点から見ていきましょう。
当初， 会計監査の一部であったシステム監査には， IT 化によってブラックボックスと化した経理・会計の処理について点検し， 企業から開示される財務諸表の内容が適正であること， すなわち， 投資家に対して， 処理結果の信頼性を保証することが求められました。 その後， IT が会計業務だけでなく， 多様な業務に活用されるようになると， システムを開発した供給者や業務で活用する利用者からは独立した第三者であるシステム監査人が， 独自のテストを実施し， システム内で実行される処理の妥当性を確認するようになりました。 ここでは， 利用者に対して， システムが安心して利用できることを保証したり， 是正すべき不具合の存在を指摘したりすることが， システム監査の役割だと考えられました。
システムの大規模化・複雑化， IT 活用の高度化が急速に進展する中で， “情報化社会の健全化に資する” ことをうたって昭和 60 年（1985 年）に公表された （旧）システム監査基準では， 安全性・信頼性・効率性の向上を図るために， システム監査人が， 組織体の長に助言及び勧告を行うと記されています。 改善を目指している情報システムの運営組織からの要請に基づく助言監査が， システム監査の本質であると明示されたといえるでしょう。 IT 化の対象範囲が拡大し， 対象業務が多岐にわたるようになると， 全ての業務に関して， システム監査人が， 直接， システム内での処理の妥当性を確認することは困難になり， システムそのものではなく， IT 化の企画 ・ 開発 ・ 運用 ･ 保守のプロセスがシステム監査の対象になりました。 検出されたシステムの不具合よりも， 不具合を生じさせた， 又は， 生じさせるおそれがある IT 化プロセスの欠陥が， 重要な指摘事項となり， 改善勧告の対象になってきました。
今世紀に入ると， 技術の発展に伴って， 機器の高性能化・低価格化の進展， インターネットの普及によって， 多くの人々がネットワークでつながっているようになります。 基幹業務のオンラインシステムから， PC， スマートフォンを含むモバイル端末まで， 様々なレベルのシステムが混在し， 個々のシステムで重要視される特性も多岐にわたります。 それまでは， 特定の企業内や関連企業群に限られていたシステムの不具合や障害発生の影響が， ネットワークでつながれた一般消費者や直接の取引のない企業・組織にまで波及します。 システム障害や不適切な運営の状況によっては， 企業そのものの存続を危うくします。 IT 化の主ライフサイクルプロセスを対象に， 限られた特性だけに着目していたシステム監査も， 補助プロセス， 管理プロセスを含めた全ライフサイクルプロセスを対象として， 適切なシステムを構築し， 運用できる能力を有していること， すなわち， IT ガバナンスの状況を評価し， その向上に資することが求められています。
IT とネットワークが重要な経営基盤へと変化してきた中で， 平成 15 年（2003 年）に制定された “情報セキュリティ管理基準 ・ 情報セキュリティ監査基準”， 平成 16 年（2004 年）に改訂された “システム監査基準 ・ システム管理基準” では， Web サイトの利用者やシステムの開発や運用の業務委託者などの利害関係者に対して， 信頼性や安全性などを保証する保証監査と， 運営組織が自ら実施する， 業務プロセスや管理水準の改善を支援することを目的とする助言監査とが区別され， そのどちらにも適用できることが示されています。
システムのトラブルは， 偶発的な障害の発生や運営上のミスだけではありません。 インターネット上には， 悪意をもってウイルスに感染させたり， クレジットカードなどの情報を盗み出して金銭を窃取したり， 不正なプログラムをダウンロードさせて PC を遠隔操作することで犯罪に加担させたりする Web サイトやホームページなども出現しています。 利用者がインターネット上の情報を閲覧したり， 電子商取引（以下， EC という）で個人情報を開示したりする際の不安を払拭し， 安心を保証するために， 現在， 様々な認証サービスが提供されています。 保証の内容やレベルは個々のサービスによって異なりますが， ISMS など， その枠組みの中にシステム監査が組み込まれていて， 定期的にシステム監査を実施していることが， 認証の取得や更新の前提条件になっているものもあります。
IT 化の進展， 活用範囲の拡大に伴って拡大してきたシステム監査の目的と対象などについては， 表 1 のように整理することができます。
| No. | 保証・助言の別 | 監査の対象 | 監査の視点 | 報告の宛先 |
|---|---|---|---|---|
| 1 | 保証 | 会計システムでの処理 | 処理結果の信頼性 | 直接： 監査法人・公認会計士 最終： 投資家 |
| 2 | 保証・助言 | 特定の業務システム （要求仕様が第三者にも明らかなもの） | 処理内容の妥当性 | システムの管理者・利用者 （組織内） |
| 3 | 助言 | IT 化の主ライフサイクルプロセス （企画・開発・運用・保守） | システムの安全性・信頼性・効率性 | （情報システムを活用する） 組織体の長 |
| 4 | 助言 | IT 化の全ライフサイクルプロセス | IT ガバナンスの向上 | （情報システムを活用する） 企業などの経営者 |
| 5 | 保証 | 重要な情報の取扱 （システムでの処理を含む業務プロセス） | 情報の安全性， 完全性など | 直接： システムの運営者 最終： Web サイトや EC の利用者 |
ここで， 一つ注意しなければいけないことは， 時代とともにシステム監査のあり方が変わってきたのではなく， システム監査の対象や視点が拡張されてきたのだということです。 歴史的な役割が， その幕を閉じてしまったのではなく， 会計システムの処理結果の信頼性についての保証から， インターネット上での安心の保証まで， 全ての役割が現役であり続けていて， 現代のシステム監査に期待される役割は， 幅広いものになってきているのです。 次に， 期待される幅広い役割を果たすために， システム監査を実施する主体について見ていくことにしましょう。 外部監査と対比することで， 本稿のテーマである “内部監査部門の役割” を浮かび上がらせていきます。 現代の， そしてこれからの内部監査部門に期待される役割が見えてきました。 しかしながら， 内部監査部門単独では， その役割を果たすことはできないのです。 内部監査部門が実施するシステム監査における重要なステークホルダである， 被監査部署との関係について見ていくことにしましょう。 筆者が現場で経験し， 感じたことを実務者の視点で整理してきた本稿も， この辺で筆をおくことにしたいと思います。
なお， 情報システムは， 企業組織の業務を処理するものだけではありません。 現代の便利な生活は， 情報システムに支えられているといっても過言ではなく， 私たちの身の回りには， PC やモバイル端末だけでなく， 多くの機器に組み込まれた情報システム（以下， 組込みシステムという）が存在し， 私たちは， それとは気付かずに， 組込みシステムを利用しています。 テレビ， エアコン， 冷蔵庫， 全自動洗濯機などの家電製品の制御には， 組込みシステムが使われています。 自動車や航空機などは， 組込みシステムの塊となっていて， 昔ながらのリンクを介した機械的な制御に代わって， ほとんど全ての部分が電子的に制御されています。 これらの組込みシステムの信頼性が低く， 突然， 何の前触れもなく暴走したり， 異常停止したりすると， 人命に関わる重大な事故につながるおそれがあります。 しかしながら， 一部の組込みシステムにおいては， 標準となる開発工程が確立されておらず， 限られた記憶容量とプロセッサ性能の制約の中で， 業務処理系のシステムの黎明期に見られたような， 職人技に頼った開発が行われているという指摘もあります。 私たちの便利な生活の安全・安心を保証していくために， システム監査には， 業務処理系だけでなく， 組込みシステムの品質向上を支えていくことも期待されるようになってきています7)。3. 外部監査と内部監査
なお， 内部監査部門の代わりに， 外部の専門家に委託して， 本来， 内部監査部門が担当する業務を遂行してもらう， 内部監査業務の単なるアウトソーシングは， ここでは， 外部監査としてではなく， 内部監査として取り扱います。
会計システムの処理結果の信頼性やインターネット上での安心などについて， 投資家や顧客など社外の利害関係者に対して保証することができるのは， 会計監査や特定の認証に業として携わっている， 外部の専門機関だけです。 一般の工業製品についても， いろいろな認証があります。 それらの中で， 子供用の玩具として安全であることを示す ST (Safety Toy) マークを例にとってみると， 製品に ST マークが付いていれば， 安全に関する一定の基準を満たしているということが確認でき， 消費者は安心して， その製品を子供に買い与えることができます。 ST マークは， 個々の製品を検査して安全を確認したという保証ではなく， 製造工程と製品の品質が適切に管理されていることに対する認証であって， 実際に製品の安全性を維持しているのは， メーカ自身の製造プロセスと品質管理プロセスなのです。 しかしながら， 同等の水準の管理をしているからといって， ST マークではなく， 社内の品質管理部門による品質保証宣言を付けたとしたら， 消費者は信用してくれるでしょうか。 ちなみに， 工業製品に付いている保証書は， 一般に， 保証期間内に起きた故障のうち， 利用者の責に帰さないものについて， 無償での修理又は交換をすることの証であって， ここで考えているような， 製品の安全性などの品質自体を保証するものではありません。 もし， ST マークではなく品質保証宣言が付けられた製品を安心して購入する消費者がいたとしたら， それは， 社内の品質管理部門による品質保証宣言を信用したというより， メーカやブランドに対する信頼度が高かったからだと考えられます。 システム監査においては， 社外から見れば， 監査対象から独立した第三者とは見なせない内部監査部門が， いくら声を大にして保証を叫んだとしても， 社外の利害関係者の多くは， その保証を信用しはてくれないでしょう。 このような場面においては， 外部の専門機関による認証の前提として， 社内での IT 化された業務処理や IT サービス提供の品質が維持されていることを確認するのが， 内部監査部門に期待される役割ということになります。
一方， 社内の部門間というケースでは， 内部監査部門は， 監査対象から独立した第三者として機能します。 内部監査部門は， 利用部門が示した要件を満たすよう新システムの構築が進められてきたこと， IT サービス提供部門と利用部門との間であらかじめ合意したサービス水準を達成するように， 既存システムが運用されていることなどを保証することになります。 ここでは， 通常， 内部監査部門は， 利用部門に対して， 直接， “○○を保証する。” と記された監査報告書を提出するのではありません。 企業が， 監査法人から受け取った， 無限定適正意見が付された会計監査の結果を開示することで， 投資家に対して， 安心して投資できる対象であることを保証するのと同様に， 内部監査部門からの監査報告書を受け取った経営者やシステム部門の長から， 報告書には重大な指摘事項の記載が含まれていないことが利用部門に伝えられ， 利用部門は， 安心して利用できるシステムであることの保証が得られることになります。4. 被監査部署との関係
40 年ほど前になりますが， ある銀行の第 2 次オンラインシステムの開発プロジェクトで， プロジェクトマネージャがチームリーダたちを集めて， 近々， 内部検査がある見込みなので， 印章を預けておくから， 設計書類への押捺もれをなくしておくようにと指示していました。 当時， その銀行の開発標準では， “責任者（プロジェクトマネージャ）が， 設計書類の全てのページを確認して証印する” と規定されていました。 この規定は， 小規模なプロジェクトにおいては， 成果物の品質確保に有効なものでしたが， 百名を大きく超える規模のプロジェクトで， この規定どおりに業務を遂行することは， 現実的なものとは考えられません。 しかし， 当時の内部検査では， 規定自体が破綻していることには触れずに， 責任者の証印の有無だけを点検していました。 また， 銀行という減点法による評価に支配される企業文化の中では， 内部検査において何らかの指摘をされることは回避すべきことであり， 前述したような， 実行不可能な規定どおりに運用したように偽装することが是とされてきました。 このようなスタンスで内部監査を行ったのでは， 成果物の品質確保に寄与することもなく， 無駄な作業を強いることでシステム開発業務の効率を損なわせてしまうことになります。 また， 現実を的確に把握することができず， IT ガバナンスを崩壊させてしまったり， リスクの存在が隠蔽されてしまうことで， 企業の存続を危うくするようなリスクの存在を指摘することができず， リスクの現実化の抑止やリスクが現実化した際の影響の軽減について， 対応の必要性や達成すべき水準などを提言できなかったりしてしまいます。
本来， 監査では， この規定がプロジェクトの規模に適合していないことを指摘し， 成果物の品質確保に有効で， 効率よく実行可能な規定に変更することを提言すべきです。 内部監査では， 業務プロセスの改善について助言することで， 成果物の品質確保にも寄与し， マネジメントサイクルの洗練， IT ガバナンスの向上を支援していくことができます。 そのためには， 被監査部署は， 偽装したり隠蔽したりすることなく， 現実を白日の下にさらすことが重要です。 また， 日頃から感じている問題点などを提示し， 担当の監査人と改善について協議していくことも重要です。
内部監査部門に求められているのは， 被監査部署と敵対し， 多くの問題点を指摘事項として報告することではありません。 被監査部署のよきアドバイザとして信頼を得ることが重要で， 構築された相互の信頼関係の下で協調することによって， 初めて， 内部監査部門は， IT ガバナンスの向上に資する内部監査を行い， IT 経営の推進を支援していくという役割を果たすことができるのだと考えます。
|
- 7) 2010 年 3 月に，産業構造審議会 情報経済分科会情報サービス・ソフトウェア小委員会 （第 13 回） において， 今後の施策として“第三者の検証による信頼性の見える化の推進” が示されたことを受け，独立行政法人 情報処理推進機構 （IPA） は， 具体的な検討を進めてきた。 高度 IT 社会における利用者の権利の保護に向けた環境整備の施策として，第三者が供給者の品質説明を確認し， 製品・システムの利用者に提供する制度について検討した結果をまとめ， 2013 年 6 月，“製品・システムにおけるソフトウェアの信頼性・安全性等に関する品質説明力強化のための制度構築ガイドライン （通称： ソフトウェア品質説明のための制度ガイドライン） 第 1 版”を公表した。
| 【参考文献】 | |
| [1] | Dijkstra，Edsger W.， “Letters to the editor: go to statement considered harmful”， Communacationms of the ACM， Vol. 11， No. 3， pp. 147-148， 1968.03 |
| http://cacm.acm.org/magazines/1968/3/12783-letters-to-the-editor-go-to-statement-considered-harmful | |
| [2] | 堀江 正之 （Horie，M.）， “IT保証の概念フレームワーク”， 森山書店， 2006.03 |
| [3] | IBM ビジネスコンサルティング サービス， “エンタープライズ・アーキテクチャ”， 日経BP社， 2003.12 |
| [4] | 独立行政法人 情報処理推進機構 （IPA）， “製品・システムにおけるソフトウェアの信頼性・安全性等に関する品質説明力強化のための制度構築ガイドライン 第 1 版”， 2013.06 |
| http://www.meti.go.jp/committee/kenkyukai/shoujo/iryou_software/pdf/h25_01_s02_00.pdf | |
| [5] | 独立行政法人 情報処理推進機構 （IPA）， “ソフトウェアの品質説明力強化のための制度フレームワークに関する提案（中間報告）”， 2011.09 |
| http://www.ipa.go.jp/files/000004583.pdf | |
| [6] | 独立行政法人 情報処理推進機構 （IPA） 情報処理技術者試験センター （JITEC）， “情報処理技術者試験” |
| http://www.jitec.jp/ | |
| [7] | ISACA， “COBITR(R)5”， 2012.04 |
| http://www.isaca.org/COBIT/Pages/COBIT-5-japanese.aspx | |
| [8] | 一般財団法人 日本情報経済社会推進協会 （JIPDEC）， “情報セキュリティマネジメントシステム（ISMS）適合性評価制度” |
| http://www.isms.jipdec.or.jp/isms.html | |
| [9] | 一般財団法人 日本情報経済社会推進協会 （JIPDEC）， “プライバシーマーク制度” |
| http://privacymark.jp/ | |
| [10] | 経済産業省 （METI）， “コンピュータウイルス対策基準”， 平成 7 年（1995） 通商産業省告示 第 429 号 |
| http://www.meti.go.jp/policy/netsecurity/downloadfiles/esecu07j.pdf | |
| [11] | 経済産業省 （METI）， “コンピュータ不正アクセス対策基準”， 平成 8 年（1996） 通商産業省告示 第 362 号 |
| http://www.meti.go.jp/policy/netsecurity/downloadfiles/esecu06j.pdff | |
| [12] | 経済産業省 （METI）， （旧）“システム監査基準”， 昭和 60 年（1985）公表， 平成 8 年（1996.01）改訂 |
| http://www.meti.go.jp/policy/netsecurity/downloadfiles/systemaudit.pdf | |
| [13] | 経済産業省 （METI）， “システム監査基準”， 平成 16 年 10 月（2004.10）公表 |
| http://www.meti.go.jp/policy/netsecurity/downloadfiles/system_kansa.pdf | |
| [14] | 経済産業省 （METI）， “システム管理基準”， 平成 16 年 10 月（2004.10）公表 |
| http://www.meti.go.jp/policy/netsecurity/downloadfiles/system_kanri.pdf> | |
| [15] | 経済産業省 （METI）， “情報システム安全対策基準”， 平成 7 年（1995） 通商産業省告示 第 518 号 |
| http://www.meti.go.jp/policy/netsecurity/downloadfiles/esecu03j.pdf | |
| [16] | 経済産業省 （METI）， “情報セキュリティ監査基準”， 平成 15 年（2003） 経済産業省告示 第 114 号 |
| http://www.meti.go.jp/policy/netsecurity/docs/isaudit/IS_Audit_Annex04.pdf | |
| [17] | 経済産業省 （METI）， “情報セキュリティ管理基準”， 平成 20 年（2008） 経済産業省告示 第 246 号， 平成 21 年 2 月 1 日適用（2009.2） |
| http://www.meti.go.jp/policy/netsecurity/downloadfiles/IS_Management_Standard.pdf |
*本Webマガジンの内容は執筆者個人の見解に基づいており、株式会社オージス総研およびさくら情報システム株式会社、株式会社宇部情報システムのいずれの見解を示すものでもありません。
『WEBマガジン』に関しては下記よりお気軽にお問い合わせください。
