システム監査 重点教科書

会社の中では、日々「本当に正しく業務が行われているか」「不正やミスが起きていないか」を確かめる作業が行われています。これを監査と呼びます。監査というと堅苦しい響きがありますが、やっていることは「決められたルール通りに物事が進んでいるかを、当事者ではない第三者の目でチェックする」というシンプルな仕事です。学校でいえば、自分でテストの丸つけをするのではなく、先生が採点するからこそ結果が信頼される、というのと似た構造だとイメージするとわかりやすいでしょう。

監査にはいろいろな種類がある

企業などが行う監査は、何を対象にするかによっていくつかの種類に分かれます。会社のお金の流れや財務諸表が正しく作られているかを確認する会計監査、日々の業務の手順や仕事の進め方がルール通りかを確認する業務監査、情報セキュリティの対策がきちんと機能しているかを専門に確認する情報セキュリティ監査、そして情報システムそのものを対象にするシステム監査があります。この4つはいずれも「対象は違うが、第三者の目でチェックするという考え方は共通している」という点を押さえておきましょう。試験では「お金の話だから会計監査」「セキュリティ対策の話だから情報セキュリティ監査」というように、問題文に出てくるキーワードから対象を判断させる出題がよく見られます。ITパスポート試験では、この中でも情報システムそのものを対象とするシステム監査が特に重要なテーマになります。

システム監査とは何をすることか

システム監査とは、会社が使っている情報システムに関わるさまざまなリスク(情報システムリスク。たとえばシステムが止まってしまう、情報が漏れてしまう、処理された結果が間違っている、法令に違反した使い方をしてしまう、といった困りごとの総称です)に対して、会社がきちんと対応できているかどうかを確かめる仕事です。ここで大事なのは「誰が確認するか」です。担当部署の人が自分で自分の仕事を評価しても、甘い評価になりがちですし、周りからの信頼も得にくいですよね。そこで、監査を行う専門家であるシステム監査人には、高い倫理観を持ち、監査対象からは独立した、客観的な立場であることが強く求められます。「自分の仕事を自分で採点しない」というのが、システム監査の一番の土台となる考え方です。たとえば、あるシステムの開発を担当した本人が、そのシステムの監査まで担当してしまうと、自分の仕事のミスを見過ごしてしまうかもしれません。だからこそ、監査を行う立場と、監査される立場(監査対象部門)は、明確に切り離しておく必要があるのです。

システム監査の目的は、単に「粗探しをして怒ること」ではありません。リスクへの対応状況を検証・評価したうえで、経営者や関係者に対して「保証」(大丈夫だと太鼓判を押すこと)や「助言」(こうすればもっと良くなるという提案)を行い、それを通じて会社の事業活動がより効果的・効率的に進むように支援し、必要であれば業務の変革も後押しすることにあります。また、株主や取引先など会社に関わる人たち(利害関係者)に対して、会社がきちんと説明責任を果たすことも重要な目的の一つです。「監査人は敵ではなく、会社をより良くするための伴走者である」という視点を持っておくと、目的の理解が深まります。こうした監査を進めるうえでの拠り所となる公式なルールブックがシステム監査基準で、システム監査人が守るべき行動規範や監査の進め方の指針がまとめられています。試験では、この基準が「監査の品質を一定に保つための共通ルール」として位置づけられていることを押さえておきましょう。

システム監査の大まかな流れ

システム監査は思いつきで進めるものではなく、決まった手順で進みます。大きく分けると、「監査計画の策定」→「監査の実施(予備調査・本調査・評価・結論)」→「監査報告とフォローアップ」という3つの段階です。まず何をどう調べるかの計画を立て、次に実際に現場を調べて評価し結論を出し、最後にその結果を報告して改善につなげる、という流れです。この3段階は、料理にたとえるなら「献立を考える(計画)」「実際に調理して味を確認する(実施)」「食卓に出して感想を聞き、次の献立に活かす(報告とフォローアップ)」という一連の流れに近いものです。どこか一つの段階を飛ばしてしまうと、監査全体の質が下がってしまいます。この大きな3段階の中身をもう少し詳しく見ていくのが、次の章のテーマです。

なお、システム監査人は会社の中に置かれる場合(内部監査部門など)もあれば、外部の専門家に依頼する場合もあります。どちらの立場であっても、監査対象の業務から独立していること、そして客観的な立場を保つことという原則は変わりません。むしろ内部監査人の場合は、社内の人間関係やしがらみに影響されずに独立性を保てるかどうかが、監査の信頼性を左右する重要なポイントになります。

監査計画を立てる

システム監査は、対象範囲や目的、スケジュールなどをあらかじめ定めたシステム監査計画に沿って進められます。行き当たりばったりで調べ始めると、見落としが出たり、限られた時間の中で重要な部分を確認できなかったりするおそれがあるためです。計画には、どのシステムを、いつ、どのような観点で監査するのかといった大枠が示され、監査を受ける部門にも事前に伝えられることで、必要な資料の準備や関係者のスケジュール調整がスムーズに進みます。

計画を立てる際に欠かせない考え方がリスクアプローチに基づく監査手続の適用です。これは、すべての項目を同じ力の入れ方で調べるのではなく、「リスクが高い部分」に重点的に監査の手間や時間を配分するという考え方です。たとえば、顧客の個人情報を大量に扱うシステムと、社内の備品管理だけに使う小さなシステムでは、同じ深さで調べる必要はありませんよね。前者で事故が起きれば会社全体の信用に関わる大問題になりますが、後者で多少の不備があっても影響は限定的です。限られた時間と人員の中で監査の効果を最大化するために、リスクの大小を見極めてメリハリをつける、というのがリスクアプローチの本質です。「時間が無限にあるわけではないからこそ、危ないところから優先して見る」という発想だと覚えておきましょう。

実際に調べる(予備調査から結論まで)

計画ができたら、いよいよ実施の段階に入ります。実施はさらに4つのステップに分かれます。まず予備調査で、対象となるシステムや業務の概要、関連する規程やマニュアルなどをあらかじめ把握します。ここでいきなり細部を突っ込んで調べるのではなく、まず全体像をつかむことで、本調査で何を重点的に確認すべきかの当たりをつけるのです。次に本調査で、実際に現場に足を運んだり、担当者にヒアリングしたり、資料を確認したりして、具体的な事実を集めます。予備調査が「地図を眺める作業」だとすれば、本調査は「実際に現地を歩いて確かめる作業」といえます。集めた事実をもとに、リスクへの対応が十分かどうかを判断するのが評価の段階で、最後にその評価を踏まえて監査全体としての結論を出します。

こうした調査の過程で集められる、判断のよりどころとなる資料や記録のことを監査証拠と呼びます。議事録や規程集、システムの操作ログ、担当者へのヒアリング記録などが監査証拠の具体例です。監査証拠は集めっぱなしにするのではなく、その内容が信頼できるかどうか、十分な量が集まっているかどうかをきちんと吟味する「入手と評価」が欠かせません。また、いつ・誰が・何を・どのように調べて、どんな証拠を得て、どう判断したのかという監査の過程そのものを記録した文書を監査調書と呼び、これを作成し、後から見返せるよう適切に保管しておくことも、システム監査人の重要な仕事です。監査調書は、監査の結論が正しい根拠に基づいていることを後から証明するための「仕事の記録」だとイメージするとよいでしょう。もし後になって「本当にちゃんと調べたのか」と問われても、監査調書があれば経緯を客観的に説明できます。

具体的な調べ方(システム監査技法)

実際に監査証拠を集めるための具体的な調べ方をまとめて代表的なシステム監査技法と呼びます。あらかじめ確認項目を一覧にしておき、一つずつ照らし合わせて確認するチェックリスト法、担当者に直接質問して状況を聞き取るインタビュー法(質問法)、規程やマニュアル、議事録などの文書を確認するドキュメントレビュー法(閲覧調査法)、実際の業務の流れに沿って処理を最初から最後まで追いかけて確認するウォークスルー法、そしてコンピュータを使って大量のデータを効率よく検証するCAAT(コンピュータ支援監査技法)が代表的な手法です。たとえば、日々発生する大量の取引データの中から不自然なパターンを見つけたいときは、人の目でひとつずつ確認するより、CAATで機械的に検証するほうがずっと効率的です。一方、規程通りに手続きが行われているかを一連の流れで確かめたいときはウォークスルー法が向いています。どれか一つだけで済ませるのではなく、対象や目的に応じてこれらを組み合わせて使うのが実務での基本です。

監査結果を報告し、改善につなげる

監査で分かったことは、システム監査報告書という形にまとめて、経営者など報告を受けるべき相手に提出します。報告書には、見つかった問題点だけでなく、どう改善すればよいかという提案も盛り込まれるのが一般的です。ただし、報告して終わりでは監査の意味が半減してしまいます。提案した改善が実際に実行されているかどうかを、後日あらためて確認する改善提案のフォローアップまで行って、はじめてシステム監査は完結します。「言いっぱなしにしない」という姿勢が、監査の実効性を保つうえでとても大切なポイントです。指摘された部門が改善策を実行したつもりでも、実際には形だけで中身が伴っていないケースもあるため、フォローアップによって「本当に改善されたか」を確認する工程が欠かせません。

このように整理すると、システム監査は「計画→予備調査→本調査→評価→結論→報告→フォローアップ」という一続きのサイクルであることが見えてきます。試験では、この流れの途中の一部分だけを切り取って「これは何の段階か」を問う出題や、監査証拠・監査調書・監査報告書という似た名前の3つの文書の役割の違いを問う出題がよく見られます。監査証拠は「集めた材料」、監査調書は「調べた過程の記録」、システム監査報告書は「最終的な結論と提案をまとめたもの」と、それぞれの役割を対応づけて覚えておくと迷いにくくなります。

内部統制とは

会社が健全に、かつ効率よく運営されるためには、経営者や一部の担当者の「頑張り」や「性善説」だけに頼るわけにはいきません。誰か一人が不正をしようとしても、あるいは誰かがうっかりミスをしてしまっても、それが会社全体の大きな損失につながらないような仕組みを、会社自身があらかじめ作り、運用しておく必要があります。この仕組み全体を内部統制と呼びます。ポイントは「会社が自ら構築し、自ら運用する」という点です。外部の誰かに押し付けられるものではなく、会社自身が「健全かつ効率的な組織運営のための体制」として主体的に作り上げていくものだと理解しておきましょう。

内部統制を実現するためには、いくつかの要素が欠かせません。まず、誰が何をどんな手順で行うのかをはっきりさせる業務プロセスの明確化です。手順があいまいなままでは、チェックのしようがありません。次に、一人の人がお金や情報の入口から出口まで全部を担当してしまわないように、仕事の役割を複数の人や部署に分けて割り当てる職務分掌が重要です。たとえば、支払いを申請する人と、それを承認する人と、実際に振り込みを実行する人が全員同じ一人だったら、不正が起きてもチェックする人がいませんよね。役割を分けることで、お互いにチェックし合う関係を作るのが職務分掌の狙いです。これは、悪意のある不正だけでなく、一人の担当者のうっかりミスを他の人が発見できるようにするという意味でも効果があります。

さらに、日々の業務をどのように行うべきかという実施ルールの設定、そして決めたルール通りに物事が進んでいるかを確認するチェック体制の確立も、内部統制を支える大切な柱です。ルールを作っただけで満足してしまい、実際に守られているかを確認する仕組みがなければ、絵に描いた餅になってしまいます。「業務プロセスの明確化」「職務分掌」「実施ルールの設定」「チェック体制の確立」の4つはセットで覚えておくと、内部統制の全体像がつかみやすくなります。

モニタリングとレピュテーションリスク

内部統制は一度作ったら終わりというものではありません。仕組みがきちんと機能し続けているかを継続的に監視するモニタリングが欠かせません。ルールを作った当初はうまく機能していても、業務の状況や社会の変化、担当者の異動などに伴って、いつの間にか形骸化してしまうこともあるからです。1章・2章で学んだシステム監査は、この内部統制がきちんと機能しているかどうかを、第三者の立場から検証・評価する活動でもあります。つまり内部統制とシステム監査は、「会社が自分で作る仕組み」と「それが機能しているか外部の目でチェックする仕組み」という、いわば車の両輪のような関係にあるのです。

内部統制が不十分で不祥事や事故が起きてしまうと、会社は金銭的な損失だけでなく、「あの会社は信用できない」という評判の悪化、つまりレピュテーションリスクを負うことになります。レピュテーションとは「評判」という意味の英語です。一度失った信用を取り戻すのは簡単ではなく、取引先が離れたり、採用活動に支障が出たりと、金額に換算しにくい形で長期的な打撃を受けることも少なくありません。内部統制はお金の問題であると同時に、会社の信用を守るための仕組みでもあるということを覚えておきましょう。

ITガバナンスとITマネジメント

内部統制と似た文脈でよく登場する言葉にITガバナンスがあります。これは、会社の経営を統治する仕組み(ガバナンス)のうち、情報技術(IT)に関わる部分を指すものです。具体的には、取締役会などの経営層が、株主や顧客といった利害関係者(ステークホルダ)のニーズを踏まえたうえで、自社にとって「ITをどう活用していくべきか」というあるべき姿を描いたIT戦略と方針を定め、それを実現していくための活動全体を指します。ITガバナンスがうまく機能すると、会社の価値や、会社に対する信頼を高めることにつながります。IT投資の判断が現場任せになっていて経営層が把握していない、といった状態は、ITガバナンスが弱い会社の典型例といえます。

ITガバナンスが「どんなITの使い方を目指すか」という方針や戦略のレベルの話であるのに対して、それを実際に現場で動かしていくのがITマネジメントです。ITマネジメントとは、経営方針やITガバナンスの方針に基づいて立てられたIT戦略の目標を達成するために、日々のITの利活用に関する具体的なコントロール(統制活動)を実行し、その結果を経営者に報告するための体制を整え、運用していく活動のことです。両者の違いを整理すると、ITガバナンスは「方向性を決める経営層の仕事」、ITマネジメントは「決まった方向性を現場で実行し、結果を経営層に返す仕事」とイメージすると分かりやすいでしょう。会社の舵取りをする「船長」がITガバナンス、実際にエンジンを動かし航海を進める「機関士・乗組員」がITマネジメント、と考えると両者の役割分担がイメージしやすくなります。内部統制・ITガバナンス・ITマネジメントは、いずれも「会社を健全に運営し続けるための仕組み」という共通点を持ちながら、それぞれ役割分担がなされているのです。

最後に、この3つと1章・2章で学んだシステム監査との関係も整理しておきましょう。内部統制やITガバナンス・ITマネジメントは「会社が自ら作り、動かしていく仕組み」であるのに対し、システム監査は「その仕組みが本当にきちんと機能しているかを、独立した立場から検証・評価する活動」です。会社が自分たちで築いた体制を、自分たちだけで「うまくいっている」と思い込んでしまうことのないよう、外部あるいは独立した立場からの目を入れる。この構造こそが、システム監査と内部統制・ITガバナンスがセットで出題される理由だと理解しておくと、単なる用語の暗記にとどまらず、分野全体のつながりが見えてくるはずです。