システム監査技術者 2019年 春期 午後I 問題

共通の文章

RPA(Robotic Process Automation)システムの監査に関する次の記述を読んで,設 問1ン5に答えよ。 流通業のP社では,数年前から業務の効率向上に取り組んでいる。その一環とし て,営業管理部では,1年前からRPAの導入を進めてきた。RPAは,ソフトウェア ロボット(以下,ロボットという)を利用することによって業務処理を自動化する ものである。 営業管理部でのRPA導入後において,特に問題は発生せず,効果が得られる見込 みとなったので,P社では,他の部署でもRPA導入を進めることにした。その一方 で,今後RPAの利用が拡大すると,問題が発生した場合に業務に与える影響が大き いと想定した。そこで,BAMA,P社におけるRPAを実現するための情報システ ム(以下,RPAシステムという)について監査を実施することになった。 〔予備調査1 監査部は,予備調査として営業管理部長にヒアリングを行い,関係資料を閲覧し て,RPAシステムの概要・構成,及びRPA導入の進め方を把握した。その内容は次 のとおりである。 (1)RPAシステムの概要 RPA導入前に人間が行っていた作業を,ロボットに組み込まれた自動処理(以 下,ロボット処理という)によって実行する。ロボット処理によって操作できる 対象には,業務に関連した情報システム(以下,関連システムという)の画面, 表計算・電子メールなどを取り扱う事務処理用ソフトウェア,Webブラウザなど がある。 (2)RPAシステムの構成 RPAシステムには開発環境と実行環境があり,更に実行環境には管理画面が提 供されている。RPAシステムの実行環境の概要を,図1に示す。 ーゥー [=|arn is bee Yt M1 RPAシステムの実行環境の概要 ①開発環境としては,一般には,サーバ上で開発するサーバ型と,PC上で開発 するクライアント型がある。営業管理部で採用したのは後者で,5台の開発専用 PCにロボットの開発環境を導入している。 ②実行環境においては,開発されたロボットがサーバ上で稼働することによっ て,関連システムの画面などを操作して,定義された処理を行う。 ③管理画面からは,実行環境のロボットの稼働状況を閲覧でき,UY LOR 働回数・稼働時間などのデータをダウンロードして分析することも可能となっ ている。 (3)RPA導入の進め方 営業管理部ではRPA導入を,RPAについての研修,業務調査,業務フロー作成, ロボットの開発・テスト,及び実行環境への導入というプロセスで進めた。 [予備調査2] 監査部は,予備調査として情報システム部長にヒアリングを行うとともに,仕 様・構成などを記載しているRPAシステムの説明資料を閲覧し,現在の状況を把握 した。その内容は次のとおりである。 (1)RPAシステム変更の検討 ロボット数の増加に対応するために,開発環境はクライアント型からサーバ型 に変更するとともに,実行環境のためのサーバを増強することにした。 (2)開発方針 今後の開発作業を進める上での方針(以下,開発方釘という)ELT,幾つか の項目を定めた。その例を次に示す。 開発方針の:できるだけ幅広い業務をRPAの対象とする。 開発方針②:開発を効率よく行うために,類似作業を共通化した上で開発する。 具体的には,業務フローを作成した後に,類似作業を洗い出して, 同一のロボット処理によって実現する。 開発方針③:業務フローを作成する際には,現行業務について,できるだけ,作 業目的や作業方法などの背景を含めて文書化する。 (3)業務処理の時間短縮 RPA導入によって,人間が作業を行う場合と比べて,業務処理の時間がどの程 度短縮できるのか,営業管理部にヒアリングを行った。その結果,ロボットによ る,事務処理用ソフトウェア及びWebブラウザの画面の操作速度は,人間による 操作と比べて5倍から10倍であることが分かった。すなわち,ロボットを利用す ることによって,業務の効率が従来よりも格段に向上することが期待できる。 (4)ロボットが使用するIDとパスワードの管理 ロボットが,実行環境の中で関連システムを操作する際には,通常の利用者と 同様に,関連システムの画面にIDとパスワードを入力する必要がある。関連シス テムの管理部署には,RPAシステムの管理部署から,ロボット処理の対象となる ことを事前に連絡して,ロボット処理による操作を行って問題がないことを確認 する。その上で,関連システムの管理部署は,ロボットが使用するIDとパスワー ドを発行し,IDの棚卸対象としてID一覧表に記載して管理する。 (5)関連システムの状況 関連システムの中には,構築してから10年以上が経過し,機能不足や,業務量 増加によるレスポンス遅延などの苦情が出ているものがある。現時点では大きな 再構築計画はないが,関連システムによっては,業務の見直し,法令対応に合わ せて,数か月ごとに改修が行われている。 〔本調査の結果] 監査部は,予備調査の結果を基に,本調査を行った。その結果は次のとおりであ る。 1)[予備調査2}②の開発方針②について 監査部は,RPA導入によって,業務の効率向上の効果があるが,一方で,類似 作業を共通化した場合,業務に関わるリスクもあると考えた。そこで,具体的な 運用方法を関係者にヒアリングしたところ,共通化しようとする類似作業の差異 分析,共通化した場合の影響評価などが検討されていた。 (2②)[予備調査2}】(3)について 監査部は,RPA導入の対象となる業務処理の時間が短くなる一方で,関連シス テムの稼働に関わるリスクがあると考えた。そのために必要な対応が行われてい ることを,情報システム部へのヒアリングによって確認した。 (3③[予備調査2}】(について 監査部は,ロボットが使用するIDとパスワードに関しては,関連システムにお ける管理を確かめるだけでは不十分であると考えた。そこで,RPAシステムにお ける,関連システムのIDとパスワードの管理方法について,RPAシステムの説明 資料を閲覧して,問題がないことを確認した。 (4) 〔予備調査2]】(5)における関連システムの改修について 監査部は,RPAシステムに必要な対応が行われているかどうかを,情報システ ム部の変更管理プロセスの手順書を閲覧して確認した。CORR,対応が不十分 であることが分かったので,手順書を見直すよう提案することとした。 (5)監査部は,情報システム部長に対して,RPAの利用拡大による費用対効果につ いて検討しているかどうかを,ヒアリングした。その結果,情報システム部では, RPAシステムの管理画面を活用した取組を計画していることが分かった。

共通の文章

システムの開発計画の監査に関する次の記述を読んで,設問1こ5に答えよ。 A社は,機械部品,工具などを製造・販売している中堅企業であり,業務拡大のた めに,営業支援システムを刷新することになった。現在,A社内で要件定義を行って おり,設計工程以降はベンダに外部委託する計画である。 昨今,他社でシステム開発の外部委託を巡るトラブルで訴訟に発展する事例が発 生していることから,A社の監査室に対してシステム監査の実施が指示された。しか し,監査室は,これまでシステム監査の経験がほとんどないので,外部のシステム 監査人S氏に今回のシステム監査チーム(以下,監査チームという)に参画しても らい,助言を受けながら監査を実施することにした。 〔予備調査の結果] 監査チームは,A社の新しい営業支援システム(以下,新システムという)の開発 計画の状況を,次のとおり把握した。 1)A社の営業戦略を担う営業統括部と現行システムを管理するシステム部が中心 となって,システム企画書を作成した。 2)A社のシステム部では,数名の部員が主に委託先への発注業務などの事務的な 作業を行っているだけで,ここ10年以上大きなシステム開発は行っていない。ま た,現行システムの運用・保守は,開発を担当したZ社に任せている。 3)新システム開発プロジェクトで要件定義を開始する際に,システム部のT課長 がプロジェクトマネージャ(PM)に任命された。T課長は,他部署から異動して きたばかりで,システム開発プロジェクトのPMに任命されたのは初めてである。 (4)T課長は,現行システムの仕様を十分に把握していないので,現行システムを 熟知しているZ社の担当者に依頼して,現行仕様を基に要件定義書の原案を作成 してもらっつた。 ⑤5)営業統括部が,営業戦略上重要な新規機能の要件を要件定義書の原案に付け加 えた。そして,関連部門が現行システムに対する要望事項に大中小の重要度を付 加し,T課長に提出した。その後,システム部が,関連部門にインタビューしなが ら業務上の代替手段などを検討し,要望事項にプロジェクトとしての優先順位を 付与した上で,“要望事項一覧"として要件定義書に追記した。 ー6一 (6)要件定義書を作成した後,Z社を含む複数のベンダに見積りを依頼し,そのうち の1社に基本設計からシステムテストまでの工程を請負契約で委託する。開発委 託先が決まったら,開発スケジュールを詳細化し,プロジェクト計画書を作成す ることになっている。 (1)システム部は,システムテストまでの工程の成果物が過不足なく納品されてい ることを確認する。また,システムテストのテストケース及びテスト結果を確認 して検収を行う。検収完了後から本番リリース準備開始前までにA社内でユーザ 受入テストを実施する。 (8)開発着手後も要件の追加・変更が見込まれるので,委託先には一定の条件下で 要件の追加・変更を依頼する前提で発注する。 〔リスクの洗い出し] 監査チームは,予備調査の結果を基に,新システムの開発計画のリスクを洗い出 した。その内容は,次のとおりである。 Q)T課長が関連部門からの要望を整理できず,要件定義書をまとめきれない。そ の結果,“開発範囲が確定しない”",“開発に着手できない",“プロジェクト計画書 を作成できない”などの状況に陥るリスクがある。 (2)業務要件が十分に固まっていない状態で開発に着手することによって,後から 要件の追加・変更が頻発し,計画どおりにプロジェクトを進められないリスクが ある。 3)委託先への発注窓口であるシステム部の体制が不十分で,開発着手後も委託先 に『“丸投げ"の状態となむるリスクがある。その結果,“進捗状況を十分に把握でき ず,進捗遅れ・予算超過を適時に把握できない",“開発着手後の追加・変更要求 を要件として委託先に依頼できない"といった状況に陥るリスクがある。 (4)PMの責任・権限が曖昧なことから,T課長が判断に迷った場合に:,プロジェク トとしての意思決定ができないリスクがある。 〔本調査の計画 監査チームは,リスクを洗い出した後,表1に示す監査手続書を作成し,S氏に助 言を求めることにした。 表1監査手続書 1(1)関連部門から出された要|・要望事項一覧を閲覧して,“BEE”の項目があ 望について,優先順位がり,大中小のいずれかが漏れなく設定されてい 検討されているか。ることを確認する。 2①(3③(④|新システム開発プロジェ|・システム企画書を閲覧して,委託先が決定し, クトの本番リリースまで開発に着手した後の体制と役割が明確になって の体制と役割が,明確にいることを確認する。 定められているか。・システム企画書を閲覧して,システムオーナが 明記されていることを確認する。 3(D2)|要件定義書の作成時に,・新システム開発プロジェクトの体制図を閲覧 利用部門の代表者が参画し,利用部門の代表者が参画する体制になって しているか。いることを確認する。 4(3)委託先の進捗状況を適時|-BHECOBZMAROFSHRE,進捗報告とし に,正確に把握できるよて求める内容などについて,システム企画書を うになっているか。閲覧して確認する。 5(2)3)|開発着手後の要件の追|・要件の追加・変更に関する手順に係る文書を閲 加・変更に関する手順が|BL,内容の妥当性を検証する。 文書化されているかな。 注り“リスク項番"”は,【リスクの洗い出し](1)て〈④のリスクのうち,どのリスクに対応してい るかを示している。 [S氏からの助言〕 S氏からの助言内容は,次のとおりである。 (1)表1の項番1の監査手続について 重要度の項目が,要望事項一覧に漏れなく設定されているかどうかを確認する だけでは不十分である。 (2)表1の項番3の監査手続について 新システム開発プロジェクトの体制図の閲覧だけでなく,要件定義書作成時の 議事録の閲覧,及び体制図に記載された利用部門の代表者へのヒアリングを行っ て確認する必要がある。 (38)表1の項番4の監査手続について 進捗状況を適時に把握できるよう,委託先との進捗会議の実施頻度を確認して おくことは重要である。さらに,“委託先からは,進捗報告資料のほかに成果物の 一部とテスト結果を提出してもらい,システム部が進捗報告の内容と比較するこ とを計画しているかどうか"を確認する必要がある。 ーー8ーー 〔本調査の実施 監査チームは,表1の監査手続書,ROS氏からの助言を踏まえて,要件定義書 の完成前に本調査を実施した。その内容の一部は,次のとおりである。 QQ)表1の項番2の監査手続について 監査チームは,開発に着手した後の体制と役割が明確になっていることを把提 した。ただし,検収完了後の体制については確認できなかった。監査チームは, 検収完了後から本番リリース準備開始前までのA社内の体制について,更に詳細 に確認することにした。 2)表1の項番5の監査手続について T課長が作成した,委託先向けの“要件の追加・変更に関する手順"には,必要 と考えられる事項は網羅されていた。そこで,監査チームは,これらの手順が委 託先との間で合意可能かどうかを,T課長にヒアリングして確認した。T課長によ ると,“委託先に対して手順の人遵守を求めることは,契約時に双方で確認するので 問題ない”との回答であった。この結果を受けて,S氏は利用部門向けにも要件 の追加・変更に関する手順”の周知が必要であると指摘した。監査チームは,追 加の監租手続として,要件の追加・変更の要求がある程度増えても期間内に対応 できるような対策が設けられているかどうかを,課長に確認することにした。

共通の文章

基幹システムのオープン化の監査に関する次の記述を読んで,設問1ー5に答えよ。 B社は,中堅の機械メーカである。B社では,メインフレーム上に,販売,購買, 生産管理のサブシステムで構成される基幹システム(以下,現行システムという) を構築し,運用・保守を行っている。これまではメインフレームを更新しながら使 用してきたが,昨年社長から情報システムのコスト削減を指示された。また,メイ ンフレームの技術者を維持することが今後困難になると想定されることから,B社情 報システム部は,基幹システムをオープン化する検討を始めた。 [B社基幹システムのオープン化〕 情報システム部は,早期にコストを削減すること,オープン系システムのノウハ ウが不十分であることなどを考慮した結果,B社基幹システムの再構築を次の2段階 に分けて実施することにした。 ・第1段階:現行システムのインフラをオープン化し,本番稼働した後,オープ ン系システムのノウハウを蓄積する。 ・第2段階:システム機能の再配置,業務処理の最適化など,業務機能を見直す。 情報システム部は,第1段階のB社基幹システム再構築(以下,本システム再構 築という)計画を取りまとめて,B社の経営会議に提案する予定である。 [本システム再構築計画に関するシステム監査〕 B社におけるシステム再構築が20年ぶりということもあり,B社監査部はコスト 超過,稼働遅れなどが発生するリスクが高いと判断し,本システム再構築計画につ いてシステム監査を行うことにした。 監査チームは,現行システムの状況及び本システム再構築計画の検討過程につい て,予備調査として情報システム部と利用部門へのヒアリングを行った。その結果 lk,次のとおりである。 (1)情報システム部へのヒアリング結果 ①現行システムの状況 ・情報システム部では,現行システム構築後,継続的に機能・画面・帳票の追 加,変更などの保守業務を行っている。 ー10一 ・現行システムのソフトウェア資産は,全て最新のソースプログラムが保管さ れている。 ・現行システムのドキュメントは,システム構築時の要件定義書,機能設計書 及び詳細設計書が全て保管されている。 ・大きな機能追加の際には,追加機能の設計書を作成している。しかし,その 他の機能変更の際には,担当者の判断でソースプログラムにコメントを追加 する場合もあるが,設計書の更新までは行っていない。その結果,設計書の 内容と実際の機能仕様・プログラム仕様とが必ずしも一致していない状態と なっており,保守業務ではテスト工程で発生したエラーの原因解析に手間取 るケースズもあるo ・情報システム部では,部員の異動に加え,各サブシステムの部分的な機能師 加,機能変更を繰り返してきたことから,現行システム全体の機能要件及び 業務要件について精通した部員がいない。 ②本システム再構築計画の検討過程 ・情報システム部の検討チームでは,数社のITベンダに本システム再構築の提 案を依頼し,提示された革つかの案を比較検討した。その結果,本番稼働ま での期間とコストを重視して,現行システムのソフトウェア資産を流用する, いわゆる“URAL”と呼ばれる方法を選択した。 ・本システム再構築の方針は,表1のとおりである。 ・表1本システム再構築の方針 再構築の方針 機能要件の変更・変更なし(現行機能を踏襲) 2|基盤・アーキテクチャ|・メインフレームからオープン系のサーバに変更 の変更・ユーザインタフェースはWebブラウザを使用 3|ソフトウェア資産の変|・原則として現行資産を流用 更ITベンダが提供するプログラム変換ツールなど でオープン系のソフトウェア資産に変換 再構築に必要な投資・最低限のコストに抑制 再構築期間 ③本システム再構築の概要 本システム再構築は,分析工程,設計工程,製造工程,テスト工程の順に実 施する。各工程における実施内容は表2のとおりである。 表2各工程における実施内容 分析・現行システムのソフトウェア資産(帳票などの定義体,JCLを含む)を調査し, 再構築対象範囲を決定する。 ・プログラム変換ツールのトライアルとして,FBICROMOTUAFTARBE し,変換の可否及び精度を確認する。 設計・プログラム変換ツールのトライアルの結果を受け,プログラム変換ツールのカス タマイズ内容や手作業で作成するプログラムの範囲を決定し,設計を行う。 ・データベースの移行については,原則として移行ツールを使用して行うが,必要 に応じてデータベースの再設計を行う。 ・0S,ミドルウェアなど,インフラの設計を行う。 製造・プログラム変換ツールによる現行システムのプログラムの自動変換を行う。プロ グラム変換ツールによる自動変換が困難なソフトウェア資産ICL ZY)は,手 作業で作成する。 ・データベースの作成,及びインフラの環境設定を行う。 テスト・和情報システム部のほかに利用部門が参画し,システムテスト及びユーザ受入テス トを行う。 ・システムテストでは性能テストのほか,現行機能が適切に踏襲されていることを 確認するために,現新比較テストを実施し,現行システムの処理結果と再構築後 のシステムの処理結果とを照合する。 (2)利用部門へのヒアリング結果 ・現行システムが利用部門の要望に合わせて機能追加,機能変更を行ってきてい ることから,現時点では大きな不満や重要な機能不足は認識されていない。 ・本システム再構築計画について,情報システム部から現行の機能要件を踏襲す るという説明を受けており,特に問題はないと認識しているので,利用部門は テスト工程から参画する計画である。 ・現行システムは構築当初から時間がたっており,その間の業務変更などによっ て,現在では使用されていない機能・画面・帳票も存在する。 ー12一 [想定されるリスクと本調査での確認ポイント〕 監査チームは,予備調査の結果を基に,本システム再構築計画に関して想定され るリスクについて検討を行い,本調査での確認ポイントを表3のとおりまとめた。 表3想定されるリスクと本調査での確認ポイント 本調査での確認ポイント 1|現行システムのソフトウェア資産をそのまま流|分析工程における情報システム部 用すると,本システム再構築のコストが過大に|の計画の詳細を確認する。 なる。 2製造工程におけるプログラム変換ツールによる|分析工程の実施内容について追加 変換作業で問題が発生し,本番稼働が遅れる。確認する。 3テスト工程における,手作業で作成したプログ|テスト工程の予備期間が考慮され ラムを含む現新比較テストが計画どおりに進ま|ているか確認する。 4現行システムから基盤・アーキテクチャが変更|適切なリスク軽減策が計画されて になることで,ユーザ受入テストの際に,シス|いるかが確認する。 テムの操作性で問題が表面化する。 5|現行システムの状況を考慮すると,本システム|情報システム部の第2段階に向け 再構築終了後に予定されている第2段階の業務|た対応計画を確認する。 機能の見直しが円滑に進まない。