Section 4: 技術ビジネスプロセス分析 — 📘 基礎編

対象: 実務 1-2 年・GCP 初学者 / プロセス・組織まわりの用語を初めて学ぶ人。目標: SDLC、CI/CD、DR、コスト最適化、変更管理の基本を一通り押さえる。

1. なぜ「プロセス」が試験範囲に入るのか

クラウドアーキテクトの仕事は 技術選定だけ ではありません。プロジェクトを成功させるには：

観点	必要なスキル
技術	サービス選定、性能・コスト設計
プロセス	SDLC、CI/CD、テスト、DR の設計
人・組織	ステークホルダー管理、変更管理、教育

試験では「技術的に正しい解」ではなく「ビジネス的に正しい解」を求められます。例えば「Refactor が技術的にベストでも、組織がスキルレディでないなら段階的に Rehost → Replatform」のような判断が問われます。

2. ソフトウェア開発ライフサイクル（SDLC）

SDLC の 6 フェーズ

1. 要件定義  →  2. 設計  →  3. 実装  →  4. テスト  →  5. デプロイ  →  6. 運用・保守
   ↓              ↓           ↓           ↓            ↓             ↓
ヒアリング      アーキ図    コード書き  単体/結合    リリース      監視・改善
ユーザー       ER 図                    手動/自動                  バグ修正
ストーリー    シーケンス図

主要な開発モデル

モデル	特徴	適する状況
Waterfall	各フェーズを順番に、戻りなし	要件が固定、規制業界（金融・医療）
Agile (Scrum)	2-4 週間の Sprint、反復開発	要件が変化、ユーザーフィードバック重視
DevOps	開発と運用の統合、自動化重視	高頻度リリース、Web サービス
SRE	サービス信頼性に責任を持つチーム、SLO 駆動	大規模サービス（Google 発祥）

Agile / DevOps / SRE の関係

Waterfall ──→ Agile ──→ DevOps ──→ SRE
（順次）    （反復）   （自動化） （信頼性）
              ↓
     Shift Left（テスト・セキュリティを早期に）

Agile: 「何を作るか」を反復で検証
DevOps: 「どう届けるか」を自動化で短縮
SRE: 「どう運用するか」を SLO で定量化

3. CI/CD（継続的インテグレーション/継続的デリバリー）

CI/CD の流れ

コード変更
  ↓
Git Push ──→ CI（自動ビルド + テスト）── 失敗 → 通知
                ↓ 成功
              アーティファクト保存
                ↓
              CD（自動デプロイ）
                ├── 開発環境
                ├── ステージング
                └── 本番環境

GCP の CI/CD サービス

サービス	役割
Cloud Source Repositories	Git ホスティング（GitHub/GitLab 連携も可）
Cloud Build	ビルド・テスト実行サーバーレス CI
Artifact Registry	コンテナイメージ・パッケージ保管（旧 Container Registry の後継）
Cloud Deploy	マネージド CD（GKE / Cloud Run / Anthos に対応）
Binary Authorization	デプロイ前のイメージ署名検証

Cloud Build の基本

# cloudbuild.yaml
steps:
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'us-docker.pkg.dev/$PROJECT_ID/app/image:$SHORT_SHA', '.']
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'us-docker.pkg.dev/$PROJECT_ID/app/image:$SHORT_SHA']
  - name: 'gcr.io/cloud-builders/gcloud'
    args: ['run', 'deploy', 'my-app', '--image', 'us-docker.pkg.dev/$PROJECT_ID/app/image:$SHORT_SHA', '--region', 'us-central1']

Cloud Deploy の基本

Cloud Build が ビルド、Cloud Deploy が 段階的デプロイ を担当します。

[Cloud Build] ──→ Artifact Registry ──→ [Cloud Deploy]
                                          ├── dev    （自動デプロイ）
                                          ├── stg    （承認後デプロイ）
                                          └── prod   （承認 + Canary）

Delivery Pipeline: dev → stg → prod の順序を定義
Target: 各環境（GKE / Cloud Run / Anthos）
Promote / Rollback: 環境間の昇格・切り戻しが 1 コマンド

CI と CD の違い

用語	内容
CI (Continuous Integration)	コードを頻繁に統合し、自動テストで品質担保
CD (Continuous Delivery)	本番デプロイ可能な状態を常に維持（最終リリースは手動）
CD (Continuous Deployment)	本番への自動デプロイまで含む

4. トラブルシュートと RCA（根本原因分析）

インシデント対応の流れ

1. 検知（アラート）
  ↓
2. トリアージ（重要度判定）
  ↓
3. 復旧（Workaround で被害最小化）
  ↓
4. 根本原因調査（RCA）
  ↓
5. 恒久対策実施
  ↓
6. Postmortem（振り返り）

Root Cause Analysis（RCA）の手法

手法	内容
5 Whys	「なぜ？」を 5 回繰り返して根本原因に到達
Fishbone（Ishikawa）	人・プロセス・技術・環境などカテゴリ別に原因を整理
Fault Tree Analysis	トップダウンで障害の論理的因果を分析

5 Whys の例

障害: 本番サイトが 10 分間ダウンした
↓ なぜ？
DB 接続プールが枯渇した
↓ なぜ？
バッチがコネクションを解放しなかった
↓ なぜ？
例外時に finally 句でクローズしていなかった
↓ なぜ？
コードレビューで見逃された
↓ なぜ？
DB 接続用のチェックリストがなかった
→ 対策: PRテンプレートに DB 接続チェック項目を追加

Blameless Postmortem

個人を責めず、システム・プロセスの改善 に焦点を当てる文化。SRE の中心思想。

「誰が悪い」ではなく「どのプロセスが脆弱だったか」
心理的安全性を確保し、隠蔽を防ぐ

GCP の観測可能性ツール

ツール	役割
Cloud Monitoring	メトリクス・アラート・SLO 管理
Cloud Logging	ログ集約・検索・エクスポート
Cloud Trace	分散トレース（マイクロサービス間）
Cloud Profiler	本番環境の CPU/メモリプロファイル
Error Reporting	例外の集約・通知
Cloud Debugger（廃止）	旧サービス、現在は Logging/Trace で代替

5. テストと検証

テストの種類

ピラミッド構造（下から多く）

         /\
        /E2E\          少（高コスト・遅い）
       /------\
      / 結合   \
     /---------\
    /  単体     \      多（低コスト・速い）
   /------------\

種類	内容	実行頻度
単体テスト（Unit）	関数単位、モックを多用	毎コミット
結合テスト（Integration）	複数モジュール連携	毎 PR
E2E テスト	ユーザー操作を再現、本番に近い環境	デプロイ前
スモークテスト	デプロイ後の最低限の動作確認	デプロイ直後
負荷テスト	想定トラフィックでの性能確認	リリース前
カナリアテスト	本番でごく一部のユーザーに先行リリース	リリース時

インフラのテスト

IaC（Infrastructure as Code）の検証は コードと同じくテスト必須 です。

ツール	役割
terraform validate	構文チェック
terraform plan	適用前のドリフト確認
Terratest	Terraform の統合テスト
InSpec	コンプライアンス検査
Config Validator / OPA	Policy as Code でガードレール

6. Service Catalog とプロビジョニング

Service Catalog

組織内で 承認済みのソリューション をエンドユーザーに提供する仕組み。

管理者
  ↓ ソリューション登録
Service Catalog
  ├── 承認済み VM テンプレート
  ├── 承認済み Terraform モジュール
  └── 承認済みアプリ構成
  ↓ 利用
開発者・部門ユーザー（GUI で 1-Click デプロイ）

Service Catalog vs Marketplace

観点	Service Catalog	Marketplace
提供元	組織内（自社管理者）	外部ベンダー / Google
用途	社内標準テンプレート	サードパーティ製品の購入
課金	自社プロジェクトの利用料のみ	ベンダー従量課金 + GCP 利用料
例	「承認済みの社内 VM パターン」	「Datadog、MongoDB Atlas」

Cloud Foundation Toolkit (CFT)

組織の 着地ゾーン（Landing Zone） を構築する Terraform モジュール集。

CFT Blueprint: 推奨組織構造、IAM、ネットワーク構成のリファレンス
Terraform Validator: ポリシー違反を検出

7. ディザスタリカバリ（DR）

DR の 2 大指標

指標	意味	例
RTO（Recovery Time Objective）	どれくらいで復旧できるか（許容停止時間）	30 分以内、4 時間以内
RPO（Recovery Point Objective）	どれくらいデータ損失を許容するか（許容データ損失時間）	5 分以内、1 時間以内

障害発生
  ↓
  ←── RPO（データ損失許容量）
     [最後のバックアップ]
  ↓
  ←── RTO（復旧時間） ───→
                          [サービス再開]

DR 戦略の 4 パターン（重要・頻出）

戦略	説明	RTO	RPO	コスト
Backup & Restore	バックアップから手動復旧	数時間〜数日	数時間	低
Pilot Light	最小構成だけ起動、必要時に拡大	数十分	数分〜時間	中低
Warm Standby	縮小版を常時起動、フェイルオーバー時に拡大	数分	数分	中
Hot Standby (Active-Active)	本番と同等の構成を常時起動	数秒	ほぼ 0	高

GCP の DR 関連サービス

サービス	用途
Backup and DR Service	統合バックアップ（VM / DB / アプリ）
Cloud Storage（マルチリージョン）	バックアップ保管、地理冗長
Persistent Disk Snapshot	VM ディスクのスナップショット
Cloud SQL PITR	Point-in-Time Recovery（任意の時点まで復旧）
Spanner Multi-region	強整合性のグローバル冗長
HA VPN	フェイルオーバー用ネットワーク冗長

8. ステークホルダー管理

ステークホルダーとは

プロジェクトに 影響を与える、または影響を受ける すべての関係者。

例：

内部: 経営層、開発チーム、運用チーム、セキュリティ、法務、財務
外部: 顧客、ベンダー、規制当局、株主

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

9. 変更管理（Change Management）

変更管理とは

組織や業務プロセスの変化を、人の抵抗を最小化しつつ定着 させる方法論。

ADKAR モデル（5 ステップ）

A: Awareness（認識）   ─ なぜ変化が必要かを理解
↓
D: Desire（意欲）       ─ 変化に参加したい気持ち
↓
K: Knowledge（知識）    ─ どうすべきかを学ぶ
↓
A: Ability（能力）      ─ 実際にできるようになる
↓
R: Reinforcement（定着） ─ 変化を維持・強化

例: 「オンプレ → GCP 移行」では、まず なぜクラウドか を全員に納得させ（A）、研修で GCP の使い方 を教え（K）、実際に手を動かして使えるようにする（A）。

Kotter 8 Step Model

組織変革の古典モデル。

1. 危機感の醸成
2. 推進チーム結成
3. ビジョン策定
4. ビジョン共有
5. 行動の障害除去
6. 短期的成功の達成
7. 成果定着・追加変革
8. 文化として定着

ITIL Change Management

IT 運用での変更管理プロセス。

種類	内容	承認
Standard Change	定型・低リスク（事前承認済み）	不要
Normal Change	標準外、CAB（変更諮問委員会）承認	必要
Emergency Change	緊急、迅速な承認プロセス	簡略化

10. コスト最適化（CapEx vs OpEx）

CapEx vs OpEx

項目	CapEx（資本支出）	OpEx（運用支出）
意味	資産購入（一度に大きく）	月次の費用（継続的）
例	オンプレ機器購入、データセンター建設	クラウド月額利用料、ライセンス
会計	減価償却（数年に分散）	その期に全額計上
柔軟性	低（売却・廃棄が大変）	高（解約・スケール調整可能）

クラウド移行の財務的メリット: CapEx を OpEx に変換 → キャッシュフロー改善・柔軟性向上

コスト最適化の 5 つの基本テクニック

Right-sizing: 過剰サイズの VM を実需に合わせる（Recommender が提案）
Committed Use Discounts: 1-3 年契約で 30-55% 割引
Spot VMs: バッチ・中断許容ワークロードを 最大 91% 割引 で
Autoscaling: アイドル時にスケールダウン
Storage 階層化: GCS Autoclass、BigQuery パーティション/クラスタリング

コスト見える化ツール

ツール	役割
Cloud Billing	課金状況確認、レポート
Billing Budgets	予算アラート（しきい値超過時に通知）
Recommender	コスト最適化提案（VM Right-sizing 等）
Active Assist	AI ベースの自動最適化提案
Pricing Calculator	事前見積もり

11. ビジネス継続性（BCP: Business Continuity）

BCP と DR の違い

観点	BCP	DR
範囲	事業全体（業務プロセス含む）	IT システム
例	パンデミック時の在宅勤務体制、サプライチェーン代替	データセンター障害時のフェイルオーバー

BCP の構成要素

リスクアセスメント: 想定災害の特定（地震、火災、サイバー攻撃等）
影響分析（BIA: Business Impact Analysis）: 業務停止の影響度評価
戦略: 復旧優先順位の決定
訓練: フェイルオーバー演習（年 1-2 回）
見直し: 体制変化に応じて更新

12. まとめ — 試験頻出の判断軸

質問のキーワード ──→ 該当領域 ──→ デフォルト解
─────────────────────────────────────────────
「自動デプロイ」     → CI/CD     → Cloud Build + Cloud Deploy
「コンテナイメージ管理」→ Artifact → Artifact Registry
「障害原因分析」     → RCA       → 5 Whys + Postmortem
「許容停止 4 時間」  → DR        → Pilot Light or Warm Standby
「許容停止数秒」     → DR        → Hot Standby (Active-Active)
「役割明確化」       → 組織      → RACI マトリクス
「変革の定着」       → 変更管理  → ADKAR
「30% コスト削減」   → コスト    → Committed Use + Spot + Right-sizing
「予算オーバー通知」 → コスト    → Billing Budgets アラート
「社内標準テンプレ」 → カタログ  → Service Catalog
「サードパーティ製品」→ カタログ → Marketplace

次のステップ

中堅レベルへ進む方: 02_応用.md で DORA メトリクス・Cloud Deploy 戦略・DR パターン詳細・RAPID を学ぶ
試験準備中の方: 03_要点と暗記.md で要点を整理
演習を始める方: ../../03_問題集/section4_問題集.md