Home
Get Started
実践ガイド
外部仕様設計
バッチ処理仕様設計
UAC 仕様設計
データ仕様設計
インフラ設計
移行計画
テスト方針・計画
開発プロセス・規約
基本設計書の承認と変更管理
基本設計書の正式な承認プロセスを定義し、承認後の変更を適切に管理することで、設計の確定とトレーサビリティを確保します。
🎯 概要
- 目的: 基本設計書の正式な承認プロセスを定義し、承認後の変更を適切に管理することで、設計の確定とトレーサビリティを確保する
- スコープ: 基本設計書の承認フロー、承認基準、承認記録の管理、承認後の変更管理プロセス、版数管理を対象とする
- 推奨する実施タイミング: 全レビューが完了し、すべての指摘事項への対応が完了した後に承認プロセスを開始する。承認後の変更は変更管理プロセスに従う
- 関連するステークホルダー: 技術責任者、セキュリティ責任者、プロジェクトマネージャー、事業責任者、設計担当者、変更管理担当者
📥 重要な前提知識・インプット
- 前提知識: 組織の承認フローと意思決定プロセス、変更管理の基本概念、版数管理とベースラインの理解、プロジェクトガバナンスの基礎
- インプット: レビュー完了済みの基本設計書、レビュー記録・指摘事項対応記録、承認者リストと承認基準、組織の変更管理規約、プロジェクト管理計画書
📄 成果物の定義
- ドキュメントテンプレート: 📄
[テンプレ]承認履歴
- 必須要素: 承認記録表(承認No、承認日、承認者、役割、承認範囲、コメント、署名)、変更管理台帳(変更No、変更日、変更箇所、変更理由、変更内容、影響度、承認者)、版数管理表(版数、日付、変更内容、作成者、承認者)
✅ 品質基準・承認観点
✅ 品質チェックリスト:
| チェック項目 | チェック内容 |
|---|---|
| 承認フローの完全性 | 定義された承認階層に従って、すべての必要な承認者から承認を得ている |
| 承認記録の明確性 | 承認日、承認者、承認範囲、コメントが明確に記録されている |
| 変更管理の追跡可能性 | 承認後の変更がすべて変更管理台帳に記録され、影響度に応じた承認が得られている |
| 版数管理の一貫性 | 版数管理表が正確に更新され、各版の変更内容が明確に記録されている |
👁️🗨️ 承認観点:
- 技術的妥当性: 技術選定、アーキテクチャ設計が適切で実現可能か(技術責任者)
- セキュリティ要件充足: セキュリティ要件を満たし、脆弱性対策が適切か(セキュリティ責任者)
- プロジェクト実行可能性: スケジュール・コスト・リスクが許容範囲内か(プロジェクトマネージャー)
- ビジネス整合性: ビジネス要件と整合し、投資対効果が見込めるか(事業責任者)
- 完全性: すべてのレビュー指摘事項が対応済みで、設計書が完成状態にあるか(全承認者共通)
🧪成果物のサンプル
# 承認履歴
設計書の内容が、プロジェクトの主要な意思決定者によって正式に承認されたことを明示します。
## 承認記録テーブル
- 承認書原本: [approval-documents.pdf](approvals/approval-documents.pdf)
| 承認No | 承認日 | 承認者 | 役割 | 承認範囲 | コメント | 署名 |
|-------|--------|-------|------|---------|---------|------|
| APP-001 | 2025-12-10 | 山田太郎 | 技術責任者 | 技術設計全般 | 技術的に問題なし。承認します。 | [署名リンク] |
| APP-002 | 2025-12-11 | 佐藤花子 | セキュリティ責任者 | セキュリティ設計 | セキュリティ要件を満たしています。 | [署名リンク] |
| APP-003 | 2025-12-12 | 鈴木一郎 | プロジェクトマネージャー | 全体 | 次工程への移行を承認します。 | [署名リンク] |
| APP-004 | - | 田中次郎 | 事業責任者 | ビジネス整合性 | 承認待ち | - |
## 承認プロセスフロー
```mermaid
graph TB
A[全レビュー完了] --> B[承認依頼]
B --> C[技術責任者承認]
C --> D{承認?}
D -->|No| E[差し戻し]
E --> F[修正]
F --> B
D -->|Yes| G[セキュリティ責任者承認]
G --> H{承認?}
H -->|No| E
H -->|Yes| I[PM承認]
I --> J{承認?}
J -->|No| E
J -->|Yes| K[事業責任者承認]
K --> L{承認?}
L -->|No| E
L -->|Yes| M[設計書確定]
M --> N[ベースライン設定]
N --> O[開発工程開始]
```
## 承認階層
```mermaid
graph TD
A[事業責任者] --> B[プロジェクトマネージャー]
B --> C[技術責任者]
B --> D[セキュリティ責任者]
C --> E[アーキテクト]
C --> F[インフラ担当]
D --> G[セキュリティ担当]
```
## 承認基準
各承認者は、以下の基準に基づいて承認を行います。
| 承認者 | 承認基準 |
|-------|---------|
| 技術責任者 | ・技術選定が適切である<br>・アーキテクチャが要件を満たす<br>・技術的リスクが管理されている |
| セキュリティ責任者 | ・セキュリティ要件を満たす<br>・脆弱性対策が適切である<br>・コンプライアンスに準拠している |
| プロジェクトマネージャー | ・スケジュール・コストが妥当<br>・リスクが許容範囲内<br>・品質基準を満たす |
| 事業責任者 | ・ビジネス要件と整合する<br>・投資対効果が見込める<br>・事業戦略と合致する |
## 承認後の変更管理
設計書が承認され、ベースラインとして確定した後の変更は、変更管理プロセスに従います。
**変更管理フロー**:
```mermaid
graph TB
A[変更要求] --> B{影響度評価}
B -->|軽微| C[担当者判断]
B -->|中程度| D[PM承認]
B -->|重大| E[再承認プロセス]
C --> F[変更実施]
D --> F
E --> G[全承認者による再承認]
G --> F
F --> H[変更履歴記録]
H --> I[関係者通知]
```
**変更履歴テーブル**:
- 変更管理台帳: [change-log.xlsx](changes/change-log.xlsx)
| 変更No | 変更日 | 変更箇所 | 変更理由 | 変更内容 | 影響度 | 承認者 |
|-------|--------|---------|---------|---------|-------|-------|
| CHG-001 | 2025-12-15 | 2.2 API設計 | 新規要件追加 | [エンドポイント2つ追加](管理台帳リンク) | 中 | 山田太郎 |
| CHG-002 | 2025-12-18 | 5.1 インフラ構成 | コスト最適化 | [インスタンスタイプ変更](管理台帳リンク) | 軽微 | 佐藤花子 |
---
## ドキュメント版数管理
| 版数 | 日付 | 変更内容 | 作成者 | 承認者 |
|------|------|---------|-------|-------|
| 0.1 | 2025-11-15 | 初版作成 | 開発チーム | - |
| 0.5 | 2025-12-01 | 技術レビュー反映 | 開発チーム | - |
| 0.9 | 2025-12-08 | 全レビュー反映 | 開発チーム | - |
| 1.0 | 2025-12-12 | 正式承認版 | 開発チーム | 全承認者 |
| 1.1 | 2025-12-15 | 変更要求CHG-001反映 | 開発チーム | PM |
--- 🔄 設計の進め方・プロセス
📝 プロセス1: 承認準備と承認依頼
実施内容:
全レビューが完了し、すべての指摘事項への対応が完了したことを確認した上で、承認依頼を行う。
具体例:
- すべてのレビュー記録を確認し、指摘事項がすべて「完了」ステータスになっていることを検証
- 承認記録テンプレートを準備し、承認者リスト、承認階層、承認基準を明記
- 承認依頼書を作成し、基本設計書と関連資料(レビュー記録、指摘事項対応記録)を添付して承認者に送付
準備のポイント:
- 完了条件の確認: 承認申請の前提条件(全レビュー完了、全指摘対応完了)が満たされていることを確認
- 承認順序の明確化: 承認階層に従って、どの順序で承認を得るかを明確にする(技術責任者→セキュリティ責任者→PM→事業責任者など)
- 承認期限の設定: 各承認者に対して承認期限を設定し、スケジュールに余裕を持たせる
文書化の推奨表現:
- 承認依頼書に承認対象範囲、承認基準、承認期限を明記
- 承認記録表を準備し、承認者ごとの承認状況を追跡可能にする
📝 プロセス2: 承認プロセスの実施と記録
実施内容:
承認階層に従って順次承認を得て、各承認者からの承認記録を取得する。
具体例:
- 技術責任者から技術設計全般に対する承認を得て、承認記録表に承認日、コメント、署名を記録
- セキュリティ責任者からセキュリティ設計に対する承認を得て、同様に記録
- プロジェクトマネージャーから全体承認を得て記録
- 事業責任者からビジネス整合性の承認を得て記録
- 差し戻しがあった場合は、修正を実施し、再度承認依頼を行う
実施のポイント:
- 承認基準の明確化: 各承認者が何を基準に承認するかを事前に明確にし、承認依頼時に伝える
- 差し戻し対応: 差し戻しがあった場合は、指摘内容を明確にし、迅速に修正して再承認を得る
- 承認記録の完全性: 承認者、承認日、承認範囲、コメント、署名をすべて記録し、後から検証可能にする
文書化の推奨表現:
- 承認記録表に各承認者の承認No、承認日、承認者名、役割、承認範囲、コメント、署名を記録
- 差し戻しがあった場合は、差し戻し理由と修正内容を記録
📝 プロセス3: ベースライン設定と版数確定
実施内容:
全承認者から承認を得た後、基本設計書を正式版として確定し、ベースラインを設定する。
具体例:
- 版数管理表を更新し、承認版の版数(例: 1.0)、承認日、承認者を記録
- 設計書のドキュメント管理システムまたはリポジトリにベースラインタグを設定
- 関係者に承認完了と次工程開始を通知
確定のポイント:
- ベースラインの固定: 承認後の設計書を「ベースライン」として固定し、以降の変更は変更管理プロセスに従う
- 版数の明確化: 承認版の版数を明確にし、以降の変更版と区別する
- アーカイブ化: 承認版をアーカイブし、後から参照可能にする
文書化の推奨表現:
- 版数管理表に「1.0 正式承認版」として記録
- 承認完了通知書を作成し、関係者に配信
📝 プロセス4: 承認後の変更管理
実施内容:
承認後に変更要求が発生した場合、変更管理プロセスに従って影響度を評価し、適切な承認を得て変更を実施する。
具体例:
- 変更要求を受け付けたら、変更箇所、変更理由、変更内容を明確にする
- 影響度を評価し、軽微(担当者判断)、中程度(PM承認)、重大(再承認プロセス)に分類
- 影響度に応じた承認を得て、変更を実施
- 変更管理台帳に変更No、変更日、変更箇所、変更理由、変更内容、影響度、承認者を記録
- 版数管理表を更新し、変更版の版数(例: 1.1)を記録
変更管理のポイント:
- 影響度評価の基準: 軽微な変更(誤字脱字、表記統一)、中程度の変更(機能追加、設計変更)、重大な変更(アーキテクチャ変更、要件変更)を明確に定義
- 変更履歴の追跡: すべての変更を変更管理台帳に記録し、トレーサビリティを確保
- 関係者への通知: 変更が承認されたら、関係者に変更内容を通知
文書化の推奨表現:
- 変更管理台帳に変更No、変更日、変更箇所、変更理由、変更内容、影響度、承認者を記録
- 版数管理表に変更版の版数、変更内容、承認者を記録
🚨 よくある失敗と予防策
🚧 実例収集後、追記予定
📚 参考資料・関連リンク
- 参考文献: プロジェクトガバナンス標準、変更管理ガイドライン、CMMI(能力成熟度モデル統合)、ISO/IEC 12207(ソフトウェアライフサイクルプロセス)
- 関連する他のガイド: 基本設計書レビューガイド、基本設計書 改訂履歴、要件トレーサビリティマトリクス、プロジェクト管理計画書
- ツール・テンプレート: 承認記録テンプレート、変更管理台帳テンプレート、版数管理表テンプレート、承認依頼書テンプレート
テンプレートサイト: 📄テンプレート集