システム監査技術者

システム監査技術者試験を受けてきました。
さすが情報処理技術者試験でも難関のシステム監査技術者試験です。中々受かりません…
３度目の挑戦で今度こそは、と思っていたのですが、春に転勤になってしまい、勉強がほとんどできていない状態に。
午前I免除もなくなってしまったので、まぁ午前I免除だけでも取れればイイか、と気楽に受けたのが良かったのか、午後I・IIとも全然用意してなかった割にはまずまずの手ごたえ。
逆に午前Iはやっぱりかなり忘れているので、ちょっと不安な結果に。６割は大丈夫だと思うけど、確信はない感じ。

取りあえず、解答再現して、5chでいつもの答え合わせを楽しんできます。
試験の後の「問１どうだった～？」「あれは○○じゃないの～」みたいなやり取りが、学生時代を思い出して好きです。

午前I
まったく勉強してない上、最近の情報技術の動向はyahooニュースぐらいでしか得ていないので、聞いたことのない用語がちらほら。ついでに込み入ったハード・ソフトの話は忘れていて、確信ある解答は５割ぐらいしかありませんでした。大丈夫かな…
エエウエウ
アエウウイ
イアウウイ
エエウウイ
イアイエア
ウエウエア

→　追記
何か27/30で90％もありました。最初の計算２問でいきなりテンパったインパクトだった模様。
問１、ビットずれが２つだけだと思い込んで、３つとも１になったので？？？？となったけど、今見たらX1は３つとも入ってるのな。

午前II
唯一まともに勉強した科目。と言っても問題集を１周。
監査分野は割と簡単だったので多分ほとんどOK。他はやっぱり聞いたことのない用語が少し。でも午前IIは６割は大丈夫だと思いますがいかに。
イイエイイ
イエイウイ
ウアウアエ
エエアイイ
エアアイエ

→　追記
19/25で76％でした。意見が割れたときは追加の監査手続なんですね…、併記でいいじゃん、と思って問題を読み返したら「調査不足から」って書いてあった。それなら監査手続の追加だわ。

午後I
まったく対策なしで臨んだ割に、手ごたえ十分。6割は十分あると思っているんですが、システム監査技術者の午後Iって他の試験種と違い、正解だと思ってる記述が全然違うことがあるからなぁ。
ちなみに選択は問１と問３。

問１
設問１　システムオーナに登録されている部署がシステムの主管部署となっていること。（３６字）
設問２(i)　システム移行に係る費用
(ii)　投資委員会によるゲート２の審査記録を閲覧し、費用項目の不足をチェックしているかを確認する。（４５字）
設問３　各ゲートで行われる投資委員会の審査における判定の基準（２６字）
設問４　プロジェクトごとにステージ２で設定された投資による効果が得られるまでの期間（３７字）
設問５　審査対象システムの主管部署の者が含まれていないこと（２５字）

問３
設問１　新しい販売管理システムが行う受注内容の自動チェック（２５字）
設問２(1) b:EDI取引契約書, c:要件定義書
(2)　受発注成立がEDI取引契約書で定めた条件を満たしているかどうか
設問３ e:１０万円以上の受注を、１０万円未満の複数の受注に分割して入力する
f:１日の受注金額が１０万円以上となった得意先の受注リストを受注責任者がチェックする
設問４　出荷完了リストの出力対象に、出荷完了入力が未入力のデータも含まれているかどうか確認すること

午後II
問１のアジャイル開発を選択。
ア－１　情報システムの概要
・Web通販システムパッケージを販売している企業が、パッケージからスピード感のあるサブスクリプションに切り替えるのを機にアジャイル型開発に変更した。

アー２　アジャイル型開発手法を採用する理由及び内容

・大規模開発では要件定義の時期からリリースまでの期間が長く、リリース時には要件が陳腐化している現状、情報技術の進展、商品・サービスのディジタル化の加速、消費者の価値観の多様化などに素早く対応し続けることが必要
・ペアプログラミングによる開発、ペアで設計からリリースまで
・顧客の要望、ペアの改修提案などを機能に分割、優先度をつけ、各ペアに割り振り
イー１　アジャイル型開発手法のリスク
・ウォータフォール型は大人数開発、各工程ごとの複数人によるレビューにより、個人のスキル差を吸収するが、それがないアジャイル型開発は最終成果物の品質にバラつきが出るリスクがある
・ウォータフォール型は各工程ごとにコスト差異分析をする機会があり、先の工程のコスト超過を後の工程で吸収することを行いやすいが、アジャイル型開発は個々の開発にこそコスト目標を設定できても、開発の各段階での差異分析や超過の吸収を行いずらいため、１開発ごとの微細な超過が１年を通すと大きなコスト増要因になるリスクがある
イー２　リスクに対するコントロール
・最終成果物の品質のバラつき
開発標準の策定と適用
性能：処理内容ごとの標準処理時間を設定
セキュリティ：対応すべき攻撃手法を防御手段を設定
保守性：関数の上限行数、変数の命名規則、テスト標準などを設定し、チェックシートを様式化
・コスト増
ペアの年間予算を設定し、１開発ごとの予算と実績値を出力し、差異分析させる。５％以上の予算超過が見られた場合は改善方針の提出をさせる
ウ
確認すべきポイントは、リスクに対するコントロールが機能しているかどうか
ウー１　最終成果物の品質のバラつき
ポイントは開発標準が確実に適用され、機能しているかどうか
性能
監査手続：テストデータ投入による処理時間測定、標準処理時間の確認
監査証拠：測定した処理時間と標準処理時間との差異
セキュリティ
監査手続：対応すべき攻撃手法によるペネトレーションテスト
監査証拠：テスト結果
保守性
監査手続：チェックシートの確認、コードの試査
監査証拠：チェックシート内容とコードの照合結果
ウー２　コスト増
ポイントはペアが予算と実績を１開発ごとに確認し、管理しているか
監査手続：出力された予算と実績値の確認、改善方針書の確認と５％以上の予算超過したペアへのヒアリング
監査証拠：出力された予算と実績値がすべての開発に存在しているかの確認結果、改善方針書とペアへのヒアリングの内容に矛盾や趣旨の違いがないかどうかの確認結果

→　追記　5ch見てて、あっと思いました。「開発が始まる前に」の前提を全力で忘れていました。ダメだこりゃ。