ストーリー

技術標準の体系

3層の標準化モデル

┌────────────────────────────────────────────┐
│  Layer 3: 推奨（Recommended）               │
│  ・ベストプラクティスガイド                    │
│  ・参考テンプレート                           │
│  ・技術レーダーのTRIAL/ASSESS                 │
│  → チームの裁量で採用/不採用を判断             │
├────────────────────────────────────────────┤
│  Layer 2: 標準（Standard）                   │
│  ・コーディング規約                           │
│  ・API設計ガイドライン                        │
│  ・テスト戦略ガイドライン                      │
│  → 原則として従う。例外は技術リードの承認が必要  │
├────────────────────────────────────────────┤
│  Layer 1: 必須（Mandatory）                  │
│  ・セキュリティポリシー                        │
│  ・データ分類・取り扱い規程                     │
│  ・コンプライアンス要件                        │
│  → 例外なし。自動化されたガードレールで強制      │
└────────────────────────────────────────────┘

技術標準カタログ

Policy as Code

自動化されたガードレール

ポリシー定義（OPA/Rego）
    │
    ↓
┌──────────────────────────────────────┐
│         Policy Engine (OPA)          │
├──────────┬──────────┬───────────────┤
│ CI/CD    │ クラウド  │ Kubernetes    │
│ ゲート   │ ゲート   │ Admission     │
│          │          │ Controller    │
└──────────┴──────────┴───────────────┘
    │           │           │
    ↓           ↓           ↓
 パイプライン  Terraform   Pod作成の
 の通過/ブロック plan検証   許可/拒否

ポリシー例

# セキュリティポリシー: コンテナイメージは承認済みレジストリからのみ許可
package kubernetes.admission

deny[msg] {
  input.request.kind.kind == "Pod"
  container := input.request.object.spec.containers[_]
  not startswith(container.image, "123456789.dkr.ecr.ap-northeast-1.amazonaws.com/")
  not startswith(container.image, "ghcr.io/techforward/")
  msg := sprintf("未承認のコンテナレジストリ: %v", [container.image])
}

# コスト管理ポリシー: 全リソースにコストタグ必須
deny[msg] {
  input.resource_type == "aws_instance"
  not input.resource.tags.cost_center
  msg := "cost_centerタグが設定されていません"
}

# データポリシー: PIIデータは暗号化必須
deny[msg] {
  input.resource_type == "aws_rds_instance"
  input.resource.tags.data_classification == "pii"
  not input.resource.storage_encrypted
  msg := "PIIデータを含むRDSは暗号化が必須です"
}

技術ガバナンス体制

ガバナンス組織

┌─────────────────────────────────────────┐
│      Technology Governance Board         │
│  CTO、VPoE、各部門技術リード              │
│  ・アーキテクチャ原則の策定・更新           │
│  ・技術レーダーの四半期レビュー             │
│  ・重大な技術判断の承認                    │
│  開催頻度: 月1回                          │
└────────────────┬────────────────────────┘
                 │
    ┌────────────┼────────────┐
    ↓            ↓            ↓
┌────────┐ ┌─────────┐ ┌─────────┐
│ アーキ  │ │ セキュリ │ │ データ   │
│ テクチャ│ │ ティ    │ │ ガバナンス│
│ レビュー│ │ レビュー │ │ レビュー  │
│ 委員会  │ │ 委員会   │ │ 委員会   │
└────────┘ └─────────┘ └─────────┘
  週1回       週1回        隔週

ガバナンスプロセス

例外管理プロセス

例外申請
    │
    ↓
┌──────────────────────┐
│ 申請内容の確認          │
│ ・どの標準からの逸脱か  │
│ ・なぜ必要か           │
│ ・代替案の検討結果     │
│ ・リスク評価           │
│ ・期限（暫定措置か永続か）│
└──────────┬───────────┘
           │
    ┌──────┴──────┐
    ↓             ↓
  承認          却下
    │             │
    ↓             ↓
  期限付き       代替案の
  例外登録       提案
    │
    ↓
  定期レビュー
  （解消計画の追跡）

コンプライアンスの自動化

Compliance as Code

まとめ

チェックリスト

• 3層の標準化モデルを理解した
• Policy as Codeの考え方と実装方法を把握した
• ガバナンス組織体制を設計できる
• 例外管理プロセスの重要性を理解した
• コンプライアンスの自動化手法を把握した

次のステップへ

次は演習です。Step 2で学んだ目標アーキテクチャ、プラットフォーム戦略、統合設計、技術標準を統合して、TechForward社の目標アーキテクチャを設計しましょう。

推定読了時間: 30分