アイレット株式会社 Advent Calendar 2025

アイレット株式会社

【Google Cloud入門】サービスの定義

Last updated at 2025-12-21Posted at 2025-12-21

皆様、こんにちは！
アイレット株式会社 DX開発事業部の楊林と申します。

前回の投稿では、Google Cloud における DevOps の自動化について整理しました。

今回は、Google Cloud でサービスを定義する際によく用いられるいくつかの方法と、重要な指標について整理していきます。

要件分析と設計

4W1H

Google Cloud のサービスを定義する際には、まず 4W1H を用いて要件を分析することがおすすめです。
4W1H とは、以下 5 つの英語の疑問詞の頭文字を取ったものです。

Who：システムのユーザーだけでなく、開発者や関係者（ステークホルダー）も含めて決定します。システムが直接的・間接的に影響を及ぼす人の全体像を描くことが目的です。
What：必須となる機能の主な領域（スコープ）を明確に定義します。
Why：なぜそのシステムが必要なのか、提案されたシステムでどのような問題を解決しようとしているのかを明確にします。ニーズが不明確なままだと、「余分な」要件が追加される可能性があります。KPI、SLO、SLA を定義する際にも役立ちます。
When：現実的なタイムラインの策定や、その範囲を限定する際に役立ちます。
How：機能以外の多くの要件（非機能要件）を決定する際に役立ちます。以下のような項目が含まれます。
- システムが同時にサポートすべきユーザー数
- サービスリクエストにおけるペイロードの平均サイズ
- レイテンシー要件の有無

ユーザーロール

ロールでは、システムを使用する際のユーザーの目標を説明します。ロールを用いることで、特定のコンテキストにおいて要件を分析できます。

重要なのは、ロールは必ずしも「人」である必要はないという点です。システム上のアクターであり、別のマイクロサービスにアクセスするマイクロサービスクライアントなど、他のシステムである場合もあります。

ペルソナ

ペルソナとは、ユーザーロールを具体化した仮想的な人物像です。ペルソナの目的は、ユーザーをパーソナライズすることで、アーキテクトや開発者がユーザーの特性をより具体的にイメージしやすくすることにあります。

多くの場合、1 つのロールに対して複数のペルソナを設定します。ペルソナを用いることで、より深い洞察を得ることができます。

ユーザーストーリー

ユーザーストーリーでは、ユーザーがシステムにしてほしいことを 1 つずつ説明します。通常は、以下のような定型フォーマットを用いて記述します。

[ユーザーのタイプ]として、[何らかの利点を得る]ことができるように、[何か]をしたい
[特定のコンテキスト]で、私が[何かをする]と、[こうなるはず]です

ストーリーを書く際には、まず各ストーリーにその目的を表すタイトルを付けます。その後、上記の形式のいずれかに従って、ストーリーを 1 文で簡潔に記述します。これらのフォーマットでは、ユーザーロール、ユーザーがやりたいこと、その理由が明確になります。

ユーザーストーリーを評価するためには、INVEST 基準を利用できます。INVEST は以下の単語の頭文字を取ったものです。

Independent（独立）：優先順位付けやプランニングの問題を防ぐため、ストーリーは互いに独立している必要があります。
Negotiable（交渉可能）：ストーリーは契約書ではなく、顧客と開発者の議論を促進し、合意形成を支援するためのものです。
Valuable（価値あるもの）：何を作るかではなく、どのような成果や影響をもたらすかに着目します。
Estimatable（見積もり可能）：見積もれない場合、多くは情報不足か、ストーリーが大きすぎます。
Small（簡潔）：スコープを小さく保つことで曖昧さを減らし、迅速なフィードバックを得やすくなります。
Testable（テスト可能）：要件が満たされているか、ストーリーが完了したかを検証できる必要があります。

KPI

KPI は成果を測定するためによく使用され、ビジネス KPI とテクニカル KPI に分類できます。

ビジネス KPI は、プロジェクトやサービスのビジネスバリュー（ROI や税引前利益など）を測定するフォーマルな指標です。そのほか、顧客離れといったユーザーへの影響や、従業員離職率なども含まれます。

テクニカル KPI（またはソフトウェア KPI）は、システムの効果を測定するための指標であり、ページビュー、ユーザー登録数、チェックアウト数などが該当します。

KPI はビジネス目標と密接に整合している必要があります。アーキテクトにとって重要なのは、設計するシステムの成果がどのように測定されるのかを理解することです。

KPI は目標や目的そのものではありません。目標とは達成したい成果や結果であり、KPI はその目標に向かって順調に進んでいるかを示す指標です。KPI の効果を高めるには、それに対応する明確な目標が必要です。

KPI は SMART である必要があります。SMART は以下の単語の頭文字を取ったものです。

Specific：具体的
Measurable：測定可能
Achievable：達成可能
Relevant：関連性がある
Time-bound：期限が明確

サービスレベル

顧客に一定レベルのサービスを提供するためには、サービスレベル指標（SLI）、サービスレベル目標（SLO）、サービスレベル契約（SLA）を定義することが重要です。これらはそれぞれ、測定する指標、目標値、達成できなかった場合の対応を定義するものです。

SLI

サービスレベル指標（SLI）は、提供するサービスレベルのある側面を定量的に測定する指標です。スループット、レイテンシー、エラー率などが該当します。

SLI は、明確な測定期間を持ち、定量的に測定可能である必要があります。

SLO

サービスレベル目標（SLO）は、SLI によって測定されるサービスレベルの目標値、または許容される範囲について合意したものです。通常は「SLI ≤ 目標値」や「下限 ≤ SLI ≤ 上限」といった形式で表現されます。

SLO では妥当性（Achievable）が極めて重要です。ユーザーエクスペリエンスの改善につながる目標である必要があり、測定しやすさだけを理由に定義すべきではありません。SLO を明確にするためには、測定方法と有効となる条件をあらかじめ定義しておく必要があります。

SLO の選択は、プロダクトとビジネスの両方に影響を与えます。目的はユーザー満足度を維持することであり、過度な努力を前提とした SLO を設定することではありません。

SLO 選択時には、以下の点に注意すべきです。

高すぎない：達成が困難で高コストな SLO を最初から設定するのではなく、システムへの理解が進むにつれて徐々に厳しくしていく方が効果的です。
シンプル：SLI を複雑にしすぎると、重要な変化が把握しづらくなります。
絶対値を避ける：100% の可用性を SLO とするのは非現実的であり、運用コストが過剰になります。
SLO の数を最小限にする：主要な特性をカバーできていれば十分です。

ユーザーの関心が反映された SLO が、適切な SLO です。SLO は開発チームにとっての原動力となりますが、厳しすぎると無駄な作業が増え、緩すぎると品質の低いプロダクトにつながります。

SLA

サービスレベル契約（SLA）は、サービスプロバイダと利用者の間で結ばれるビジネス契約です。サービス提供に対する責任と、その責任が果たされなかった場合の対応を定義します。

SLA は、SLO をより厳格にしたものと考えられます。プロバイダは SLA を満たすための余力を考慮してシステムを設計し、合意された SLO を維持する必要があります。

合意したレベルを維持できなかった場合には、ペナルティが発生することがあります。

すべてのサービスに SLA が存在するわけではありませんが、SLO は定義する必要があります。

SLA についても、SLO と同様に保守的であることが重要です。SLA は変更や削除が難しく、顧客への補償が発生することで財務的な影響を受ける可能性があります。内容が過度に厳しいと、不必要な補償を支払うことになりかねません。

そのため、SLA のしきい値は SLO より低く設定するのが一般的です。SLO を超過しても、直ちに SLA 違反とならないよう、一定のバッファを持たせることが重要です。この SLO と SLA の間の関係性は、実運用において不可欠です。

最後に

今回は、Google Cloud でサービスを定義する際によく使われる方法と重要な指標について整理しました。

次回は、Google Cloud におけるマイクロサービスの設計方法とアーキテクチャについてまとめていく予定です。
引き続き読んでいただけると嬉しいです。

以前の投稿

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up