AUシステム監査技術者試験 午後Ⅰ
令和6年度秋期 システム監査技術者 午後Ⅰ 問1
事例を読んで設問の答えを考えてから、解説のポイントとIPA公式の解答例・採点講評で確認しましょう。
問題

解き方のヒントを見る
リスクと統制の対応関係を確かめる
監査の観点で考える問題では、ある状況で何が起こり得るかというリスクと、それを抑えるための仕組みである統制が、筋の通った対応関係になっているかを一つずつ確かめる姿勢が役立ちます。
この問題で問われていること
問われているのが、リスクそのものの把握なのか、統制の妥当性の評価なのか、監査人として確認すべき事項なのかを最初に見極めます。そのうえで、各候補が問いの趣旨と合っているかを検討することが焦点になります。
視点
監査では、リスクを「何がうまくいかなくなるおそれがあるか」、統制を「そのおそれを抑えるための手段」として分けて捉えます。統制は特定のリスクに向けて設けられるものです。どのリスクに効くのかを説明できなければ、監査上の根拠としては弱くなります。開発や運用の進め方が変わっても、リスクと統制の対応関係を確かめるという考え方自体は変わりません。
確認ポイント
- 示されている状況で、何が損なわれるおそれがあるのかを自分の言葉で説明できるか
- 取り上げられている仕組みや手続が、そのおそれを抑えることに実際につながっているか
- 監査人として確かめる対象がリスクなのか統制なのかを区別して読めているか
正解と解説を見る
解説
DevOpsを取り入れたECシステムの開発・運用を題材に、職務の分離に代わるCI/CDツールの予防的・発見的コントロール、ユーザー受入テストを自動化の範囲から外すこと、コーディングルールを各チームに徹底すること、単体テストステージが確実に自動化されていることを監査手続として問う問題です。予備調査(2)①〜④と監査手続の検討(1)〜(4)を一つずつ対応させて読むことが解答の鍵になります。
問題の全体像
A社は、ECシステムでアジャイル開発を採用してきましたが、本番リリースの頻度が上がったため、開発・運用プロセスにDevOpsを適用しました。監査の観点は二つで、リリースサイクル短縮というDevOpsの目的を達成できる運用方法になっているか、DevOps特有の環境やプロセスのリスクに対応できているかです。予備調査(2)①〜④では、開発担当者による本番環境へのデプロイ、本番リリースまでのステージの早期自動化、他チームのプログラムを理解しにくい問題、習熟度に応じた自動化範囲の拡大が挙げられ、監査手続の検討(1)〜(4)がそれぞれに対応しています。出題趣旨では、DevOpsの特性やメリット・デメリットを理解したうえで、コントロールやマネジメント方法を提言する能力と監査手続を設定する能力を問うとしています。
設問1(i)
予備調査(2)①では、開発担当者がCI/CDツールを使って本番環境を含む各実行環境にデプロイできます。つまり、開発した人が本番環境への反映という運用作業も行える状態です。従来のウォーターフォール型開発では、開発担当者と運用担当者を分け、開発者が単独で本番環境を変更できないようにして、未承認のプログラムが本番環境に入るのを防いでいました。公式解答例では「開発と運用の職務の分離」です(11字で15字以内に収まります)。採点講評でも、DevOps環境では職務の分離などのコントロールを適用しにくい場合があり、CI/CDツールの設定によるコントロールで代替してリスクを下げる必要があると述べられています。
設問1(ii)
根拠は予備調査(2)①の「各環境へのデプロイの権限及びアクセス可能な環境や期間を開発担当者ごとに設定できる」という記述です。未承認のデプロイを事前に防ぐ予防的コントロールとしては、本番環境への権限を常に持たせるのではなく、必要なときだけ期間を区切って付与するのが有効です。公式解答例では「本番環境へのアクセス権を常時付与せずに、必要なときに一時的に付与すること」です。40字以内で答えるには、対象(本番環境へのアクセス権)、常時付与しないこと、必要なときに一時的に付与すること、の三つを入れます。
設問1(iii)
根拠は予備調査(2)①の「デプロイや設定変更が行われると、指定した者に通知されるように設定できる」という記述です。未承認のデプロイを適時に見つける発見的コントロールとしては、本番環境へのデプロイだけでなく、権限や通知の設定そのものを変える操作も通知の対象にし、開発チームのリーダーであるスクラムマスターが把握できるようにします。公式解答例では「本番環境へのデプロイやCI/CDツール設定の変更がスクラムマスターに通知されること」です。45字以内で答えるには、通知の対象(本番環境へのデプロイと、CI/CDツールの設定変更)、通知先(スクラムマスター)、通知されること、を入れます。採点講評では、この小問は正答率がやや高かったとされています。
設問2
監査手続の検討(2)では、全てのステージを自動化すべきではないとして、自動化の検討範囲を確認するとしています。図1と各ステージの説明を見ると、ユーザー受入テストは機能要件を満たしているか、使いやすいかなど、利用者の観点で検証するステージです。採点講評では、テストデータやシナリオを事前に設定すれば本番リリースまでのステージを自動化できるものの、使いやすさなど利用者の立場から判断すべきテストを自動化するとリスクがあると説明しています。公式解答例では「ユーザー受入テストが自動化の範囲に含まれていないこと」です。30字以内で、対象となるステージ名と、自動化の範囲から外れていることを書きます。採点講評では正答率がやや低かったとされています。
設問3
予備調査(2)③によると、各メンバーは自分の担当機能に集中しているため、生産性も単体での品質も高い状態です。ところが、他チームの支援でプログラムを修正した際には、修正前のプログラムを理解するのに時間が掛かりました。チームやメンバーごとに書き方が異なり、共通のルールが守られていない可能性がうかがえます。予備調査(1)③では、共通チームがコーディングルールなどの標準化を担当しています。公式解答例では「コーディングルールの遵守を各開発チームに徹底すること」です。採点講評では、コーディングルールなどの標準を作るだけでなく、浸透させる取組がリスク低減につながる点に着目してほしいとしています。30字以内で答える際は、ルールを作成することではなく、各開発チームに守らせることを役割として書くのがポイントです。
設問4
予備調査(2)④では、CI/CDツールの自動化の範囲を開発担当者の習熟度に応じて順次広げる計画であり、第一段階となる単体テストステージでは各スクラムマスターが開発担当者の権限を設定しています。〔ECシステムの開発・運用プロセス〕によると、CIはプログラムの開発と単体テストを自動化することであり、単体テストステージではモジュールのビルドから単体テストまでを実行します。第一段階の設定を各スクラムマスターに任せているため、この段階で自動化が十分に設定されていなければ、リリースサイクル短縮という目的の達成が遅れます。そこで監査チームは、単体テストステージで実際に自動化が設定されているかを確かめる必要があります。公式解答例では「単体テストステージのビルド、デプロイ、テストが自動化されるように設定されていること」です。45字以内で、対象のステージ、自動化される作業(ビルド、デプロイ、テスト)、そのように設定されていること、の三つを書きます。
学習のポイント
DevOps環境で職務の分離が効きにくい理由と、代わりになるCI/CDツールの設定(権限の一時付与、変更通知)を整理しておくことが重要です。あわせて、自動化に向かないテスト(ユーザー受入テスト)、標準を作るだけで終わらせず浸透させる取組、リリースサイクル短縮という目的に照らして運用方法を監査する視点を身につけましょう。
出典:独立行政法人 情報処理推進機構(IPA)令和6年度秋期 システム監査技術者試験 午後Ⅰ 問1(公式資料:問題冊子(PDF) / 解答例 / 採点講評)
関連する過去問一覧
IPA Advancedは非公式の学習サイトです。解説にはAIによる補助生成を含む場合があります。公式の問題冊子・解答例・採点講評を優先し、誤りは確認後に訂正します。運営・編集方針