基本情報技術者 2014年 春期 午前（科目A） 問59

利用者参画による設計レビュー【午前解説】

正解の理由

解法ステップ

1. 問題文のキーワードを抽出：「システム設計の段階」「利用者要件が充足されないリスクを低減」「コントロール」「監査のチェックポイント」。
2. 「設計段階でのリスク低減」に直結する手段は何かを考える（早期の妥当性確認、ステークホルダ参画）。
3. 各選択肢を「いつ実施されるか（設計段階か否か）」と「利用者の関与があるか」で評価する。
4. 設計段階で利用者が能動的に関与する選択肢を最優先と判断する。

選択肢別の誤答解説

• ア: システム設計書に基づき、プログラム仕様書を作成していること
  • 解説: これは設計から実装への移行プロセスであり、プログラム仕様作成は設計の検証ではなく実装準備です。利用者の要件妥当性確認とは直接結びつきません。
• イ: システムテスト要件に基づいてテスト計画を作成し、システム運用部門の責任者の承認を得ていること
  • 解説: テスト計画は検出手段であり、テスト段階で要件違反を発見できますが、設計段階での早期是正には遅いためリスク低減の効果が限定的です。
• ウ: プログラミングは定められた標準に従っていること
  • 解説: コーディング標準は品質や保守性を向上させますが、利用者要件の妥当性確認や業務適合性の検証には直結しません。
• エ: 利用部門が参画して、システム設計書のレビューを行っていること（正解）
  • 解説: 利用者が設計段階でレビューに参加することで、要件の誤解や見落としを早期に発見し是正できるため最も有効です。

よくある誤解

• 「テスト計画やプログラミング標準が整っていれば要件問題は防げる」は誤り。これらは検出の手段や品質管理であり、設計段階での要件誤認を未然に防ぐ手段ではありません。
• 「利用部門の参画＝形だけの会議出席」では不十分。参加の深さ（実務担当者の発言、レビュー結果の反映、承認の記録）が重要です。
• 「レビューは開発側だけで完結してよい」という考えは不可。利用者視点での妥当性確認が欠けると運用後に要望と異なるシステムになる恐れがあります。

補足コラム

• 監査で高評価となる実務的な証跡例：レビュー議事録、レビュー指摘一覧と対応履歴、利用部門の正式な承認（署名や承認メール）、要件トレーサビリティマトリクス（要件→設計→テストの対応表）。
• 開発プロセスでは「Shift Left（左方移行）」の考え方が重要で、検出や是正を可能な限り早い段階に移すことでコストとリスクを低減します。設計レビューはその代表的な手法です。
• レビューの形式はインスペクション、ウォークスルー、ワークショップなどがあり、利用部門の役割に応じて適切な形式を選ぶと効果が高まります。

FAQ