architecture-design-review

アーキテクチャ設計レビュー

体系的なアーキテクチャ設計レビューを実施し、システム設計を検証し、品質特性を評価し、技術選定を評価して、実装前にリスクを特定します。

レビュープロセス

包括的なアーキテクチャレビューを実施するため、以下の手順に従います。

1. アーキテクチャドキュメントの収集

必要な資料を収集します。

必須ドキュメント：

• アーキテクチャ図（C4：コンテキスト、コンテナー、コンポーネント）
• アーキテクチャ決定記録（ADR）：判断の根拠と代替案を含むもの
• 技術仕様と非機能要件（パフォーマンス、スケーラビリティ、セキュリティ）
• データモデル、スキーマ、API 仕様
• 技術スタックとその選定理由
• デプロイメント図とインフラストラクチャ図

コンテキスト情報：

• ビジネス上の制約（予算、タイムライン、コンプライアンス要件）
• パフォーマンス目標（レスポンスタイム、スループットを定量化）
• スケーラビリティの目標（ユーザー増加率、データ量の予測）
• セキュリティ要件（認証モデル、データ保護、コンプライアンス）
• 統合要件（内部／外部システム、API）

2. アーキテクチャスタイルとパターンの評価

アーキテクチャスタイルの適切性を検証します。

スタイルと要件の適合性：

• モノリシック：小規模なチーム（10 人未満）、単純なドメイン、ユーザー数 1,000 人未満
• マイクロサービス：大規模なチーム（20 人超）、複雑なドメイン、ユーザー数 10 万人超
• サーバーレス：イベント駆動型、負荷の変動が大きい、ステートレスな処理
• イベント駆動型：非同期ワークフロー、疎結合、高スループット

パターンの評価：

☐ Architecture style matches requirements (scale, team, complexity)
☐ Service boundaries align with business domains (DDD)
☐ Communication patterns appropriate (sync vs async)
☐ Data management strategy clear (per-service vs shared DB)
☐ Integration patterns documented (gateway, mesh, events)
☐ Deployment model specified (containers, VMs, serverless)

アンチパターンの検出：

• ビッグボールオブマッド：構造がなく、密結合で、データベースを共有している
• ゴッドサービス：単一のサービスが複数のドメインを処理する
• チャッティ通信：サービス間の呼び出しが過剰（リクエストあたり 5 回超）
• 分散モノリス：共有データベースを介してサービスが結合している
• ゴールデンハンマー：すべての問題に同じ技術を適用する

3. 品質特性の評価

スケーラビリティ評価：

• 水平スケーリング：ロードバランサー、ステートレスサービス、自動スケーリング
• データベースのスケーリング：シャーディング、リードレプリカ、キャッシュ層
• キャパシティプランニング：現在の負荷 → 予測される負荷（成長戦略を文書化）
• コストへの影響：インフラストラクチャの通常時およびピーク時のコスト

パフォーマンスの検証：

• 各レイヤーに割り当てられたレスポンスタイムの予算
• キャッシュ戦略（CDN、Redis、アプリケーションキャッシュ）
• データベースの最適化（インデックス、コネクションプーリング、クエリ分析）
• 長時間実行タスクの非同期処理（キュー、バックグラウンドジョブ）

セキュリティレビュー：

☐ Authentication mechanism (OAuth 2.0, JWT, SAML)
☐ Authorization model (RBAC, ABAC, policy-based)
☐ API security (rate limiting, input validation, CORS)
☐ Data encryption (at-rest: AES-256, in-transit: TLS 1.3)
☐ Secret management (AWS Secrets Manager, HashiCorp Vault)
☐ Network security (VPC, security groups, WAF)
☐ Security headers (HSTS, CSP, X-Frame-Options)

可用性と信頼性：

• 高可用性を実現するマルチ AZ／リージョンへのデプロイ
• サーキットブレーカーによる連鎖障害の防止
• ヘルスチェックと自動復旧の設定
• バックアップ／DR 手順（RPO < 1 時間、RTO < 4 時間）
• 重要度の低い機能のグレースフルデグラデーション

4. 技術スタックのレビュー

技術適合性の検証：

• バックエンドフレームワークがユースケースに適合している（Spring Boot、Node.js、Django、Go）
• データベースの選定に根拠がある（PostgreSQL、MongoDB、Cassandra、Redis）
• デプロイメントプラットフォームが適切である（Kubernetes、ECS、Cloud Run）
• 検討した代替案が ADR に記録されているか評価する

技術リスクの評価：

• ベンダーロックイン：移植性と移行の複雑さを評価する
• チームのスキル：必要なトレーニングと期間を記録する
• コミュニティサポート：エコシステムの成熟度と長期的な存続可能性を確認する
• パフォーマンス：技術が要件を満たすことを検証する
• ライセンス：商用利用のコンプライアンスを確認する

5. データアーキテクチャの分析

データ戦略の検証：

• サービスごとのデータベースか共有データベースか（選択の根拠を示す）
• SQL と NoSQL の選定とその根拠
• データのパーティショニングおよびシャーディング戦略
• データ整合性モデル（強整合性か結果整合性か）
• データの所有者が明確に割り当てられている
• サービス間クエリを最小限に抑える

6. モニタリングとオブザーバビリティのレビュー

オブザーバビリティのチェックリスト：

☐ Metrics: Application, infrastructure, business metrics
☐ Logging: Centralized aggregation with correlation IDs
☐ Tracing: Distributed tracing across services
☐ Alerting: Error rate, latency, availability thresholds
☐ Dashboards: Real-time visibility into system health
☐ On-call: Rotation and escalation procedures

7. レビューレポートの作成

レポートの構成：

1. エグゼクティブサマリー：アーキテクチャスタイル、全体評価（承認／条件付き承認／不承認）、主な強みと懸念事項

2. 指摘事項：重大度（重大／高／中／低）ごとに整理し、以下を記載します。

   • 説明と影響
   • 工数の見積もりを含む推奨事項
   • 優先度（必ず修正／修正を推奨／検討）

3. リスク評価：技術、リソース、スケジュール、運用上のリスクと軽減策

指摘事項の形式：

Finding: [Clear description]
Severity: Critical | High | Medium | Low
Impact: [Specific consequences]
Recommendation: [Actionable solution]
Effort: [Time estimate]
Priority: Must Fix | Should Fix | Consider

参考ドキュメント

特定のレビュー領域に関する詳細なガイダンスを読み込みます。

コアレビューリソース：

• architecture-review-process.md - フェーズごとのチェックリストを含む、完全なレビュー手法
• review-checklists.md - アーキテクチャのあらゆる側面を網羅した、包括的な検証チェックリスト
• quality-attributes.md - スケーラビリティ、パフォーマンス、セキュリティ、信頼性、保守性の詳細な評価
• common-patterns-to-validate.md - アーキテクチャパターン（マイクロサービス、イベント駆動、サーバーレス）の検証基準
• anti-patterns.md - 検出基準と修正方法を含む、一般的な設計上の欠陥
• review-report-template.md - 例と重大度分類を含むレポートの構成
• review-severity-levels.md - 重大度分類の基準（重大／高／中／低）
• best-practices-for-architecture-reviews.md - レビュープロセスのベストプラクティス

API と統合：

• api-design.md - REST、GraphQL、gRPC の設計評価

データアーキテクチャ：

• data-management.md - データ戦略、所有権、同期、一貫性パターン
• data-storage-strategy.md - データベースの選定、パーティショニング、レプリケーション
• data-consistency.md - 一貫性モデルとトレードオフ
• data-scalability.md - シャーディング、レプリケーション、キャッシュ戦略
• database-selection.md - SQL と NoSQL の比較、テクノロジーの選定基準

セキュリティ：

• application-security.md - 認証、認可、暗号化、コンプライアンスを含むセキュリティアーキテクチャ
• authentication-and-authorization.md - ID およびアクセス管理のパターン

スケーラビリティとパフォーマンス：

• horizontal-scalability.md - 水平スケーリング戦略と自動スケーリング
• caching-strategy.md - キャッシュレイヤー、無効化、CDN

信頼性と運用：

• high-availability-design.md - HA アーキテクチャ、冗長化、フェイルオーバー
• fault-tolerance.md - サーキットブレーカー、再試行、バルクヘッド、タイムアウト
• disaster-recovery.md - バックアップ、復旧手順、RPO／RTO の計画
• monitoring-and-observability.md - メトリクス、ロギング、トレーシング、アラート

マイクロサービス：

• service-boundaries-microservices.md - サービスの分割、境界づけられたコンテキスト、ドメイン境界

その他のトピック：

• external-integrations.md - サードパーティ API の統合パターン
• testing-strategy.md - テストカバレッジ、統合テスト、契約テスト
• operational-readiness.md - 本番環境への準備状況チェックリスト
• cost-analysis.md - インフラコストの見積もりと最適化
• infrastructure-costs.md - コンポーネント別の詳細なコスト内訳
• infrastructure.md - インフラ設計とデプロイパターン
• risk-assessment.md - 技術的リスクの特定と軽減

注：技術選定（フレームワーク、データベース、クラウドプラットフォーム）のガイダンスについては、architecture-design スキルを参照してください。

重要なレビュー原則

実装ではなく、アーキテクチャに注目する：

• コード品質ではなく、設計とパターンをレビューします
• 構文ではなく、判断とトレードオフを検証します
• 変数名ではなく、構造と境界を評価します

指摘事項を具体的に示す： ✅ 「Order→Payment の呼び出し（平均 50 calls/sec）にサーキットブレーカーがありません。エラーしきい値を 50% に設定した Resilience4j を追加してください。」 ❌ 「エラー処理を改善する必要があります」

パフォーマンス要件を数値化する： ✅ 「API の応答時間は、1000 req/s の負荷で 95 パーセンタイルが <200ms である必要があります」 ❌ 「API は高速であるべきです」

実行可能な推奨事項を提示する： ✅ 「UserService を認証（ID）サービスとプロフィール（データ）サービスに分割してください。推定作業期間は 3 週間です。同期にはイベントバスを使用してください。」 ❌ 「サービスの境界の改善を検討してください」

コンテキストに基づいて評価する：

• スタートアップの MVP とエンタープライズシステムでは要件が異なります
• ユーザー数が 100 人のシステムに、マイクロサービスの複雑さは必要ありません
• 規模、チーム、スケジュールに適しているか評価します