更新：2022/7/2
本記事ではシステム監査技術者の論文対策についてまとめます。
受験を申し込んだはよいが、監査の経験が無いので
どうやって論文対策しよう？と悩んでいたり、
せっかく受験するからには、監査の有用性について
本質的に理解したい！と思っていたりしませんか？
本記事では、システム監査技術者を受験予定の
エンジニア、社会人、学生の方に向けて
- 試験センターはどのような論述を求めているの？
- リスクとかコントロールとか監査手続って何？ 具体的に説明して！
- 論文試験にはどんな傾向があって、どんな対策があるの？
といった疑問・要望にお答えしたいと思います。
試験センターの求めるシステム監査技術者としての論述とは
システム監査技術者の採点講評を読めば
次のような論述が求められていることが分かります。
- システム担当者の立場ではなく、システム監査人からの立場で論述すること
- 監査手続の意味を周辺の概念と合わせて理解して論述すること
実際に採点講評を読んでみましょう。
採点講評は試験センターが公開しています。
画像は令和2年度から持ってきていますが、言われていることは例年と同様です。
システム監査人の立場から論述することを求めているが、システム担当者としての対応を論述している解答が散見された
毎回のようにこれを言われるような解答が多いということは、
それだけ頭をシステム監査人に切り替えるのは難しいということです。
監査手続を求めている論述では、そもそも監査手続の意味を理解できていなかったり
これも頻出の講評であり、これは「監査手続とは何か」ということを
周辺の概念と合わせて理解しておく必要があることを示しています。
この点、次章で詳しく説明してみましょう。
採点講評で毎回のように立場のことが取り沙汰されるのは、
受験者においてはエンジニアなどのシステム担当の方が
監査担当より圧倒的に多いということなのでしょう。
ただ、これもよく言われることですが、情報処理試験の高度試験は
必ずしもその試験で問われている立場（今回はシステム監査人）としての
経験は不要です。
私も、多くの高度試験は、その経験を踏まえないまま合格してきました。
合格に必要なのは、その立場を想像して成りきること。
決して「優秀な」システム監査人ではなく「一般的な」システム監査人に
成りきれれば合格できるので、どうか何度受験している方も、
あきらめないでほしいです。
リスク、コントロール、監査手続の考え方
システム監査技術者には一にも二にもこれを理解することが第一と言える概念が、
リスクとコントロールと監査手続です。
これらを関連付けて説明できることが合格の必須条件と言ってよいでしょう。
思考としては、リスク⇒コントロール⇒監査手続の順に整理するとよいでしょう。
イメージしやすい身近な例で考えてみます。
- リスクの例：傘を忘れて雨が降ると体が濡れてしまう（想定とは異なる「望ましくない」状態）
- コントロールの例：天気予報を毎朝必ず見る。天気予報の結果を踏まえて、出掛ける際、傘を持っていくかを必ず玄関で判断する（リスクを低減させる施策）
- 監査手続の例：天気予報を毎朝見ているか確認する。玄関で傘を持っていくかを家族に報告する（徹底されているかが確認できる状態）
3つの中でも中心的な概念である、「監査手続」について、もう少し詳しく説明しましょう。
独立性の原則
監査には被監査対象と監査人が別の人であるべきという独立性の原則があります。
前節の例を見て、行動の主体が「リスク」「コントロール」と「監査手続」で
変わっていることにお気づきでしょうか？
傘を忘れて体が濡れて困る人と、そうならないように天気予報を見て傘を持っていくかを判断する人は同じです。
しかし、きちんと天気予報を見ているかを確認し
傘を持っていくかの報告をさせる人は別の人（家族や恋人）なのです。
これは、監査の目的に立ち返ってみれば自明なことです。
すなわち、システムを問題なく設計・構築・運用する担当者と、
果たして本当に問題ないかをチェックする監査人は別の人
であるべきという原則です。（独立性の原則）
監査証拠
それを確認することで監査手続ができるものを監査証拠と言います。
採点講評でも論述が不足しがちと指摘されている監査証拠は
他の熟語と混乱しやすいですが明確な単語です。
監査人は自分の役割を全うするため、実現可能な監査手続を組む必要があります。
具体的には
- ドキュメントやログなどの査閲
- 担当者本人にヒアリングする
などが考えられます。
これ（ドキュメントやログ、ヒアリング内容）が監査証拠となります。
従って、監査手続を実現可能たらしめるものと言えます。
監査手続を説明する際には、
××（監査証拠）を査閲して○○（コントロールされていること）を確認する
という表現がテンプレートになります。
逆に言えば監査証拠が定義されていない監査手続は
監査手続と言えません。
前節の例でいえば、天気予報を毎日見ていることを確認するために
毎日メールやLINEで連絡させたものを確かめる、というようなことが
考えられるでしょう。
・・・。
というようなことが現実に起きたとしたら、
おそらくその人は相当に、束縛の気が強いと言えそうです・・・。
というのは半分冗談ですが、実際に監査人は対象のリスクが起きないよう
助言・保証したりしないといけない訳ですから、
感覚的に言うとある程度束縛感のある振る舞いが求められることになります。
ここまでのまとめ
一枚の絵でまとめておきましょう。
これらのことが頭に入っていれば、
あとは設問に問われた条件・シチュエーションに当てはめて考えればよいです。
それでは、実際に過去問を見てみましょう。
過去問分析
本章では令和2年度の過去問をもとに分析します。
令和2年度システム監査技術者午後II過去問(ipa.go.jp)
問1（AI技術を利用したシステムの企画・開発）
はじめに採点講評を見てみます。
リスクを問うているのにコントロールを論述していたり、確かめるべき具体的な監査証拠を記述していなかったり
と、前章の中核的な概念に沿ってない解答が見られたようですね。
本問題はAI技術・AIシステムを題材にしています。
どのようなリスクやコントロールの例が考えられるかを検討しましょう。
リスクの例
リスクについては設問イで問われています。
状況は「利用段階におけるリスク」です。
AI技術は便利ですが、必ずしも想定した結果を返してくれる存在ではありません。
ここから、想定される主なリスクの例としては、
- 学習が足りなくて、想定した結果が導かれないリスク
- 学習させるのに、学習用データセットを準備するなど想定以上に時間やコストが発生するリスク
を考えるとよいでしょう。
また、AIシステムに関係がなくなってしまいますが、
一般的なシステムでも考えられる利用段階におけるリスクとして
- 利用者の要求を満たしていない（開発者のひとりよがりな）システムができてしまうリスク
も挙げてもよいかもしれません。
いくつかのリスクを書けば、700字以上の文字数は楽に超えるでしょう。
コントロールの例
コントロールは、設問イで述べたリスクに対して考えます。
未然に防ぐために上流工程でどのような施策（＝コントロール）がとれるか？
という考え方になります。
リスクに対応付けてコントロールを考えます。一例を示します。
- 学習が足りなくならないよう、必要な学習量を設計し事前にテストをする
- 学習用データセットを準備する時間やコストが想定外にならないよう、インクリメンタル（段階的に）リリースする計画とし経営陣に合意をとる
- 利用者の要求を踏まえられるように、利用者からの要求を吸い上げ確定できるような会議体を設置する
最後の例は、まさによくある例ですね。
逆に現場経験がある人は、当たり前すぎて施策になっている自覚が
得にくいところかもしれません。
ただ、ここではあくまで監査人として実現可能な監査手続を考えられる
コントロールであることが重要です。
監査手続の例
監査手続は設問ウで問われています。
状況は「企画・開発段階」です。
監査手続には監査証拠が必要なので、
前項のコントロールが機能しているかを確認する監査証拠を考えます。
一例を示します。
- 学習量が想定された設計書。テストの計画書。
- 経営陣への報告書。議事録。
- 利用部門との会議事録。利用者にヒアリング。
これらを併記すれば、700字以上は楽に書けるでしょう。
なお、設問イのリスクと設問ウの監査手続の間に、
説明しなければならないコントロールはどちらで書くべきかという問題が残ります。
これは、結論から言うと、どちらに書いても構わないです。
その時の文字数の状況から、臨機応変に判断しましょう。
ちなみに私の経験則からは、設問イ（リスク）の中で合わせて
コントロールを説明してしまう方がおさまりがよくなることが
多かったように思います。
問2（IT組織の役割・責任に関するシステム監査）
問1と同様に、はじめに採点講評を見てみます。
問2でも設問イでリスクを、設問ウで監査手続を主に問われている構成は
変わらないですが、採点講評では、
設問ア、イ、ウで一貫した論述を心がけてほしい
と言われています。
すなわち、リスク・コントロール・監査手続の論理の展開を
設問で問われている状況に即して破綻なく論述できていない解答が
多かったと想像できます。
問2も、同様にリスク・コントロール・監査手続の3点セットで考えてみましょう。
問題文の例にパブリッククラウドサービスに関する言及があるので、
それに沿うと、たとえば次のような流れが考えられます。
- リスク：クラウドサービスは手軽に利用できる反面、IT部門ではない様々な部門が深く考えずにサービスを利用することにより、サービスレベルやコストを想定通り維持できなくなってしまう
- コントロール：クラウドサービスを選定する際、サービスレベルやコストを必ず確認するようガイドラインを社内に公布し、事前にIT部門に相談するように標準化する
- 監査手続：ガイドラインを査閲。またIT部門に相談した際の議事録を査閲し、クラウドサービスを導入する前にアセスメントがされているかを確認する
この問題は、他にも問題文中に例がありますので、
また違った3点セットを導くこともできそうです。
おわりに
よくあるリスク・コントロール・監査手続の3点セットを
たくさん事前に想定できるようになっておけば、
設問で指定される多様な状況に対応して論述することができるようになるでしょう。
また、リスク・コントロール・監査手続の中核的概念は、
午後Ｉの問題に解答するときも重要な概念になります。
午後Ｉの採点講評を読んで分析した記事もあるので参照ください。
合格直後の振り返りの記事はこちらを参照ください。
本ブログでも、リスク・コントロール・監査手続の3点セットの
事例集をまとめることができたら、参考になると思いますので
手掛けてみたいと思っています。
ではそれまで。
