mr_sorao’s diary 2015年度システム監査技術者受験に取り組んだ記録と備忘録

2015年度情報処理技術者試験 システム監査技術者に取り組んだ記録と備忘録

AU速攻サプリの公開

無事に合格できました! もう嬉しくて嬉しくて堪りません!

f:id:mr_sorao:20150619122303j:plain

 今回のAU受験において作成いたしました午後1対策用のツールAU速攻サプリ」を公開いたします。
 ツールと言っても大それたものではありません。午後1問題の設問要旨とIPAの模範解答を左右に並べたエクセルシートです。
 このツールのアイデアも、私のオリジナルではありません。SC受験時に出会った参考書「ポケットスタディ 情報セキュリティスペシャリスト」に載っていた「速攻サプリ」のAU版を作成したに過ぎません。

<このツールでは出来ないこと>

AUの専門知識や合格に必要な前提知識の習得は出来ません。これにはやはり市販の参考書などが必要になるかと思います。

・問題文の中から解答のヒントとなる記述を素早く正確に見つけ出す力。これが午後1攻略で最も大切なことだと思うのですが、このツールでは会得できません。この力を磨くには机に向かって時間を計りながら過去問に取り組む以外に方法は無いと思っています。

・問題文や設問の効率的な読み方や時間配分に関する攻略テクニックなどは、このツールでは会得できません。攻略テクニックに関しては「情報処理教科書 高度試験 午後Ⅰ記述」などが参考になるかと思います。

<このツールで出来ること>
(自画自賛で申し訳ございません)

・何が問題となっているかは判るけど、うまく30文字にまとることが出来ない。IPAの模範解答に比べると自分の解答に記述不足が目立つ。こういう症状の改善に効果があると思います。

・最初はきちんと机に向かって取り組むのがベストだと思います。一度机に向かって解いた問題をスピーディーに再練習するのにこのツールはとても便利です。また、仕事に忙しくてキチンと問題を解く時間がない、過去問練習は進んでいないのに明日はもう本試験だ、なんて方へのカンフル剤としても役立つかもしれません。

・午後1解答に必要な独特の日本語の言い回しを会得できます。

<このツールの画期的なこと>
(またも自画自賛で申し訳ございません)

・このツールを使えば隙間時間を利用してスピーディーに午後1対策が出来ます。冒頭の写真は私が実際に使用したものです。私はこれを胸ポケットに忍ばせて、通勤ラッシュの電車の中で午後1対策を行いました。試験日当日も、お握りを頬張りながらこいつのページをめくっていました。

<その他(著作権etc)>

著作権などは主張いたしません。元々IPAの公開資料をまとめただけのものですしね。
・このツールを使って合格する方が現れて、こいつの保守後バージョンをどこかで公開して下さったらとても素敵なことだなと、ひそかに夢を見ております。

<ダウンロードサイトへのリンク>

googleクラウドサービスを使っての公開ですので、Chrome以外のブラウザでは上手く表示されないかも

https://drive.google.com/file/d/0B0vqF_uMCZ_wNE5MLWNNQTlTUE0/view?usp=sharing

それではさようなら。AU受験の皆さまのご健勝を祈りながら

 

 

 

情報処理教科書 高度試験 午後I記述 春期・秋期

情報処理教科書 高度試験 午後I記述 春期・秋期

 

 

情報処理教科書 午後Ⅰ記述 を読み始めました

 「情報処理教科書 高度試験 午後Ⅰ記述」を買いました。まだ読んでいる途中なので、現時点での感想だけサラッと書きます。
 内容は「午後1で60点を取るための対策集」といった所です。100点を取るための問題の解き方、ではない所が "肝" かもしれません。つまり90分2問の勝負に勝つ、という明確な目標を乗り越えるための対策です。
 解法テクニックそのものに関しては、既刊の「PM情報処理教科書」に書かれているものに近い内容ですが、それを全区分に共通する部分と、各区分独自の工夫に分けて整理されている所が美味しいです。個人的感想としては、区分独自の部分がもっと厚いと嬉しかったのですが、全区分対応版というこの本のスタイルを考えればこれが限界なのでしょうね。そうそう、「AU情報処理教科書」の午後1の解説に目を通した方ならお馴染みの図、問題文の何処に何が記述されているのかを整理したあの図の有効性を再確認することも出来ました。
 意外と(失礼)面白かったのは、色々な区分に合格している達人達へのインタビュー記事です。解説されている解法のポイントごとに、「あなたはこの部分どうしているの?」という問いかけに10数人の達人が答えているのです。その内容には個人差の大きい部分もあり、共通部分もあり、本文には載っていない独自の考えもありで貴重な情報源になりました。

 

情報処理教科書 高度試験 午後I記述 春期・秋期

情報処理教科書 高度試験 午後I記述 春期・秋期

 

 

『AU即効サプリ』を作成しながら

 こんにちは。仕事でも私事でもバタバタしてしまい、思うように勉強がはかどっておりません(汗) しかしそんな中で、午後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字 基盤管理課長の承認印の確認だけでは、課長が照合を怠った場合の不一致を発見できないから
本番リリース依頼書と添付の登録内容表を照合し、記録されたメッセージが一致することを確認する

今期の初論文に着手しました

 勤務先も先の週末から冬休みに突入し、大掃除やら何やらの年末行事を行いながら、システム監査の基本部分の学習を行っております。
 今年の学習は、分野別のスパイラル型の学習を行う、一つの分野は[知識インプット]-[午後2論文]-[午後1記述式]の順で行うと前の日記に書きました。今日はその流れの中でシステム監査基本の分野の午後2論文に手を染めました。
 午後2問題は「H17-1 システム監査の品質確保」を選びました。なぜこの問題を選んだかというと、システム監査の一連の流れの特定な部分に特化した問題ではなく、システム監査の流れ全体を対象にした問題だからです。そしてその狙いは色々な論文に転用可能な元ネタ論文にしようという企みです。
 元ネタ論文の作成、という目的のために、今回は二時間という時間制限は設けず、また参考書カンニングもアリとしました。後からのブラッシュアップが簡単に出来るようにと、手書きではなくPCを使って始めました。
 しかし・・・、問題に取り組み始めてからすぐに後悔しました。監査の流れ全体を対象とする問題ゆえに、とっても難しいのです。正直に言うとカンニングに大きな時間を使うこととなり、一日かけても終わりませんでした。しかし途中であきらめるのは負け犬になるような気がしますので、引き続き頑張ることにします。参考書をカンニングするのもいい勉強になりますしね。

 話の内容はIT統制に対する内部監査で、ERPを導入しちゃったものだからサァ大変、というストーリーです。ストーリーも他の論文に転用しやすいネタということを意識しました。
 完成できましたら時間の余裕を見て拙作をアップさせていただきますね。

 

学習する内容の分類を行いました

 いよいよ年の瀬ですね。12月は仕事がバタバタしたのと宴席が多かったので、なかなか思うように勉強がはかどりませんでした。あぁ見苦しい言い訳ごめんなさい。
 さて、11月12日の日記で「今年は学習内容を分類した上で、スパイラル型で勉強する」と宣言しました。それに沿って、まずは過去問の分類を行うと同時に分類方法の見直しを実施しました。見直し後の分類方法をここに書きます。

分類IDキーワード
AU システム監査の基本
SC 情報セキュリティマネージメント・個人情報保護
BCP 事業継続計画
ST 経営戦略・全体最適化・長中期計画・企画・投資計画
PM 要求分析・要件定義・開発・テスト・移行
SM 運用・保守・全般統制(GeneralControls)
AC 業務処理統制(ApplicationControls)・個別システムの監査

 若干の補足を書きます。
 PMは通常の定義範囲よりも若干拡張していることになるのかな。境界線を引くのが難しかったので、上流の要求分析や、下流のユーザー受入テスト・移行のあたりまで含ませることにしました。
 代表的な全般統制(GeneralControls)に関する問題とSMに関する問題を区別することはできなかったので、SMという一つの枠の中にまとめています。従って上の分類でのSMは、代表的な全般統制を含んでいます。
 前の分類にはなかったACという区分を追加しました。業務処理統制(ApplicationControls)です。

高度情報処理試験のIPA公式解答が出ました

 今年の九月に行われました高度情報処理試験の公式解答が、IPAから公表されましたね。
 最初の日記で書きました通り、私はSCを受けたのですが、見事に玉砕した模様です。今年のSCの問題はちょっと癖が強くて単純に過去門に取り組んだだけでは解けない問題だと感じました。過去問で対策すれば何とかなるだろうと考えていた自分の甘さが悔やまれます。

 さてこの週末は公式解答が発表されたのを受けまして、STの最新午後1、つまり今年の9月に行われたST試験の問題を解いてみました。チェーン店ではない一店舗経営のレストランを題材にした問題なんてのもあって面白かったです。メガバンクからレストランまで題材にするSTの試験って、何が来るのか全く予測がつかないですね。
 問1から問3まではなんとか合格点、つまり正答6割に達して気を良くしたのですが、問4の大型工事機器の問題では3割しか正答できずガッカリしました。STも午後1での問題選択が命運を分けますね。

 AUで問題選択に失敗しない方法って何なのでしょうね。未だ良い方法がつかめません。対策として今年は過去問を分野別に解く予定にしているので、どの分野が得意でどの分野が苦手なのか、客観的に分析できたらいいなって思っています。
 ではでは。今週末あたりから、いよいよ本丸であるAUの勉強を始めようかと思っています。

iTECの論文講座資料一式が届きました

こんにちは

 今年の論文対策として、iTecの「論文対策コース」に申し込みをしておりました。代金の\16,000-はかなり懐に痛かったですけど、本年度リニューアルされた「合格論文の書き方・事例集」が含まれていて、論文添削が二回ついて、おまけにWeb動画の講義までついているので、全体のコストパフォーマンスは悪くないと思って申し込みをしました。

 昨夜、この講座の資料一式が家に届いたので、中身の確認をしていた所、論文添削用の問題文がチラリと目に入ってしまいました。
 iTecの論文添削は二つの問題から一つを選んで提出する形式です。どんな問題だったか具体的に書くのは控えますが、一つは「またこれ?」と思わずうなった頻出問題、もう一つは新しいキーワードを使った問題でした。iTecがこの問題を作成した意図を想像するに、頻出問題は今年初めてAUを受験する方のために用意したもので、新しいキーワードの問題は私のような浪人生のために用意したものなのかなって思いました。
 はい、もちろん新しいキーワードの問題の方で取り組みます。

システム監査技術者 合格論文の書き方・事例集 第4版 (論文事例集シリーズ)

システム監査技術者 合格論文の書き方・事例集 第4版 (論文事例集シリーズ)