ストーリー
佐
佐藤CTO
設計書は書いて終わりじゃない。レビューを通して初めて価値が生まれる
佐
佐藤CTO
レビューしやすい文書とは何か。それを理解するだけで、設計の質は格段に上がる
レビュー可能な設計書とは
| 特徴 | 説明 |
|---|---|
| 自己完結 | 前提知識なしで読める |
| 構造化 | 見出し・箇条書きで整理されている |
| 図表活用 | テキストの壁がない |
| 適切な粒度 | 詳しすぎず、粗すぎない |
| 決定の根拠明示 | 「なぜ」が説明されている |
レビューチェックリスト
アーキテクチャ設計書のレビュー観点
□ 品質要件が定量的に定義されているか
□ アーキテクチャスタイルの選択理由が明確か
□ トレードオフが明示されているか
□ セキュリティが考慮されているか
□ スケーラビリティの戦略があるか
□ 障害時の振る舞いが定義されているか
□ デプロイ戦略が記述されているか
□ モニタリング・アラートの方針があるか
□ 技術的負債のリスクが認識されているか
□ 図が最新で、テキストと一致しているかフィードバックの受け方
| ステップ | アクション |
|---|---|
| 1. 感謝する | フィードバックは改善の機会 |
| 2. 明確化する | 不明点は質問して理解する |
| 3. 判断する | 取り入れるか、理由を述べて対案を示す |
| 4. 更新する | 設計書に反映し、変更箇所を明示する |
Living Documentation
設計書を「生きた文書」として維持する方法：
- Markdown + Git: バージョン管理と差分追跡
- PR レビュー: コードと同じレビュープロセス
- 自動生成: コードからの図の自動生成（Structurizr DSL等）
- 定期見直し: 四半期ごとにアーキテクチャ棚卸し
まとめ
| ポイント | 内容 |
|---|---|
| レビュー容易性 | 構造化・図表・根拠明示でレビューしやすくする |
| チェックリスト | 観点を事前に定義してレビュー品質を均一化 |
| フィードバック | 建設的に受け入れ設計を改善する |
| 継続更新 | Living Documentationとして維持する |
チェックリスト
- レビュー可能な設計書の特徴を理解した
- レビューチェックリストの観点を把握した
- フィードバックの受け方を理解した
次のステップへ
次は演習で、実際にアーキテクチャ設計書を作成します。
推定読了時間: 15分