システム監査技術者 2019年 午後1 問02

解答の導き方

1. まず、要望事項には「重要度」と「プロジェクトとしての優先順位」の二つがあると読み取れます。本文では、関連部門が要望事項に「大中小の重要度」を付けた後、システム部がインタビューを行い、業務上の代替手段なども検討して「プロジェクトとしての優先順位」を付与しています。
2. この二つは同じものではありません。重要度は、関連部門がそれぞれの要望をどれほど重視しているかを示すものです。一方、プロジェクトとしての優先順位は、代替手段なども考慮して、開発計画の中でどの要望を優先するかを判断したものです。
3. 表1の項番1の監査手続では、「重要度」の項目があり、「大中小」のいずれかが漏れなく設定されていることを確認します。この確認で分かるのは、各要望に重要度が記入されているかどうかです。システム部が要望を検討し、プロジェクトとしての優先順位を決めたかどうかまでは確認できません。
4. したがって、重要度の記入漏れだけを確認する手続では、プロジェクトとして優先順位が検討されたかを確かめるには不十分です。

誤りやすいポイント

• 「重要度」と「プロジェクトとしての優先順位」を同じ意味だと捉えないようにします。本文では、別々の主体が異なる段階で付与しています。
• 「大中小」が漏れなく設定されていることを確認すれば、優先順位も検討済みだと判断するのは誤りです。記入の有無と、優先順位を決定した過程の確認は別です。
• 要望事項一覧に優先順位の欄があるかどうかだけでなく、監査手続が実際に何を確認できるかに注目します。

FAQ

解答の導き方

1. まず、この監査手続で確認したいのは、利用部門の代表者が要件定義書の作成に実際に関わっているかどうかです。表1の項番3では、要件定義書の作成時に利用部門の代表者が参画しているかを監査要点としています。
2. 体制図から分かるのは、利用部門の代表者がプロジェクトに参加する予定になっているかどうかです。しかし、体制図に名前があるだけでは、要件定義書の作成に実際に参加したか、また十分に意見を述べたかまでは分かりません。
3. 本文では、要件定義書の原案をZ社の担当者が作成し、営業統括部が新規機能の要件を加えた後、関連部門の要望事項をシステム部が整理しています。このような作成過程では、利用部門の代表者がどのように関与したかを確認することが重要です。
4. そこで、議事録を閲覧すれば要件定義の場での参加状況を確認でき、代表者へのヒアリングを行えば、役割や関与の程度を確かめられます。つまり、体制上の参加予定だけでなく、要件定義書の作成への十分な関与が実際にあったかを確認するためです。

誤りやすいポイント

• 体制図に利用部門の代表者が記載されていれば、要件定義への参加も確認できたと考えてしまうことです。体制図が示すのは、主に参加予定や役割です。
• 議事録の閲覧とヒアリングを、単なる参加の有無の確認と捉えることです。重要なのは、要件定義書の作成にどの程度関与したかまで確認することです。
• 利用部門の代表者がプロジェクトに参画すること自体を目的と考えることです。監査では、利用部門の業務上の要望を要件定義に反映できるだけの関与があったかを確かめます。

FAQ

解答の導き方

誤りやすいポイント

• 進捗会議の回数や頻度を確認すれば、進捗状況を正確に把握できると考えることです。会議の頻度は適時性に関わりますが、報告内容の正しさを裏付けるものではありません。
• 委託先に進捗報告を求めること自体を、報告内容の確認と混同することです。成果物やテスト結果との照合が、報告の正確性を確かめる手段になります。
• 委託先の報告を信頼できるかという一般論にとどまり、A社側で報告の正確性を確認する必要がある点を述べないことです。

FAQ

解答の導き方

1. 本調査では、開発に着手した後の体制と役割は確認できましたが、「検収完了後の体制については確認できなかった」とあります。したがって、確認が不足しているのは、検収が終わった後のA社内の体制です。
2. その期間に何を行うのかは、本文に「検収完了後から本番リリース準備開始前までにA社内でユーザ受入テストを実施する」と示されています。よって、確認対象は、このユーザ受入テストをA社内で実施するための体制です。
3. 体制の確認では、誰がどの役割を担うのかも明確になっている必要があります。そのため、ユーザ受入テストの役割分担と実施体制について、明確に定められていることを確認するのが適切です。

誤りやすいポイント

• 委託先の検収と、A社内で行うユーザ受入テストを混同しないようにします。本文では、検収完了後にユーザ受入テストを実施するとされています。
• 本問は、テストケースやテスト結果の妥当性を問うものではなく、検収後のA社内の体制を問うものです。
• 「ユーザ受入テストを実施する予定があるか」だけでは不十分です。誰が何を担当するのかという役割分担も確認対象です。

FAQ

解答の導き方

1. まず、本調査では「要件の追加・変更に関する手順」の内容が必要事項を網羅していることを確認しています。さらに、委託先がその手順を守れるかについても、T課長は「契約時に双方で確認する」と回答しています。したがって、委託先との契約上の手順だけを確認するのでは不十分です。
2. 次に、S氏は「利用部門向けにも」手順を周知する必要があると指摘しています。要件の追加・変更を求めるのは利用部門でもあるため、委託先との取り決めだけでは、利用部門からの要求をどのように扱うかが定まりません。
3. そこで監査チームは、追加・変更の要求が増えても期間内に対応できる対策があるかを確認することにしました。要求をすべて採用するのではなく、どの要求を受け入れるかの条件を明確にし、その条件を利用部門と合意しておけば、要求の増加による開発範囲の拡大やスケジュールへの影響を抑えられます。

誤りやすいポイント

• 委託先との手順の合意だけを答えないようにします。本調査では、委託先が手順を守ることは契約時に確認するとの回答を得ています。
• 手順を利用部門に周知することだけで終わらせないようにします。設問が問うのは、要求が増えても期間内に対応するための具体策です。
• 要求の優先順位付けだけに限定しないようにします。ここでは、採用条件を明確にして利用部門と合意することがポイントです。

FAQ

• Q: 委託先との合意だけでは、なぜ不十分なのですか？
  A: 利用部門から追加・変更の要求が出るためです。委託先との手順に加えて、利用部門がどのような条件で要求を採用するかを理解し、合意している必要があります。
• Q: 利用部門に手順を知らせれば十分ですか？
  A: 周知だけでは、要求を採用する基準が利用部門との間で共有されたとは限りません。採用条件を明確にして、利用部門と合意することが必要です。
• Q: 採用条件を決める目的は何ですか？
  A: 追加・変更要求を無制限に受け入れて開発範囲が膨らむことを防ぎ、期間内に対応できる範囲を関係者間で明確にするためです。