📚 GCP PCA 学習: 2026-05-18

セクション: 4.2 ビジネスプロセスの分析と定義 前回からの繋がり: 技術プロセス（CI-CD・テスト）の自動化が整ったら、次はビジネスプロセス（変更管理・フィードバック・プロダクト計画）で「何を」「いつ」デプロイするかを意思決定する構造を整える

① 一言サマリー

ビジネスプロセスとは、一言でいうと「プロダクトの意思決定サイクル（計画 → 実行 → フィードバック → 改善）を構造化し、技術チームとビジネスチームを繋ぐ仕組み」です。

② たとえ話

飲食店の運営改善に例えます：

• 変更管理プロセス：「新メニュー追加」を決めても、急に調理場で準備できません。「いつから？」「食材は確保？」「スタッフ教育は？」を計画化する。クラウドも同じ。デプロイは技術判断ではなく、ビジネスタイミング（キャンペーン開始・顧客要件）に合わせます。

• フィードバックループ：新メニューを出したら、お客さんの評判を毎日聞く。「思ったより売れない」「副菜が不評」と分かったら、来週すぐ改良版を用意。このスピード（「計画 → 実装 → 測定 → 改善」の 1 サイクルが 1 週間）がビジネス成功の鍵。

• ロードマップ：「3 ヶ月後のシーズン変更」「半年後の新テーマ店舗」のように、中期計画を可視化。店員全員が「今月の優先度は何か」を理解できます。

③ 図解

graph LR
    A["📋 ロードマップ
3-6 ヶ月計画"] --> B["🔄 スプリント計画
2 週間単位"]
    B --> C["🛠️ 実装
技術チーム"]
    C --> D["✅ デプロイ
変更管理ゲート"]
    D --> E["📊 フィードバック
ユーザー測定"]
    E --> F["💡 レトロスペクティブ
チーム学習"]
    F -.-> B
    E -.-> A

    style A fill:#e1f5ff
    style B fill:#fff3e0
    style C fill:#f3e5f5
    style D fill:#e8f5e9
    style E fill:#fce4ec
    style F fill:#f1f8e9

④ 仕組みの深掘り

なぜビジネスプロセスが必要か

単に「できる」だけでは失敗する例：

• エンジニアが「顔認証機能」を 1 ヶ月かけて実装した
• でも営業は「顧客から要件がない」と知らなかった
• リリース後、使用率 2% で廃止になった
• 開発コスト $50K 無駄

ビジネスプロセスで防ぐ仕組み：

1. 事前ゲート（計画段階）
2. 「この機能の売上見込みは？」「何名のエンジニアで何週間？」をマトリクスで可視化

3. ROI（費用対効果）が $50K / 2% = 実現不可能 → 却下、または条件変更

4. 段階的なデプロイ

5. 内部テスト（ユーザー 0 名）→ ベータ（ユーザー 100 名、 1 週間）→ 本番（ユーザー全体）

6. ベータで「実際の使用率」を測定し、本番に進むか判断

7. フィードバックループ

8. デプロイ後、毎日「利用者数・エラー率・顧客フィードバック」を追跡
9. 問題が出たら「ロールバック（1 日）」か「パッチデプロイ（3 日）」か「放置（判断延期）」を即決

変更管理プロセスの 3 ステップ

計画 → 承認ゲート → デプロイ → 監視 → フィードバック → 改善

詳細：

⑤ 他サービスとの使い分け

ビジネスプロセス vs 技術プロセス

設定メモ：ここで登場する「エラーバジェット」とは：「SLO（目標稼働率 99.9%）を達成できれば、残りの 0.1% 分は計画的にダウンタイムして本番で新機能をテストできる」という概念。

PCA 試験での使い分け出題パターン：

• 「新機能 X を月末に本番投入したい。何をするか？」
• 技術側：Git main ブランチ保護・Pull Request 承認・自動テスト実行
• ビジネス側：フィーチャーフラグで段階的リリース・A/B テスト・フィードバック測定

⑥ 実務への応用

ケース 1: Web スタートアップ（月 4 回リリース）

[月曜] リーダーと PM が "今週のロードマップ 4 つ機能" を確定
  ↓
[火-木] エンジニア 3 人が実装・PR レビュー自動化
  ↓
[金朝] デプロイ前チェックリスト：「SLA 影響なし・DB マイグレーション OK・セキュリティ」
  ↓
[金午後] Canary 5% で 30 分監視 → Blue 50% で 1 時間 → Green 100%
  ↓
[月曜夕方] カスタマーサクセスから「利用者 1000 → 1200（+20%）」報告
  ↓
[火朝] 昨金デプロイの "うまくいった点・失敗点・次の改善" を 30 分レトロ

GCP での実装： - Cloud Build: Git push → 自動テスト実行 - Cloud Deploy: Canary / Blue-Green 自動ステージング - Cloud Monitoring: ダッシュボード（デプロイ前後の比較） - Cloud Logging: 変更履歴を 6 年自動保存（監査対応）

ケース 2: 受託開発（顧客ごとに異なるリリースサイクル）

顧客 A: 月 1 回（リスク低い・安定性重視）
  → Canary 2% / 監視 1 週間 / 承認ゲート厳格

顧客 B: 週 2 回（スタートアップ・高速試行）
  → Canary 10% / 監視 2 時間 / フィーチャーフラグ多用

顧客 C: リリース不定期（大規模変更のみ）
  → Canary 1% / 監視 2 週間 / DB バックアップ 2 回

実装の鍵： - Infrastructure as Code（Terraform）で環境をコード化 → 顧客ごとのパラメータ切り替え - フィーチャーフラグで本番で機能 ON/OFF → リスク分散 - Shared VPCで共有リソース・監視基盤を一元管理 → 運用効率化

ケース 3: 金融機関（規制厳格・監査必須）

[計画フェーズ] 規制部門も参加 → セキュリティ・コンプライアンス事前チェック
  ↓
[デプロイ前] 昨年のリリースノート・変更内容を全部出力
  ↓
[デプロイ後] Cloud Audit Logs で「誰がいつ何をデプロイしたか」記録
  ↓
[監査時] 「2024 年 3 月 15 日のデプロイは誰の承認？」に 1 秒で回答

⑦ よくある誤解・落とし穴

誤解 1: 「CI-CD がある = ビジネスプロセスは自動」

❌ 誤り： - デプロイ自動化（技術プロセス）だけでは、何をデプロイするかは決まらない - 「毎時間勝手に本番コードが更新される」会社もあり、障害が増える

✅ 正解： - デプロイ権限は PM / リーダーが持つ - エンジニアは「デプロイできる状態」を用意するだけ - 実際のデプロイ指示は、ビジネス判断に基づく

誤解 2: 「フィードバックループ = ユーザー アンケート」

❌ 誤り： - 機能リリース後に「いかがでしたか？」アンケート - 回答率 3%、参考にならない

✅ 正解： - 定量データ：Cloud Monitoring / Google Analytics で自動測定 - 「利用者数が 1000 → 800 に低下」（肌感覚でなく数字） - 「エラー率が 0.5% → 0.8%」 - 定性データ：カスタマーサクセスが毎日 3-5 社に直接ヒアリング - リアルタイム：デプロイ後 24 時間以内に測定開始

誤解 3: 「ロードマップ = 3 年先の計画」

❌ 誤り： - 「1 月に決めた 3 月のロードマップが 2 月に変わる」 - 「6 ヶ月先の予測が 50% 外れる」 - ロードマップは「呪い」になる

✅ 正解： - 1-3 ヶ月: 確度 90%（ほぼ確定） - 3-6 ヶ月: 確度 60%（方向性のみ） - 6 ヶ月以上: 確度 30%（参考値） - 毎週「今の優先度」を更新 → ロードマップは「生きた計画」

誤解 4: 「変更管理 = 遅い」

❌ 誤り： - 「変更管理ゲートで毎回 1 週間待つ」 - Web スタートアップには不要？

✅ 正解： - ゲートは 2 日以内（パラレル化で短縮可能） - 小さな変更（バグフィックス）は自動承認（ルールベース） - 大きな変更（新機能）は手動承認（ビジネス影響チェック） - 結果、全体のスピードが上がる（後で問題対応で 1 週間失う方が遅い）

⑧ 理解度チェック

シナリオ：Web サービス企業が「新しいレコメンド機能」を実装しました。月末に本番投入したいのですが、ビジネス側から「確実に利用者が使う機能か？」と質問されました。どのようなプロセスを提案しますか？

• (A) ベータ版（内部テスト 1 週間）→ 本番リリース
• (B) Canary デプロイ（ユーザー 5%）→ 24 時間監視 → 指標改善なら 100% 拡大
• (C) フィーチャーフラグで段階的リリース（10% → 50% → 100%）+ 毎日フィードバック測定
• (D) A/B テスト（グループ A: 新レコメンド / グループ B: 旧レコメンド）を 2 週間実施 → 勝ったグループの仕様で本番化

⑨ 深掘り補足（PCA 試験範囲外・オプション）

企業規模による変更管理サイクルの違い

スタートアップ（< 50 人） - リリース頻度：週 2-4 回 - 承認ゲート：15 分（Slack 投票） - ロールバック：人力（1 分） - 監視：自分たちで見る（自分たちが被害者） - 例：Stripe, Figma, Notion の初期段階

スケールアップ（50-500 人） - リリース頻度：週 1 回（金曜）か月 2 回 - 承認ゲート：1-2 日（チェックリスト自動化） - ロールバック：自動（エラー率上昇時） - 監視：SRE 専任チーム - 例：現在の Stripe, GitHub, Salesforce

エンタープライズ（> 500 人・金融など規制対象） - リリース頻度：月 1 回（予定通りまたは延期） - 承認ゲート：1 週間（複数部門レビュー） - ロールバック：計画的（ウォーム スタンバイ構成） - 監視：監査部門も参加 - 例：銀行、保険、大手企業

フィーチャーフラグ vs Git ブランチ戦略

フィーチャーフラグ（推奨）

本番コードに新機能のコード埋め込み
flag: "new_recommendation" = OFF → ユーザーに見えない
タイムスタンプ: 2026-05-18 10:00 に flag = ON → 自動デプロイなし、本番環境のみ有効化
問題発生 → flag = OFF で 30 秒に戻す

Git ブランチ（非推奨）

feature/new-recommendation ブランチで開発
→ 4 週間開発
→ PR マージ
→ デプロイ（戻せない）
→ バグ発見 → git revert（ユーザーに見える 3 分間のダウンタイム）

PCA 試験：「本番環境でのリスク最小化」という判断軸から、フィーチャーフラグが正解（デプロイ = 有効化ではない）。

次回: 4.3 信頼性を確保するための手順開発