基本情報 平成26年度 秋期 問59：マネジメント系に関する問題

答えは d「利用部門が設計書のレビューに参加していること」です。

設計書はITの専門用語だらけ。これを開発者だけで作って終わると、使う人（利用部門）が「これじゃ使えない！」と後で大問題になります。

だから設計段階で利用部門にも見てもらって「本当に欲しかったのはこれ？」を確認するのが大事。

👉 覚え方：「使う人もチェックしてれば、間違いが減る」。

ほかの選択肢：a プログラム仕様書作成＝設計後の話／b テスト計画の承認＝テスト段階／c コーディング標準＝プログラミング段階。利用者要件のチェックは d だけ。

なぜこれが正解か

正解は d。設計段階で利用者要件が充足されないリスクを低減するには、要件を最もよく知る「利用部門」が設計レビューに参加し、設計内容が要件を満たしているかを直接確認する必要がある。これにより手戻り防止と業務適合性が担保される。

各選択肢の解説

• a 誤り：プログラム仕様書作成は設計の下流工程。利用者要件充足の直接コントロールではない。
• b 誤り：システムテスト計画の承認は次フェーズの品質保証で、利用者要件の検証は受入テスト段階。
• c 誤り：コーディング標準遵守は実装段階の品質管理で、要件充足とは異なる観点。

覚え方・ひっかけ注意

「要件＝利用部門」「設計＝開発部門」「テスト＝品質保証部門」と工程別に責任部門を整理。要件充足リスクの対策は早期に利用部門を巻き込むこと（レビュー・プロトタイプ・JAD）。後工程に行くほど修正コストが指数関数的に増える点（Boehmの法則）も押さえる。

理論的背景

システム監査基準（経済産業省）における「コントロール」とは、目標達成を阻害するリスクを低減する仕組み（IT統制）。利用者要件充足リスクは要件定義〜設計フェーズで顕在化し、対応策として「ステークホルダー参画」「設計レビュー」「プロトタイピング」「ユーザビリティテスト」がある。COBIT 2019では「APO（Align, Plan and Organise）」と「BAI（Build, Acquire and Implement）」の境界に位置する論点。

実務での使われ方

設計レビュー（Design Review：DR）は社内外の関係者を集めた公式レビュー会議。日本企業ではDR-1（基本設計）、DR-2（詳細設計）、DR-3（製造前）と多段階で実施するのが一般的。アジャイル開発ではスプリントレビューで同等の機能を果たす。要件充足の追跡には要件トレーサビリティマトリクス（RTM）が用いられ、要件→設計→実装→テストのリンクを可視化する。

試験での位置づけ

システム監査・情報処理安全確保支援士・システム監査技術者試験で頻出。基本情報では「監査のチェックポイント」を問う形式が定番。近年はDXとの絡みで「アジャイル監査」「クラウド利用時の責任分界」も出題される。

選択肢の発展補足

• aの「プログラム仕様書」作成は設計工程の整流性に関するコントロールで、別観点の監査ポイント。
• bのシステムテスト計画は「テスト計画の妥当性」というコントロール。誰の承認を取るかも論点（運用部門・利用部門・経営層）。
• cのコーディング標準遵守は実装品質のコントロールで、プログラム品質監査のチェックポイント。
• 設計レビューの形式（ウォークスルー・インスペクション・ピアレビュー）の差は別途頻出。