セクション 4：技術およびビジネスプロセスの分析と最適化
SDLC・CI/CD・DR などの技術プロセスと、ステークホルダー管理・変更管理・コスト最適化などのビジネスプロセスを扱う、PCA で「人とプロセス」を問う唯一のセクションです。技術的に正しい解ではなくビジネス的に正しい解を導く力が問われます。
📊 出題比重 ~15%
🔧 SDLC / CI/CD
🛡️ DR (RTO/RPO)
👥 RACI / ADKAR / RAPID
💰 FinOps / CUD / Spot
🔑 TL;DR（このセクションの核）
- CI/CD は Cloud Build → Artifact Registry → Cloud Deploy が定番。本番手前は Binary Authorization + Approval ゲート
- DR 戦略は RTO/RPO の数値感 で 4 パターンを即答（Backup&Restore / Pilot Light / Warm / Hot）
- DORA メトリクス 4 つ（Deployment Frequency / Lead Time / MTTR / CFR）は DevOps 成熟度の標準指標
- 組織側は ADKAR（個人変革）/ Kotter 8 Step（組織変革）/ RACI（役割明確化）/ RAPID（意思決定） を要件で使い分け
- コスト最適化は Right-sizing + CUD（30-55%）+ Spot（91%）+ Autoscaling の組合せ。Recommender / Active Assist は自動提案
- 「社内テンプレ」→ Service Catalog、「サードパーティ製品」→ Marketplace。混同しない
🎯 学習目標チェックリスト
このセクションの到達度0 / 0
※ チェック状態はこのブラウザに保存されます。
4.1 技術プロセスの分析と定義
技術プロセスは「どうやって作って・テストして・届けて・直すか」を扱う領域です。SDLC・CI/CD・テスト・トラブルシュート・サービスカタログ・DR の 6 テーマが公式試験ガイドのカバー範囲。
📘 ① SDLC モデル比較 — Waterfall / Agile / DevOps / SRE
クラウドアーキトは「どのモデルがプロジェクトに適合するか」を判断します。要件の変化頻度・規制・組織成熟度で選びます。
| モデル | 特徴 | 強み | 弱み | 適すケース |
|---|---|---|---|---|
| Waterfall | 各フェーズを順次・戻りなし | 計画明確、コスト読みやすい | 変化に弱い | 規制業界（医療・金融）、ハードウェア統合 |
| Agile (Scrum) | 2-4 週 Sprint で反復開発 | 変化に強い、フィードバック早い | ドキュメント弱め | Web/モバイル、SaaS |
| DevOps | Dev と Ops の統合、自動化重視 | デリバリ速度と品質を両立 | 文化変革が必要 | クラウドネイティブ、高頻度リリース |
| SRE | SLO 駆動、サービス信頼性に責任 | 信頼性定量化、自動化推進 | 組織成熟度必要 | 大規模サービス、グローバル（Google 発祥） |
Waterfall ──→ Agile ──→ DevOps ──→ SRE
（順次） （反復） （自動化） （信頼性）
↓
Shift Left（テスト・セキュリティを早期に）
💡 Shift Left の概念
テスト・セキュリティを開発の早期段階に組み込む。後段で問題を発見すると修正コストが指数的に増えるため、IaC バリデーション・SAST・SCA・Policy as Code を CI に組み込むのが現代のベストプラクティス。
クラウド 3 大ベンダー比較（SDLC ツール）
| 概念 | GCP | AWS | Azure |
|---|---|---|---|
| CI | Cloud Build | CodeBuild | Azure Pipelines (Build) |
| アーティファクト | Artifact Registry | ECR / CodeArtifact | ACR / Artifacts |
| CD | Cloud Deploy | CodeDeploy / CodePipeline | Azure Pipelines (Release) |
| Git | Cloud Source Repositories | CodeCommit | Azure Repos |
| カタログ | Service Catalog | Service Catalog | Service Catalog |
📘 ② CI/CD パイプライン — Cloud Build → Artifact Registry → Cloud Deploy
GCP の CI/CD は マネージドサービス 3 つの組合せが定番。役割を混同しないことが試験対策の最初のステップです。
[Source: GitHub / Cloud Source Repositories]
│ git push / PR / tag
▼
┌────────────────────────────────────────┐
│ Cloud Build (CI) │
│ - cloudbuild.yaml でステップ定義 │
│ - テスト・コンテナビルド・脆弱性スキャン │
│ - Workload Identity Federation 認証 │
└──────────────┬─────────────────────────┘
│ push image
▼
┌────────────────────────────────────────┐
│ Artifact Registry │
│ - リージョナル、Docker/OCI/Maven/npm/Py │
│ - 脆弱性スキャン / SBOM / CMEK │
└──────────────┬─────────────────────────┘
│ Attestation（署名）
▼
┌────────────────────────────────────────┐
│ Cloud Deploy (CD) │
│ - Delivery Pipeline: dev→stg→prod │
│ - Strategy: Standard/Canary/Custom │
│ - Approval / Verification │
└──────────────┬─────────────────────────┘
│ デプロイ
▼
Cloud Run / GKE / Anthos
│
▼ Binary Authorization 検証 → OK のみ実行
| サービス | 役割 | キーワード |
|---|---|---|
| Cloud Source Repositories | Git ホスティング（GitHub/GitLab 連携も可） | git push トリガー |
| Cloud Build | サーバーレス CI、cloudbuild.yaml でステップ定義 | 並列実行、Private Pool、E2/N1 マシン |
| Artifact Registry | コンテナイメージ / パッケージリポジトリ（旧 Container Registry の後継） | *-docker.pkg.dev、脆弱性スキャン、SBOM |
| Cloud Deploy | マネージド CD、環境間進行を宣言 | Delivery Pipeline、Promotion、Rollback、Approval |
| Binary Authorization | デプロイ前のイメージ署名検証 | 未署名イメージのデプロイ拒否 |
| Config Sync | GitOps（GCP 純正）、Anthos / GKE Enterprise 用 | K8s マニフェストの宣言的同期 |
Cloud Build の基本サンプル
# cloudbuild.yaml
steps:
- name: 'gcr.io/cloud-builders/go'
args: ['test', './...']
id: 'test'
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', '${_IMAGE}:${SHORT_SHA}', '.']
waitFor: ['test']
id: 'build'
- name: 'gcr.io/cloud-builders/gcloud'
args: ['artifacts', 'docker', 'images', 'scan', '${_IMAGE}:${SHORT_SHA}']
waitFor: ['build']
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
args: ['gcloud', 'deploy', 'releases', 'create', 'rel-${SHORT_SHA}',
'--delivery-pipeline=app-pipeline',
'--region=asia-northeast1']
substitutions:
_IMAGE: 'asia-docker.pkg.dev/PROJECT/repo/app'
options:
logging: CLOUD_LOGGING_ONLY
machineType: 'E2_HIGHCPU_8'
Cloud Deploy のデプロイ戦略
| 戦略 | 内容 | 用途 |
|---|---|---|
| Standard | 全インスタンス一括更新 | 開発・小規模 |
| Canary | 一部（10% → 50% → 100%）に段階リリース | 本番リリース |
| Blue/Green | 旧版と新版を並行稼働、切替で全量更新 | ダウンタイム最小化 |
| Progressive | 自動メトリクス監視つきカナリア | 高度な本番運用 |
📋 Cloud Deploy の Delivery Pipeline 例（クリックで展開）
# clouddeploy.yaml
apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
name: app-pipeline
serialPipeline:
stages:
- targetId: dev
profiles: [dev]
- targetId: staging
profiles: [staging]
strategy:
canary:
runtimeConfig:
cloudRun:
automaticTrafficControl: true
canaryDeployment:
percentages: [10, 50]
verify: true
- targetId: prod
profiles: [prod]
strategy:
canary:
canaryDeployment:
percentages: [5, 25, 50]
verify: true
🔑 Binary Authorization の鉄則
本番デプロイのガードレール。署名（Attestation）された安全なイメージだけを Cloud Run / GKE / Cloud Deploy で許可。「未署名イメージのデプロイ防止」「サプライチェーン攻撃対策」のキーワードが出たら即答。
CI と CD の違い
| 用語 | 内容 |
|---|---|
| CI (Continuous Integration) | コードを頻繁に統合し、自動テストで品質担保 |
| CD (Continuous Delivery) | 本番デプロイ可能な状態を常に維持（最終リリースは手動） |
| CD (Continuous Deployment) | 本番への自動デプロイまで含む |
📘 ③ DORA メトリクス（必須暗記）
DevOps Research and Assessment が定義する 4 つの主要メトリクス。DevOps 成熟度を測る業界標準で、試験頻出。
| メトリクス | 定義 | Elite | High | Medium | Low |
|---|---|---|---|---|---|
| Deployment Frequency | 本番リリースの頻度 | オンデマンド（>1/日） | 1/日 〜 1/週 | 1/週 〜 1/月 | <1/月 |
| Lead Time for Changes | コミット → 本番までの時間 | <1 時間 | <1 日 | 1 日 〜 1 週 | >1 週 |
| MTTR | 障害発生 → 復旧までの平均時間 | <1 時間 | <1 日 | 1 日 〜 1 週 | >1 週 |
| Change Failure Rate | リリース後に障害となる割合 | 0-15% | 16-30% | 16-30% | 46-60% |
各メトリクスの改善方法
⬆ 向上
Deployment Frequency
CI/CD 自動化、小さなバッチサイズ、Feature Flags で機能と公開を分離。
⬇ 短縮
Lead Time
ビルド・テスト並列化、自動デプロイ、承認自動化。
⬇ 短縮
MTTR
Runbook 整備、自動ロールバック、観測可能性強化（SLO Burn Rate）。
⬇ 低下
Change Failure Rate
テスト自動化、Canary デプロイ、Progressive Delivery。
💡 DORA 補足メトリクス（最近追加）
Reliability（SLO 達成度）/ Code Review Speed / Documentation Quality / Developer Experience。基本は 4 つだが、最新の問題は 5 番目以降を聞いてくることもある。
📘 ④ テスト戦略と IaC バリデーション
テストは「ピラミッド（下から多く）」で構成し、IaC はコードと同様にテスト必須。
/\
/E2E\ 少（高コスト・遅い）
/------\
/ 結合 \
/---------\
/ 単体 \ 多（低コスト・速い）
/------------\
| 種類 | 内容 | 実行頻度 |
|---|---|---|
| 単体テスト（Unit） | 関数単位、モック多用 | 毎コミット |
| 結合テスト（Integration） | 複数モジュール連携、Emulator 活用 | 毎 PR |
| E2E テスト | ユーザー操作を再現、本番に近い環境 | デプロイ前 |
| スモークテスト | デプロイ後の最低限の動作確認 | デプロイ直後 |
| 負荷テスト | 想定トラフィックでの性能確認（Locust/k6） | リリース前 |
| カナリアテスト | 本番でごく一部のユーザーに先行リリース | リリース時 |
| カオスエンジニアリング | 意図的に障害を起こして耐性を検証 | Game Day / 定期 |
IaC（Infrastructure as Code）のテスト
| 階層 | ツール | 内容 |
|---|---|---|
| 構文 | terraform fmt, terraform validate | 構文・型チェック |
| 静的解析 | tflint, checkov, tfsec | セキュリティ・ベストプラクティス |
| Plan 検証 | terraform plan, Conftest, OPA | ドリフト、ポリシー違反 |
| 統合テスト | Terratest, Kitchen-Terraform | 実環境でのデプロイ確認 |
| コンプライアンス | InSpec, Config Validator | 規制適合 |
🔑 Policy as Code の鉄則
Config Validator（GCP 純正）や OPA / Gatekeeper で「公開 IP 禁止」「特定リージョン以外禁止」などをコード化。Terraform Plan 段階で違反を検出することで、本番ガードレールが効く。
📘 ⑤ トラブルシュート / RCA / Postmortem
障害対応は 復旧 → 根本原因分析 → 恒久対策 → Postmortem の流れ。Blameless（個人を責めない）が SRE の鉄則。
1. 検知（アラート / Uptime Check）
↓
2. トリアージ（重要度・影響範囲判定）
↓
3. 復旧（Workaround / Rollback で被害最小化）
↓
4. 根本原因調査（RCA: 5 Whys / Fishbone / FTA）
↓
5. 恒久対策実施
↓
6. Postmortem（振り返り、Blameless）
RCA 手法
| 手法 | 内容 |
|---|---|
| 5 Whys | 「なぜ？」を 5 回繰り返して根本原因に到達 |
| Fishbone（Ishikawa） | 人・プロセス・技術・環境などカテゴリ別に整理 |
| Fault Tree Analysis | トップダウンで障害の論理的因果を分析 |
📋 5 Whys の実例（クリックで展開）
障害: 本番サイトが 10 分間ダウンした
↓ なぜ？
DB 接続プールが枯渇した
↓ なぜ？
バッチがコネクションを解放しなかった
↓ なぜ？
例外時に finally 句でクローズしていなかった
↓ なぜ？
コードレビューで見逃された
↓ なぜ？
DB 接続用のチェックリストがなかった
→ 対策: PR テンプレートに DB 接続チェック項目を追加Postmortem の必須項目（Blameless）
①
タイムライン
何が、いつ、どの順で起きたか
②
影響
何人 / どの機能が影響を受けたか、SLO 消費
③
検知方法
何で気づいたか（アラート / 顧客報告）
④
緩和策
どう被害を最小化したか
⑤
根本原因
何が悪かったか（プロセス / 技術）
⑥
アクション項目
再発防止策（Owner、期限つき）
GCP の観測可能性ツール
| ツール | 役割 |
|---|---|
| Cloud Monitoring | メトリクス・アラート・SLO 管理 |
| Cloud Logging | ログ集約・検索・エクスポート |
| Cloud Trace | 分散トレース（マイクロサービス間） |
| Cloud Profiler | 本番環境の CPU/メモリプロファイル |
| Error Reporting | 例外の集約・通知 |
📘 ⑥ Service Catalog と Marketplace
「承認済みソリューションをエンドユーザーに 1-Click で提供」する仕組み。Marketplace との混同が頻出。
管理者
↓ ソリューション登録
Service Catalog
├── 承認済み VM テンプレート
├── 承認済み Terraform モジュール
└── 承認済みアプリ構成
↓ 利用
開発者・部門ユーザー（GUI で 1-Click デプロイ）
| 観点 | Service Catalog | Marketplace |
|---|---|---|
| 提供元 | 組織内（自社管理者） | 外部ベンダー / Google |
| 用途 | 社内標準テンプレート | サードパーティ製品の購入 |
| 課金 | 自社プロジェクトの利用料のみ | ベンダー従量課金 + GCP 利用料 |
| 例 | 「承認済みの社内 VM パターン」 | 「Datadog、MongoDB Atlas」 |
Cloud Foundation Toolkit (CFT)
組織の 着地ゾーン（Landing Zone） を構築する Terraform モジュール集。
- CFT Blueprint: 推奨組織構造、IAM、ネットワーク構成のリファレンス
- Terraform Validator: ポリシー違反を検出
📘 ⑦ ディザスタリカバリ（DR）戦略
DR の 2 大指標は RTO / RPO。要件の数値感で 4 パターンを即答するのが試験対策のコア。
障害発生
↓
←── RPO（データ損失許容量）
[最後のバックアップ]
↓
←── RTO（復旧時間） ───→
[サービス再開]
| 指標 | 意味 | 例 |
|---|---|---|
| RTO（Recovery Time Objective） | どれくらいで復旧できるか（許容停止時間） | 30 分以内、4 時間以内 |
| RPO（Recovery Point Objective） | どれくらいデータ損失を許容するか（許容データ損失時間） | 5 分以内、1 時間以内 |
DR 戦略の 4 パターン（重要・頻出）
| 戦略 | 説明 | RTO | RPO | コスト |
|---|---|---|---|---|
| Backup & Restore | バックアップから手動復旧 | 数時間〜数日 | 数時間 | 低 |
| Pilot Light | 最小構成だけ起動、必要時に拡大 | 数十分 | 数分〜時間 | 中低 |
| Warm Standby | 縮小版を常時起動、フェイルオーバー時に拡大 | 数分 | 数分 | 中 |
| Hot Standby (Active-Active) | 本番と同等の構成を常時起動 | 数秒 | ほぼ 0 | 高 |
📋 DR パターン詳細（クリックで展開）
Backup & Restore
本番リージョン DR リージョン（停止中）
┌──────────┐ ┌──────────┐
│ App │ │ （停止） │
│ DB ────→│ Snapshot ──→ │ GCS バックアップ │
└──────────┘ └──────────┘
障害時: バックアップから手動で復旧（数時間）
Pilot Light
本番リージョン DR リージョン（最小起動）
┌──────────┐ ┌──────────┐
│ App │ │ DB Replica │ ← 常時同期
│ DB ────→│ Replication →│ │
└──────────┘ └──────────┘
障害時: アプリ層を起動（数十分）
Warm Standby
本番リージョン DR リージョン（縮小起動）
┌──────────┐ ┌──────────┐
│ App x10 │ │ App x2 │ ← 常時稼働
│ DB │←── 同期 ──→ │ DB │
└──────────┘ └──────────┘
障害時: スケールアップ（数分）
Hot Standby (Active-Active)
本番リージョン DR リージョン
┌──────────┐ ┌──────────┐
│ App x10 │←── Global LB →│ App x10 │
│ DB │←── 同期 ──→ │ DB │
└──────────┘ └──────────┘
障害時: LB が自動でトラフィック切替（数秒）
GCP の DR 関連サービス
| サービス | DR 機能 | RPO |
|---|---|---|
| Backup and DR Service | 統合バックアップ（VM / DB / アプリ） | 設定次第 |
| Cloud SQL | PITR + Cross-region Read Replica | 数秒（PITR） |
| Spanner Multi-region | 5 ノード以上で 99.999% SLA、強整合性、同期レプリ | 0 |
| Cloud Storage Multi-region | リージョン跨ぎ自動レプリケーション | ほぼリアルタイム |
| BigQuery | リージョン内冗長、Cross-region データセットコピー | 数時間 |
| Bigtable | App Profile + Cluster ルーティング | 数秒〜分 |
| Persistent Disk | Region PD（同期）、Snapshot Schedule | 数分〜時間 |
| GKE | Multi-cluster + Backup for GKE | 設定次第 |
| HA VPN | フェイルオーバー用ネットワーク冗長 | — |
DR テスト（DiRT: Disaster Recovery Testing）
📝
Tabletop Exercise
机上演習、シナリオを口頭で確認。最も低リスク。
🔧
Partial Failover
一部システムだけ切替。検証段階。
⚙️
Full Failover
本番を DR リージョンに切替。最終検証。
🎯
Game Day
故意に障害を起こして対応訓練。Chaos と組合せ可。
🔧 SDLC モデルの選定判断
モデルは 要件の変化頻度 × 規制 × 組織成熟度 の 3 軸で決定。
| モデル | 強み | 弱み | 適すケース |
|---|---|---|---|
| Waterfall | 計画明確、コスト読みやすい | 変化に弱い | 規制業界（医療・金融）、ハードウェア統合 |
| Agile (Scrum) | 変化に強い、フィードバック早い | ドキュメント弱い | Web/モバイル、SaaS |
| DevOps | デリバリ速度、品質両立 | 文化変革が必要 | クラウドネイティブ |
| SRE | 信頼性定量化、自動化推進 | 組織成熟度必要 | 大規模サービス、グローバル |
🔧 Cloud Build の機能と制約
| 項目 | 内容 |
|---|---|
| 並列実行 | 最大 30 同時ビルド（デフォルト、増減可） |
| ビルド時間 | デフォルト 60 分、最大 24 時間 |
| マシンタイプ | E2、N1（Standard）/ High-CPU / High-Memory |
| Private Pool | VPC 内で実行（プライベートリソースアクセス） |
| トリガー | Git push、Pub/Sub、手動、cron |
| 認証 | Workload Identity Federation（鍵管理不要） |
| セキュリティ | カスタム SA、Secret Manager 連携、SLSA Provenance |
🔧 Binary Authorization の詳細フロー
[ビルド] ── 署名 (Attestation) ──→ [Artifact Registry]
↓
[GKE / Cloud Run]
↓
Binary Authorization が
署名検証 ── 失敗 → デプロイ拒否
── 成功 → デプロイ許可
- 本番では 2 個以上のアテステーション必須（ビルド + 脆弱性スキャン合格）
- 開発環境は緩い設定で運用速度を優先
- Container Analysis と組合せて CVE 検出
🔧 GitOps パターン
[Git] ── 宣言（YAML） ──→ [Config Sync / ArgoCD] ──→ [GKE Cluster]
↑ ↓
←──────── PR でロールバック ──────────────── ドリフト検知
- Config Sync: GCP 純正、Anthos / GKE Enterprise 用
- ArgoCD / Flux: OSS、汎用 K8s
🔧 DR 設計の意思決定フロー
要件: RTO / RPO の数値感を確認
│
├── 「数日許容、コスト最重視」 → Backup & Restore
├── 「数十分許容」 → Pilot Light（DB 同期 + アプリ停止）
├── 「数分以内、両拠点稼働」 → Warm Standby
└── 「数秒、ほぼ 0」 → Hot Standby (Active-Active)
└── Spanner Multi-region + Global LB + GKE Multi-cluster
🔧 DORA Elite の達成方法
Deployment Frequency >1/日
- マイクロサービス化 + チームごとのパイプライン
- Trunk-based Development
- Feature Flag で機能とリリースを分離
Lead Time <1 時間
- Cloud Build 並列ステップ + キャッシュ
- 承認自動化（Policy as Code）
- 環境間 Promotion を 1 コマンド化
MTTR <1 時間
- Cloud Deploy Rollback で即時切戻し
- Runbook + Gemini Cloud Assist Investigations
- SLO Burn Rate Multi-window アラート
CFR 0-15%
- Canary + Verification ステップ
- Binary Authorization で署名済みのみ
- Progressive Delivery (Argo Rollouts)
🔧 Chaos Engineering 4 原則
- 定常状態の仮説を立てる（SLO 達成状態）
- 現実世界の事象を変数として扱う
- 本番環境（または近い環境）で実験
- 自動化して継続実行
⚠️ Chaos の段階的導入
Phase 1（開発環境で手動）→ Phase 2（Staging で定期）→ Phase 3（本番で限定的、夜間）→ Phase 4（本番常時）。いきなり本番で Chaos を実施しない。
🔧 実践ケーススタディ — CI/CD 設計
📋 ケース: 製造業の Web サイト刷新（クリックで展開）
要件
- 月 1 回リリース → デイリーリリースにしたい
- 規制対応で本番デプロイは承認必須
- 既存のオンプレ Jenkins からの脱却
選択
- Cloud Build（CI、Jenkins と並走移行可能）
- Artifact Registry（コンテナイメージ管理）
- Cloud Deploy（dev → stg → prod、prod は承認ゲート）
- Binary Authorization（本番には署名済みのみ）
- DORA メトリクス測定でリリース頻度 / Lead Time を可視化
📋 ケース: 決済システムの DR 設計（クリックで展開）
要件
- RTO 30 秒以内、RPO ほぼ 0
- 規制で関東・関西で地理冗長必須
- コストは無制限ではない
選択
- Spanner Multi-region (asia)（強整合性、99.999% SLA）
- GKE Multi-cluster（asia-northeast1 + asia-northeast2）
- Global External Application LB（自動フェイルオーバー）
- 月次 DiRT 訓練
🔧 SRE Workbook の信条
- エラーバジェット: SLO に未到達分をリリース速度に振り向ける
- Toil の削減: 繰り返し作業を自動化（50% 以下が目標）
- Blameless: 個人を責めずプロセスを直す
- Production Readiness Review (PRR): 本番投入前のチェックリスト
- DiRT: 計画的障害訓練
⚡ CI/CD サービス（即答）
| 用途 | 答え |
|---|---|
| CI（ビルド・テスト） | Cloud Build |
| アーティファクト保管 | Artifact Registry（旧 Container Registry の後継） |
| マネージド CD | Cloud Deploy |
| Git ホスティング | Cloud Source Repositories（GitHub/GitLab 連携も可） |
| イメージ署名検証 | Binary Authorization |
| GitOps（GCP 純正） | Config Sync（Anthos / GKE Enterprise） |
| 本番デプロイ承認 | Cloud Deploy Approval |
⚡ DORA メトリクス 4（必須暗記）
| メトリクス | 意味 | Elite |
|---|---|---|
| Deployment Frequency | デプロイ頻度 | オンデマンド（>1/日） |
| Lead Time for Changes | コミット → 本番までの時間 | <1 時間 |
| MTTR | 障害復旧平均時間 | <1 時間 |
| Change Failure Rate | リリース失敗率 | 0-15% |
⚡ DR 戦略（RTO/RPO 即答・最重要）
| 戦略 | RTO | RPO | コスト |
|---|---|---|---|
| Backup & Restore | 数時間〜数日 | 数時間 | 低 |
| Pilot Light | 数十分 | 数分〜時間 | 中低 |
| Warm Standby | 数分 | 数分 | 中 |
| Hot Standby | 数秒 | ほぼ 0 | 高 |
⚡ Service Catalog vs Marketplace
| 観点 | Service Catalog | Marketplace |
|---|---|---|
| 提供 | 組織内 | 外部ベンダー |
| 用途 | 社内標準テンプレ | サードパーティ製品 |
⚡ 暗記必須の数値
- Cloud Build 標準ビルド時間: デフォルト 60 分、最大 24 時間
- Spanner Multi-region SLA: 99.999%（5 ノード以上）
- HA VPN SLA: 99.99%
- DORA Elite: Deploy Freq >1/日、Lead Time <1h、MTTR <1h、CFR 0-15%
4.2 ビジネスプロセスの分析と定義
「人と意思決定と組織変革」を扱う領域。技術的に正解でも組織がスキルレディでなければ採用できないため、PCA ではしばしばここが決め手になります。
📘 ① ステークホルダー管理と RACI
プロジェクトに 影響を与える / 受ける すべての関係者がステークホルダー。内部（経営層・開発・運用・セキュリティ・法務・財務）と外部（顧客・ベンダー・規制当局・株主）に分類。
Power / Interest Grid（影響力・関心マトリクス）
高 ┌──────────┬──────────┐
│ │ 注意深く │ 緊密に │
│ │ 管理 │ 関わる │
影響力 ├──┼─────────┼──────────┤
│ │ 監視 │ 情報提供 │
│ │ するだけ │ し続ける │
低 └──────────┴──────────┘
低 関心 高
| 象限 | 対応 |
|---|---|
| 高影響力 × 高関心 | 緊密に管理（経営層、PM） |
| 高影響力 × 低関心 | 注意深く管理（法務、財務） |
| 低影響力 × 高関心 | 情報提供（一般ユーザー、サポート） |
| 低影響力 × 低関心 | 監視（その他） |
RACI マトリクス — 役割と責任の明確化
| 略 | 役割 | 内容 |
|---|---|---|
| R | Responsible | 実行責任者（手を動かす人） |
| A | Accountable | 説明責任者（最終承認、1 人のみ） |
| C | Consulted | 相談される人（双方向） |
| I | Informed | 報告を受ける人（一方向） |
RACI 例（クラウド移行プロジェクト）
| タスク | クラウドアーキ | DevOps | セキュリティ | 経営層 |
|---|---|---|---|---|
| アーキ設計 | R/A | C | C | I |
| CI/CD 構築 | C | R/A | C | I |
| 規制対応 | C | C | R/A | I |
| 予算承認 | C | I | I | R/A |
🔑 RACI の鉄則
A（Accountable）は 1 人のみ。複数人に分散させると責任の所在が不明確になる。R は複数可能。
📘 ② 変更管理 — ADKAR / Kotter / ITIL
組織や業務プロセスの変化を、人の抵抗を最小化しつつ定着 させる方法論。試験では「クラウド移行プロジェクトでの組織変革」を問われる。
ADKAR モデル（個人変革の 5 段階）
A: Awareness（認識） ─ なぜ変化が必要かを理解
↓
D: Desire（意欲） ─ 変化に参加したい気持ち
↓
K: Knowledge（知識） ─ どうすべきかを学ぶ
↓
A: Ability（能力） ─ 実際にできるようになる
↓
R: Reinforcement（定着） ─ 変化を維持・強化
| 段階 | 課題 | 施策例（GCP 移行） |
|---|---|---|
| A: Awareness | なぜ変化が必要か | 経営層宣言、競合事例の共有 |
| D: Desire | やる気にならない | 早期参加メリット、表彰制度 |
| K: Knowledge | 何をすべきかわからない | GCP 認定トレーニング、ハンズオン |
| A: Ability | できない | ペアプロ、メンター、サンドボックス環境 |
| R: Reinforcement | 元に戻る | 成功事例共有、KPI 連動、評価制度 |
Kotter 8 Step Model（組織変革の古典）
1. 危機感の醸成 ── 「3 年後に EOL、対応必須」
2. 推進チーム結成 ── クラウド推進室を組成
3. ビジョン策定 ── 「2 年でフルクラウド、デプロイ 10 倍」
4. ビジョン共有 ── 全社タウンホール
5. 行動の障害除去 ── 旧プロセス廃止、予算配分変更
6. 短期的成功の達成 ── パイロット部門で成果報告
7. 成果定着・追加変革 ── 他部門展開
8. 文化として定着 ── 評価制度に組込、新人研修に反映
ITIL Change Management（IT 運用での変更管理）
| 種類 | 内容 | 承認 |
|---|---|---|
| Standard Change | 定型・低リスク（事前承認済み） | 不要 |
| Normal Change | 標準外、CAB（変更諮問委員会）承認 | 必要 |
| Emergency Change | 緊急、迅速な承認プロセス | 簡略化 |
📘 ③ 意思決定プロセス — RAPID
意思決定の役割を 5 つに分けるフレームワーク（Bain & Co.）。RACI と混同しないように。
| 略 | 役割 | 内容 |
|---|---|---|
| R | Recommend | 推奨案を作成 |
| A | Agree | 推奨案に同意（拒否権あり） |
| P | Perform | 決定後に実行 |
| I | Input | 情報を提供 |
| D | Decide | 最終決定 |
RAPID 例（マルチクラウド戦略決定）
| 役割 | 担当 |
|---|---|
| R | クラウドアーキ |
| A | セキュリティ部門 |
| P | DevOps チーム |
| I | 各事業部門 |
| D | CTO |
意思決定スタイル
Consensus（全員合意）
遅いが定着率高い
Consultative（協議型）
中庸、現実的
Authoritative（権威型）
速いが反発リスク
Delegative（委任型）
速いが責任分散
💡 Disagree and Commit（Amazon 流）
反対しても、決まったら全力でコミット する文化。意思決定スピードと実行力を両立する考え方。
📘 ④ コスト最適化（FinOps）
クラウド移行は CapEx を OpEx に変換。柔軟性が増す代わりに、コストが「気付かないうちに」増えやすいため、組織として継続管理する文化（FinOps）が必要。
CapEx vs OpEx
| 項目 | CapEx（資本支出） | OpEx（運用支出） |
|---|---|---|
| 意味 | 資産購入（一度に大きく） | 月次の費用（継続的） |
| 例 | オンプレ機器購入、データセンター建設 | クラウド月額利用料、ライセンス |
| 会計 | 減価償却（数年に分散） | その期に全額計上 |
| 柔軟性 | 低（売却・廃棄が大変） | 高（解約・スケール調整可能） |
コスト最適化チェックリスト
①
Right-sizing
過剰サイズの VM を実需に合わせる。Recommender が自動提案。
②
Committed Use Discounts (CUD)
1-3 年契約で 30-55% 割引。Resource-based / Spend-based / Flexible の 3 種類。
③
Spot VMs
バッチ・中断許容ワークロードを 最大 91% 割引 で。24 時間以内に中断通知。
④
Autoscaling
アイドル時にスケールダウン。MIG / Cloud Run / GKE で実装。
⑤
Storage 階層化
GCS Autoclass、Lifecycle ルール、BigQuery パーティション/クラスタリング。
⑥
FinOps 文化
Showback / Chargeback、Cost Anomaly Detection、部門別タグ。
Committed Use Discounts (CUD) の種類
| 種類 | 対象 | 割引率 |
|---|---|---|
| Resource-based CUDs | 特定 VM タイプ・リージョン | 1 年 30% / 3 年 55% |
| Spend-based CUDs | 金額コミット（柔軟） | 1 年 28% / 3 年 46% |
| Flexible CUDs | リージョン跨ぎ、ファミリー跨ぎ可 | 中間水準 |
コスト見える化ツール
| ツール | 役割 |
|---|---|
| Cloud Billing | 課金状況確認、レポート |
| Billing Budgets | 予算アラート（しきい値超過時に通知） |
| Recommender | コスト最適化提案（VM Right-sizing 等） |
| Active Assist | AI ベースの自動最適化提案 |
| Cost Anomaly Detection | AI で異常コストパターンを検知 |
| Pricing Calculator | 事前見積もり |
| Carbon Footprint | カーボン排出量可視化（リージョン別 Grid Carbon Intensity） |
📘 ⑤ カスタマーサクセスマネジメント
営業（販売） ──→ オンボーディング ──→ 活用支援 ──→ 拡大販売
↑ ↑ ↑
セットアップ ヘルスチェック アップセル/クロスセル
（Customer Success Manager）
重要指標（暗記）
| 指標 | 内容 |
|---|---|
| NRR（Net Revenue Retention） | 既存顧客の収益維持率（>100% で拡大） |
| Churn Rate（解約率） | 一定期間の解約割合 |
| NPS（Net Promoter Score） | 推奨意向スコア |
| TTV（Time to Value） | 顧客が価値を実感するまでの時間 |
| Adoption Rate | 機能の利用率 |
GCP のカスタマーサクセス支援
| サービス | 内容 |
|---|---|
| Customer Care Plans | Standard / Enhanced / Premium のサポートレベル |
| TAM（Technical Account Manager） | Premium で専任 |
| Customer Engineer (CE) | 提案 / PoC 支援 |
| Professional Services | 設計・移行コンサルティング |
📘 ⑥ ビジネス継続性（BCP）
BCP は 事業全体 の継続を計画。DR は IT システム の復旧計画。試験では混同を狙った設問が出る。
| 観点 | BCP | DR |
|---|---|---|
| 範囲 | 事業全体（業務プロセス含む） | IT システム |
| 例 | パンデミック時の在宅勤務体制、サプライチェーン代替 | データセンター障害時のフェイルオーバー |
| 構成要素 | リスクアセスメント + BIA + 戦略 + 訓練 | 技術構成 + 手順書 + テスト |
BCP の構成要素
- リスクアセスメント: 想定災害の特定（地震、火災、サイバー攻撃等）
- 影響分析（BIA: Business Impact Analysis）: 業務停止の影響度評価
- 戦略: 復旧優先順位の決定
- 訓練: フェイルオーバー演習（年 1-2 回）
- 見直し: 体制変化に応じて更新
🔧 Salience Model（顕著性モデル）
3 軸でステークホルダーを分類する応用フレームワーク。
- Power（影響力）
- Legitimacy（正当性）
- Urgency（緊急性）
3 軸全て持つ ─→ Definitive（最優先対応）
2 軸 ─→ Expectant（期待される対応）
1 軸 ─→ Latent（潜在的、軽く対応）
🔧 抵抗を減らすコミュニケーション戦略
| 抵抗タイプ | 原因 | 対処 |
|---|---|---|
| 失職への不安 | スキル陳腐化を懸念 | 研修提供、配置転換 |
| 慣れた業務の喪失 | 既存業務へのプライド | 既存業務の価値を認め、新業務に意義付け |
| 技術への不信 | 知らないものへの恐れ | デモ、PoC、サンドボックス |
| マネジメント不信 | 過去の失敗体験 | 透明性、約束遵守、小さな成功積み上げ |
🔧 階層別コスト最適化
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 で部門制限
🔧 FinOps 用語
| 用語 | 内容 |
|---|---|
| FinOps | Cloud Financial Operations、コスト管理の組織文化 |
| Showback | 部門別コストの「見える化」（請求はしない） |
| Chargeback | 部門別に実費請求 |
| Cost Anomaly Detection | AI で異常コストパターンを検知 |
| TCO | Total Cost of Ownership、総所有コスト |
| ROI | Return on Investment、投資対効果 |
🔧 Carbon Footprint と Sustainability
- GCP の Carbon Footprint レポートで カーボン排出量を可視化
- リージョン別の Grid Carbon Intensity を開示
- 24/7 Carbon-Free Energy リージョン（finland, taiwan 等）を選定すれば持続可能性 + 規制対応に有利
🔧 ケーススタディ — 組織変革
📋 ケース: メインフレーム → クラウド（300 人体制）（クリックで展開）
要件
- 300 人の COBOL 開発者がいる
- 3 年で全システム GCP 移行
- 反対勢力多数
選択
- Kotter Step 1-2: 経営層から「3 年後 EOL」宣言、推進室設立
- ADKAR:
- A: 全社タウンホール、競合事例共有
- D: 早期参加者にインセンティブ
- K: GCP 認定トレーニング、ベンダー集合研修
- A: メンター制度、サンドボックス環境
- R: 評価制度連動、Success Story 共有
- 6R 戦略: Rehost → Replatform 段階移行
- Service Catalog: 標準テンプレート提供で開発者の学習コスト低減
⚡ ステークホルダー管理（即答）
| 状況 | 即答 |
|---|---|
| 「影響力 × 関心」 | Power / Interest Grid |
| 「役割明確化」 | RACI（R/A/C/I） |
| 「3 軸分析」 | Salience Model（Power/Legitimacy/Urgency） |
| A は何人？ | 1 人のみ |
⚡ 変更管理（即答）
| フレームワーク | 用途 |
|---|---|
| ADKAR | 個人変革の 5 段階（Awareness/Desire/Knowledge/Ability/Reinforcement） |
| Kotter 8 Step | 組織変革の古典 |
| ITIL Change Management | IT 運用（Standard/Normal/Emergency） |
| Lewin Change Model | Unfreeze → Change → Refreeze |
⚡ 意思決定（即答）
| 略 | 役割 |
|---|---|
| R | Recommend（推奨案） |
| A | Agree（同意、拒否権） |
| P | Perform（実行） |
| I | Input（情報提供） |
| D | Decide（最終決定） |
⚡ コスト最適化（即答）
1. Right-sizing → Recommender 活用
2. Committed Use → 1年 30% / 3年 55%
3. Spot VMs → 最大 91% 割引
4. Autoscaling → MIG / Cloud Run / GKE
5. Storage 階層化 → GCS Autoclass
6. BigQuery 予約 → Editions / Slot Reservations
7. Idle 削減 → Recommender / Active Assist
⚡ コスト管理ツール（即答）
| 状況 | 即答 |
|---|---|
| 予算超過通知 | Billing Budgets |
| 異常コスト検知 | Cost Anomaly Detection |
| 最適化提案 | Recommender / Active Assist |
| 事前見積もり | Pricing Calculator |
| カーボン削減 | Carbon Footprint レポート |
⚡ BCP vs DR
| 観点 | BCP | DR |
|---|---|---|
| 範囲 | 事業全体 | IT システム |
| 例 | パンデミック対応 | DC 障害時フェイルオーバー |
⚡ 必殺フレーズ（4.2）
| 状況 | 即答 |
|---|---|
| 「役割明確化」 | RACI |
| 「組織変革推進」 | ADKAR + Kotter |
| 「意思決定構造化」 | RAPID |
| 「30-55% コスト削減」 | Committed Use Discounts |
| 「最大 91% 割引」 | Spot VMs |
| 「予算超過通知」 | Billing Budgets |
| 「異常コスト検知」 | Cost Anomaly Detection |
| 「CapEx → OpEx 変換」 | クラウド移行の財務メリット |
📌 章末まとめ — 試験頻出の判断軸
| 質問のキーワード | 該当領域 | デフォルト解 |
|---|---|---|
| 「自動デプロイ」 | CI/CD | Cloud Build + Cloud Deploy |
| 「コンテナイメージ管理」 | Artifact | Artifact Registry |
| 「本番デプロイ承認」 | CI/CD | Cloud Deploy Approval + Binary Authorization |
| 「障害原因分析」 | RCA | 5 Whys + Blameless Postmortem |
| 「許容停止 4 時間」 | DR | Pilot Light or Warm Standby |
| 「許容停止数秒」 | DR | Hot Standby（Spanner Multi-region + Global LB） |
| 「データ損失ゼロ」 | DR | 同期レプリ（Spanner / Region PD） |
| 「役割明確化」 | 組織 | RACI マトリクス |
| 「変革の定着」 | 変更管理 | ADKAR + Kotter |
| 「意思決定の構造化」 | 意思決定 | RAPID |
| 「30% コスト削減」 | コスト | Committed Use + Spot + Right-sizing |
| 「予算オーバー通知」 | コスト | Billing Budgets アラート |
| 「社内標準テンプレ」 | カタログ | Service Catalog |
| 「サードパーティ製品」 | カタログ | Marketplace |
| 「統合バックアップ」 | DR | Backup and DR Service |
| 「ポリシー違反検知」 | IaC | Config Validator / OPA |
| 「リリース定量化」 | DORA | 4 メトリクス（Deploy/Lead/MTTR/CFR） |
🔑 試験中の判断フローチャート
問題文を読む ↓ [キーワード抽出] ├── 「自動」「パイプライン」 → CI/CD 系（Cloud Build/Deploy） ├── 「障害」「原因」「ポストモーテム」→ RCA / SRE ├── 「停止」「データ損失」「RTO/RPO」→ DR 戦略 ├── 「コスト」「割引」「予算」 → コスト最適化 ├── 「変化」「抵抗」「教育」 → 変更管理（ADKAR） ├── 「役割」「責任」「承認」 → RACI / RAPID ├── 「承認済みテンプレ」「社内」 → Service Catalog └── 「サードパーティ」「製品購入」 → Marketplace ↓ RTO/RPO 数値 or 割引率 or フレームワーク名で候補絞り込み ↓ ビジネス制約（規制 / 予算 / 期限）で最終選択
💡 次のステップ
- 続けて Section 5: 実装管理 へ
- または 問題演習 で出題形式に慣れる
- 用語整理は 用語集 で確認