Section 4: 技術ビジネスプロセス分析 — 🔧 応用編

対象: 実務 3-5 年・GCP 経験あり / CI/CD 設計・DORA・DR パターン・組織変革 を体系化したい人。 目標: 試験で問われる「プロセス設計と組織判断」を高精度で出せるようになる。

1. SDLC モデルの選定判断

モデル別の適性

Shift Left の概念

テスト・セキュリティを開発の早期段階に組み込む 考え方。

従来（Right）:
要件 → 設計 → 実装 → 【テスト】 → 【セキュリティ】 → リリース
                       ↑問題発覚時の修正コスト大

Shift Left:
要件 → 設計 →【テスト計画】【セキュリティ】→ 実装（自動テスト）→ リリース
              ↑早期発見で修正コスト小

AWS / Azure との比較

2. CI/CD パイプライン設計の深掘り

Cloud Build の機能と制約

Cloud Deploy のデプロイ戦略

Cloud Deploy 構造

# clouddeploy.yaml
apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
  name: my-pipeline
serialPipeline:
  stages:
  - targetId: dev
  - targetId: staging
  - targetId: prod
    strategy:
      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "my-svc"
        canaryDeployment:
          percentages: [10, 50]

Binary Authorization（重要）

未承認・未署名イメージのデプロイを防ぐ ガードレール。

[ビルド] ── 署名 (Attestation) ──→ [Artifact Registry]
                                       ↓
[GKE / Cloud Run]
   ↓
Binary Authorization が
署名検証 ── 失敗 → デプロイ拒否
        ── 成功 → デプロイ許可

ポリシー例：

• 本番環境では 2 個以上のアテステーション必須（ビルド + 脆弱性スキャン合格）
• 開発環境は緩く

GitOps パターン

[Git] ── 宣言（YAML） ──→ [Config Sync / ArgoCD] ──→ [GKE Cluster]
   ↑                                                       ↓
   ←──────── PR でロールバック ──────────────── ドリフト検知

• Config Sync: GCP 純正、Anthos / GKE Enterprise 用
• ArgoCD: OSS、汎用 K8s

3. DORA メトリクス（重要・頻出）

DevOps Research and Assessment が定義する 4 つの主要メトリクス。

4 メトリクス

改善方法

DORA 補足メトリクス（最近追加）

• Reliability: SLO 達成度
• Code Review Speed: PR から承認までの時間
• Documentation Quality: ドキュメントの最新性
• Developer Experience: 開発者満足度

4. テスト戦略の詳細

テストピラミッド vs テストトロフィー

テストピラミッド（古典）        テストトロフィー（Kent C. Dodds）

         /\                          ___
        /E2E\                       /E2E\
       /------\                    /-----\
      / 結合 \                    / 結合  \  ← 重視
     /--------\                  /---------\
    /  単体   \                 / 単体     \
   /----------\                /------------\
                              / 静的解析     \  ← 重視
                             /---------------\

Chaos Engineering（カオスエンジニアリング）

Netflix の Chaos Monkey が起源。意図的に障害を起こして耐性を検証 する手法。

IaC のテスト

Config Validator / Policy as Code

GCP 環境のリソースが ポリシーに違反していないか を自動チェック。

[Terraform Plan] ──→ [Config Validator] ──→ ✓/✗
                          ↓ ポリシー
                    constraints/
                    ├── no_public_ip.yaml
                    ├── encrypt_disk.yaml
                    └── allowed_locations.yaml

5. RCA とポストモーテム文化

良い Postmortem の要素

Google 流 SRE の信条

1. エラーバジェット: SLO に未到達分をリリース速度に振り向ける
2. Toil の削減: 繰り返し作業を自動化
3. Blameless: 個人を責めずプロセスを直す
4. Production Readiness Review (PRR): 本番投入前のチェックリスト
5. DiRT（Disaster Recovery Testing）: 計画的障害訓練

6. DR 戦略の詳細設計

DR パターン詳細

Backup & Restore

本番リージョン               DR リージョン（停止中）
┌──────────┐               ┌──────────┐
│ App     │               │ （停止） │
│ DB ────→│ Snapshot ──→ │ GCS バックアップ │
└──────────┘               └──────────┘

障害時: バックアップから手動で復旧（数時間）

• RTO: 数時間〜数日、RPO: バックアップ間隔
• 例: Cloud SQL の自動バックアップ + Cloud Storage に保管

Pilot Light

本番リージョン               DR リージョン（最小起動）
┌──────────┐               ┌──────────┐
│ App     │               │ DB Replica │ ← 常時同期
│ DB ────→│ Replication →│            │
└──────────┘               └──────────┘

障害時: アプリ層を起動（数十分）

• RTO: 数十分、RPO: 数分〜時間
• DB だけ常時同期、アプリは停止状態でリソース節約

Warm Standby

本番リージョン               DR リージョン（縮小起動）
┌──────────┐               ┌──────────┐
│ App x10 │               │ App x2  │ ← 常時稼働
│ DB     │←── 同期 ──→  │ DB     │
└──────────┘               └──────────┘

障害時: スケールアップ（数分）

• RTO: 数分、RPO: 数分

Hot Standby (Active-Active)

本番リージョン               DR リージョン
┌──────────┐               ┌──────────┐
│ App x10 │←── Global LB →│ App x10 │
│ DB     │←── 同期 ──→  │ DB     │
└──────────┘               └──────────┘

障害時: LB が自動でトラフィック切替（数秒）

• RTO: 数秒、RPO: ほぼ 0
• 例: Spanner Multi-region + Global LB + GKE Multi-cluster

サービス別 DR 機能

DR テスト（DiRT）

実際にフェイルオーバーを定期実施 して計画の有効性を検証。

7. Service Catalog の応用

組織への導入パターン

Cloud Identity / Workspace
  ↓
組織 (Organization)
  ├── フォルダ: 本社
  │     └── プロジェクト群
  └── フォルダ: 部門 A
        └── 部門用 Service Catalog ← 部門固有テンプレート
        └── プロジェクト群

組織レベル Service Catalog ── 全社共通テンプレート

コンテンツの種類

統制とガバナンス

• 承認フロー: 管理者がレビュー → 公開
• アクセス制御: IAM で公開先（組織/フォルダ/プロジェクト）を制御
• バージョン管理: テンプレート更新時に旧版も保持

8. ステークホルダー管理の応用

戦略的なステークホルダー分析

Salience Model（顕著性モデル）

3 軸でステークホルダーを分類：

• Power（影響力）
• Legitimacy（正当性）
• Urgency（緊急性）

3 軸全て持つ ─→ Definitive（最優先対応）
2 軸 ─→ Expectant（期待される対応）
1 軸 ─→ Latent（潜在的、軽く対応）

Influence Strategy

コミュニケーション計画

9. 変更管理の応用

ADKAR の各段階での施策

Kotter 8 Step の現場応用

抵抗を減らすコミュニケーション

10. 意思決定プロセス（RAPID 等）

RAPID モデル

意思決定の役割を 5 つに分けるフレームワーク（Bain & Co.）。

RAPID 例（マルチクラウド戦略決定）

意思決定スピード

Disagree and Commit（Amazon 流）

反対しても、決まったら全力でコミット する文化。意思決定スピードと実行力を両立。

11. カスタマーサクセスマネジメント

Customer Success の役割

営業（販売） ──→ オンボーディング ──→ 活用支援 ──→ 拡大販売
                ↑                ↑              ↑
            セットアップ   ヘルスチェック   アップセル/クロスセル
                    （Customer Success Manager）

重要指標

GCP のカスタマーサクセス支援

12. コスト最適化の応用

階層別コスト最適化

1. アーキテクチャ層
   - サーバーレス優先（リソース最小）
   - マネージドサービス活用（運用コスト削減）
   - リージョン選定（北米は安い）

2. リソース層
   - Right-sizing（Recommender）
   - Spot VMs（バッチ）
   - Custom Machine Type
   - Hyperdisk（旧 SSD より割安）

3. 課金モデル層
   - Committed Use Discounts
   - Sustained Use Discounts（自動）
   - BigQuery Editions / Slot Reservations
   - Cloud Storage Autoclass

4. 運用層
   - Billing Budgets / Alerts
   - Cost Anomaly Detection
   - Idle リソース削除（Recommender / Active Assist）
   - タグ付け（Labels）でコスト追跡

5. 組織層
   - チャージバック / ショーバック
   - FinOps チーム設立
   - Cloud Quotas / Budgets で部門制限

Committed Use Discounts (CUD)

Cost Anomaly Detection / FinOps

Carbon Footprint

GCP の カーボン排出量を可視化 する Carbon Footprint レポート。

• リージョン別の Grid Carbon Intensity 開示
• 24/7 Carbon-Free Energy リージョン（finland, taiwan, 等）

13. 実践ケーススタディ

ケース 1: CI/CD 設計（製造業の Web サイト刷新）

要件:

• 月 1 回リリース → デイリーリリース にしたい
• 規制対応で 本番デプロイは承認必須
• 既存のオンプレ Jenkins からの脱却

選択:

• Cloud Build（CI、Jenkins と並走移行可能）
• Artifact Registry（コンテナイメージ管理）
• Cloud Deploy（dev → stg → prod、prod は承認ゲート）
• Binary Authorization（本番には署名済みのみ）
• DORA メトリクス測定でリリース頻度 / Lead Time を可視化

ケース 2: DR 設計（決済システム）

要件:

• RTO 30 秒以内、RPO ほぼ 0
• 規制で関東・関西で地理冗長必須
• コストは無制限ではない

選択:

• Spanner Multi-region (asia)（強整合性、99.999% SLA）
• GKE Multi-cluster（asia-northeast1 + asia-northeast2）
• Global External Application LB（自動フェイルオーバー）
• 月次 DiRT 訓練

ケース 3: 組織変革（メインフレーム → クラウド）

要件:

• 300 人の COBOL 開発者がいる
• 3 年で全システム GCP 移行
• 反対勢力多数

選択:

• Kotter Step 1-2: 経営層から「3 年後 EOL」宣言、推進室設立
• ADKAR:
  • A: 全社タウンホール、競合事例共有
  • D: 早期参加者にインセンティブ
  • K: GCP 認定トレーニング、ベンダー集合研修
  • A: メンター制度、サンドボックス環境
  • R: 評価制度連動、Success Story 共有
• 6R 戦略: Rehost → Replatform 段階移行
• Service Catalog: 標準テンプレート提供で開発者の学習コスト低減

14. 章末まとめ

必ず覚える「プロセス選定パターン」

次のステップ

• 直前確認: 03_要点と暗記.md
• 演習: ../../03_問題集/section4_問題集.md
• 関連セクション: Section 5 (実装管理), Section 6 (運用卓越性)