Section 4: 技術ビジネスプロセス分析 — 問題集（20 問）
対象範囲: Section 4 (~15%) — Analyzing and optimizing technical and business processes 総問題数: 20 問 想定所要時間: 60 分（1 問 3 分目安）
学習方針
- 本問題集は 公式試験ガイド v2025-10 改訂版 に準拠しています。
- Section 4 は技術プロセス（SDLC/CI/CD/RCA/テスト/サービスカタログ/DR）と、ビジネスプロセス（ステークホルダー/変更管理/意思決定/コスト最適化/BCP）を横断します。
- 暗記より思考プロセスが重視されます。シナリオを読みながら、まず「これは技術プロセスか、ビジネスプロセスか」を判定してください。
正答率の目安
| 正答率 | 評価 | 次のアクション |
|---|---|---|
| 90% 以上 | 合格圏（試験本番でも安定） | 模擬試験 → 直前は要点と暗記のみループ |
| 75–89% | 合格安全圏未到達 | 弱点別復習ガイド（巻末）で重点強化 |
| 60–74% | 要対策 | 02_応用.md を再読 → 関連 Section 1/3 と紐付け |
| 60% 未満 | 不合格圏 | 01_基礎.md から学び直し |
問題 1 （難易度: ★）
シナリオ: Altostrat Media は動画配信プラットフォームを運営しています。これまで月 1 回のリリースだったものを、競合に追いつくため週 1 回以上にしたいと考えています。リリース後の本番障害が増えるのを避けるため、開発チームから運用チームへの "Wall of Confusion" を解消し、自動化されたデリバリパイプラインを構築する必要があります。アーキテクトとして組織モデルを助言する立場です。
質問: この状況で 最も推奨される SDLC モデルはどれですか。
選択肢:
- A. Waterfall モデルで段階レビューを徹底する
- B. DevOps モデルで開発と運用の責任を統合する
- C. V-Model でテスト工程を厚くする
- D. Big Bang リリースで全機能を一度に出す
解答と解説
正解: B
解説:
- B が正解: DevOps は開発（Dev）と運用（Ops）の組織サイロを解消し、CI/CD 自動化・共通責任モデル・ポストモーテム文化により、デプロイ頻度向上と障害削減を両立できる Google 推奨モデルです。Altostrat のような頻繁リリース要件には最適です。
- A 不正解: Waterfall は順次・戻りなしで、規制業界向け。週次リリースには不向きです。
- C 不正解: V-Model はテスト重視ですが、テスト工程が直列で時間がかかり頻繁リリースには不向きです。
- D 不正解: Big Bang リリースは Anti-pattern。一括変更は障害リスクが極めて高くなります。
ひっかけポイント: 「頻繁リリース + 障害削減」キーワードでは DevOps または SRE が定石。SRE は SLO 駆動でより成熟した形態。
関連リソース:
問題 2 （難易度: ★★）
シナリオ: Cymbal Retail は EC サイトの本番環境を Cloud Run でホストしています。新機能リリースで本番障害が頻発しており、CTO は DORA メトリクスを使って成熟度を測定したいと考えています。リリース失敗率（Change Failure Rate）が現在 35% で、Elite 水準を目指しています。
質問: DORA メトリクスにおいて Elite 水準とされる Change Failure Rate の数値はどれですか。
選択肢:
- A. 0–15%
- B. 16–30%
- C. 31–45%
- D. 46–60%
解答と解説
正解: A
解説:
- A が正解: DORA レポート（Google 公式 DevOps Research）における Elite 水準は CFR 0–15%。High が 16–30%、Medium が 16–45%、Low が 46–60% です。CFR は (失敗デプロイ件数 ÷ 全デプロイ件数) で計算します。
- B/C/D 不正解: これらは Elite ではなく High / Medium / Low の水準です。
ひっかけポイント: DORA の 4 メトリクス（Deployment Frequency / Lead Time / MTTR / CFR）はすべて暗記必須。Elite 水準は「Deployment Frequency: オンデマンド (>1/日)」「Lead Time: <1 時間」「MTTR: <1 時間」「CFR: 0–15%」。
関連リソース:
問題 3 （難易度: ★★）
シナリオ: EHR Healthcare は医療情報を扱う SaaS を運営しており、規制要件で RPO 5 分以内、RTO 1 分以内 が求められます。本番 DB は Cloud SQL for PostgreSQL ですが、リージョン障害が起きてもデータ損失がほぼゼロで瞬時に切替できる構成にしたいと考えています。コストよりも復旧速度を最優先します。
質問: この要件に最も合致する DR 戦略はどれですか。
選択肢:
- A. Backup & Restore（GCS にバックアップ）
- B. Pilot Light（最小限のレプリカを常時起動）
- C. Warm Standby（縮小スケールの待機環境）
- D. Hot Standby（Active-Active のマルチリージョン同期構成）
解答と解説
正解: D
解説:
- D が正解: Hot Standby (Active-Active) は同期レプリケーションで RPO ほぼ 0、RTO 数秒。Cloud Spanner Multi-region 構成や Cloud SQL Cross-region Read Replica（同期側）を使えば、リージョン障害時に瞬時切替可能。コスト最大ですが要件に合致します。
- A 不正解: Backup & Restore は RTO 数時間〜数日、RPO 数時間。要件を満たしません。
- B 不正解: Pilot Light は RTO 数十分、RPO 数分〜時間。RTO が要件を超過します。
- C 不正解: Warm Standby は RTO 数分、RPO 数分。RTO 1 分以内は厳しいです。
ひっかけポイント: 「データ損失ほぼ 0 + 復旧瞬時 + コスト無視」= Hot Standby + Spanner Multi-region。逆に「コスト最小 + 復旧数時間 OK」= Backup & Restore。
関連リソース:
問題 4 （難易度: ★★★）
シナリオ: KnightMotives Automotive はコネクテッドカー基盤を運営しています。先週、本番環境で 4 時間続く大規模障害が発生し、CEO 直々にポストモーテム実施を指示されました。原因は新人エンジニアが本番 SQL を誤実行したことですが、SRE リード として組織文化に根付かせる Postmortem の在り方を提案する必要があります。
質問: Google SRE が推奨する Postmortem の原則として 適切な記述を 2 つ 選びなさい。
選択肢:
- A. 個人を責めず、プロセスとシステムに焦点を当てる（Blameless）
- B. 責任者を明確に特定し、再発時のエスカレーション先とする
- C. タイムライン・影響範囲・トリガー・根本原因・アクション項目を文書化する
- D. ポストモーテムは関係者のみで共有し、組織全体には公開しない
解答と解説
正解: A, C
解説:
- A が正解: Blameless Postmortem は SRE 文化の核。個人責めから心理的安全性を確保し、本質的な原因分析を促します。
- C が正解: 必須項目は「タイムライン / 影響 / 検知 / 緩和 / 根本原因 / トリガー / アクション項目」。これにより再発防止につながります。
- B 不正解: 個人責任の追及は心理的安全性を損ね、Blameless 原則に反します。
- D 不正解: Google SRE 流では Postmortem は 組織全体に公開 し、学びを横展開するのが推奨。
ひっかけポイント: 「責任者特定」「閉じた共有」は Anti-pattern。Blameless + 全社共有 + アクション追跡が正解パターン。
関連リソース:
問題 5 （難易度: ★★）
シナリオ: 社内開発チームが、毎回新規プロジェクトで VPC ネットワーク・IAM・Firewall の構成を一から作っており、設定ミスや非標準構成が増えています。アーキテクト として、社内承認済みのインフラテンプレートを開発者がセルフサービスでデプロイできる仕組みを整備したいと考えています。
質問: この用途に最適な GCP サービスはどれですか。
選択肢:
- A. Google Cloud Marketplace
- B. Service Catalog
- C. Cloud Foundation Toolkit のみ配布
- D. Terraform Registry（HashiCorp 公式）
解答と解説
正解: B
解説:
- B が正解: Service Catalog は組織管理者が承認済み Terraform / Deployment Manager テンプレートを公開し、開発者がコンソール経由でセルフサービスデプロイできる GCP 純正サービス。社内標準化に最適です。
- A 不正解: Marketplace は 外部ベンダー / Google 提供 のサードパーティ製品の場で、社内テンプレ用途ではありません。
- C 不正解: CFT は配布の仕組みではなくサンプルテンプレート集。Service Catalog で配布するのが望ましいです。
- D 不正解: HashiCorp Terraform Registry は公開モジュール置き場で、社内承認の仕組みではありません。
ひっかけポイント: 「社内標準テンプレ」→ Service Catalog、「サードパーティ製品」→ Marketplace。両者を混同しないこと。
関連リソース:
問題 6 （難易度: ★★）
シナリオ: あるスタートアップが GCP に移行しました。最初の月の請求書を見て CFO が驚いており、「予算を超過する前に通知できないのか」と問い合わせがありました。さらに、不正なリソース起動による異常なコスト急増も自動検知したいと考えています。
質問: この要件を満たすために組み合わせるべき GCP 機能の組み合わせとして 適切な記述を 2 つ 選びなさい。
選択肢:
- A. Billing Budgets で月次予算アラートを設定する
- B. Cloud Monitoring の Uptime Check で予算逼迫を監視する
- C. Cost Anomaly Detection で異常コスト急増を自動検出する
- D. Cloud Asset Inventory でリソース一覧を毎日棚卸しする
解答と解説
正解: A, C
解説:
- A が正解: Billing Budgets は予算しきい値（例: 50%、90%、100%）で Email / Pub/Sub 通知を送出。予算超過前にプロアクティブに通知できます。
- C が正解: Cost Anomaly Detection は機械学習で平常パターンから逸脱したコスト急増を検知。不正リソース起動などのスパイクを自動アラート可能です。
- B 不正解: Uptime Check はサービス可用性の外形監視で、コスト用途ではありません。
- D 不正解: Cloud Asset Inventory はリソース棚卸し用で、コスト異常検知の機能はありません。
ひっかけポイント: 「予算超過通知」→ Billing Budgets、「異常コスト検知」→ Cost Anomaly Detection。両方とも Billing 系の機能で、観測系（Monitoring）と混同しないこと。
関連リソース:
問題 7 （難易度: ★）
シナリオ: 3 年間継続して GCE n2-standard-8 を 100 台稼働させる業務システムがあります。リージョン変更や VM タイプ変更の予定はありません。CFO からは「最大限の割引を引き出してほしい」と依頼されました。
質問: 最も大きな割引率を得られる Committed Use Discount (CUD) の種類はどれですか。
選択肢:
- A. Resource-based CUD（3 年）
- B. Spend-based CUD（3 年）
- C. Flexible CUD（1 年）
- D. Sustained Use Discount（自動適用）
解答と解説
正解: A
解説:
- A が正解: Resource-based CUD（3 年） は VM タイプ・リージョン固定で 最大 55% 割引。固定構成で長期利用が確定している場合に最適です。
- B 不正解: Spend-based CUD は金額コミットで柔軟ですが、Resource-based より割引率が低いです。
- C 不正解: Flexible CUD はリージョン跨ぎ・ファミリー跨ぎで柔軟ですが、割引率は低めです。
- D 不正解: SUD は GCE 月次自動適用ですが、最大 30% 程度で CUD より低いです。
ひっかけポイント: 数値暗記必須。1 年 30% / 3 年 55% が Resource-based の上限。固定構成なら Resource-based、変動するなら Flexible / Spend-based。
関連リソース:
問題 8 （難易度: ★★★）
シナリオ: 大規模組織でクラウド移行プロジェクトを進めていますが、現場エンジニアからの抵抗が強く、トレーニング参加率も低調です。Change Manager として、個人レベルでの変革モデルに沿った介入策を体系的に進めたいと考えています。
質問: ADKAR モデルの 5 段階のうち、トレーニング参加率を高める ために最も直接的にアプローチすべき段階はどれですか。
選択肢:
- A. Awareness（なぜ変化が必要か認識させる）
- B. Desire（参加したい気持ちを醸成する）
- C. Knowledge（どうすべきか学ぶ機会を提供する）
- D. Reinforcement（変化を強化・定着させる）
解答と解説
正解: B
解説:
- B が正解: Desire（意欲） は「参加したい」気持ちの醸成段階。トレーニング参加率が低いのは「学ぶ機会がない」のではなく「学びたい動機がない」可能性が高いため、Desire への介入が最も直接的です。インセンティブ設計や成功事例共有が有効です。
- A 不正解: Awareness は「なぜ変化が必要か」の段階で、より前のステップ。Desire の前段階としては重要ですが、すでに認識はある状況なら次に進むべきです。
- C 不正解: Knowledge はトレーニングを「提供」する段階。参加率向上には先に Desire の醸成が必要です。
- D 不正解: Reinforcement は変化定着の段階で、トレーニング参加率の前提条件ではありません。
ひっかけポイント: ADKAR は A (Awareness) → D (Desire) → K (Knowledge) → A (Ability) → R (Reinforcement) の順。「トレーニング受講」は Knowledge 段階ですが、参加率が低いなら前の Desire 段階に問題があります。
関連リソース:
問題 9 （難易度: ★★）
シナリオ: あなたは新規プロジェクトのアーキテクトで、5 つの主要意思決定をスピーディに進める必要があります。複数部署の利害が絡む中、誰が最終決定権を持つか、誰の同意が必須か、誰に情報を伝えるべきかを明確化する意思決定フレームワークを採用したいと考えています。
質問: この目的に最も合致する意思決定フレームワークはどれですか。
選択肢:
- A. RAPID（Recommend / Agree / Perform / Input / Decide）
- B. SWOT 分析（Strengths / Weaknesses / Opportunities / Threats）
- C. RACI マトリクス（Responsible / Accountable / Consulted / Informed）
- D. SMART 目標設定（Specific / Measurable / Achievable / Relevant / Time-bound）
解答と解説
正解: A
解説:
- A が正解: RAPID は意思決定プロセスの 5 役割を明確化するフレームワーク。Recommend（推奨案作成）/ Agree（同意・拒否権）/ Perform（実行）/ Input（情報提供）/ Decide（最終決定）で、誰が決めるかが明確になります。
- B 不正解: SWOT は戦略分析ツールで、意思決定の役割分担には使えません。
- C 不正解: RACI はタスク実行の役割分担で、意思決定そのものの役割ではありません。両者は補完関係ですが、質問の主軸は「意思決定」。
- D 不正解: SMART は目標設定の枠組みで、意思決定プロセスではありません。
ひっかけポイント: 「意思決定」= RAPID、「役割分担」= RACI。両方とも頻出だがニュアンスが違う。「最終決定権を誰が持つか」は RAPID の Decide が該当。
関連リソース:
問題 10 （難易度: ★★）
シナリオ: あなたは SaaS プロダクトの Customer Success Manager 兼アーキテクトとして、顧客の解約率上昇に頭を悩ませています。CTO と話し合い、既存顧客が機能を本当に活用できているかを定量化したいと考えています。
質問: 顧客が新機能の価値を実感するまでの時間を短縮するために、最も注目すべき Customer Success 指標はどれですか。
選択肢:
- A. NRR（Net Revenue Retention）
- B. Churn Rate（解約率）
- C. TTV（Time to Value）
- D. NPS（Net Promoter Score）
解答と解説
正解: C
解説:
- C が正解: TTV (Time to Value) は顧客が価値を実感するまでの時間。オンボーディング設計の改善やセルフサービス強化、ガイド付きツアー導入で短縮できます。CS で最重要の早期指標の 1 つです。
- A 不正解: NRR は既存顧客収益の維持率。重要ですが、「価値実感までの時間」とは焦点が異なります。
- B 不正解: Churn Rate は解約率で、結果指標。TTV 改善は Churn 削減の上流対策となります。
- D 不正解: NPS は推奨意向で、価値実感の結果として現れる指標です。
ひっかけポイント: 「価値実感までの時間」= TTV が一発で出ること。NRR/Churn/NPS は結果指標、TTV は原因系指標。
関連リソース:
問題 11 （難易度: ★）
シナリオ: あなたはセキュリティ・コンプライアンス担当として、社内 IT 環境全体で BCP（Business Continuity Plan）を整備しています。BCP と DR（Disaster Recovery）の違いを経営層に説明する必要があります。
質問: BCP と DR の違いとして 適切な記述を 2 つ 選びなさい。
選択肢:
- A. BCP は事業全体（業務含む）が対象、DR は IT システムが対象
- B. BCP は IT システムが対象、DR は事業全体が対象
- C. BCP には BIA（Business Impact Analysis）が必須要素として含まれる
- D. DR は BCP より広い概念で、BCP を包含する
解答と解説
正解: A, C
解説:
- A が正解: BCP は 事業全体（人・業務・サプライ・IT）を含む包括的計画。DR は IT 復旧に焦点を絞った技術計画です。
- C が正解: BIA (Business Impact Analysis) は BCP の必須要素。業務停止が事業に与える影響を分析し、復旧優先度を決定します。
- B 不正解: 逆。BCP が事業全体、DR が IT。
- D 不正解: 逆。BCP > DR の関係で、BCP が DR を包含します。
ひっかけポイント: BCP と DR の関係は BCP ⊃ DR（包含関係）。BCP は経営視点の計画書、DR は技術視点の手順書。
関連リソース:
問題 12 （難易度: ★★）
シナリオ: Cymbal Retail は新サービス起動前に DR テストを実施したいと考えています。本番影響を最小化しつつ、災害復旧手順が実際に機能するかを段階的に検証する必要があります。最初は手順書のレビューから始め、徐々に実環境に近い演習に進めたいと考えています。
質問: DR テスト（DiRT: Disaster Recovery Testing）の種類のうち、最も本番影響が少ないもの はどれですか。
選択肢:
- A. Tabletop（机上演習・手順書レビュー）
- B. Partial Failover（一部システムのフェイルオーバー実施）
- C. Full Failover（全システム実切替）
- D. Game Day（自由形式の障害演習）
解答と解説
正解: A
解説:
- A が正解: Tabletop は会議室での手順書レビュー型演習。本番影響ゼロで、手順の妥当性チェックや関係者のロール確認に最適です。DR テストの第 1 段階として位置付けられます。
- B 不正解: Partial Failover は一部システムを実切替するため、限定的に本番影響があります。
- C 不正解: Full Failover は全システム実切替で、本番影響が最大です。
- D 不正解: Game Day は予告なしの障害演習で、リアルタイム対応スキルを検証します。Tabletop より影響大です。
ひっかけポイント: 段階順は Tabletop → Partial Failover → Full Failover → Game Day の順で本番影響が大きくなります。
関連リソース:
問題 13 （難易度: ★★）
シナリオ: あるエンタープライズで、IT 部門にチケットが大量に殺到しています。マネージャーは ITIL に基づき変更を分類し、「事前承認済みで頻繁に行う標準的変更」については承認フローを簡略化したいと考えています。
質問: ITIL 変更管理における Standard Change の特徴として、最も正確な記述 はどれですか。
選択肢:
- A. CAB（Change Advisory Board）の毎回承認が必要
- B. 事前承認済みのため、追加承認は不要
- C. 緊急事態でのみ実行され、事後審査される
- D. 影響範囲が極めて大きく、CIO 直接承認が必要
解答と解説
正解: B
解説:
- B が正解: ITIL の Standard Change は事前にリスク評価・承認済みのため、追加承認なしで実行可能。例: 標準的なソフトウェアパッチ適用、テンプレ化された VM 起動などです。
- A 不正解: CAB 承認が毎回必要なのは Normal Change。
- C 不正解: 緊急時の簡略承認は Emergency Change。
- D 不正解: CIO 直接承認のような重大変更は Normal Change のうち、特に高リスクなものに該当します。
ひっかけポイント: ITIL 3 種を覚える: Standard（事前承認）/ Normal（CAB 承認）/ Emergency（事後審査）。Standard を CAB 承認と混同しないこと。
関連リソース:
問題 14 （難易度: ★★）
シナリオ: KnightMotives Automotive は世界 30 か国にサプライチェーン拠点を持ち、複数事業部に分かれています。CFO は「クラウド利用料を部門別に可視化したいが、社内振替請求はしたくない（運用負荷増）」と相談してきました。
質問: この要件に最も合致する FinOps プラクティスはどれですか。
選択肢:
- A. Chargeback（部門別実費請求）
- B. Showback（部門別コスト見える化、請求なし）
- C. TCO 分析（総所有コスト試算）
- D. ROI 計算（投資対効果）
解答と解説
正解: B
解説:
- B が正解: Showback は部門別コストを可視化（レポート提示）するが、実際の請求は行わない方式。運用負荷を抑えつつ、コスト意識を醸成できます。Cloud Billing のラベル・プロジェクト構造で実装可能です。
- A 不正解: Chargeback は実費請求のため、社内振替プロセスが必要で運用負荷が増します。
- C 不正解: TCO は移行前後のコスト試算で、運用中の継続可視化ではありません。
- D 不正解: ROI は投資判断指標で、コスト配賦の方法ではありません。
ひっかけポイント: Showback（見える化のみ）と Chargeback（実費請求）の違いは頻出。「請求はしたくない」がキーワードなら Showback。
関連リソース:
問題 15 （難易度: ★★★）
シナリオ: Altostrat Media は動画変換ワークロードを GCE で大量実行しています。バッチ処理のため、ジョブ中断は許容できます（チェックポイント再開可）。コスト削減を最大化したい一方で、確実に終わらせる必要がある一部のジョブは中断不可です。
質問: この混在ワークロードに対する最適な構成として、適切な記述を 2 つ 選びなさい。
選択肢:
- A. 中断可能なバッチには Spot VM を使い、最大 91% 割引を享受する
- B. 中断不可なジョブには通常 VM + Resource-based CUD を適用する
- C. すべて Spot VM に統一し、再起動ロジックを書く
- D. すべて Preemptible VM（24 時間制限あり）に統一する
解答と解説
正解: A, B
解説:
- A が正解: Spot VM は最大 91% 割引 で中断可能ワークロードに最適。動画変換のようなチェックポイント可能ジョブにフィットします。中断時は 30 秒前に通知が出ます。
- B が正解: 中断不可ジョブは通常 VM + CUD（1 年 30% / 3 年 55%） で安定割引。両者の組み合わせで TCO 最小化できます。
- C 不正解: 中断不可ジョブを Spot にするとリスク大。再起動ロジックがあってもタイムリミット制約のあるジョブには不向きです。
- D 不正解: Preemptible VM は旧名（24 時間上限）。後継の Spot VM（時間制限なし）が現行推奨。すべて Preemptible に統一は最適ではありません。
ひっかけポイント: Spot VM ≠ Preemptible VM。Spot は 時間制限なし で Preemptible の後継。Spot + CUD の組み合わせ最適化が王道。
関連リソース:
問題 16 （難易度: ★★）
シナリオ: あるグローバル製造業がデータセンターからクラウドへの移行を進めています。これまで CapEx 中心の IT 投資で 5 年減価償却していました。CFO は会計影響を理解したいと相談してきました。
質問: クラウド移行による会計影響として、最も正確な記述 はどれですか。
選択肢:
- A. CapEx が増加し、OpEx は減少する
- B. CapEx は減少し、OpEx が増加する（月次費用として継続計上）
- C. CapEx も OpEx も両方とも減少する
- D. 会計区分は変わらず、税金計算のみ変わる
解答と解説
正解: B
解説:
- B が正解: クラウド移行は典型的に CapEx → OpEx 変換。オンプレ機器購入（CapEx、減価償却）から、月次クラウド利用料（OpEx、当期費用）への切り替えで、初期投資負担が軽減され、財務柔軟性が向上します。
- A 不正解: 逆方向。CapEx が増えるならクラウド化のメリットが薄れます。
- C 不正解: 単純に減るのではなく、CapEx ↓ / OpEx ↑ の変換が正確です。
- D 不正解: 会計区分が変わるのが本質的な財務インパクトです。
ひっかけポイント: 「クラウド = OpEx 化」を一発で出せること。減価償却（5–7 年）から月次費用へ。
関連リソース:
問題 17 （難易度: ★★）
シナリオ: あなたは Cymbal Retail のプロジェクトマネージャーとして、複数ステークホルダーを管理しています。CEO は「変革成功にすごく関心はあるが、日々の意思決定は委任」、開発リードは「現場の関心は高いが、決裁権限はない」、業界規制庁は「変革には影響力が大きいが、関心は低い」状態です。
質問: Power / Interest Grid に基づき、業界規制庁への対応として 最も適切な戦略 はどれですか。
選択肢:
- A. 緊密管理（Manage Closely）— 高影響力 × 高関心のグループ
- B. 注意深く管理（Keep Satisfied）— 高影響力 × 低関心のグループ
- C. 情報提供（Keep Informed）— 低影響力 × 高関心のグループ
- D. 監視（Monitor）— 低影響力 × 低関心のグループ
解答と解説
正解: B
解説:
- B が正解: 業界規制庁は 高影響力 × 低関心（規制違反になれば事業に致命傷だが、日々の関心は薄い）。"Keep Satisfied" 戦略で、必要十分な情報提供と、関心を引かないよう注意深く管理することが推奨されます。
- A 不正解: 高影響力 × 高関心向け（例: 直属の経営層）。
- C 不正解: 低影響力 × 高関心向け（例: 現場開発リード）。
- D 不正解: 低影響力 × 低関心向け（例: 外部一般メディア）。
ひっかけポイント: Power/Interest Grid 4 象限を理解する。CEO（高影響 × 低関心 = Keep Satisfied）、開発リード（低影響 × 高関心 = Keep Informed）、規制庁（高影響 × 低関心 = Keep Satisfied）など、各象限を即答できることが大切です。
関連リソース:
問題 18 （難易度: ★★）
シナリオ: EHR Healthcare は GCP に医療データ基盤を構築しました。GCP の Customer Care サポートを契約しようとしていますが、専任の TAM（Technical Account Manager）が必要で、リアルタイム連絡や四半期事業レビューも欲しいと考えています。
質問: EHR Healthcare に推奨される Google Cloud Customer Care Plan はどれですか。
選択肢:
- A. Basic Support（無料・コミュニティベース）
- B. Standard Support
- C. Enhanced Support
- D. Premium Support
解答と解説
正解: D
解説:
- D が正解: Premium Support は専任 TAM（Technical Account Manager）が付与され、四半期事業レビュー、優先サポート、最短対応 SLA が含まれます。エンタープライズ・規制業界向けの最上位プランです。
- A 不正解: Basic は無料コミュニティのみで、TAM は含まれません。
- B 不正解: Standard には TAM は含まれません。
- C 不正解: Enhanced は中位プランで、TAM は標準では含まれません（オプション）。
ひっかけポイント: 「専任 TAM 必須」= Premium。Customer Care Plan の階層（Basic → Standard → Enhanced → Premium）を覚えること。
関連リソース:
問題 19 （難易度: ★★★）
シナリオ: あなたは SRE として、Cloud Run の本番障害で 5 Whys を使った RCA を実施しています。「Cloud Run が 503 を返した」→「メモリ不足で OOM Kill」→「直近のリリースでメモリリーク」→「コードレビューで見落とした」→「コードレビューチェックリストにメモリ系項目がなかった」と展開しました。
質問: このようなプロセス的根本原因に対し、最も効果的な再発防止策はどれですか。
選択肢:
- A. メモリリークしたコードを書いた開発者を厳重注意する
- B. コードレビューチェックリストにメモリ系項目を追加し、Cloud Profiler を CI に組み込む
- C. Cloud Run のメモリ上限を 2 倍に増やす
- D. 障害の発生していたリリースをロールバックする
解答と解説
正解: B
解説:
- B が正解: 5 Whys で特定した根本原因「チェックリストの欠落」に対する プロセス的対応。コードレビューの仕組み改善 + CI への Cloud Profiler 統合で、メモリリークを継続検知できます。これが Blameless Postmortem の本質的アクションです。
- A 不正解: 個人責めは Blameless 原則に反する Anti-pattern。再発防止になりません。
- C 不正解: メモリ増強は対症療法で、根本原因に対応していません。次回もリークすれば再発します。
- D 不正解: ロールバックは緊急対応であって、再発防止策ではありません。
ひっかけポイント: 5 Whys の最終根本原因は 「プロセス・システム」 であることが多い。それに対する対応もプロセス改善でなければ意味がない。「個人責任」「対症療法」「緊急対応」と「再発防止」を区別すること。
関連リソース:
問題 20 （難易度: ★★★）
シナリオ: ある中堅企業がクラウド移行プロジェクト中。Phase 1（インフラ移行）は完了し、Phase 2（アプリケーション最適化）を進めようとしています。しかし、組織全体で疲弊感が広がり、Phase 2 着手前に追加変革を進める動機が薄れています。Change Manager として、Kotter の 8 Step に沿って次の打ち手を打ちたいと考えています。
質問: Kotter の 8 Step のうち、Phase 1 完了直後、Phase 2 への移行を加速するために 最も重要なステップ はどれですか。
選択肢:
- A. Step 1: 危機感の醸成（Create Urgency）
- B. Step 6: 短期的成功を計画する（Generate Short-term Wins）
- C. Step 7: 追加変革を進める（Sustain Acceleration）
- D. Step 8: 文化への定着（Anchor in Culture）
解答と解説
正解: C
解説:
- C が正解: Kotter Step 7 は 「Sustain Acceleration（追加変革を進める）」。Phase 1 の成功を踏まえ、勢いを保ち追加変革（Phase 2）を進める段階。短期成果を活かして次の変革を加速するのがこのステップの本質です。
- A 不正解: Step 1 は変革開始時点。すでに Phase 1 完了後で、危機感醸成は遅すぎます。
- B 不正解: Step 6（短期的成功）は Phase 1 の完了がそれに相当。次のステップに進むべき段階です。
- D 不正解: Step 8（文化定着）は最終ステップで、Phase 2 完了後の話です。
ひっかけポイント: Kotter 8 Step を順序通り暗記する。1.危機感 → 2.推進チーム → 3.ビジョン → 4.共有 → 5.障害除去 → 6.短期成功 → 7.追加変革 → 8.文化定着。「次のフェーズへの加速」= Step 7。
関連リソース:
正答率早見表
| 問題 | 難易度 | 主トピック | 正解 |
|---|---|---|---|
| 1 | ★ | SDLC モデル選定 | B |
| 2 | ★★ | DORA メトリクス | A |
| 3 | ★★ | DR 戦略選定 | D |
| 4 | ★★★ | Blameless Postmortem | A, C |
| 5 | ★★ | Service Catalog | B |
| 6 | ★★ | Billing Budgets + Anomaly | A, C |
| 7 | ★ | CUD 種類 | A |
| 8 | ★★★ | ADKAR | B |
| 9 | ★★ | RAPID 意思決定 | A |
| 10 | ★★ | Customer Success TTV | C |
| 11 | ★ | BCP vs DR | A, C |
| 12 | ★★ | DiRT Tabletop | A |
| 13 | ★★ | ITIL Standard Change | B |
| 14 | ★★ | Showback | B |
| 15 | ★★★ | Spot VM + CUD | A, B |
| 16 | ★★ | CapEx → OpEx | B |
| 17 | ★★ | Power/Interest Grid | B |
| 18 | ★★ | Premium Support | D |
| 19 | ★★★ | 5 Whys 根本原因 | B |
| 20 | ★★★ | Kotter Step 7 | C |
弱点別復習ガイド
正答率が低かった分野に応じて、以下の学習資料に戻ってください。
| 弱点分野 | 関連問題 | 復習リソース |
|---|---|---|
| SDLC / DORA | 1, 2, 19 | ../02_学習資料/04_技術ビジネスプロセス分析/02_応用.md §「DORA メトリクス」「SDLC」 |
| DR / BCP | 3, 11, 12 | ../02_学習資料/04_技術ビジネスプロセス分析/02_応用.md §「DR 戦略」「BCP」 |
| RCA / Postmortem | 4, 19 | ../02_学習資料/04_技術ビジネスプロセス分析/02_応用.md §「RCA」「Postmortem」 |
| Service Catalog / カタログ管理 | 5 | ../02_学習資料/04_技術ビジネスプロセス分析/02_応用.md §「Service Catalog」 |
| コスト最適化（CUD / Spot / Billing） | 6, 7, 14, 15, 16 | ../02_学習資料/04_技術ビジネスプロセス分析/02_応用.md §「コスト最適化」「CUD」「FinOps」 |
| 変更管理（ADKAR / Kotter / ITIL） | 8, 13, 20 | ../02_学習資料/04_技術ビジネスプロセス分析/02_応用.md §「ADKAR」「Kotter」「ITIL」 |
| 意思決定 / ステークホルダー | 9, 17 | ../02_学習資料/04_技術ビジネスプロセス分析/02_応用.md §「RAPID」「Stakeholder 管理」 |
| Customer Success / Care Plans | 10, 18 | ../02_学習資料/04_技術ビジネスプロセス分析/02_応用.md §「Customer Success」 |
推奨復習サイクル
- 誤答した問題のみを翌日に再演（メタ認知の強化）
- 3 日後に全 20 問を再演（記憶定着確認）
- 1 週間後に模擬試験で総合演習 →
../04_模擬試験/配下
次は →
section5_問題集.md（実装管理）に進む。