----------------------------------------------------------------------

　リスク重視のシステム監査

----------------------------------------------------------------------
（設問ア）
----------------------------------------------------------------------
ア−１．監査対象の情報システム
----
　Ｓ社は、建設業と人材派遣業を中心事業とする従業員
５００名の中堅企業である。全国に２０の支店・営業所
をもつ。Ｓ社の情報システムは、20年前に自社開発した
勘定系システムが中心であった。昨年、人材派遣事業部
門のニーズに対処する為に、イントラネット系のミドル
ウェアを導入し、人事給与系と情報系をこれに移管した。
このミドルウェアは会計・勘定系のモジュールも提供し
ており、これを機に、勘定系も移管する事になり、現在
設計中である。
　従来の勘定系は月末バッチ処理で決算書類を出力する
もので、決算書類が経営トップに届くのは、毎月５日〜
７日ぐらいであった。ミドルウェア上で稼動する新勘定
系導入により、
　・会計・経理データがリアルタイムで把握できる
　・情報系、人事系と連携し、データを有効活用できる
などのメリットと共に、オープン系であることから、ハ
ード調達や運用・管理上のメリットも期待された。さら
に、費用対効果を上げるために、会計帳簿の電子帳簿化
も同時に盛りこまれた。

----
ア−２．リスクとリスクコントロール
----
　Ｓ社の新システムは、勘定系の全面移行と共に、電子
帳簿化による業務改革も含むものである。経営層は、成
果を期待すると共に、全面一括改革による危惧も感じて
いる。
　・新システムが期待通りの効果を発揮するのか？
　・全面的な業務改革は早急ではないか？
　・電子帳簿が失われた時、代替措置は機能するのか？
　経理業務という企業の基幹業務の重要性から、システ
ム監査を行なう必要があると、経営企画室長のわたしは
提言した。

----------------------------------------------------------------------
（設問イ）
----------------------------------------------------------------------
イ−１．監査計画の策定
----
　正式なシステム監査としては、今回がＳ社では初めて
である。それまでは、システム企画時に費用対効果の検
討会が行なわれていたに過ぎない。基幹業務に関わる案
件は、それが必要・必須であることは明らかであるから、
管理部による内部監査も形式的であった。
　監査計画は、もちろん監査基準に基づいて策定されね
ばならない。それと共に、監査の目的を明確にすること
が、わたしは不可欠であると考えた。
　わたしは、経営層のねらいと期待を確実に理解するこ
とが、まず第１であると考えた。具体的な、達成度の基
準や指標も聞き出す事が必要である。そうして、経営層
の描く情報システムによる業務の理想像を共有すること
ができれば、監査の目的と計画はおのずから集約できる。

----
イ−２．監査対象のリスク
----
　経営層の目からみると、新システムは単に経理システ
ムの更新や、伝票・帳票の業務改善だけではない。
　例えば、人事系・情報系とのデータ交換、連携は、職
能・機能別の部門体制を超えた情報交換を意図している
し、基幹業務における電子帳簿化の採用は業務革新に聖
域がないことを宣言したいものとも思えた。
　さらに、基幹系・情報系のプラットフォームを１つの
ミドルウェアに統合することは、ＥＵＣも含めて、全社
の情報資源を一元管理し、資源配分の効率を向上すると
ころまでねらったものといえる。
　すると、新システムのリスクは構造的に次のように識
別される。それぞれ、監査手続きの重心も変えるべきで
あろう。
　１）経営戦略、情報戦略との整合性に関わるリスク
　２）他の情報系・人事系との連結性に関わるリスク
　３）勘定系システムとしての効果に関するリスク
　４）新旧業務体制との連携性に関わるリスク
一般の監査基準、すなわち信頼性、安全性、効率性など
に関わるリスクの検証と共に、具体的には、次のような
項目も監査の重点とする。
　・ＳＡと経営層との意志疎通は充分か？
　・経営層との確認事項は文書化されているか？
　・データの受け側、供与側は明確になっているか？
　・バックアップ、リストアの多重性と運用体制は？
　・業務モデル、マニュアルは経理部だけでなく、支店
　　や営業所まで配布・レビューされているか？
これらにより、経営層のねらいが反映・徹底されている
かどうかのリスクコントロールとすることができる。

----
イ−３．監査実施上のリスク
----
　監査実施上のリスクとしては、監査手法上のリスクや
情報技術上のリスクなど、主にシステム監査人の側に帰
するリスクがある。これらは、監査室や外部の専門家に
よる支援を受ける事によって解決できる。
　その他に、対象部門の協力を得られない事によるリス
クが考えられる。

----------------------------------------------------------------------
（設問ウ）
----------------------------------------------------------------------
ウ−１．監査実施上のリスクを低減する方法
----
　システム監査の関係者には、経営者、システム部門、
利用部門とシステム監査人がある。
　システム部門にとっては、システム監査は意図的な粗
探しと受けとめられる怖れが多分にある。実際には、シ
ステム監査は構築される情報システムの品質を向上させ
る効果もあるのだが、限られた期間・要員によって一定
の成果を挙げなければならないという、一種の強迫概念
が常に彼らの念頭にある。したがって、システム部門の
協力を得るためには、構築される情報システムの目的と
システム監査の目的とが相反するものではないことを説
明し理解をえることが必要である。
　利用部門にとって、システム監査はシステム及びシス
テム部門に対する欲求不満の捌け口とされる怖れがある。
一般に、要件定義において、利用部門のすべての要求が
採用されることは稀であり、システム監査は、そのよう
な利用部門にとって救済措置の１つとして映るかもしれ
ない。利用部門もシステム構築の当事者であることの自
覚を求めて、皮相的でない真の協力を得ることが必要で
ある。
　システム監査は情報システム構築の重要な一部である
が、それゆえに構築作業に取り込まれる怖れがある。例
えば、開発工程の区切りで行なわれるレビューが、シス
テム監査が行なわれるのを前提として、簡略化されるこ
とがある。
　以上のように、システム監査は、関係者から誤解を受
け易い作業であり、それが要因となってシステム監査の
実施上のリスクとなる。これを回避するには、システム
監査の意義と目的を関係者全員に熟知させねばならない。
そのような誤解を生むもとは、おおむね監査計画、手続
きなどが関係者にゆきわたっていない点にあることが多
い。
　システム監査のすべて、目的・手続きや計画・日程な
どを公開することは必要である。情報システム開発の最
初の会合、キックオフミーティング時に、全関係者の前
でシステム監査について説明し、開発・構築・運用作業
の日程に組み込んでおくことが重要である。