ストーリー
田
田中VPoE
アーキテクチャ標準ができた。次は「品質」の標準化だ。コード品質、テスト品質、そしてコーディング規約を定める
あなた
コーディング規約はチームごとに決めればいいのでは？
あ
田
田中VPoE
チーム内のスタイルはチームに任せていい。だが品質の「最低基準」は組織全体で統一すべきだ。「テストを一切書かないチーム」と「カバレッジ90%のチーム」が混在していたら、組織としての品質は保証できない
あなた
最低ラインを決めて、上はチームに任せるということですね
あ
田
田中VPoE
そうだ。品質の床（フロア）を定義し、天井（シーリング）は設けない。全チームが最低限の品質を担保しつつ、より高い品質を目指すチームの自主性を尊重する
品質標準の設計
品質の4つの柱
| 柱 | 内容 | 標準化レベル |
|---|---|---|
| テスト品質 | テストカバレッジ、テスト戦略 | Should |
| コード品質 | 複雑度、重複、依存関係 | Should |
| セキュリティ品質 | 脆弱性スキャン、静的解析 | Must |
| 運用品質 | 可観測性、デプロイメント、SLO | Should |
テスト品質標準
テストピラミッドの標準化
テストピラミッド（推奨比率）:
┌─────┐
│ E2E │ 10%
│ │ ← 重要なユーザーシナリオのみ
─┴─────┴─
┌─────────┐
│Integration│ 30%
│ │ ← API境界、DB連携
─┴──────────┴─
┌──────────────┐
│ Unit Tests │ 60%
│ │ ← ビジネスロジック中心
└──────────────┘テスト品質の基準値
| 指標 | 最低基準（Must） | 推奨値（Should） | 備考 |
|---|---|---|---|
| ユニットテストカバレッジ | 60% | 80% | ビジネスロジック層は80%必須 |
| インテグレーションテスト | 主要APIパスをカバー | 全APIパスをカバー | ハッピーパス + 主要エラーパス |
| E2Eテスト | クリティカルパス | 主要ユーザーシナリオ | 過度なE2Eテストは避ける |
| テストの実行時間 | CI/CDで10分以内 | 5分以内 | 遅いテストは開発速度を低下させる |
| テストの独立性 | テスト間に順序依存なし | - | 並列実行可能であること |
テスト品質のアンチパターン
| アンチパターン | 問題 | 対策 |
|---|---|---|
| テストのないコード | 品質保証ができない | PR時にカバレッジチェックを必須化 |
| 脆いテスト（Flaky Test） | CIの信頼性低下 | Flaky Testの自動検出と修正ルール |
| 過度なモック | テストが実装に密結合 | 統合テストとのバランスを取る |
| E2Eテスト偏重 | 遅い、不安定 | テストピラミッドの比率を遵守 |
コード品質標準
静的解析の標準化
| ツールカテゴリ | 言語 | 推奨ツール | 標準化レベル |
|---|---|---|---|
| リンター | TypeScript | ESLint | Should |
| リンター | Go | golangci-lint | Should |
| リンター | Python | Ruff | Should |
| フォーマッタ | TypeScript | Prettier | May |
| フォーマッタ | Go | gofmt | Must（Go標準） |
| フォーマッタ | Python | Black | May |
| 型チェック | TypeScript | tsc —strict | Should |
| 型チェック | Python | mypy | Should |
| セキュリティ | 全言語 | Trivy / Snyk | Must |
コード複雑度の基準
| 指標 | 基準値 | ツール | 説明 |
|---|---|---|---|
| 循環的複雑度 | 関数あたり10以下 | ESLint, golangci-lint | 分岐の複雑さの指標 |
| 認知的複雑度 | 関数あたり15以下 | SonarQube | 人間の理解コストの指標 |
| 関数の行数 | 50行以下（推奨） | リンター | 長すぎる関数は分割 |
| ファイルの行数 | 300行以下（推奨） | リンター | 長すぎるファイルは分割 |
| コードの重複 | 5%以下 | SonarQube, jscpd | DRY原則の遵守 |
セキュリティ品質標準
セキュリティチェックの必須化
| チェック項目 | タイミング | ツール例 | 標準化レベル |
|---|---|---|---|
| 依存関係の脆弱性スキャン | CI/CD | Trivy, Dependabot | Must |
| SAST（静的アプリケーションセキュリティテスト） | CI/CD | SonarQube, Semgrep | Must |
| シークレット検出 | pre-commit | gitleaks, truffleHog | Must |
| コンテナイメージスキャン | CI/CD | Trivy, Snyk Container | Must |
| DAST（動的テスト） | ステージング | OWASP ZAP | Should |
| ライセンスチェック | CI/CD | FOSSA, license-checker | Should |
セキュリティ品質ゲート
セキュリティ品質ゲート（CIで自動チェック）:
PR作成時:
├── SAST: Critical/High の脆弱性がゼロであること ← Must
├── シークレット検出: 機密情報がコードに含まれないこと ← Must
└── 依存関係: 既知のCritical CVEがゼロであること ← Must
マージ時:
├── 上記すべて + High CVEの対応計画があること
└── セキュリティレビューが完了していること（重要な変更の場合）
リリース時:
├── コンテナイメージスキャン通過
└── セキュリティチェックリストの完了運用品質標準
デプロイメント標準
| 項目 | 基準 | 標準化レベル |
|---|---|---|
| デプロイ頻度 | 週1回以上 | Should |
| デプロイ方式 | ローリングアップデートまたはBlue/Green | Should |
| ロールバック | 5分以内にロールバック可能 | Must |
| デプロイパイプライン | 手動ステップなし（完全自動化） | Should |
| ステージング検証 | 本番デプロイ前にステージングで検証 | Must |
ヘルスチェック・可観測性標準
| 項目 | 基準 | 標準化レベル |
|---|---|---|
| ヘルスチェックエンドポイント | /health を実装 | Must |
| メトリクス | RED（Rate, Errors, Duration）メトリクスを出力 | Should |
| トレーシング | 分散トレースIDの伝播 | Should |
| アラート | エラー率・レイテンシのアラート設定 | Must |
「品質基準は”床”であって”天井”ではない。全チームが最低限の品質を保ちつつ、より高い品質を目指すチームを称える文化を作ろう」 — 田中VPoE
まとめ
| ポイント | 内容 |
|---|---|
| 品質の4つの柱 | テスト、コード、セキュリティ、運用 |
| テスト品質 | テストピラミッドの比率、カバレッジ基準、実行時間制限 |
| コード品質 | 静的解析の必須化、複雑度の基準値 |
| セキュリティ品質 | CI/CDでの自動スキャン必須化、品質ゲート |
| 運用品質 | デプロイ自動化、ロールバック、ヘルスチェック |
チェックリスト
- 品質の4つの柱を理解した
- テストピラミッドと品質基準値を理解した
- コード品質の静的解析ツールと基準を理解した
- セキュリティ品質ゲートの設計方法を理解した
- 運用品質（デプロイ・可観測性）の基準を理解した
次のステップへ
次は演習「技術標準ドキュメントを設計しよう」に進みます。Step 2で学んだ範囲設計、言語戦略、アーキテクチャ標準、品質標準を統合した実践演習です。
推定読了時間: 30分