基本情報技術者 2011年 秋期 午前（科目A） 問58

要点まとめ

• 結論: 利用部門が参画してシステム設計書のレビューを行っていることが、ユーザ要件未充足のリスクを最も低減します。
• 根拠: 設計段階で利用者の期待や業務制約を確認しないと、後工程での手戻りや誤実装が発生しやすいためです。
• 差がつくポイント: 参画の実態（出席者、議事録、指摘の追跡と是正）や要件トレーサビリティを監査で重視してください。

正解の理由

よくある誤解

• 参画＝形式的出席と考える: 参加者名だけでは不十分で、議論の内容や是正履歴が重要です。
• テスト計画の承認で要件確認が完了すると思う: テストは結果検証手段であり、設計段階の要件確認を代替できません。
• コーディング標準の順守で要件は満たされると誤解する: 標準は品質維持に寄与しますが、要件適合性そのものを保証しません。

解法ステップ

1. 問題文のキーワードを確認：「システム設計の段階」「ユーザ要件が充足されないリスクを低減」
2. 設計段階で直接的に要件検証・承認を行うコントロールを選ぶ（利用部門の参画・レビュー等）。
3. 他の選択肢が「後工程の活動」か「品質維持の手段」かを区別して除外する。
4. 監査証拠（議事録、欠陥一覧、トレーサビリティ）を意識して正答を裏付ける。

選択肢別の誤答解説

• ア: システム設計書に基づき、プログラム仕様書を作成していること
  • 説明: 設計から実装への引き継ぎが適切であることを示すが、利用者の要件確認を確保するコントロールではありません。変換ミスが発生している場合は既に問題が残っています。
• イ: システムテスト要件に基づいてテスト計画を作成し、システム運用部門の責任者の承認を得ていること
  • 説明: テスト計画と運用承認は運用性や受入準備の評価に有効ですが、設計段階での要件解釈や業務適合性の検証という点では間接的です。利用部門の承認が無ければ要件充足は保証されません。
• ウ: プログラミングは定められた標準に従っていること
  • 説明: コーディング標準は保守性や品質確保に寄与しますが、業務要件が正しく反映されているかを担保するものではありません。
• エ: 利用部門が参画して、システム設計書のレビューを行っていること（正解）
  • 説明: 利用部門の参画は要件の妥当性確認と受入基準の合意を早期に得るための最も直接的で有効なコントロールです。レビューのエビデンスが監査で重要になります。

補足コラム

• トレーサビリティマトリクスを活用すると、要件→設計→実装→テストの対応関係を明確化でき、設計時点での抜け漏れ発見に有効です。
• 監査で確認すべき証憑の例：設計レビュー議事録、出席者名簿、指摘一覧と対応記録、利用部門の承認サイン、要件トレーサビリティ表。
• 実務では「設計レビュー」→「プロトタイプの利用者確認」→「ユーザ受入テスト（UAT）」の組合せで要件充足を段階的に保証します。設計レビューはその最初の鍵です。

FAQ