システム監査技術者 RPAツールの業務処理の自動化【過去問論文分析】(令和3年秋問1)
本記事ではシステム監査技術者の午後II(論文)対策として、
令和3年問1で出題された過去問を分析します。
実際に論文を書く上での考え方を整理し
論文骨子を設計するところまでやっていきます。
※本記事はメインの過去問分析は無料記事であり、参考として載せている論文の全文のみが有料記事です。
問題(令和3年問1)
表題:『RPAツールを利用した業務処理の自動化に関する監査について』
設問文は以下の通り。
何が問われているかを把握する
本問題はRPAツールを題材とした開発・運用・保守の
システム監査が問われています。
設問アは「対象業務」「期待効果」「開発・運用・保守の体制」
が問われています。
設問イは「リスク」「コントロール」、
設問ウは「監査手続」が問われています。
システム監査技術者で問われるポイントは
リスク・コントロール・監査手続です。
この3点セットについて詳しく理解したいという方は
以下記事を参照ください。
■システム監査技術者の論文対策■
システム監査技術者の論文対策(リスク・コントロール・監査手続)
本問題の特徴はRPAツール(により開発されたロボット)であり、
特徴的なリスクとしては問題文の3段落目に例示されています。
「ユーザ部門は情報システムに精通している訳ではない」
「ユーザ部門が業務選定を間違えたりテストが不足したりする」
「運用管理や保守体制が明確ではなくロボットのメンテがされなくなる」
どれもユーザ部門とシステム部門の折衝で現れそうな課題です。
プロジェクトとして考えると、鍵は部門間調整をいかに行うかに
かかっています。
監査人の目線から考えると、いかに部門間調整を行ったかという
ことを確認することが鍵になります。
まとめると問われていることは次の通りです。
出題要旨と採点講評からの分析
出題の意図と論述のNG例を把握します。
出題要旨
採点講評
出題要旨の2段落目に以下の記述があります。
「ユーザ部門だけでロボットを開発し、運用及び保守するにはリスクが生じる」
試験センターとしても、RPAツールによるロボット開発を
ユーザ部門だけで完結させることは難しい認識を持っていると
読み取れます。
採点講評からは次の記述が目を引きます。
「システム部門やベンダ委託によるツール導入の一般的な開発、
運用・保守の内容にとどまり、RPAの特徴を踏まえた論述になっていない」
前節から申し上げている通り本問はRPAの特徴を踏まえることが重要です。
別の切り口から言うとRPAの特徴としては、自動化対象とする
業務領域の選定も一つのポイントとなります。
たとえば基幹システムなどで実装すべきものようなら、
それはシステム部が主体で実装するべきということになります。
経験が思いつかない場合、ヒントとしては基幹システムの
周辺に目を向けてユーザ部門が担当する業務を検討すると
よいでしょう。
たとえば営業部が顧客マスタを保守したり
製造部が商品マスタや部品マスタをメンテしたりする
ことなどが考えられると思います。
論文を設計する
自身の経験や用意してきた論文パーツに当てはめて
どのように論述を展開するかを設計します。
設問アの設計
設問アは「対象業務」「期待効果」「開発・運用・保守の体制」
について問われています。
○対象業務
前節でも述べた通り対象業務はシステム部門が
主体でやるできではなくユーザ部門が主体で
行う必要があります。
私の場合は衣料品卸売業の事例が、
顧客層が多岐に渡り営業部門が顧客マスタに入力する
業務の自動化が考えられたため論述対象に選択しました。
○開発・運用・保守の体制
また「開発・運用・保守の体制」については、
後述する設問イ・設問ウの「リスク」「コントロール」「監査手続」
と合わせて考えた方がよいでしょう。
なぜなら、体制こそがRPA特有のリスクを体現すると同時に
解決策でもあるからです。
いくつかは考えられますが、
運用をシステム部門がやるというシナリオは避けた方が
よいと思います。
私の場合は、保守対応を保守が発生するきっかけによって
営業部とシステム部が分担するという体制としました。
問題文より保守体制が明確でない事態が言及されており、
後述のリスクとコントロールを論じる上での
伏線としています。
設問イの設計
設問文の問われ方は
「リスクを低減するにはどのようなコントロールが必要か」
「リスクと関連付けて」
と出題されています。
論文上は、単純に2-1.節でリスクを論じ、
2-2.節でコントロールを論じるのがよいでしょう。
それぞれの説を記号付きの箇条書きで列挙し
関連付けのために記号を揃えておくのがよいと思います。
私の場合は保守対応の体制を主眼とし
「役割分担」
「営業部担当のスキル」
「システム部からの情報連携の徹底」
を切り口としました。
1. はプロジェクト期間における運用受け入れフェーズのタイミング、
2. と 3. はリリース後の定期的なタイミングの施策となります。
○リスク
番号順にリスクを説明すると、
役割分担が曖昧だとロボットの保守対応が適切になされず
期待効果を達成できないスキルが不足していると適切な運用・保守ができない
システム部からの情報連携が徹底されないと適切な
保守対応が実施できずロボットの動作に支障をきたす
といった内容になりました。
リスクの書き方は、
が定型構文です。
リスクの結果発生する問題や不具合は互いに少々重複していても
問題ありませんが全く同じ内容にはならないように
表現を工夫する方がよいでしょう。
○コントロール
番号順にコントロールを説明すると、
運用受け入れフェーズにおいて営業部・システム部双方合意のもと
役割分担を定義する営業部担当者に適切な研修を受講させる
システム部からの情報発信をワークフローで管理し
対応が宙に浮かないように管理する
といった内容になりました。
コントロールは
ことを確認しながら論述します。
またここで書くコントロールは
後述の設問ウの監査手続で確認がとれるものを
書いておく必要があります。
そうでなくては設問間のつながりを論述で
表現できないことになってしまうためです。
設問ウの設計
設問イのリスク・コントロールは、
プロジェクトマネージャ(PM)の視点で
論述していることを確認してください。
一方設問ウの監査手続ではシステム監査人の
立場となるので明確に主体が異なります。
上述のコントロールが機能していることを確認するための
監査手続なので、箇条書きで番号は揃えて論述するのがよいでしょう。
営業部・システム部双方合意の役割分担表を査閲し
役割分担が定義・承認されていることを確認する研修の受講履歴を査閲し営業部担当者がスキルを備えている
ことを確認するワークフローの対応履歴を査閲し
保守対応が完遂していることを確認する
監査手続のテンプレートは
です。
監査証跡はドキュメントの他、
システムログや履歴、担当者インタビューでも構わないです。
これらを織り交ぜて監査手続とします。
論文骨子
以上を踏まえ、論文骨子は次のようになりました。
まとめ
いかがでしたでしょうか?
本記事ではシステム監査技術者の午後II(論文)対策として、
令和3年問1で出題された過去問を分析しました。
RPAという若干経験を要する分野であったかもしれませんが、
部門間調整をキーにリリース後の運用・保守対応も
スムーズにするために監査として何ができるかを
考えさせる良問であったように思います。
問題に合わせて自分の経験をあてはめ論述するというやり方に
慣れるという意味でも参考になったら幸いです。
今後も、よろしくお願いいたします。
論文全文
ここまででも十分お伝え出来たと思いますが、
論文の全文を参考にされたいという方は
有料とはなりますがここから先の部分をご購読お願いします。
■設問ア
1.RPAを利用した業務処理の自動化の概要
1-1.対象業務の概要と期待される効果
J社は衣料品を主に手掛ける卸売業である。論述の対
象とする業務は、顧客マスタへの顧客情報の入力・更新
業務である。基幹システムである受注管理システムが参
照する顧客マスタの情報入力・更新はJ社営業部の役割
である。J社の顧客層は個人事業主からアパレル大手ま
で幅広く、流行に敏感な業界でもあり顧客名や顧客担当
者や事業部などの情報が頻繁に変化した。
RPAを利用する期待効果としては、顧客名や住所な
どの入力作業や整合性チェックを自動化することによる
営業担当者の負荷軽減と業務品質の向上である。かつて
J社営業部では受注管理システムから出力される見積書
や請求書の顧客情報に誤りがあり、クレームに発展した
ことがあった。顧客マスタへの入力情報の整合性チェッ
クは営業部でしか分からない勘所もあるため、営業部主
導で要件を定めRPAを利用したロボットを開発するこ
ととなった。
ここから先は
この記事が気に入ったらチップで応援してみませんか?