AUシステム監査技術者試験 午後Ⅰ

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

事例を読んで設問の答えを考えてから、解説のポイントとIPA公式の解答例・採点講評で確認しましょう。

問題

問2 システムの開発計画の監査に関する次の記述を読んで,設問1~5に答えよ。 A社は,機械部品,工具などを製造・販売している中堅企業であり,業務拡大のために,営業支援システムを刷新することになった。現在,A社内で要件定義を行っており,設計工程以降はベンダに外部委託する計画である。 昨今,他社でシステム開発の外部委託を巡るトラブルで訴訟に発展する事例が発生していることから,A社の監査室に対してシステム監査の実施が指示された。しかし,監査室は,これまでシステム監査の経験がほとんどないので,外部のシステム監査人S氏に今回のシステム監査チーム(以下,監査チームという)に参画してもらい,助言を受けながら監査を実施することにした。 〔予備調査の結果〕 監査チームは,A社の新しい営業支援システム(以下,新システムという)の開発計画の状況を,次のとおり把握した。 (1) A社の営業戦略を担う営業統括部と現行システムを管理するシステム部が中心となって,システム企画書を作成した。 (2) A社のシステム部では,数名の部員が主に委託先への発注業務などの事務的な作業を行っているだけで,ここ10年以上大きなシステム開発は行っていない。また,現行システムの運用・保守は,開発を担当したZ社に任せている。 (3) 新システム開発プロジェクトで要件定義を開始する際に,システム部のT課長がプロジェクトマネージャ(PM)に任命された。T課長は,他部署から異動してきたばかりで,システム開発プロジェクトのPMに任命されたのは初めてである。 (4) T課長は,現行システムの仕様を十分に把握していないので,現行システムを熟知しているZ社の担当者に依頼して,現行仕様を基に要件定義書の原案を作成してもらった。 (5) 営業統括部が,営業戦略上重要な新規機能の要件を要件定義書の原案に付け加えた。そして,関連部門が現行システムに対する要望事項に大中小の重要度を付加し,T課長に提出した。その後,システム部が,関連部門にインタビューしながら業務上の代替手段などを検討し,要望事項にプロジェクトとしての優先順位を付与した上で,“要望事項一覧”として要件定義書に追記した。 (6) 要件定義書を作成した後,Z社を含む複数のベンダに見積りを依頼し,そのうちの1社に基本設計からシステムテストまでの工程を請負契約で委託する。開発委託先が決まったら,開発スケジュールを詳細化し,プロジェクト計画書を作成することになっている。 (7) システム部は,システムテストまでの工程の成果物が過不足なく納品されていることを確認する。また,システムテストのテストケース及びテスト結果を確認して検収を行う。検収完了後から本番リリース準備開始前までにA社内でユーザ受入テストを実施する。 (8) 開発着手後も要件の追加・変更が見込まれるので,委託先には一定の条件下で要件の追加・変更を依頼する前提で発注する。 〔リスクの洗い出し〕 監査チームは,予備調査の結果を基に,新システムの開発計画のリスクを洗い出した。その内容は,次のとおりである。 (1) T課長が関連部門からの要望を整理できず,要件定義書をまとめきれない。その結果,“開発範囲が確定しない”,“開発に着手できない”,“プロジェクト計画書を作成できない”などの状況に陥るリスクがある。 (2) 業務要件が十分に固まっていない状態で開発に着手することによって,後から要件の追加・変更が頻発し,計画どおりにプロジェクトを進められないリスクがある。 (3) 委託先への発注窓口であるシステム部の体制が不十分で,開発着手後も委託先に“丸投げ”の状態となるリスクがある。その結果,“進捗状況を十分に把握できず,進捗遅れ・予算超過を適時に把握できない”,“開発着手後の追加・変更要求を要件として委託先に依頼できない”といった状況に陥るリスクがある。 (4) PMの責任・権限が曖昧なことから,T課長が判断に迷った場合に,プロジェクトとしての意思決定ができないリスクがある。 〔本調査の計画〕 監査チームは,リスクを洗い出した後,表1に示す監査手続書を作成し,S氏に助言を求めることにした。 表1 監査手続書 〔S氏からの助言〕 S氏からの助言内容は,次のとおりである。 (1) 表1の項番1の監査手続について 重要度の項目が,要望事項一覧に漏れなく設定されているかどうかを確認するだけでは不十分である。 (2) 表1の項番3の監査手続について 新システム開発プロジェクトの体制図の閲覧だけでなく,要件定義書作成時の議事録の閲覧,及び体制図に記載された利用部門の代表者へのヒアリングを行って確認する必要がある。 (3) 表1の項番4の監査手続について 進捗状況を適時に把握できるよう,委託先との進捗会議の実施頻度を確認しておくことは重要である。さらに,“委託先からは,進捗報告資料のほかに成果物の一部とテスト結果を提出してもらい,システム部が進捗報告の内容と比較することを計画しているかどうか”を確認する必要がある。 〔本調査の実施〕 監査チームは,表1の監査手続書,及びS氏からの助言を踏まえて,要件定義書の完成前に本調査を実施した。その内容の一部は,次のとおりである。 (1) 表1の項番2の監査手続について 監査チームは,開発に着手した後の体制と役割が明確になっていることを把握した。ただし,検収完了後の体制については確認できなかった。監査チームは,検収完了後から本番リリース準備開始前までのA社内の体制について,更に詳細に確認することにした。 (2) 表1の項番5の監査手続について T課長が作成した,委託先向けの“要件の追加・変更に関する手順”には,必要と考えられる事項は網羅されていた。そこで,監査チームは,これらの手順が委託先との間で合意可能かどうかを,T課長にヒアリングして確認した。T課長によると,“委託先に対して手順の遵守を求めることは,契約時に双方で確認するので問題ない”との回答であった。この結果を受けて,S氏は利用部門向けにも“要件の追加・変更に関する手順”の周知が必要であると指摘した。監査チームは,追加の監査手続として,要件の追加・変更の要求がある程度増えても期間内に対応できるような対策が設けられているかどうかを,T課長に確認することにした。 設問1 〔S氏からの助言〕(1)において,S氏が“不十分である”と考えた理由を,50字以内で述べよ。 設問2 〔S氏からの助言〕(2)において,S氏が議事録の閲覧,及び利用部門の代表者へのヒアリングを行って確認する必要があるとした理由を,40字以内で述べよ。 設問3 〔S氏からの助言〕(3)について,S氏が監査手続の追加を助言した理由を,45字以内で述べよ。 設問4 〔本調査の実施〕(1)について,監査チームが確認することにした具体的な内容を,35字以内で述べよ。 設問5 〔本調査の実施〕(2)について,監査チームがT課長に確認した対策の具体的な内容を,45字以内で述べよ。
表1 監査手続書。リスク項番、監査要点、監査手続を整理した5項目のシステム開発計画監査の手続表。下部にリスク項番の注記がある。
表1 監査手続書。リスク項番、監査要点、監査手続を整理した5項目のシステム開発計画監査の手続表。下部にリスク項番の注記がある。
解き方のヒントを見る

監査手続とリスクの対応を読む視点

事例中のリスク、関係者の役割、監査手続、追加確認の流れを対応づけ、各設問が求める「なぜ確認するのか」という理由の種類に注目して考える。事実確認と統制評価を混同しないことも意識する。

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

各設問の該当箇所について、単に文書や会議を確認する対象を探すのではなく、その確認でどのリスクや判断上の不確実さを減らそうとしているのかを一つに絞って整理すること。

視点

監査では、計画上のリスクと、それを確かめるための証拠の信頼性・十分性を結び付けて読む。文書閲覧、聞き取り、運用確認などの手段は、対象の存在だけでなく、関係者間の認識や実行可能性を確かめる観点から捉える。

確認ポイント

  • 設問が問うのは、確認対象そのものか、その確認を追加する理由かを区別する
  • 事例のリスクと、確認手続で得られる証拠の対応を一つだけ考える
  • 誰が何を決め、どの段階で不確実さが残るかを本文から確認する
正解と解説を見る

解説

本問は、システム部門の経験や体制が十分でない企業が開発を外部委託する際、丸投げを防ぎ、発注者責任を果たせる統制と監査手続を考える問題です。

問題の全体像

A社は営業支援システムの刷新を計画し、要件定義後の工程をベンダに委託する。しかし、システム部門の経験が浅く、PMも初任で、現行仕様の把握や要件変更への対応を外部に依存している。そこで、要件の優先順位、利用部門の関与、委託先の進捗確認、受入体制、変更管理が適切かを監査する。出題趣旨では、発注者側が発注者責任を果たせる体制かを確認し、リスクに応じた監査ポイントと手続を設定する力が問われている。

設問1

表1項番1は、要望事項に大中小の重要度が漏れなく設定されているかだけを確認する手続です。しかし、重要度の記載があっても、プロジェクトとしてどの要望を先に実現するかという優先順位まで検討されたとは限らない。したがって、公式解答例のとおり、重要度の設定確認だけではプロジェクトとしての優先順位を確認できない点を述べる。

設問2

体制図に利用部門の代表者が記載されているだけでは、実際に要件定義書の作成へ十分に関与したかは分からない。要件定義時の議事録と代表者へのヒアリングを確認することで、形式的な参加ではなく、利用部門の代表者が要件定義に十分関与した事実を確かめられる。

設問3

委託先との進捗会議の頻度だけでは、委託先の報告内容が正確かどうかを検証できない。成果物の一部やテスト結果を提出させ、進捗報告と照合すれば、A社が委託先の進捗報告の正確性を確認できる。公式解答例も、このA社側での確認の必要性を理由としている。

設問4

検収完了後から本番リリース準備開始前までに、A社内でユーザ受入テストを実施する計画がある。この段階について体制を確認できていないため、ユーザ受入テストを誰が担当し、どのような体制で実施するかという役割分担と体制が明確に定められていることを確認する。

設問5

開発着手後の要件追加・変更が増えても、無条件に受け入れると期間内に対応できない。そこで、追加・変更要求を採用する条件を明確にし、その条件を利用部門と事前に合意する対策を確認する。公式解答例では、採用条件の明確化と利用部門との合意が示されている。

学習のポイント

リスクから監査要点と具体的な確認手続を導く力を養う。

出典:独立行政法人 情報処理推進機構(IPA)平成31年度春期 システム監査技術者試験 午後Ⅰ 問2(公式資料:問題冊子(PDF) / 解答例 / 採点講評)

関連する過去問一覧

IPA Advancedは非公式の学習サイトです。解説にはAIによる補助生成を含む場合があります。公式の問題冊子・解答例・採点講評を優先し、誤りは確認後に訂正します。運営・編集方針