実装と運用
業務プロセスと組織
試験ガイド 4.2 の設問は、技術の知識がなくても選べる形で出ます。事業の目的に照らして関係者の懸念を先に聞き、小さく試し、チームが運用できるものを選ぶ答えが正解になります。
試験ガイドのセクション 4.2 は、ステークホルダー管理、変更管理、チームのスキル評価、意思決定、カスタマーサクセス、CapEx と OpEx、事業継続を扱います。問われるのはサービス選びより、アーキテクトとしての動き方です。正解はほぼ共通で、事業の目的と関係者の懸念を先に確かめ、小さく試して数字で判断し、チームが運用できる形を選びます。上の承認を盾に押し切る、全部を一度に切り替える、チームの経験を無視して最新の技術を選ぶ、という選択肢は外れです。
関係者ごとに、気にしていることが違う
移行や新しい構成の提案では、誰が承認し、誰が影響を受けるかを最初に洗い出し、それぞれが判断できる材料を持っていきます。
CISO がデータを国外に出したくないと言うなら、リージョンを国内に限る組織ポリシーや Assured Workloads を示して再提案します。仕組みはコンプライアンスとデータの所在で扱います。
変更は小さく始め、人の不安を先に扱う
変更管理には 2 つの意味があり、どちらも出ます。1 つは本番への変更を承認し記録する IT の手続きです。変更をコードにしてレビューを通し、戻せる状態で出します (IaC とデリバリー)。会議での承認待ちでリリースが遅れるなら、自動テストと段階的なリリースに安全の確認を移し、低リスクの変更は会議を通さない形にします。
もう 1 つは、組織や働き方の変化を人に受け入れてもらう取り組みです。運用チームが仕事を失うと反発したら、移行後の役割を示し、研修の時間と予算を確保し、小さなシステムの移行をチーム自身に成功させます。移行後に運用するのはそのチームなので、外部に任せきりにする案は選びません。
チームのスキルに合うサービスを選ぶ
同じ要件を満たす構成が 2 つあれば、チームが今のスキルで運用できるほうを選びます。SQL に慣れていて Hadoop の経験がないなら Managed Service for Apache Spark (旧 Dataproc) より BigQuery、Kubernetes の経験がないなら GKE Standard より Cloud Run か GKE Autopilot です。既存の Spark のジョブを書き換えずに動かしたいなら Dataproc を選びます。足りないスキルは、研修 (Google Cloud Skills Boost)、パートナーとの協業、マネージドサービスの採用で補います。組織の成熟度を測る枠組みとして Cloud Adoption Framework があります。
意思決定は、戻しやすさで進め方を変える
技術の選択は、売上や処理時間のような事業の KPI への影響で決めます (要件からアーキテクチャを組む)。「新しいから」は理由になりません。
PoC は期間と成功の基準を先に決め、満たさなければやめます。選んだ案、選ばなかった案、理由をアーキテクチャ決定記録などに残すと、前提が変わったときにどの判断を見直すかが分かります。
カスタマーサクセスは、利用者が成果を出せたかで測る
納品したかではなく、利用者がそのシステムで目的を達成できたかを追います。相手は社外の顧客か社内の利用部門です。移した分析基盤が使われていなければ、使いにくい点を聞き、利用状況を測り、研修やダッシュボードで障壁を下げます。
自社が Google Cloud から受けるサポートもここに入ります。Customer Care には複数のプランがあり、上位の Premium Support では Technical Account Manager が付きます。止められないワークロードがあるなら、重大な障害への応答時間で選びます (Customer Care)。
CapEx から OpEx へ移ると、予測と管理の仕方が変わる
CapEx は設備を先にまとめて買い数年で償却する支出、OpEx は使った分を毎月払う支出です。オンプレミスは CapEx が中心で、クラウドの従量課金は OpEx です。需要を読み違えても設備が余らない代わりに、毎月の費用の予測と管理が要ります。CFO が予測しやすさを求めるなら、安定した分に確約利用割引を買い、予算とアラートを設定し、請求データを BigQuery に出して部門ごとに見せます (コストの最適化)。
会計上の分類は会社の方針で決まります。設備投資の予算が無く運用予算はあるなら従量課金のマネージドサービスで始め、既存ハードウェアの償却が 2 年残るなら、償却の終わりに合わせて段階的に移す案を検討します。
事業継続は、システムの DR より広い
業務ごとに止まってよい時間と失ってよいデータの量を事業側と決め、RTO と RPO として設計に落とします (可用性と災害復旧)。DR 環境を作っただけで一度も切り替えていないなら、計画的な切り替え訓練を行う答えを選びます。
場面で判断を確かめる
下の場面はこのカリキュラムで作った例です。行動を選ぶと、試験で正解とされるかどうかと理由が出ます。
次の章では、4 つのケーススタディを読み、これまでの知識をどの要件に使うかを対応付けます。