平成25年度春期 システム監査技術者 午後Ⅰ 問1

リスクとコントロールの対応関係を確かめる

監査の観点では、ある懸念に対して挙げられた手当てが、その懸念を実際に小さくする働きを持つかを一組ずつ確かめることが基本です。用語の印象ではなく、懸念の中身と手当ての効き目がかみ合っているかに注目して検討しましょう。

この問題で問われていること

問われているのは、想定されるリスクと、それを抑えるために置かれるコントロールとの関係を監査人の立場で評価する力です。企画段階という時点を意識しつつ、両者が因果的につながっているかを判断します。

視点

システム監査でいうリスクとは、目的の達成を妨げるおそれのある事象を指します。コントロールとは、その発生可能性や影響を抑えるための仕組みや手続です。監査人は、個々の施策が望ましいかどうかを単独で判断するのではなく、特定のリスクに対してその施策が抑止・発見・是正のいずれかの形で有効に働くかという対応関係を評価します。開発手法が変わっても、この対応関係を一組ずつ吟味する姿勢は共通です。

確認ポイント

• 各リスクについて、それが実現した場合に何が損なわれるのかを自分の言葉で言い表せるか確認する
• コントロールとされる手当てが、そのリスクの発生可能性または影響を実際に下げる働きを持つかを確かめる
• 一般論として望ましい施策であっても、対応させたリスクとは別の懸念に効くものになっていないかを見直す

解説

S社がアジャイル開発で営業支援システムを開発する場面で、企画段階のシステム監査を行う問題です。計画段階や保守・運用段階のドキュメントが不足するリスク、イテレーション終了後の振り返り、プロセスオーナの人選、ツールの使用方法の周知とその有効性の確認が問われています。アジャイル開発の特徴を理解したうえで、リスクを見極めてコントロールを導く力が試されます。

問題の全体像

S社はこれまでウォータフォール型で開発してきましたが、介護ビジネスなど新しい事業分野に柔軟に対応するため、営業支援システムをアジャイル開発で短期間に作ることにしました。開発企画書では、4週間を1単位とするイテレーションを6回実施すること、途中で随時変更が生じるような設計ドキュメントは作らないこと、ツールの使用方法やチーム間のコミュニケーションは修正を加えながら進めることなどが定められています。表1では、システム部のT氏がPMとプロセスオーナを兼ねています。出題趣旨では、「コスト削減」「短期開発」「ドキュメントを作成しない」といった観点だけに注目するとかえって問題が起きることを示したうえで、システム監査人としてアジャイル開発の特徴や留意点を理解し、リスクを見極め、必要なコントロールを抽出する能力を問うとしています。

設問1(1)

本調査の実施(1)で、システム監査人は「システム化の目的」や「開発を開始する際に必要な要件、スコープなど」を記述したドキュメントの作成状況を確認しています。これらが文書化されていないと、要件を柔軟に追加・変更するアジャイル開発では、どこまでが開発範囲なのかという判断基準がなくなります。その結果、本来の範囲を超えた要求まで取り込まれ、目的からのずれや期間・コストの膨張につながります。公式解答例では、この点を「スコープ外の要求まで取り込んでしまうリスク」とまとめています。採点講評では、「目的が共有されない」のような表面的な事象を書いた解答が多かったと指摘しています。そのうえで、システム化の目的が達成されない、スコープがずれるといった具体的なリスクまで踏み込むよう求めています。25字以内なので、「スコープ外の要求の取込み」という結果を中心に書くのがよいでしょう。

設問1(2)

保守・運用段階で必要なドキュメントとして、問題文は「システム構成などの記述」を挙げています。本番稼働後に障害が起きたとき、システム構成などの資料がなければ、原因箇所を特定するためにプログラムなどを一から調べる必要があります。公式解答例では、「調査に工数が掛かり、障害への迅速な対応ができないリスク」としています。答案では、①調査に手間や時間がかかること、②その結果として障害に迅速に対応できないこと、の二つを30字以内に収めることがポイントです。

設問2

開発企画書の①〜④は、要件確定→開発→ユーザテスト→テスト結果・成果物・進捗の確認という流れで、④でイテレーションを終えて次に移る計画になっています。問題文では、S社のアジャイル開発の方法論は厳密に定義されておらず、ツールの使用方法やコミュニケーションは修正しながら進めるとされています。そのため、各イテレーションの進め方そのものを振り返り、改善点を次のイテレーションに反映する仕組みがなければ、同じ問題が繰り返されます。公式解答例は「イテレーションの進め方を評価し、次回に反映すること」です。採点講評では、「該当イテレーションの終了を承認する」といった形式的な承認行為や、ウォータフォール型の開発手順を意識した解答が目立ち、正答率は低かったとしています。「評価する」と「次回へ反映する」の両方を書くことが大切です。

設問3

システム監査人は、コンサルタントへのヒアリングで「プロセスオーナが要件の最終確定を行う」という原則の重要性を認識しました。一方、表1ではシステム部のT氏がPMとしてプロセスオーナを務め、組み込む要件の優先順位を付けることになっています。業務内容を把握しているのはユーザチームにいる営業企画部の社員です。システム部のT氏が業務の要件や優先順位を正しく判断できるとは限りません。公式解答例では、「システム部のT氏がプロセスオーナだと、業務の要件や優先順位を的確に判断し意思決定できないから」としています。採点講評では、形式的な手続の不足を書いた解答が多かったとしています。答案では「誰がプロセスオーナか（業務を熟知していないシステム部のT氏）」と「何ができないか（要件・優先順位の的確な判断と意思決定）」を50字以内で結び付けて書くことが求められます。

設問4(1)

本調査の実施(4)では、アジャイル開発が初めてのメンバが多く、ツールの使用方法にも習熟していないことがリスクの理由とされています。そこで、開発の開始段階で必要なコントロールは、ツールの使用方法をメンバに伝え、理解させる機会を設けることになります。表1でも、基盤チームの役割に「開発手順を決定し、メンバを教育する」とあります。公式解答例では、監査項目を「ツールの使用方法を参加メンバに周知する場が設けられているか」としています。監査項目なので、「〜が設けられているか」のように確認の観点として35字以内で書く形になります。

設問4(2)

開発の途中で、設問4(1)のコントロールが有効に機能しているかを確かめる監査手続が問われています。周知の場が設けられていても、実際に決められたルールどおりにツールが使われ、成果物が作られていなければ、コントロールは機能していません。そこで、成果物という証拠を見て、ルールへの準拠を確認します。公式解答例では、「事前に決められたルールに従って成果物が作成されているかどうかを確認する。」としています。採点講評では、監査手続を問うているのに監査項目だけを書いた解答が散見されたと指摘しています。答案では「何を対象に（成果物）」「何と照らして（事前に決められたルール）」「どうするか（確認する）」という手続の形で40字以内に書くことが大切です。

学習のポイント

アジャイル開発の原則（プロセスオーナによる要件の確定、振り返りによる改善、最小限必要なドキュメント）と監査上のリスクを結び付けて理解することが重点です。あわせて、監査項目と監査手続を書き分ける練習をしておきましょう。