システム監査技術者 2013年 午後1 問01

解答の導き方

1. 問われているのは、開発の途中で更新される設計ドキュメントではなく、計画段階で作成するドキュメントを作成しない場合のリスクです。
2. 本文では、システム監査人が「システム化の目的を記述したドキュメント」と、「開発を開始する際に必要な要件、スコープなどを記述したドキュメント」の作成状況を確認しています。これらは、何を実現するために、どこまでを開発対象とするのかを関係者間で共有するためのものです。
3. 今回は、要件を開発の進行に合わせて確定し、追加・変更するアジャイル開発です。そのため、開始時点の目的やスコープが明確でないと、提示された要求が開発対象に含まれるかどうか判断しにくくなります。
4. その結果、本来の開発対象ではない要求まで受け入れてしまうおそれがあります。したがって、リスクはスコープ外の要求まで取り込んでしまうことです。

誤りやすいポイント

• 「ドキュメントを作成しないリスク」を、単に記録が残らないことや引継ぎが難しくなることと捉えないようにします。設問が問うのは、計画段階のドキュメントが不足することで生じる開発範囲のリスクです。
• アジャイル開発では変更に柔軟に対応しますが、何でも開発対象にしてよいという意味ではありません。目的やスコープを共有しておかないと、対象外の要求まで取り込む可能性があります。
• 保守・運用段階のドキュメント不足によるリスクと混同しないようにします。この設問では、開発開始前に作成すべき目的・要件・スコープのドキュメントが焦点です。

FAQ

解答の導き方

• 問われているのは、保守・運用段階で使うドキュメントが不足した場合に、どのような業務上の支障が起こるかです。
• 本文では、監査人が「保守・運用段階で必要となるドキュメント（システム構成などの記述）」が作成されるかを確認しています。つまり、稼働後にシステムの構成を把握するための情報が用意されているかが、問題の焦点です。
• こうした情報が不足すると、保守や障害対応の際に、システムの構成や影響範囲をその都度調べる必要が生じます。その分、調査に工数が掛かり、原因の特定や復旧に時間がかかります。
• したがって、リスクは「調査に工数が掛かり、障害への迅速な対応ができないリスク」と表せます。

誤りやすいポイント

• 「保守が難しくなる」だけでは、具体的に何が問題となるのかが不明確です。調査に時間がかかり、障害への対応が遅れるところまで述べます。
• 開発中に設計ドキュメントを頻繁に更新する負担と混同しないようにします。ここで問われているのは、保守・運用段階で必要なドキュメントが不足した場合のリスクです。
• ドキュメント不足から直ちにシステム停止やデータ損失が発生すると決めつけるのではなく、構成などを調べる手間が増え、障害対応が遅れるという因果関係で考えます。

FAQ

解答の導き方

誤りやすいポイント

• 開発ツールが準備されていることだけを確認項目にしないようにします。ツールがあっても、メンバが使い方を知らなければ、適切な運用につながりません。
• 「開発途中で使用方法を修正する」ことを、メンバへの説明や教育の代わりと考えないようにします。使い方の調整と、参加メンバへの周知は別の対応です。
• 開発ツールの選定や機能の適切性ではなく、ツールに不慣れなメンバが使い方を把握できる機会の有無に焦点を当てます。

FAQ

解答の導き方

1. 問われているのは、開発を始めた後に、事前に設けたコントロールが実際に機能しているかを確認する監査手続です。
2. 本文では、開発ツールの使用方法やチーム間のコミュニケーションについて「修正を加えながら開発を進めていく」としています。一方、開発チームには「ツールの使用方法にも習熟していない」メンバが多いとあります。この状況では、開発の進め方がメンバごとにばらつき、作業や成果物の作成方法が統一されないおそれがあります。
3. したがって、開発開始時にルールを決めるだけでは十分ではありません。開発の途中で実際の成果物を確認し、事前に決めたルールに沿って作成されているかを確かめる必要があります。これにより、ルールが現場で守られているかを確認できます。

誤りやすいポイント

• 開発ツールの操作に習熟しているかだけを確認しても、成果物が決められた手順や形式に沿って作成されているかまでは分かりません。
• ルールを決めたことを確認するだけでは、開発の途中でルールが実際に守られているかを確認できません。
• 進捗状況やテスト結果の確認に置き換えると、問われている「コントロールが有効に機能しているか」の確認から外れます。

FAQ