佐藤CTOからの指令：「エンジニア50名規模の組織でアーキテクチャガバナンスの仕組みを設計してほしい。ADR運用、レビュープロセス、テクニカルスタンダード、フィットネス関数の4つの柱で設計してくれ。」
| # | ミッション | 難易度 | 目安時間 |
|---|---|---|---|
| 1 | ADRテンプレートとプロセス設計 | ★★☆ | 15分 |
| 2 | アーキテクチャレビューチェックリスト | ★★★ | 15分 |
| 3 | テクニカルスタンダードの策定 | ★★☆ | 15分 |
| 4 | フィットネス関数の実装計画 | ★★★ | 15分 |
Mission 1: ADRテンプレートとプロセス設計
50名のエンジニア組織でADRを運用するプロセスを設計せよ。
解答例
# ADR-XXXX: [タイトル]
## ステータス
提案中 / 承認済み / 廃止 / 置換（ADR-YYYY）
## コンテキスト
- 何を決定する必要があるか
- どのような制約や要件があるか
## 検討した選択肢
### 選択肢A: [名前]
- メリット: ...
- デメリット: ...
### 選択肢B: [名前]
- メリット: ...
- デメリット: ...
## 決定
選択肢Aを採用する。
## 根拠
なぜこの選択肢を選んだか。
## 影響
- この決定が影響するチーム・コンポーネント
- 移行が必要な場合のタイムライン■ ADR運用プロセス
1. 起票: 任意のエンジニアがPRでADRを提出
2. レビュー: 影響を受けるチームのTech Leadが72時間以内にレビュー
3. 議論: コメントで議論、週次アーキテクチャ会議で対面議論も可
4. 承認: 2名以上のTech Leadの承認で採択
5. 共有: 全エンジニアにSlack通知、月次ニュースレターに掲載
6. 見直し: 四半期ごとに既存ADRの妥当性をレビュー
■ ADRが必要なケース（ガイドライン）
- 新しい言語/フレームワークの導入
- データベースの変更
- 認証/認可方式の変更
- API設計方針の変更
- インフラアーキテクチャの大きな変更Mission 2: アーキテクチャレビューチェックリスト
新しいサービスや大きな変更に対するアーキテクチャレビューのチェックリストを作成せよ。
解答例
| カテゴリ | チェック項目 |
|---|---|
| 設計 | 既存のADRとテクニカルスタンダードに準拠しているか |
| 設計 | 適切な設計パターンを使用しているか |
| 設計 | サービス間の依存関係は適切か（循環依存なし） |
| データ | データモデルは正規化/非正規化の判断が適切か |
| データ | 個人情報の取り扱いが適切か |
| セキュリティ | 認証・認可が適切に設計されているか |
| セキュリティ | 入力バリデーションが実装されているか |
| パフォーマンス | SLOが定義されているか |
| パフォーマンス | キャッシュ戦略は適切か |
| 運用 | 監視・アラートが設計されているか |
| 運用 | ロールバック手順が明確か |
| コスト | コスト見積もりが妥当か |
| テスト | テスト戦略が定義されているか |
Mission 3: テクニカルスタンダードの策定
組織のテクニカルスタンダード（技術標準）のドキュメント構成を設計せよ。
解答例
■ テクニカルスタンダード構成
1. 言語・フレームワーク
- 推奨: TypeScript (Node.js), Python (FastAPI)
- 許可: Go (パフォーマンスクリティカル)
- 非推奨: Java (レガシーのみ), Ruby
- 新規採用には ADR が必要
2. データベース
- OLTP: PostgreSQL (デフォルト)
- キャッシュ: Redis
- 検索: OpenSearch
- 新DB導入には ADR + PoC が必要
3. API設計
- 同期: REST (OpenAPI 3.0)
- 非同期: SQS + SNS
- 内部通信: gRPC (検討中)
- 命名規則: kebab-case, バージョニング: URI path (/v1/)
4. インフラ
- コンテナ: ECS Fargate
- IaC: Terraform (モジュール化)
- CI/CD: GitHub Actions
- 監視: CloudWatch + Datadog
5. セキュリティ
- 認証: OAuth 2.0 / OIDC
- シークレット: AWS Secrets Manager
- 脆弱性スキャン: Snyk (CI統合)Mission 4: フィットネス関数の実装計画
5つのフィットネス関数を定義し、CI/CDへの統合計画を策定せよ。
解答例
| # | フィットネス関数 | 閾値 | 実行タイミング | ツール |
|---|---|---|---|---|
| 1 | レイヤー間依存ルール | 違反0件 | PR | dependency-cruiser |
| 2 | バンドルサイズ | < 300KB gzip | PR | size-limit |
| 3 | API レイテンシ p95 | < 500ms | main マージ後 | k6 |
| 4 | セキュリティ脆弱性 | Critical 0件 | 日次 | Snyk |
| 5 | テストカバレッジ | > 80% | PR | Jest + Istanbul |
■ 導入ロードマップ
Month 1: #1, #2 (静的チェック、導入容易)
Month 2: #5 (テストカバレッジ)
Month 3: #3, #4 (動的テスト、セキュリティ)
■ 違反時の対応
- PR時: マージブロック（error）or コメント通知（warning）
- 日次: Slackチャンネルに通知、チケット自動作成
- 四半期: フィットネススコアレポートを経営会議で報告