基本情報 平成23年度 春期 問58：マネジメント系に関する問題

答えは d です。

「ユーザが本当に欲しいもの」が作れているか確認するには、ユーザ自身が設計書をチェックするのが一番。利用部門（実際に使う人）が設計書のレビューに参加していれば、要件のズレを早く発見できます。

👉 覚え方：要件確認＝ユーザに見てもらうのが王道。

ほかの選択肢：a プログラム仕様書作成は設計の後工程の話／b テスト計画も設計後／c プログラミング標準は実装の話。

なぜこれが正解か

正解は d。ユーザ要件が充足されないリスクは「開発者の理解と実際の業務要件のズレ」から発生する。これを早期発見するには利用部門（業務側）がシステム設計書のレビューに参画することが最も有効。要件定義から設計工程までユーザ参画を確保する内部統制が監査ポイントとなる。

各選択肢の解説

• a：プログラム仕様書作成は実装準備の段階で、設計内容の妥当性確認とは別。
• b：システムテスト計画はテストフェーズの統制で、設計段階のリスクには対応しない。
• c：プログラミング標準遵守は実装品質の統制で、要件適合性は確認できない。

覚え方・ひっかけ注意

「ユーザ要件のズレ」対策＝ユーザ参画の組合せで覚える。システム監査では「コントロールの目的」と「監査ポイント」の対応関係を問う問題が定番。各工程の主要リスク（要件→ユーザ理解、設計→技術選定、実装→品質、テスト→網羅、運用→可用性）を整理。

理論的背景

システム監査は経済産業省「システム監査基準」・「システム管理基準」に基づき実施される。内部統制（COSO Framework、J-SOX法）の観点では、ITプロセス全般に対するIT全般統制（ITGC: IT General Controls）と、各業務システムでのIT業務処理統制（ITAC: IT Application Controls）に分類される。COBITはITガバナンスの国際フレームワークでプロセスごとの統制目標を体系化している。

実務での使われ方

システム設計段階の監査ではユーザ要件定義書のトレーサビリティ（要件→設計→実装→テストの追跡可能性）、設計レビュー記録（参加者・指摘事項・是正状況）、変更管理プロセスの遵守が中心観点。アジャイル開発ではスプリントレビューにプロダクトオーナー（ユーザ代表）が参加する仕組みが、本問の「利用部門参画」に相当する。

試験での位置づけ

基本情報・応用情報のサービスマネジメント・システム監査分野で頻出。監査の3段階（予備調査・本調査・評価結論）、監査技法（チェックリスト・ドキュメントレビュー・インタビュー・現地調査）、監査証拠の収集が出題される。システム監査技術者試験では監査計画・実施・報告書作成の実践能力が深掘りされる。

選択肢の発展補足

他選択肢も別の監査ポイントとして重要：a「プログラム仕様書」は設計→実装の橋渡しドキュメントとしての妥当性、b「テスト計画の運用部門承認」は本番移行リスクの軽減、c「プログラミング標準遵守」はソフトウェア品質の統制で、それぞれ別工程の典型監査ポイント。SLCP（共通フレーム）やシステム監査基準の体系を理解しておくと、どの工程のどのリスクに対する統制かを的確に判断できる。