はじめに
設計書に必要な項目が記載されていても、その設計が正しいとは限りません。
要件との不一致や設計同士の矛盾、異常時の考慮漏れが残ったまま実装へ進むと、後から大きな修正が必要になります。
設計レビューは、設計上の判断が要件や制約を満たし、実装やテストへ進める状態かを確認する活動です。
この記事で分かること
- 設計レビューを行う目的
- 設計レビューで確認する内容
- 設計レビューの基本的な進め方
- 設計レビューの完了条件
設計レビューとは
設計レビューとは、設計書や関連資料をもとに、設計上の判断が妥当かを確認する活動です。
主に次のような問題がないかを確認します。
- 要件と設計が一致していない
- 基本設計と詳細設計に矛盾がある
- 必要な条件や処理が決まっていない
- 実装やテストで判断できない
- 技術的に実現できない
設計書が設計上の判断を記録する成果物であるのに対し、設計レビューは、その判断を確認する活動です。
| 項目 | 役割 |
|---|---|
| 設計 | 要件を実現する方法を決める |
| 設計書 | 設計で決めた内容を記録して共有する |
| 設計レビュー | 設計上の判断が妥当か確認する |
| コードレビュー | 実装されたコードを確認する |
設計レビューは、誤字脱字を探す作業や、レビュー担当者の好みを反映する場ではありません。
設計レビューを行う目的
設計レビューには、主に三つの目的があります。
実装前に問題を見つける
設計の問題を実装後に発見すると、プログラムだけでなく、テストや関連機能の修正も必要になります。
設計段階で不一致や考慮漏れを見つけることで、後工程での手戻りを減らします。
複数の立場から確認する
設計者、実装者、テスト担当者、運用担当者では、設計を見る観点が異なります。
実装担当者は実現可能性、テスト担当者は確認可能性、運用担当者は運用時や障害時の扱いを確認します。
複数の立場から見ることで、設計者だけでは気づきにくい問題を見つけられます。
次の工程へ進めるか判断する
設計レビューは、問題を指摘するだけの活動ではありません。
重要な問題と未決事項を整理し、実装やテストを開始できる状態かを判断します。
設計レビューで確認する三つの観点
設計レビューでは、次の三つの観点から設計全体を確認します。
要件や制約と整合しているか
設計が、前提となる要件や制約を満たしているか確認します。
- 必要な機能を実現できるか
- 権限や利用条件を満たしているか
- 性能やセキュリティの条件を満たしているか
- 外部システムや既存システムの制約に反していないか
- 基本設計と詳細設計に矛盾がないか
設計内容だけを見るのではなく、何を実現するための設計なのかを基準に評価します。
必要な判断が揃っているか
実装やテストに必要な内容が決まっているか確認します。
- 正常時の処理が決まっているか
- 異常時や境界条件の扱いが決まっているか
- 画面、処理、データの関係が明確か
- 権限による動作の違いが決まっているか
- 重要な判断の前提や理由が分かるか
テンプレートの項目が埋まっていても、後の担当者が処理方法を推測しなければならない状態では不十分です。
後続工程で利用できるか
設計内容が、実装やテストで利用できる状態か確認します。
- 実装者が同じ前提で処理を作れるか
- テスト担当者が期待する結果を判断できるか
- 完成後に設計どおりか判定できるか
- 変更時に影響範囲を追跡できるか
内容を理解できても、完成後の合否を判定できなければ、設計として十分に具体化されていません。
設計レビューの進め方
設計レビューは、次の流れで進めます。
1．対象範囲と確認基準を決める
どの機能や設計書を対象とするのかを明確にします。
あわせて、要件、制約、上位設計、社内ルールなど、確認の基準となる資料を整理します。
基準が曖昧なままでは、担当者の好みによる指摘が増えてしまいます。
2．資料を共有して事前に確認する
設計書と関連資料を事前に共有し、各担当者が自分の立場から確認します。
レビューの場で初めて内容を読む状態では、設計の説明だけで時間を使い、十分な確認ができません。
3．指摘と対応方針を整理する
指摘された問題について、修正するのか、対応しないのか、追加の調査が必要なのかを決めます。
すぐに結論が出ない内容は、未決事項として担当者と期限を明確にします。
対応しない指摘についても、理由を残します。
4．確定した内容を設計書へ反映する
レビューで決まった内容は、議事録だけで終わらせず、設計書へ反映します。
設計書が更新されなければ、実装者やテスト担当者が古い内容を参照する可能性があります。
5．完了条件を確認する
修正後の設計を確認し、実装やテストを開始できるか判断します。
指摘をすべて閉じることではなく、重大な問題が解消され、残る未決事項やリスクが管理されていることを確認します。
注文履歴機能をレビューする例
注文履歴機能を例にすると、次のような内容を確認します。
| 確認対象 | レビューで確認する内容 |
|---|---|
| 閲覧権限 | 権限ごとの閲覧範囲が明確か |
| 検索期間 | 保存期間や検索可能期間が要件と一致しているか |
| 検索結果 | 0件の場合とデータ取得失敗時の扱いが区別されているか |
| 性能 | 注文件数が多い場合でも必要な応答時間を満たせるか |
| テスト | 権限や異常時ごとの期待結果を判定できるか |
例えば、利用者、上司、管理者で閲覧範囲が異なる設計であれば、それぞれが閲覧できる注文履歴の範囲を明記する必要があります。
「権限に応じて制限する」とだけ記載されていても、設計が正しいか判定できません。
設計レビューを形骸化させないために
設計レビューが機能しなくなる主な原因は、次の三つです。
確認基準が決まっていない
要件や制約などの基準がなければ、誤字脱字や表現の好みを指摘するだけのレビューになります。
何と照らして設計を確認するのかを、あらかじめ明確にします。
指摘を出すことが目的になっている
指摘件数の多さは、レビューの品質を表しません。
重要なのは、設計上の問題を見つけ、対応方針を決めることです。
結論が設計書へ反映されていない
口頭で結論を出しても、設計書が更新されなければ、確定した内容を後続工程へ引き継げません。
レビュー結果は、設計書と未決事項の管理へ反映します。
設計レビューの完了条件
設計レビューは、次の状態を確認して完了とします。
- 要件や制約との重大な不整合が解消されている
- 実装やテストに必要な判断が揃っている
- 後続工程を止める未決事項が解消されている
- 残る未決事項に担当者、期限、影響範囲が設定されている
- 確定した内容が設計書へ反映されている
- 残っているリスクを関係者が認識している
- 実装やテストを同じ前提で開始できる
指摘がなくなることが完了ではありません。
後続工程を止める問題が解消され、残る未決事項やリスクが管理されたうえで、次の工程へ進めると判断できることが完了の基準です。
まとめ
設計レビューとは、設計上の判断が要件や制約を満たしているかを確認する活動です。
要件や制約との整合性、必要な判断の十分性、後続工程での利用可能性という三つの観点から確認します。
レビューでは、問題を指摘するだけでなく、対応方針を決め、確定した内容を設計書へ反映する必要があります。
重大な問題が解消され、残る未決事項とリスクが管理され、実装やテストを開始できる状態になったかで完了を判断します。
コメント