ITパスポート 2019年 春期 問51

システムの設計書が利用者要求を満たしているかを確認するもの【ITパスポート 解説】

正解の理由

• 共同レビュー：関係者（利用者、開発者、品質担当など）が集まり設計書などを点検する活動。英語では joint review に相当。
• 設計書：システムをどのように作るかを記した文書。要求仕様を開発側が実装できる形に落としたもの。

解法ステップ

1. 問題の目的を確認する：「設計書の記載内容が利用者の要求を満たしていることを確認する」点検活動を問う。
2. 各選択肢の活動の目的を短く把握する。
   • 共同レビュー：文書を点検し合意する活動。
   • 結合テスト：部品を組み合わせて動作を確かめるテスト（integration test）。
   • シミュレーション：実際の動きを模擬して挙動を確認すること。
   • 進捗会議：スケジュールや進み具合を確認する会議。
3. 「文書を利用者と開発者が一緒に確認する」という条件に合うのは文書点検活動であると判断して、アを選ぶ。
4. 残りを理由で除外する（テスト・模擬・スケジュール確認は目的が異なる）。

選択肢別の誤答解説

• ア：共同レビューは設計書を関係者で読み合わせ、要求との整合を確認する活動です。利用者の意図を直接確認できるため正解です。
• イ（結合テスト）：結合テストは複数の部品やモジュールをつなげて、相互の動作を確認する試験です。実際に動くソフトウェアを対象にするため、「設計書の記載内容」を文書の段階で利用者と確認する目的には合いません。
• ウ（シミュレーション）：シミュレーションはシステムの振る舞いを模擬して評価する方法です。動作の検証には有効ですが、設計書の記述が要求に合っていることを利用者と文書ベースで確認する「共同確認」そのものではありません。
• エ（進捗会議）：進捗会議は工数やスケジュールの管理が主目的です。設計書の内容検証を目的とした会議とは異なります。

よくある誤解

1. 「テスト（結合テスト）で要件が満たされているか確認できる」は誤解です。テストは動作確認が主です。設計書の記載が要求に合っているかを文書ベースで利用者と合意するためにはレビューが必要です。
2. 「進捗会議で内容の確認もするだろう」と考えるミス。進捗会議は主にスケジュール確認で、詳細な設計内容の検証や合意形成には向きません。
3. 「シミュレーション＝文書確認」と混同すること。シミュレーションは挙動確認に向くが、設計書の記述の正しさや利用者の要求解釈の確認は、共同レビューのような議論と合意が必要です。

補足コラム

• ウォークスルー（walkthrough）：作成者が設計書を説明し、参加者が質問・指摘を行う。学習的要素が強い。
• インスペクション（inspection）：チェックリストに基づき厳格に欠陥を探す。形式的で品質確保向け。
  どちらも目的は「設計が要求通りか、誤りや抜けがないかを早期に見つける」ことです。ユーザー（利用者）を早めに巻き込むと、後で修正コストが増えるのを防げます。開発では「後で動かしてから気づく」より「文書の段階で気づく」方が安上がりです。

• 事前にチェックリストを配る（要求との整合、機能一覧、データ仕様など）。
• 指摘は「事実」と「影響」で出す（例：項目Aの説明がない → 要件が満たされるか不明）。
• 指摘はチケットやIssueで記録して責任者を明確にする。

FAQ