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

共通の文章

チャットボット開発の企画段階における監査に関する次の記述を読んで,設問1~ 4に答えよ。 A社は,家庭用品を製造・販売している企業であり,顧客からの問合せに対応する ためのコールセンタを自社で運用している。コールセンタでは,問合せ集中時の対 応の遅れや品質のばらつきが課題となっている。他社のコールセンタで,チャット ボットを導入して効果が出ている事例があることから,A社はコールセンタへのチャ ットボットの導入を検討している。 A社は,チャットボットの開発・利用経験がないので,ITベンダの協力を得て開発 する計画である。監査部は,コールセンタでのAlの利用は業務運営,顧客サービス などに大きな影響を与える可能性があると考え,システム監査を実施することにし た。しかし,チャットボット開発の監査経験がないので,社外のシステム監査人M 氏に監査チームへ参画してもらい,助言を受けながら監査を実施することにした。 [コールセンタの概要〕 コールセンタは,電話や電子メールを用いて,顧客からの問合せ対応やアフター フォローを行っている。コールセンタの運営は,着呼の自動振分け,顧客に関する 情報照会,対応記録の一元管理,稼働状況に応じしたオペレータへの着呼の割当て,通 話録音などの機能をもつコールセンタシステムで支援されている。 〔チャットボット開発の概要〕 監査チームは,予備調査として,コールセンタとシステム部にヒアリングを行い, 関係資料を閲覧した結果,次の情報を得た。 (1)チャットボットの機能 コールセンタとシステム部が協議して,オペレータを支援する機能の強化とし てチャットボットを導入することとした。チャットボットは,AIを利用した音声 認識と自然言語処理によって,対応中の顧客の発言の趣旨を解析し,オペレータ に回答候補を提示する。 (2)構想立案と概念実証 コールセンタとシステム部が協議した内容を構想立案書としてまとめ,次に, ー2一 概念実証(以下,PoCという)の実施に当たりPoC計画書を作成した。 コールセンタは,コールセンタへ問合せのあった顧客の音声(以下,学習デー タという)とオペレータの回答音声(以下,教師データという)の1か月分を準備 した。システム部は,学習データと教師データの全件をAIに学習させ,PoCの実 施結果をPoC評価書としてまとめた。 (3)要件定義以降の開発計画 システム部は,PoC評価書を踏まえて,ひとまず開発概要書を作成し,要件定義 に向けた準備を進めている。一方,PoCの実施結果に一部想定外の状況が発生して いるので,FoCを継続して実施する予定である。チャットボット開発の流れは図1 のとおりであり,現在はPoC工程の途中の段階である。 現在の工程 OED a, aie BtE ON iat KEN AE SS | 図1チャットボット開発の流れ なお,開発概要書には,次のとおり記述されている。 ①システム部が開発し,コールセンタはテスト工程で操作性などを確かめる。 ②FATEH,学習データと教師データを3か月分に増やして学習させ,結 果を評価し,想定した結果が得られた場合には本番移行が承認される。 ③本番移行工程では時間が限られ,直前のテスト工程では結果が評価されるこ とから,学習データと教師データの量を6か月分に増やして学習だけを行い,本 番運用を開始する。 (4)オペレータ教育 開発概要書には,オペレータ教育について,“現行のマニュアルの中で操作方法 が変更になる箇所だけを更新し,業務の繁閑を考慮しながらオペレータを教育す SB”と記述されている。 〔監査チームが想定したリスク〕 監査チームは,チャットボット開発のリスクを次のとおりまとめた。 =直ら (1)構想立案工程のリスク AIの利用は経営や業務へのリスクがある。導入目的や利用範囲について,経営 会議よどの審議を経て経営層が承認するプロセスが必要である。 (2)PoC工程のリスク PoCの計画策定時に評価基準が不明確な場合には,実施結果の良否判断ができず, PoCの終了を判断できないリスクがある。また,評価結果が不明確な場合には開発 計画が不確実になり,期待どおりのチャットボットを開発することができないリ スクがある。そのため,PoCの計画策定では,実施の目的,結果の評価基準及び終 了ラ基準を定める必要がある。PoC工程実施後は,計画で定めた評価基準及び終了基 準を満たしているかを明確に評価する必要がある。 (3)学習と評価のリスク チャットボットの学習では要求される品質を満たす学習データと教師データを 選定,準備し,必要な各工程で学習させないと,チャットボットが適切でない回 答をするリスクがある。学習後は,結果が正しいかどうかを評価する必要がある。 (4)オペレータ教育のリスク オペレータ教育が不十分な場合にはAIが示した誤った結果をそのまま顧客に回 答するリスクがある。AIが示す結果は常にた正しいとは限らないので,結果の利用 可否を人が判断する必要がある。チャットボットについても同様で,操作方法の 変更だけでなく,結果の正しさや利用可否をオペレータ本人が判断すべきである ことを教育する必要がある。その際,オペレータ教育の内容や実施計画の妥当性 を事前に考慮することが重要である。 (M KOS) 監査チームは,想定したリスクを踏まえて作成した監査手続書について,M Ric 助言を求めた。M氏の助言は次のとおりである。 (1)監査手続としてAIに関する開発原則を確かめるだけでは不十分であり,追加の 手続が必要である。 (2)開発概要書を作成しており,PoCを継続実施する計画になっている。今後のPoC の評価が不明確な場合は開発が遅延するリスクがある。PoCの計画と実施について の監査手続が必要である。 ae= (3)開発概要書を見る限り,本番移行工程には問題がある。本番運用において期待 効果が得られない可能性があるので,詳しく調査する必要がある。 (4)オペレータ教育について,教育内容や実施計画が不十分なので,詳しく調査す る必要がある。 〔修正した監査手続書〕 監査チームはM氏の助言を踏まえて,表1のとおり監査手続書を修正した。 表1修正した監査手続書(抜粋) (1)|AIに関する開発原則は明確か。各種規定などを閲覧して,Alに関する開発 原則を確かめる。 Alの導入目的や利用範囲について,経営層 が判断,承認しているか。 適用範囲の決定過程や利用部門の参画は適|構想立案書を閲覧して,該当の記述や利用 切か。部門の開発への参画状況を確かめる。 (2)|PoCの計画と実施は適切に行われているか。|計画について, 3)|要求品質を満たした学習データと教師デー|構想立案書,PoC計画書,開発概要書を閲覧 タを準備しているがか。して,学習データと教師データの適切性の 評価プロセスを確かめる。 テスト,本番移行及び本番運用の各工程で|構想立案書,開発概要書を閲覧して,テス 学習と評価を考慮しているか。ト,本番移行及び本番運用の各工程でのデ ータの準備・学習・評価の計画を確かめる。 (4)|Alの特性を踏まえたオペレータ教育の内容|構想立案書,開発概要書を閲覧して,オペ を検討した上で,実施計画の妥当性を考慮|レータへの教育内容や実施計画の妥当性を しているか。確かめる。

共通の文章

システム再構築プロジェクトの企画段階の監査に関する次の記述を読んで,設問1 と4に答えよ。 B社は,中堅の保険会社である。B社の情報システムは,構築時から長い間利用し て老朽化しているシステムが多いので,3年ほど前から順次再構築を実施し,基幹系 システムの再構築がほぼ終了した。次に,周辺システムのうち,ハードウェアのサ ポート切れが近づいている営業支援システムを再構築することになり,新たに“営 業支援システムの再構築プロジェクト"(以下,当プロジェクトという)を立ち上げ, プロジェクト計画書(以下,計画書という)を作成したところである。B社の営業支 援システムは,モバイルPCの活用を進めた十数年前に構築され,新商品への対応や 利便性の向上のために,何度も改修が行われてきた。 これまで,B社の再構築プロジェクトでは,開発期間の長期化や予算の超過などの 事例が幾つか発生している。そこで,監査部では,当プロジェクトを監査対象とし て,再構築計画の適切性についてシステム監査を実施することにした。 〔当プロジェクトの体制 当プロジェクトは,システム部で営業支援システムの保守を担当しているT課長が プロジェクトマネージャ(以下,PMという)を務めており,システム部のメンバ3 名を含めたシステム化検討チームが計画書をまとめている。また,利用部門の代表 である営業統括部のS課長とメンバ2名が,業務チームとして業務要求の取りまとめ を行っている。 当プロジェクトは,BA,PMが検討の状況そプロジェクト運営委員会に報告して いる。プロジェクト運営委員会は,営業担当役員,システム担当役員,営業統括部 長,システム部長及びシステム企画課長で構成されている。 (再構築計画の検討状況 B社では,これまでの基幹系システムの再構築で実施された手順を整理した“再構 築実施要領”が作成されている。当プロジェクトは,この“再構築実施要領”に従 い,次のように営業支援システムの再構築計画について検討を進めた。 1)現行システムの調査・分析 2 8 ie システルム化検討チームは,現行の営業支援システムの基本設計書を基に機能一 覧を整理した。 2)新システムの業務要求の洗い出し,優先順位付け 業務チームは,主な営業店や本社部門の各部にヒアリングを行い,再構築する 営業支援システムの業務要求を“業務要求一覧"としてまとめた。利用部門の担 当者からは,現行システムに大きな不満はなく,業務を大きく変えるようなシス テム機能の変更は避けてほしいという意見が多かった。 (3)再構築方式の検討 “再構築実施要領"には,標準的に定めた3方式の中から評価項目を定めて評価 した上で,最適な方式を選択することが定められている。再構築方式の概要は, 表1のとおりである。 表1再構築方式の概要 リホスト|現行のソースプログラムをその|・短期間,低コストで再|・新たな業務仕様の取込 まま利用し,クラウドサービス構築が実施できる。みは困難である。 上のシステム基盤に構築する。 リライト|業務仕様をそのまま利用し,ク|・新言語への書換えは,・新たな業務仕様を取り ラウドサービス上のシステム基過去のツールが活用で込もうとすると,追加 盤に適合した言語に現行のソーき,比較的短期間,低コストが発生する。 スプログラムを置き換える。コストで再構築が実施 できる。 リビルド|業務仕様を変更し,クラウドサ|・新たな業務仕様を実現|・業務仕様の検討やテス ービス上のシステムラ基盤に適合|できる。トに大きな工数が掛か した言語で新しくソースプログり,高コストになる。 ラムを作成する。・開発期間は,ほかの方 式より長くなる。 [予備調査の結果 監査部では,当プロジェクトで作成された計画書を閲覧し,内容が不明な点や記 載が暖昧な箇所について,T課長にインタビューして確かめた。その結果,次のこと が分かった。 (1)営業支援システムの主管部署は営業統括部であるが,現行システム構築時の担 当者は退職しており,営業統括部やそのほかの利用部門には,営業支援システム の業務機能の全体を把握している従業員がいない状況である。また,現行システ ーー7 es ムの開発を担当したベンダも既に保守業務から撤退し,現在は別のベンダが保守 を担当している。しかも,保守用のドキュメントが不足しており,システム部に もシステム全体を理解している担当者がいない状況である。 (2)業務チームがまとめた“業務要求一覧"は,現行システムに対する改善要望が 中心なので,現行システムから変更不要な機能については,“現行どおり"と記載 されている。 (3)基幹系システムの再構築プロジェクトの実施時,経営陣からはコストの最適化 を求められていた。一方で,営業支援システムは,今後B社の重要な戦略を担うシ ステムであり,特に,対面販売を代替することができる営業支援システムの実現 を早期に達成する,というビジネス目標が,経営陣から提示されている。 (4)B社のシステム構築に関わる規程の中に“システム投資規程"があり,予算額に 応じた決裁権限者などが定められている。 (5)業務チームの検討結果を踏まえ,当プロジェクトは,リライト方式を選択して クラウドサービス上のシステム基盤に新システムを構築する方針で計画書を作成 し,プロジェクト運営委員会への提出書類を準備中である。 〔本調査の計画] 予備調査の結果を踏まえ,監査部では,本調査の監査手続書を作成するために, 当プロジェクトの企画段階でのリスク及びコントロールを表2のようにまとめた。 表2企画段階でのリスク及びコントロール(抜粋) ①|企画段階での体制|・IT投資の意思決定に必要な情報が意|・プロジェクト運営委員会に| の妥当性思決定権をもつ者に適時に集約されIT投資の意思決定権をもつ ない。者が参画している。 ②|ビジネス目標に合|・コストを必要以上に削減した結果,・コスト削減だけでなく, 致したシステム再ビジネス目標に合致しないシステム|様々な角度から評価して再 構築計画の妥当性になる。構築方式を決定している。 @|要件定義の有当性|.wate|ァ|]・残すべき現行機能を明確に a 4 ・テスト工程:テストが計画どおりにを 進捗せず,品質低下やスケジュール|てNo 遅延を引き起こすおそれがある。° ®|企画段階の検討範|・新しいシステム基盤に依存する事項|・有識者によるプロジェクト 囲の十分性について検討漏れがあり,開発段階|計画のレビューを実施して で追加コストが発生する。いる。 es 8 mii 監査部で検討している本調査の概要は,次のとおりである。 (1)表2項番①について,プロジェクト運営委員会のメンバと,“システム投資規程" の決裁権限者とが整合しているかどうかを確認する。 ②⑫)表2項番②について,計画書の内容を見ると,コストに関する記述が中心で,再 構築方式を決定するまでの検討が不十分ではないかという懸念がある。そこで, リスクに対応したコントロールが当プロジェクトの中で適切に検討されているか どうかを確認する。 (3)表2項番$のリスクについて,計画書の内容を見ると,“現行を踏襲する"機能 については,要件定義書にも具体的な要件は記載せず,“現行どおり"と記載する 計画になっている。[予備調査の結果〕(1)で判明した事実を考慮すると,設計工程 及びテスト工程で問題が発生するリスクがある。 (4)表2項番のについて,リライト方式の具体的な手段として,現行のCOBOLから 新しいシステム基盤の構築言語である]avaへの変換ツールの採用が検討されてい る。このツールは,基幹系システムの再構築時に利用したもので,生産性向上が 見込めるものである。ただし,システムを稼働させるためには,ソースプログラ ムの変換だけでなく,新しいシステム基盤でやるクラウドサービスの機能に依存 する事項の検討が十分かどうかを確認する。

共通の文章

結合テストの監査に関する次の記述を読んで,設問1ー5に答えよ。 産業用機械メーカのC社は,20年以上前にホストコンピュータ上に構築した現行 の基幹システム(以下,現行システムという)を刷新するために,BE,VATA 再構築プロジェクト(以下,当プロジェクトという)を進めている。 現行システムは,販売管理,生産管理,購買管理の各業務システムから構成され ている。現行システムの構築当初は人事給与及び財務会計の業務システムも実装さ れていたが,これらについては,3年前にオープン系のパッケージシステムム移行済 みである。当プロジェクトは,現行システムを構築したP社に委託し,1年前からオ ープン系システムとして再構築に取り掛かっている。 C社監査部は,当プロジェクトの重要性に鑑み,システム部での勤務経験があるD 氏が中心となり,これまでにプロジェクト計画段階,要件定義完了段階のシステム 監査を実施している。当プロジェクトは,現在,結合テストの終了段階に入ってお り,監査部は,最終のテスト工程であるシステムテスト開始前に,結合テストの完 了評価の適切性について,システム監査を実施することにした。D氏を含む監査部メ ンバは,当プロジェクトの関係者にしアリングするとともに,関連資料を閲覧した。 (Feat ie) 当プロジェクトは,OBER,②設計,⑧製造/単体テスト,④結合テスト, ⑤⑥システムテスト,⑥⑯移行という工程になっている。P社との委託契約は,②設計て ③④結合テストは請負契約であり,①要件定義システムテスト,@移行に関して は準委任契約である。 C社は,業務システムごとの結合テストを完了した後,システムテストにおいて, 業務システム全てを連携させたテストとユーザ受入テストを行う計画である。 〔開発体制〕 当プロジェクトの開発体制は,図1のとおりである。システム部では,現行システ ムの運用と保守を中心に行ってきたので,新規のシステム開発のノウハウが不足し ている。そのため,実質的には,要件定義の段階からP社が中心となって開発プロジ ェクトを進めており,システム部が,P社開発成果物のレビュー・承認,C社利用部 ー10一 門との仕様などの調整を担当している。 プロジェクト管理については,システム部長がプロジェクトマネージャ(以下, PMという)として全体を統括し,システム企画謀がプロジェクト全体の運営事務局 (以下,PMOという)LUT,P社の開発リーダ及びプロジェクト管理チームと連 携して,進捗管理,品質管理,課題管理などを行っている。 C社システム部 システム課システム課システム課(PMO) P社 管理チーム 開発チーム開発チーム開発チーム M1当プロジェクトの開発体制 〔PMへのヒアリング]〕 監査部が,結合テスト完了評価の実施方法及び実施結果について,PMにヒアリン グした結果,次のことが分かった。 (1)P社の各開発チームは,P社のプロジェクト管理チームが作成した結合テスト完 了基準に従って,各業務システムの結合テスト完了評価を行い,結合テスト完了 評価報告書を作成した。 (2)PMOは,結合テスト完了基準の内容を確認した上で,完了ラ基準未充足の項目が ないかどうかを確認したが,特に問題点は見つかっていない。システムテストも 引き続きP社の協力を得て実施する予定であり,懸念点はないと考えている。 (3)生産管理システムの結合テストで進捗の遅延が一時的に発生したが,これは, マスタデータの作成ミスによって一部テストのやり直しが発生したことが原因で ある。システムテストで同様の事象が発生するとシステムテスト全体の進捗にも nf= 影響が出るので,課題として指摘し,P社に再発防止を要請した。 [結合テスト完了基準と完了評価結果] 結合テスト完了基準と根拠資料は表1のとおりである。 表1結合テスト完了基準と根拠資料 評価項目根拠資料 テスト項目を全件消化していることEMR 2品質残不良件数が0件であること不良管理表 次の品質指標が基準範囲内にあること,Mit,基準範囲内に|品質評価結果 ない場合は,その理由が明確であること ・不良密度(不良発生件数プ/システム規模) ・テスト密度(テスト項目数プシステム規模) 発生した不良の原因分析を行い,品質向上策が実施済みであ|品質評価結果 ること 3|課題結合テストで発生した課題の対応が全て完了していること,|課題管理表 又は,残課題がある場合は,対応内容,対応期限が明確であ Se 各業務システムの結合テスト完了評価報告書では,“全ての完了基準を充足してい BOC,結合テスト完了に問題ない。”と評価されていた。そこで,監査部が各業務 システムの結合テスト完了評価の根拠資料を閲覧したところ,次のことが分かった。 (1)販売管理システムの品質評価結果では,“不良密度は基準範囲を下回っつている。 LAL,テスト密度が基準範囲内であり,テスト項目数が十分であること,類似 不良の点検も実施済みであることから,品質には問題ない。"とされている。 (2)生産管理システムの品質評価結果では,“財務会計システムとの疎通確認テスト で不良が発生したことによって,不良密度が基準範囲を上回っている。しかし テスト密度は基準範囲内にあること,テスト項目はエラーケースも含めて質的に 十分であること,Hk,チーム内で類似不良についての品質向上策を実施済みで あることから,品質には問題ない。"とされている。 (3)購買管理システムの課題管理表では,結合テスト実施中に発見された生産管理 システムとのインタフェース機能の仕様漏れについて,“プログラム修正とチーム 内のテストは完了済み。生産管理システムと接続させての確認はシステムテスト で実施予定。'”とされていた。 なお,システムテストは,環境を整備するための準備期間が計画より長くなり, 余裕の少ないスケジュールとなる見込みである。 [追加の確認事項と検討事項 関係者へのヒアリング及び関連資料の閲覧の結果を踏まえ,D氏は,システム部に よる結合テスト完了評価結果に関するリスクを洗い出し,追加の確認事項と検討事 項を次のとおり整理した。 (1)販売管理システムの品質評価結果では,問題がない理由としてテスト項目数が 十分であることを評価しているが,それだけでは不十分なので,追加で確認する。 @⑫)生産管理システムで発生した課題について,システムテストに向けて適切に対 応が行われているかどうかを確認する。 (3)生産管理システムの品質評価結果に記載されている類似不良の品質向上策に関 LC,財務会計システムは他業務システムともインタフェースがあることから, プロジェクトとしての対応が適切かどうかを確認する。 (4)購買管理システムと生産管理システムとのインタフェース機能の残課題につい て,システムテストでのリスクを低減するための改善提案を検討する。 (5)【工程計画]の内容を踏まえ,今後のシステムテストにおける当プロジェクト の体制に問題がなかいかどうかを確認する。