『AU即効サプリ』を作成しながら - mr_sorao’s diary　2015年度システム監査技術者受験に取り組んだ記録と備忘録

　こんにちは。仕事でも私事でもバタバタしてしまい、思うように勉強がはかどっておりません(汗)　しかしそんな中で、午後1にも手を付け始めております。

　AU二度目の挑戦となる今年の午後1対策は『AU即効サプリ』を作成しながら進めております。この即効サプリというのは、今年の前半SCの勉強を行っていた時に、『ポケットスタディ』という本で出会ったものです。まぁ設問とIPA模範解答を左右に並べただけのものです。ただコイツは私にとってはなかなかの優れものでして、「問われてるポイントはわかるけど、それを30字で書けと言われてもまとめられない」というありがちな壁を打破するのに役立ったのです。

　今完成している部分を曝してしまいます。実際の表ではさらに「自分の答え」欄と「○△×」欄があります。

設問ID	分類	設問内容	IPA模範解答
H19-4-1	AU	作成された改善計画書について、必要項目が記載されているかどうかだけをチェックした。実施時期が明記されていない点について、随時実施とコメントが付記されていたので、実施時期が記載されていない理由をそれ以上は確認しなかった。不適切な点を30文字、その理由を30字(2)	(点1)実施時期が記載されていない理由を十分に確認しなかったこと (理1)フォローアップに必要な項目の記載を必ず求めるべきだから (点2)必要項目が記載されているかどうかしかチェックしなかったこと (理2)監査結果の指摘事項に沿った改善内容であるかを確認すべきだから
H19-4-2	AU	年度計画書にはフォローアップのスケジュールを明記せず、監査報告会でも具体的な実施時期について言及しなかった。問題点を40字(2)	年度計画書にフォローアップの実施時期を明記していなかったこと監査報告会を実施した時に、フォローアップの時期を明確にしていなかったこと
H19-4-3	AU	フォローアップを行う中で、システム企画部長の"システム運用保守基準書"の修正案を作成して欲しいとの依頼を受けることにした。勉強会の出席者名簿の査閲を行い改善が行われていると判断した。改善勧告には記されていないプログラムの本番移行手順についても調べることにした。不適切な内容を35字、その理由を40字(3)	(点1)"システム運用保守基準書"の修正案作成の依頼を受諾したこと (理1)監査人が自ら改善実施の主体となることは、監査人の独立性の観点から不適切であるから (点2)改善の実施状況を確認するのに勉強会の出席簿だけで判断したこと (理2)出席者数を確認しただけでは、周知徹底の状況は確認できないから (点3)改善計画書に記載されていない本番移行手順について調査を行ったこと (理3)フォローアップでは、改善勧告の実施状況を確認するのが目的であるから
H21-4-1	AU	コントロールの整備状況と運用状況の評価を行う監査において、内部監査部への移動の直前に深く関与し、システムについても保守についても熟知しているシステムを監査対象に選定した。また抜き打ち方式で行うこととした。問題点を40字(2)	移動直前に対象システムの開発に関与しており、監査人の独立性が不十分である抜き打ち方式は、コントロールの整備状況と運用状況を評価する監査には不適切である
H21-4-2	AU	移行計画に基づき、開発部門とユーザー部門で合同リハーサルを実施し、発生した問題点を解決する修正を行った移行計画書を承認した。移行計画書のレビューが行われていなくても不備にはあたらないとした理由を45字	ユーザー部門と開発部門の合同リハーサルは、ユーザ部門のレビューの代替的統制と考えられるから
H21-4-3	AU	要件定義書は開発部門の責任者がユーザー部門の責任者にコピーを送付している。業務処理量の見積もりは、過去の実績データを基に開発部門が行っている。問題点を35字(2)	ユーザ部門に要件定義書のコピーを送付するだけで、承認を得ていないユーザ部門に将来の業務処理量の予測を確認すべき
H21-4-4	AU	テスト段階で発見された問題点の全てに対して、原因が究明され、解決されていることを確かめる監査手続きとして「テスト担当者に質問して確認する」が不適切な理由を50字	テスト担当者への質問だけでは、すべての問題点が適切に対応されたことの確証が得られないから
H18-3-1	SM	システム開発部は、ユーザ部門に詳細な要件を確認後、プログラム変更要件定義書を作成する。システム開発部の責任者の承認後、これに基づいてプログラム開発及びテストを実施する。システム開発部におけるテスト終了後、UATが実施される。ただし、システム開発部においてユーザ影響度が低いと判断した場合はUATは省略され、電子メールでプログラムのリリースが通知される。問題点を50字(2)	プログラム変更要件定義書についての承認が、システム開発部の責任者だけであり、該当ユーザー部門の承認がない UATの省略について、システム開発部の判断だけで実施しており、該当ユーザ部門の承認がない
H18-3-2	SM	プログラムを変更した場合に、関連仕様書を修正すべきであることが、定められていない。リリース用ライブラリに移行したプログラムは、削除されるまでの間、開発担当者によって更新可能である。放置した場合にはどのようなリスクがあるか50字(2)	プログラムと仕様書に不整合が発生し、その後のプログラムの修正作業に誤りが起きやすくなるリスク開発担当者が不正なプログラムをリリース用ライブラリに移し、本番でそれが実行されてしまうリスク
H18-3-3	SM	システム開発部は、障害や誤作動の調査を本番環境において調査する。このとき、システム運用部が管理しているOS及びデータベースに関する原因調査用のアカウントとパスワードを使用する。システム運用部はどのようなコントロールを実施すべきか50字	システム開発部が使用したOS及びデータベースのアカウントのパスワードを変更する
H18-3-4	SM	修正作業中のプログラムに、本番環境で重大なバグが発見された。システム開発部は「緊急時のプログラム変更の手順」で修正を行い本番環境に反映させた。その後、修正を完了させたプログラムが通常のプログラム変更手続きに従って本番環境に移行された。しかし移行されたプログラムには緊急対応時に対応したバグの修正が反映されていなかったので、対応したはずのバグによる障害が再発した。どのような対応策をとるべきか60字	ライブラリ管理プログラムを導入し、修正中のプログラムに対する別の修正が発生したときに発見できるようにする。同一のプログラムに対する別作業での変更の有無が判断できるように、プログラム単位の修正の履歴簿を作成して管理する。
H24-4-1	SM	移行作業を行うために作成された移行タイムチャートが、移行リハーサルの処理時間に比べて余裕があることを確認した。更に確認すべき事項を35字	移行リハーサルを実施したときの条件は、本番移行時と同じ条件か
H24-4-2	SM	新シストのシステムテストにも使用されていた移行用プログラムは、データの不備が発見されるとその都度、プログラムを修正して対応していた。考えられるリスクを25字、実施する必要のある監査手続きを40字	本番移行後のデータに不具合が発生するリスク修正された移行用プログラムの結合テストの実施を、テスト結果報告書で確認する
H24-4-3	SM	顧客マスタには、過去の売上実績や与信情報に基づいて設定される項目「顧客ランク」が追加される。移行結果の確認において追加すべき確認内容を二つ45字	移行データの処理結果の確認時に、処理件数が現行データと一致していることを確認するサンプルを何件か画面表示し、「顧客ランク」が適切に付加されていることを確認する
H24-4-4	SM	移行手順書には、移行作業中に思わぬトラブルが発生したときの連絡体制及び責任者は明記されていた。移行の中止または継続に関する確認すべきコントロールを30字	移行を中止する場合の判断基準が明確になっていること
H24-3-1	SM	ヘルプデスクは、過去の障害対応が記録されているデータベースを参照するなどして対応する。その結果、問題を解決できた場合は、そこで問題対応を完了する。システム障害がシステム障害報告書に記載されない可能性のあるケースを30字	障害が保守チームに報告されず、対応が完了したケース
H24-3-2	SM	システム障害報告書には、再発防止策の実施予定日と、承認者の署名欄がある。再発防止策が権限者の承認後に実施されていることを確かめるために追加すべき項目を二つ20字、運用状況を確認するための手続きを45字	承認者が承認を行った日付再発防止策が実施された日付月次ミーティングの議事録で開催日及び出席者を確認し、パッチ適用のシステム日付と比較する
H24-3-3	SM	データベースに最新のパッチを適用していなかったことが原因で発生した障害。システム担当者は、「当社では同様の障害が発生していないので適用する必要はない」と判断した。根本的原因が何であるかを調査するための手続きを50字	システム担当者にインタビューを行い、最新のパッチを適用しなかった理由を確かめる
H24-3-4	SM	システム障害報告書は、月次ミーティングにおいて報告され、原因分析や再発防止策の適切性について協議される。再発防止策は、システム運用責任者が、ミーティングの結果を受けて承認した後、実施される。この手順で「対応できないケース」を40字	再発防止策を月次ミーティング前に実施しなければならないケース
H20-1-1	SM	システム運用部基盤課の担当者は、運用スケジュール表を受領すると、内容を確認の上、運用支援ツールへの登録を行う。登録後、運用支援ツールから出力される登録結果リストと運用スケジュール表を基盤管理課長に提出する。基盤管理課長は、登録結果リストと運用スケジュール表を照合して、一致を確認する。予定した作業が漏れなく正確に登録されていることを保証するコントロールを40字	基盤管理課長による登録結果リストと運用スケジュール表の照合を行う
H20-1-2	SM	運用支援ツールへのオペレーション登録が間に合わなかった場合、オペレータは本番作業依頼票に記された作業を実施する。監視端末をコマンドモードに切り替えてコマンドを投入する。実施された作業内容は運用監視システムのログファイルに記録されている。オペレータはオペレーションログの関連部分をプリントし、本番作業依頼票と一緒にオペレータ管理者に回付する。オペレータ管理者は回付されたログの内容を見て、問題がなければ本番作業依頼票に承認印を押す。オペレータの作業に係わるリスクが十分に低減されていない。どのようなリスクか50字、このリスクを低減するコントロールを55字	オペレータが本番作業依頼票で指示された以外の作業を本番機で行っても発見されないリスク依頼された作業だけが行われているか、オペレータ管理者が自ら出力したオペレーションログで確認する
H20-1-3	SM	アプリケーションの本番リリース依頼書に障害関連メッセージが記されていた場合、リリース担当者が運用監視システムのメッセージライブラリにメッセージを登録する。基盤管理課長は、運用監視システムから出力される登録内容表と本番リリース依頼書の内容を照合し、問題がなければ本番リリース依頼書に承認印を押す。このコントロールの運用状況の評価を行うために、ファイルされた本番リリース依頼書から一部をサンプリングし、基盤管理課長の承認印を確かめた。この監査手続きだけでは、運用状況を評価する上で不十分である。その理由を50字、実施すべき監査手続きを55字	基盤管理課長の承認印の確認だけでは、課長が照合を怠った場合の不一致を発見できないから本番リリース依頼書と添付の登録内容表を照合し、記録されたメッセージが一致することを確認する