✍️ 共著 : Yuichiro Tada w/ Takumi Imafuku
前回の記事 → ゼロから始める SLO 設計 #2
ゼロから始まる信頼性設計
こんにちは、SRE の多田です。
「ゼロから始める SLO 設計」シリーズ第 3 回です。
前回の記事では、プロダクトにとって重要な体験を言語化し、CUJ として選定するまでのプロセスを紹介しました。
どの体験に信頼性が求められるのか──その問いに向き合ったことで、ようやく「SLO を設計する」とは何かの輪郭が見え始めてきたように思います。
今回の記事では、その CUJ を出発点として、「体験のどこで信頼性が問われるのか？」をさらに深掘りしていきます。体験全体ではなく、具体的なアクションや期待にフォーカスし、それを “測ることができる形” へと近づけていくフェーズです。
このフェーズでも、ビジネス優先度とユーザー視点を欠かさず織り込むために、プロダクトオーナー（PO）と協力しながら進めていきます。
信頼性を定義する──言葉にすれば簡単に聞こえますが、いざ始めようとすると、
「何をもって “成功” とみなすのか？」
「測れることと、測るべきことの違いは？」
といった問いに、たびたび立ち止まることになります。
ここから、信頼性のかたちを少しずつ捉えていく旅が始まります。
最初に向き合ったのは、「この体験の中で、信頼性が問われるのはどこか？」という問いでした。
CUJ の構成要素に名を与える
「この体験の中で、信頼性が問われるのはどこか？」──前回整理した CUJ は、プロダクトにとって重要な体験の道筋を捉えるものですが、それだけでは SLO を定義するには粒度が大きすぎます。
たとえば EC サイトにおける「商品を購入する」という CUJ には、複数のアクションや内部処理が含まれます。このままでは「どこを守るべきか」「どこが壊れたらユーザーが困るのか」が曖昧なままです。
そこで、CUJ をさらに小さな単位──信頼性が問われる構成要素へと分解し、それらをユースケースとして整理していきます。
ユースケースの構成項目──信頼性を測るための構造化
単に「機能の一部」として記録するのではなく、信頼性設計の視点で意味のある構成要素を捉えるように記述していきます。
そうすることで、後続の SLI 設計フェーズにおいて「どの体験を、どのように測るか」を判断する強力な足がかりになります。特に成功や失敗時の影響は、「何が起きたら信頼が揺らぐのか」を言語化するために欠かせない視点です。
一般的なユースケースとの違い──設計粒度と目的の意識
ここで扱うユースケースは、いわゆる機能仕様におけるユースケース（例：「注文を確定する」「ログインする」など）よりも、やや細かく、定性的な構成を含むものです。
一般的なユースケースが、画面単位や処理単位といった業務フロー志向で記述されるのに対し、私たちは「信頼性が問われる瞬間」にフォーカスしています。ユーザーの期待が裏切られたときにビジネスや体験に影響が及ぶ単位で捉えることを意識しています。
たとえば、「商品を購入する」という EC サイトの体験で考えてみましょう。
機能観点でユースケースを分解すれば、
- 商品を検索する
- 商品詳細ページを表示する
- カートに追加する
- 注文に進む
- 決済情報を入力する
- 購入を確定する
といったように、「何をするか（Do）」という流れが整理されていきます。これが一般的なユースケースの粒度です。
しかし、ユーザー体験の信頼性という視点でこの流れを捉え直すと、
- 検索結果に期待していた商品が表示されるか
- 商品の説明や価格情報が正しく表示されているか
- カートに追加した商品がすぐに反映されるか
- 注文の最終確認で金額や内容が正確に表示されるか
- 決済完了後に確認メールがすぐ届くか
といったように、「期待が裏切られては困る瞬間（Trust）」に着目した分解になります。
一見すると同じフローを扱っているように見えても、着目点の違いによって見えてくるユースケースの粒度や意味は大きく異なります。
私たちが SLO を設計するうえで意図しているのは後者──「この信頼を測るにはどの瞬間に注目すべきか？」という視点で構成要素を切り出すことです。
この粒度は、「SLI にしやすい単位」ではなく、「守るべき体験を観測可能な粒度に近づける」ための設計です。
構成要素に “名を与える” ということ
CUJ を通じて見えてくる体験は、そのまま図解したり記号化するのが難しいものです。けれども、トリガー、成功条件、失敗時の影響……といった “構成要素の型” を与えることで、それぞれの期待や前提、リスクが具体的に言語化できるようになります。
名を与えるとは、輪郭を持たせるということ。信頼性を “測れるようにする” 最初の行為でもあるのです。
信頼性を測るということ
私たちはここまで、CUJ を起点に「信頼性が宿る構成要素」を分解し、それらをユースケースとして整理してきました。次のステップでは、それらユースケースに対して「何をどう測るべきか」、つまり SLI 設計へと進んでいきます。
その前に、ここで少し立ち止まって、「信頼性を測るということ」そのものについて考えてみたいと思います。
測れるから測る──SLO によくある出発点
SLO 設計の場面では、Datadog や Prometheus に既に存在しているメトリクスを起点に「これを SLO にしよう」と考えるケースが少なくありません。例えば、API の 5xx 割合や、ページ表示の p95 レイテンシなどは典型的です。
このアプローチは、即座に設計・導入できるという意味では非常に合理的です。多くの現場で SLO が「とにかく早く始めたい」「まず導入してみたい」ものとして扱われる中で、取れるメトリクスから逆算して SLI/SLO を定めるのは、ある意味 “現実的な解” と言えるでしょう。
ただ、それは信頼性の「観測」であって、「設計」ではない
こうした “測れるものからの逆算” は、観測可能性を前提とした「モニタリング設計」に近く、SRE の思想における「信頼性の設計」とは本質的には異なります。
このようなアプローチは、「とりあえず測れている状態」を作ることにはつながっても、「なぜその指標を守るのか？」という問いに答える設計思想には至りません。
既に存在するメトリクスから SLI を “観測する” ことはできても、どのような体験を信頼に値するものとして “設計する” かという出発点が抜け落ちてしまうのです。
つまり、SLO とは「取れる数値に意味を与える」ことではなく、「意味のある体験に数値で境界を与える」ことに本来の意義があります。
一般的な逆算型 SLO にありがちな落とし穴
しかし現実には、「既存のメトリクスでとりあえず始める」ことで満足してしまい、その SLO が本当にユーザーにとって意味があるのか、なぜ守るべきなのかといった問いが置き去りになるケースは少なくありません。
その結果、SLO が単なる “数字目標” になってしまい、
- 「数値は達成しているのに、ユーザーの不満は解消されない」
- 「どの指標が重要なのかチーム内で揉める」
- 「そもそもその SLO が何のためにあるのかよくわからない」
といった状態に陥りやすくなります。
こうした課題は、出発点として「体験」ではなく「観測可能性」を選んでしまったことに根があります。
本来の順序──体験 → 意図 → 測定
私たちが CUJ を丁寧に選定し、その体験を構成する要素へと分解していったのは、「何を守るべきか」の意味を言語化するためでした。
それは、「観測できるもの」ではなく、「観測すべきもの」を先に定めるという順番です。
つまり、信頼性を測るとは、単に数値を取ることではなく、「信頼されるとはどういう状態か」を先に定め、それに見合った形で観測・定量化することなのです。
手間がかかる、でも本質に近づく
CUJ を起点に、構成要素を見つけ、ユースケースを定義していく──
このプロセスはたしかに手間がかかります。SLO 設計に着手したつもりが、いつの間にかプロダクトの信頼性マッピングを始めているような気持ちになることもあるでしょう。
それでも、「信頼されるとはどういうことか」をあらかじめ定義しておくことは、これから進めていく SLI 定義や物理的な設計の場面で、ひとつの指針になってくれるはずです。
意味のある信頼性を先に定めておくことは、この先の設計ステップ、SLI 定義や可視化、SLO 設定を進める上で、私たちが常に原点に立ち返るための指針になります。
「この体験を守りたいから、こう測る」という順序が明確であることで、チーム内での議論や意思決定の軸もぶれにくくなります。
そして、プロダクトにとって本当に意味のある信頼性を、定義し、運用することが可能になります。
それは、単なる “導入しただけの SLO” ではありません。
時間が経っても手放されず、改善され、信頼され続ける──“プロダクトの一部としての SLO” に育っていくための、確かな土台になると私たちは信じています。
参考 : Google SRE Book
Google SRE – Defining slo: service level objective meaning
Start by thinking about (or finding out!) what your users care about, not what you can measure. Often, what your users care about is difficult or impossible to measure, so you’ll end up approximating users’ needs in some way. However, if you simply start with what’s easy to measure, you’ll end up with less useful SLOs. As a result, we’ve sometimes found that working from desired objectives backward to specific indicators works better than choosing indicators and then coming up with targets.
SLI 設計の第一歩
信頼性が求められる体験の構成要素を「ユースケース」として整理したことで、プロダクトにとって何が重要かがより立体的に見えるようになってきました。
ここからは、それらユースケースに対して「どのような観点で信頼性を測るべきか」を設計していく段階に入ります。
信頼性の観点を見極める
ユースケースはあくまで「信頼性が問われる瞬間」を捉えるための単位です。
そこから SLI を設計するには、「その瞬間に、どんな期待があるのか？」「何が損なわれたら信頼が揺らぐのか？」という問いに正面から向き合う必要があります。
たとえば、「注文の最終確認で金額や商品情報が正しく表示されるか」というユースケースがあるとします。
これは単なる「注文に進む」といった機能的な区切りではなく、「ユーザーが注文内容を確信できること」に対する期待が込められた、信頼性を軸に再定義された構成要素です。
このとき、信頼性が問われる観点は一つではありません。
- 注文内容が即座に表示されるか（レイテンシー）
- 商品名や金額が正しいか（正確性）
- ページが正しく表示されるか（可用性）
といったように、一つのユースケースから複数の SLI 候補が生まれることは少なくありません。
どの観点がどのような期待を担っているのか──それを丁寧に言語化することで、「守るべき信頼性」がようやく輪郭を持ち始めます。
このとき重要なのは、単にモニタリングしやすい技術的指標に寄るのではなく、「この瞬間に何が裏切られたらユーザーは困るのか？」という視点を貫くことです。
SLI の候補は、技術ではなく期待から始まるべきなのです。
SLI をどう記述するか
各ユースケースから抽出した SLI 候補に、以下のような内容を記述していきます。
- 名称
ビジネスや UX の観点から、その信頼性を示す識別名。設計全体での可読性と参照性を高めるために必須。 - 成功とみなす条件／失敗とみなす条件
ユーザー体験として何が「成功」か、どの状態が「失敗」とみなされるかを定義。品質期待値の明文化。 - 期待する可用性
正常に利用できる状態の割合に関する期待値。 - 期待するレイテンシー
操作やリクエストに対する応答速度への期待。 - 期待する正確性
出力や処理結果が意図通りであることの期待。 - 期待する適時性
処理や通知がタイムリーに行われることへの期待。
このように整理することで、測定値に意味を与えるのではなく、意味のある期待に数値で輪郭を与えるという設計思想を具現化しています。
なぜ複数観点で記述するのか
先ほどのように、「注文内容が即座に表示されるか」ことと「商品名や金額が正しいか」ことは、別々の SLI です。
これは、技術的な観測方法が異なるからというだけではありません。
- ユーザーがどこに不満を感じるか
- ビジネス上どの品質が求められるか
- それぞれにどの程度の影響があるか
といった、視点ごとの期待やリスクが異なるからです。
そこで私たちは、各 SLI にそのような補足情報があれば追記しています。
これらは前章のユースケースにも一部含まれていますが、ユースケース内の複数の SLI に差があるため、SLI ごとに個別に記述するようにしています。
補足情報をなぜ付けるのか
こうした補足情報をあらかじめ記述しておくことには、次のような意味があります。
- SLI を俯瞰したときに「どれがより守るべきか」の判断軸になる
- 技術的に実現困難な SLI が出た場合、優先順位を見直す材料になる
- SLO 合意の際、ビジネスとユーザーの両観点から議論できる
つまり、将来的な絞り込みや物理設計を見据えて、いま “意味” を言語化しておくということです。
“測れる” を前提にしない
ここで重要なのは、「この SLI は観測できそうか？」という視点を、今の段階ではあえて持たないことです。
あくまでこの章は、論理的に「測るべきものは何か？」を定めるフェーズであり、技術的な制約やコスト感で候補を捨てる場ではありません。
- 測れないなら意味がない？
- メトリクスが取れないと無価値？
──そうではありません。
信頼性は、まず「守りたい期待」を定義することから始まります。
それが観測可能かどうかを判断するのは、次のフェーズです。
信頼性のかたちを捉えるために
ここまで、ユースケースごとに「どのような観点で信頼性を測るべきか」を考え、論理的な SLI 候補を起票してきました。
ただし、それらすべてを計測・監視しきれるわけではありません。次のフェーズである物理設計に進むには、どの SLI を優先的に現実に落とし込むか、あるいは どの SLI は見送るか といった判断が必要になります。
この章では、そうした「絞り込み」のための前提を整理していきます。
なぜすべては測れないのか
起票された論理 SLI は、信頼性を構成する「あるべき姿」を表しています。
しかし、現実のシステムには以下のような制約があります。
- 対象となる内部処理が観測できない
- リアルタイムな取得に高いコストがかかる
- 正確性や適時性といった指標が主観的で測定が難しい
このような状況で「すべて測る」ことを目指すのは、運用や設計の複雑性を高めるばかりでなく、かえって信頼性の実態を見えにくくしてしまうリスクがあります。
だからこそ、何をまず守るべきか、どこから着手すべきかを選び取ることが求められます。
重要度を見極める
私たちは各論理 SLI に対して、補足情報を付与しています。
それらの情報は、物理設計フェーズでの判断に直結します。
たとえば、
- 影響度が高く頻度も多い SLI → 最優先で設計対象に
- 頻度は低いが代替手段がない → 守る価値が高い可能性あり
- 技術的に観測困難で影響も限定的 → 見送り候補
といった具合に、観測可能性よりも先に “守る価値” を評価しておくことが、健全な絞り込みに繋がります。
「設計できる信頼性」を選び取るということ
ここで行っているのは、「測れる SLI を選ぶ」のではなく、「守るべき SLI を、測れる形にするにはどうするか」という問いへの下準備です。
すぐに実装できるかどうかは、物理設計フェーズの中で再度向き合うことになります。
いま大切なのは、起票した論理 SLI 群を構造的に捉え、どこから信頼性の設計を進めるか、その起点を見極めることです。
意味のある信頼性を守るために
ここまでの設計プロセスを通じて、私たちは「測れるもの」ではなく「守るべきもの」から出発することを徹底してきました。
その過程で見えてきたのは、信頼性とは単なる数値のことではなく、ユーザーとの約束であり、プロダクトが大切にしたい体験そのものだということです。
起票された論理 SLI は、まだ「かたち」になる前の信頼性の原石です。
それらをどのように観測し、どのように運用していくか──
次回は、これらの信頼性を現実のシステムに落とし込んでいくフェーズに入ります。