ならず者IoTエンジニアが由緒正しきシステム監査技術者になってしまった件(2)
学習の流れ
確か第二種電工の合格通知を受け取って、登録申請した後辺りから始めたので、1月下旬～2月ごろからだったように思います。
よって学習期間は2か月程度、どちらかというと時間短めでした。
教科書、基準、参考書の読解
いつも通り通勤電車の中では知識の蓄積フェーズ。試験直前まで、熟読系はほとんどここでやってました。
演習
基本的に知識蓄積は後半に効いてくるので、まずは知識だけでは解けない午後系を中心に実施して、午前試験は終盤軽めに回す方針で進めました。
午後Ⅰで感じる違和感
まずは午後Ⅰの過去問に挑戦したんですが…ここで結構違和感があって。
高度の午後Ⅰ試験のポイントは、出題者側(IPA)と思考回路というか、考え方を合わせることだ、とよく言われます。午後Ⅰ試験は午前試験と違って記述式の自由回答なので、一字一句確定した答えはなく、出題者の意図に沿った回答を記述することが求められます。
高度を数回受験した経験から、そこまではわきまえていたんですが、システム監査技術者試験の午後Ⅰは、かなりつかみどころがなくて。
システム監査技術者試験の午後Ⅰ試験の出題形式は、他形式と違ってほぼ決まっていて、字数制限にばらつきはありますが（10字から60字ぐらい)、文章記述第5問から構成されます。
字数に合わせて答えるには答えるものの、書かれた解答例と自分の回答がだいぶ違っている、という経験を何度もしました。学習時期の後半まで回したんですが、終盤になってもあまりシンクロしなかったですね。
実は本試験の午後Ⅰの成績、個人的には合点がいってなくて。結構埋めてるはずなんだけどギリギリ、って所が。
ただ、試験勉強時のこの違和感からして、結局本試験まで出題者側の題意に沿えなかったのではないか、と解釈すると、自身の感覚とスコアの平仄は合います。
午後Ⅰにおける回答のポリシー
そんな感じで午後Ⅰが弱かった受験者なので、この辺へのアドバイスは弱めなのですが、一つ意識しておくべきことがあるとすると、
- 状況に対するリスク要因を探し、リスクに備えるためのコントロールをチェックすること
これが午後Ⅰ、及び午後Ⅱを通して大きな方針になることは確かです。
もう少し突っ込むと、午後Ⅰ試験では、大抵こんなことを聞かれます。私は演習を繰り返した結果、終盤では以下を念頭に置いて回答していました。
- 監査人がある行動をとる(べき)とされる理由
- 潜在しているリスクか、監査人の行為規範のいずれかを聞かれている。前者は問題文から、後者はシステム監査基準をベースに答える。
- 事例に潜むリスクそのもの。
- 題意に沿いながら、問題文の状況で『ここヤバくね？ こういう理由で』と言える場所を探して答える。
- リスクに対するコントロールの方法
- システム管理基準をベースに答えるのが有効だが、適切なものが見つからなければ、なるべく確実に問題を潰せる対策を答えるのが良い。技術的な対策とは限らない点に注意。
- 監査手続の方法
- 代表的な監査手法(インタビュー、文書収集等)を念頭に、自分が監査人としてコントロールが機能しているかを客観的に確かめられる手法を回答する。
システム監査技術者試験はマネジメント系試験の一つである、という点は重要な点で、リスクに対するコントロールの方法は技術的手段とは限らないことを念頭に置いておく必要があります。
技術者、チーム個人ではなく、事業部、会社全体といったマクロな組織単位でリスクがコントロールされているか、という組織的なコントロールが主要な関心事となるので、適切なコントロールにはマネジメントとしての打ち手が多く含まれます。
もう一つ、適切なコントロールが分かっても、そのコントロールを実施するのは監査人たる自分ではなく、被監査部門であるべき、という点は常に念頭に置いておきましょう。我々は『確認する側』 なのです。独立した立場の人間として問題文を読み、答案を書く必要があります。
あと、システム監査人というロールの難しさは、技術的なバックボーンなしでは最適なコントロールや監査手法を提案できない、ということと、試験で要求されるかもしれない技術領域は非常に広いという点です。
この辺は、システム監査技術者の過去数年分の午後試験をやってみるとすぐに分かります。今年の試験は比較的マネジメントに寄ってはいたものの、対象領域、業界には以下のように非常にばらつきがあります。
| 年度 | 午後Ⅰのテーマ |
|---|---|
| 2019 | RPA、開発計画、メインフレームのオープン化 |
| 2018 | ステージゲート、データ分析基盤、販売管理システム |
| 2017 | 在庫管理システム、品質管理基準、工場系ネットワーク |
| 2016 | VDI、情報セキュリティ管理、経営情報システム |
先の通り、リスクに対するコントロールをチェックする、という点がシステム監査を貫く大テーマなので、問題の出方はリスク、コントロール、監査手続の側面に帰着はするのですが、問題の円滑な理解に当たっては ITの各領域、技術分野を広く浅く知っておく(守備範囲を広くしておく) ことが有力な武器になります。
言うは易く行うは難しなのですが、特に 特定の分野に知見が偏りがちな人は気をつけましょう(私もそうでした)。 過去問を多く見ておくことと、先般紹介した事例関連本、及びシステム管理基準を読んでおくのが備えになります。
午後Ⅱに対する備え
論文学習の手順自体はシステムアーキテクトと大差ありません。その辺を知りたい方は過去記事をどうぞ。
今回も午後ⅡはPC5問、机上7問ぐらい解いて試験に臨みました。システム監査技術者の論文テーマは少ないので、学習終盤にはテーマが尽きてましたね。
午後Ⅱも監査だけ答えればいいって問題ではないのが非常に厄介です。
いやまぁ、午後Ⅱも午後Ⅰと同じく型は決まりきっているんですよ。
- 問1で受験者が関連した/する予定のシステムの概要を説明させ、
- 問2でリスクをリストアップし、当該リスクに対するあるべきコントロールを述べさせ、
- 問3で各コントロールを監査人が確認するための監査手続を問う
という流れなのです。ほとんどが。
問題はテーマや対象技術領域の候補が広いくせに、設定されたテーマから回答可能な範囲は結構狭い 、ってことなんです。
| 年度 | 午後Ⅰのテーマ |
|---|---|
| 2019 | IoTシステム企画、情報セキュリティ関連規定見直し |
| 2018 | アジャイル開発、リスク評価結果を利用したシステム監査計画 |
| 2017 | 内部不正対策、運用段階でのセキュリティ監査 |
| 2016 | システム投資に対する監査、設計、開発段階における品質管理 |
テクニカルスペシャリストやシステムアーキテクトと違って、これらのテーマには技術的に何の共通点もなく 1 、あるとすれば、 それぞれに対して監査をするということだけ なんです。
このため、幅広く経験を積んできたエンジニアでなければ、過去問、そして挑戦するであろう本試験のテーマ全てに対して実例を用意することは相当難しいはずです。 場合によっては監査部門でなければ経験しないテーマもあるので、監査未経験の一エンジニアには至難といってもいいかもしれません。
私自身も長らくエンベデッドの一部門で経験を積んでいて、横断的に多種多様な部門の監査を経験しているわけではありませんでした。なので、今回の午後Ⅱに対しては、システムアーキテクト試験の本番で発揮された『妄想力』を演習段階から全力開放しました。
論述対象システムを"見出す"
私自身が担当したシステムの種類は少ないものの、私の会社が保有したり、開発しているシステムは結構多かったので、
- 論述対象になりそうな業界のシステムをいくつか念頭に入れておいて、
- 論文テーマに対して、あるあるなリスクとコントロールの組み合わせをいくつか列挙し、
- 2で列挙したリスク、コントロールを当てはめると、現実の事例としてしっくりくるシステムを1から選んで、想定し得る状況と、その状況に対する監査手続を書く
こんなやり方で演習をしていました。
例えば、
- 設計、開発段階における品質管理→自部署が設計、開発やってるので自部署の話を書く
- 運用段階でのセキュリティ監査→人の立ち入りチェックやデータ暗号化を自社のデータセンターでやってたので、データセンター運用事例について書く
- ソフトウェア脆弱性監査→サイバー攻撃対策がいいか。自社で作ってた電子書籍販売システムへの攻撃対策を書いてみよう
みたいな感じで、用意したシステムのストックに対して、リスクとコントロールを組み合わせて事例を作ってました。
一つのシステムが複数のテーマに対応できたりもするので、全てのテーマに別々のシステムを当てはめる必要はありません。
- 本試験の時点で、出題されたテーマからリスクとコントロールを導出でき、それがしっくりハマるシステムを持ちネタとして持っていること
が、おそらく本試験午後Ⅱの勝利条件の一つなので、これをできるようになっておくとよいです。
事例、リスク、コントロールは平たく、監査手続は深く。
おそらくもう一つの、そしてあまり自明でない勝利条件はこれではないかと思っています。
端的に言うと、『問1、問2の(監査手続以外の)記述は書きすぎず、問3はしっかり書き込む』ことになります。
これ、システム監査技術者試験経験者が良く話す内容なんですが、受験当時はピンとこなかったんですよ。
ただ、今ならその理由が分かります。それは時間配分という物理的な理由だけではなく、
- システム監査技術者試験の目的は、リスクに対して適切な監査を設定できる能力を測ることだから。
だろうなぁ、と。
もちろん、リスクとコントロールを抽出し、評価することもシステム監査技術者の重要な仕事なんですが、監査技術者の仕事は第一義的には監査なので、リスクとコントロールを抽出して終わりじゃダメなわけです。
コントロールが機能しており、リスクが組織として抑止されていることを検証できないといけない。なぜならそれがシステム監査技術者の第一義的な仕事だから ってことなんだろうなぁ、と。
監査手続を問われることは、システム監査技術者の実務能力を問われるのと同義 なので、どのように監査を設定するか、何をエビデンスとしてどう確認するかは、リスク、コントロールと結び付けてガッツリ書きましょう。
-
セキュリティはちょっとだけ出やすいです。論文ネタにもなりやすい。↩
