応用情報技術者 2013年 秋期 午後 問11

　 　G社は、機械部品を製造販売する中堅の上場企業である。最近、G社の監査部員がシステム監査に関する外部セミナに参加し、ソフトウェア保守の不適切な管理にまつわるリスクについての知識を得た。監査部では、G社の管理が適切かどうかを確認するために、基幹システムのソフトウェア保守について監査することにした。 　 〔ソフトウェア保守の現状〕 　G社は、生産・販売・購買・会計の業務を統合的に扱うクライアントサーバ型の基幹システムを使用しており、そのソフトウェア保守はシステム部システム課の課長を含めた4名の社員で対応している。作業の手順は次のとおりである。 　(1) ソフトウェア保守が必要な場合は、利用部門の担当者が変更要求書を作成し、利用部門の責任者の承認を得た後、システム課に電子メールで提出する。変更要求書への記載内容は、作成年月日、作成部門、作成者、該当システム、理由、内容、希望納期、緊急度である。 　(2) システム課では、変更要求書を受け付けると、担当者が、システム設計書とプログラム設計書を基にして、プログラムの変更箇所を調査する。調査では、プログラム変更内容と他システムへの影響をチェックし、作業工数を算出する。調査結果をレビューして、システム課長が変更要求を承認する。 　(3) システム課の担当者は、承認された変更について、システム設計書、プログラム設計書及びプログラムを変更し、その後システムテストを実施する。システムテストの計画と結果は、システム課長が承認する。 　(4) システムテスト後に実施する受入れテストには、利用部門も参画する。受入れテストの計画と結果は、利用部門の責任者及びシステム課長が承認する。 　(5) システム課の担当者がプログラムの本番移行計画を作成し、システム課長が承認する。承認が得られた後、変更前のプログラム及びデータのバックアップを取得し、プログラム変更者自身がプログラムを本番環境に反映させて、作業を終了する。システム課では、受付順に(2)～(5)の処理を行っている。 　　この手順をまとめると、図1のとおりになる。

〔監査の留意点〕 　今回の監査を担当する監査部のメンバ（以下、監査チームという）は、基幹システムのソフトウェア保守の監査方針として、管理の適切性に加え、業務の効率向上の観点からも監査を行うことにした。 　また、外部セミナでの次のような他社事例も念頭におくことにした。 　・ソフトウェア保守に関する手順が守られておらず、誤った手順で行われた場合や誤った作業が行われた場合の発見的コントロールが考慮されていなかった例 　・監査人が、被監査部門とのインタビュー内容を誤解したまま監査を進めた結果、監査意見が誤ったものになってしまった例 　・監査人が、真の原因を把握せずに監査を進めた例 　　以上を受けて、監査チームは個別監査計画を文書化し、監査部長がこれを承認した。 　 〔インタビュー結果〕 　監査チームは、ソフトウェア保守作業の状況を把握するために、利用部門とシステム課にそれぞれインタビューを行った。システム課のインタビュー時、①システム課長が、以前、部下であった監査チームのH君に、細かな問題点は指摘しないよう依頼していた。

　(1) 利用部門へのインタビュー結果 　　・要求した機能を漏れなく実装してくれるので、とても助かっている。 　　・法規制や顧客からの要望など急いで対応しなければならないものもあるが、時間が掛かってしまうことがある。 　　・変更を行った結果、別の箇所に不具合が出たり、レスポンスが悪くなったりすることがある。

　(2) システム課へのインタビュー結果 　　・利用部門の要望にできるだけ応えるようにしているが、変更要求書の数に変動があり、件数が多い場合には、利用部門の希望納期までに対応できないことがある。 　　・ソフトウェア保守は、少人数で対応できるようにしており、通常は1人で担当することが多い。 　　・担当者によって変更箇所の調査手順が異なっており、調査項目の漏れがあって、本番環境への反映後に不具合が発生することがあった。原因はリグレッションテストの不備にあると考え、この対策として、最近リグレッションテストを強化した。 　 〔文書のレビューと評価・結論〕 　監査チームは、インタビューに加えて、ソフトウェア保守作業の過程で作成又は変更された文書のレビューを行った。さらに、他社事例も念頭において、インタビューで発見されなかった問題点がないかどうか、監査人が誤解していないかどうかについて、十分に確認した上で、改善勧告を次のとおり行った。

　(1) 監査チームは、急を要する変更要求の希望納期に応えられない場合があることを問題点として指摘事項に挙げることにした。また、ソフトウェア保守作業の手順に工夫を加えることによって、現行の人数でも、緊急度が高い変更要求について、利用部門へのサービスレベルを落とさずに対応することが可能であると考えて、②改善勧告を行った。 　(2) 変更箇所の調査における問題点については、③既に開始したリグレッションテストの強化では対策として不十分と考えて、変更箇所の調査手順を標準化するという改善勧告を行った。 　(3) 本番環境へのプログラムの反映における内部統制上の問題点を指摘した。この対策として、④予防的コントロールと発見的コントロールのそれぞれの観点から改善勧告を行った。