基本設計書のレビュー

目的: 基本設計書の品質を体系的に検証し、設計上の問題や不整合を早期に発見・是正することで、後工程でのリスクを低減する
スコープ: 基本設計書の技術レビュー、セキュリティレビュー、品質レビュー、ステークホルダーレビューを対象とする。レビュー計画、実施、指摘事項管理、承認までのプロセス全体を含む
推奨する実施タイミング: 各章の完成時、全体完成時、承認申請前の段階的なレビューを実施する
関連するステークホルダー: プロジェクトマネージャー、設計担当者、アーキテクト、セキュリティ担当、QA担当、レビュアー、承認者

📥 重要な前提知識・インプット

前提知識: レビュー技法の基本、設計ドキュメントの読解力、技術アーキテクチャの理解、セキュリティ・品質の基礎知識
インプット: 完成した基本設計書、要件定義書、非機能要件仕様書、レビューチェックリスト、プロジェクトの品質基準

📄 成果物の定義

ドキュメントテンプレート: 📄[テンプレ]レビュー履歴
必須要素: レビュー記録表(レビューNo、実施日、レビュー種別、レビュー対象、レビュアー、指摘件数、ステータス)、指摘事項管理表(指摘ID、指摘内容、重要度、対応内容、対応者、対応日、ステータス)

✅ 品質基準・レビュー観点

✅ 品質チェックリスト:

チェック項目	チェック内容
レビュー計画の妥当性	適切なレビュー種別とタイミングが設定されている
レビュアーの適格性	各レビュー種別に対して適切な専門性を持つレビュアーがアサインされている
指摘事項の網羅性	技術、セキュリティ、品質、ビジネス要件の観点から漏れなく検証されている
対応状況の追跡	すべての指摘事項に対する対応状況が記録され、未対応項目が明確になっている

👁️‍🗨️ レビュー観点:

設計の完全性: 要件定義で定義されたすべての要件が基本設計でカバーされているか
技術的妥当性: 技術選定、アーキテクチャ設計、パフォーマンス設計が適切か
セキュリティ: セキュリティ要件が充足され、脆弱性リスクが適切に管理されているか
整合性: 各章間、要件定義との間で矛盾や不整合がないか
実現可能性: 設計内容が技術的・コスト的・スケジュール的に実現可能か
保守性: 将来の変更や拡張に対応しやすい設計になっているか

🧪成果物のサンプル

# レビュー履歴

設計書がどのようなプロセスを経て検証され、改善されてきたかを記録し、その品質保証プロセスを可視化することを目的とします。

## レビュー記録テーブル

| レビューNo | 実施日 | レビュー種別 | レビュー対象 | レビュアー | 指摘件数 | ステータス |
|-----------|--------|------------|------------|----------|---------|----------|
| REV-001 | 2025-12-01 | 技術レビュー | 2章：システム方式設計 | 山田太郎（アーキテクト） | 5 | 完了 |
| REV-002 | 2025-12-05 | セキュリティレビュー | 5章：インフラ設計 | 佐藤花子（セキュリティ） | 3 | 完了 |
| REV-003 | 2025-12-08 | 品質レビュー | 全体 | 鈴木一郎（QAリード） | 7 | 対応中 |

## レビュー指摘事項の管理

- レビュー指摘事項詳細: [レビュー指摘事項一覧.xlsx](reviews/レビュー指摘事項一覧.xlsx)

**指摘事項の記録例**:

| 指摘ID | レビューNo | 章 | 指摘内容 | 重要度 | 対応内容 | 対応者 | 対応日 | ステータス |
|-------|-----------|---|---------|-------|---------|-------|--------|----------|
| ISS-001 | REV-001 | 2.1 | 冗長化構成の詳細が不足 | 高 | 冗長化の構成図を追加 | 田中 | 2025-12-02 | 完了 |
| ISS-002 | REV-001 | 2.3 | APIのバージョニング戦略が未定義 | 中 | バージョニングポリシーを追加 | 高橋 | 2025-12-03 | 完了 |
| ISS-003 | REV-002 | 5.2 | ネットワークセグメント分離が不十分 | 高 | セグメント構成を見直し | 伊藤 | 2025-12-06 | 完了 |
| ISS-004 | REV-003 | 4.1 | データモデルの正規化レベル要確認 | 中 | 正規化の根拠を追記 | 渡辺 | - | 対応中 |

**重要度の定義**:
- **高**: 設計の根幹に関わる、対応必須の指摘
- **中**: 品質向上のため対応が望ましい指摘
- **低**: 参考情報、必要に応じて対応

## レビュープロセスフロー

```mermaid
graph TB
    A[設計書作成] --> B[レビュー依頼]
    B --> C{レビュー種別}
    
    C -->|技術レビュー| D[アーキテクト確認]
    C -->|セキュリティレビュー| E[セキュリティ担当確認]
    C -->|品質レビュー| F[QA担当確認]
    
    D --> G[指摘事項登録]
    E --> G
    F --> G
    
    G --> H{指摘あり?}
    H -->|Yes| I[対応実施]
    H -->|No| J[レビュー完了]
    
    I --> K[対応内容レビュー]
    K --> L{承認?}
    L -->|Yes| J
    L -->|No| I
    
    J --> M[次工程へ]
```

## レビュー種別と実施タイミング

| レビュー種別 | 実施タイミング | 主なチェック項目 | 参加者 |
|------------|--------------|----------------|-------|
| 技術レビュー | 各章完成時 | ・技術選定の妥当性<br>・アーキテクチャの整合性<br>・パフォーマンス要件の充足 | アーキテクト、テックリード |
| セキュリティレビュー | インフラ設計完成時 | ・セキュリティ要件の充足<br>・脆弱性リスク<br>・認証認可の設計 | セキュリティ担当、インフラ担当 |
| 品質レビュー | 全体完成時 | ・ドキュメント品質<br>・テスト方針の妥当性<br>・非機能要件の充足 | QAリード、プロジェクトマネージャー |
| ステークホルダーレビュー | 承認前 | ・ビジネス要件との整合性<br>・コスト・スケジュール<br>・リスク評価 | プロダクトオーナー、事業責任者 |

---