✍️ 共著 : Yuichiro Tada w/ Takumi Imafuku
前回の記事 → ゼロから始める SLO 設計 #1
再会の KPI
こんにちは、SRE の多田です。
「ゼロから始める SLO 設計」シリーズ第 2 回です。
前回では、SLO 設計に取りかかる前段として、構想フェーズで整理した論点や、全体の設計ステップを紹介しました。
今回はそこから一歩進んで、実働フェーズのスタートとして行ったキックオフ、ユーザージャーニーの洗い出し、そして最も重要な体験──CUJ（クリティカル・ユーザージャーニー）を選び取るまでの流れと考えたことを綴っていきます。
実働フェーズに踏み出すにあたって、最初に私たちが取り組んだのは「キックオフ」の実施です。
SLO という考え方がチームにとって初めてのものである以上、その土台づくりから丁寧に進めることが必要だと感じたからです。
キックオフから始めた理由
SLO 設計は、単なる数値の設定作業ではありません。
それは、プロダクトに「信頼性の判断軸」を持ち込み、チームの意思決定の前提をひとつ変える行為です。だからこそ、まずはその文化の前提となる問い
「なぜ SLO を設計するのか」
「どのように進めていくのか」
「誰がどう関わるのか」
を、チーム全体で共有するところから始めるべきだと考えました。
また、関係者の多くが SLO の文脈に不慣れであることを踏まえ、「概要」「役割分担」「設計ステップ」といった基本的な構造を先に提示しておくことで、これから進む道筋をより具体的に思い描いてもらいやすくなります。たとえば、次のステップである「ユーザージャーニーの洗い出し」も、それが CUJ 選定という次のステップにつながっていくと分かっていれば、見えてくる背景も変わってきます。
さらにこのキックオフは、今後の進行にあたって、どの程度の工数をチーム内で割けそうかという感触を掴みたいという意図もありました。開発を優先しながら SLO を進めていくには、現実的なリズム感とリソース把握が不可欠です。今回のキックオフは、その感覚を掴む場としても機能していました。単なる導入説明にとどまらず、以降の進行の土台を築く役割を果たしていたと感じます。
キックオフで共有する観点
キックオフには、SRE、プロダクトのエンジニア、企画担当者など、各立場の関係者が揃って参加しました。
準備の段階では、次のような観点を整理し、共有しました。
- SLO 導入の背景と目的
なぜ今 SLO なのか。KPI との関係や、SLO で可視化したい領域を明確化。 - SLO とは何か（KPI との違いを含めて）
抽象的な概念ではなく、信頼性の判断軸としてどう機能するかを説明。 - 今後の設計ステップと進行の流れ
ユーザージャーニーの洗い出しから SLO 運用までのステップと、それぞれの意味づけを明示。 - 各ステップにおける関係者（SRE、PO、エンジニアなど）の役割
どこに誰が関与し、何をアウトプットとするか。早い段階でのすり合わせを目的に。 - 現時点でのドキュメントや既存資産の確認
ユースケース、アーキテクチャー図など既存資料の棚卸しと、再利用の可能性の把握。 - 次のアクション（ユーザージャーニー洗い出し）の頭出し
このキックオフ後、何をすればよいのかを明確にし、迷いなく動ける状態を意識。
特に「SLO とは何か」という点については、今後の設計のベースとなるため、初期段階での理解を重視しました。
SLO を一言で説明するなら、「サービスの安定性や信頼性を定義し、可視化し、維持するための指標」です。
一方、KPI はビジネス上の成果や行動指標を意味します。たとえばユーザーのアクティブ率や施策の成果など──こうした KPI を達成するには、そもそもサービスが安定して動いていることが前提になります。
もしその前提が崩れていれば、どれだけ施策を回しても成果にはつながりにくくなってしまう。
だからこそ、SLO は KPI を支える「地盤」のようなものだと考えています。
まずは地図を描くところから
SLO を定めるには、まず「どの体験を守るのか」を決める必要があります。
つまり、SLO の対象となる CUJ を選ぶところから始まりますが、この工程は SLO 設計における最初の山場となります。
私たちのチームでは、まず一番大事な CUJ をひとつ選び、その設計から運用までをやり切ってみることを最初のゴールに設定しました。
複数の CUJ を同時に進める選択肢もありましたが、SLO 導入が初めての状況では、学びや改善のサイクルを早く回すことが重要だと思います。
ひとつに絞ることで、設計や運用の実感が得やすくなり、SLO に求められる観点や感覚を段階的に育てていけると考えました。
実際、導入初期のチームにとっては、「何を、どこまで、いつまでにやるか」を決めるだけでも難しいことがあります。
スケジュールを引こうとしても、どうしても見積もりの精度は荒くなりがちです。
とはいえ、進行を完全に流れ任せにしてしまうと、開発を優先する判断が自然と強くなり、SLO 設計が後回しにされてしまうおそれがあります。結果として、スケジュールが後ろ倒しになるリスクも無視できません。
そこで今回は、最重要な CUJ ひとつに絞ったうえで、「いつまでに、どこまで進めるか」の大日程だけは先に引いておくことにしました。
SRE として複数のプロダクトに関わっている立場でもあったため、全体の流れや優先度を把握しておきたいという実務的な背景もありました。
最も重要な体験を軸にして信頼性設計を始める方針を固めた私たちは、まず「どこに向かって進むのか」を定める──いわば地図を描くところから、スタートしました。
ユーザージャーニーを選ぶまで
SLO を設計するうえで、CUJ の選定はとても重要なステップです。
その準備として、まずはプロダクトにおける「ユーザージャーニー」の洗い出しから着手します。
ユーザージャーニーとは、ユーザーがプロダクトを通じて目的を達成するまでの一連の行動や体験の流れを、時間軸や文脈を含めて俯瞰的に記述するものです。
利用の導線全体を横断的に捉えることで、どの体験が特に重要であるか（CUJ）を見極める手がかりになります。
このとき一度立ち止まり、「既存のドキュメントで代用できないか？」という可能性も検討してみました。
プロダクト開発の過程では、ユースケースやユーザーストーリーといったドキュメントが整備されていることもあります。
ユースケースは、ユーザーとシステムの間でどのようなインタラクションが起こるかを、機能単位で記述したものです。
一方、ユーザーストーリーは、「誰が、何を、なぜ」行いたいのかを簡潔に記述する形式で、主にアジャイル開発の文脈で利用されます。
いずれもユーザーの行動や意図を捉える点で有効です。
そのため、あらためてユーザージャーニーを起票しなくても済むのでは──そう考える余地もありそうです。
ただ、それぞれが個別の機能や価値にフォーカスしており、ユーザー体験の全体像や文脈を横断的に表すには不十分な場合があります。
SLO 設計においては、ユーザーがどのような目的でプロダクトを利用し、どのように一連の流れをたどっているのかを俯瞰する視点が欠かせません。
この観点から見ると、たとえユースケース等が存在していたとしても、CUJ 選定の判断軸として使うには不十分だと考えられます。
結果、私たちは一からユーザージャーニーを起票することを選びました。
なおここで注意したいのは、ユースケース自体が不要だというわけではありません。あくまで CUJ を選定するうえでは、体験全体を俯瞰するユーザージャーニーの視点が先に必要だったという意味です。
後続フェーズでは、このユーザージャーニーをもとにユースケースを起票し、SLI 設計へとつなげていきます。
ユーザージャーニーに記述すべきこと
ユーザージャーニーの一覧を洗い出す──といっても、単に「思いついた体験を列挙する」だけでは、その後の設計には活かしづらいと考えられます。
私たちは、次の CUJ 選定、さらにはユースケース起票や SLI 定義といった後続ステップを見据えて、ユーザージャーニーを “どのように書くか” のフォーマットそのものを設計することから始めました。
「起票のしやすさ」と「比較のしやすさ」の両立を意識し、粒度と構造をあらかじめ揃えることを重視しました。
実際に用意したのは、以下のような項目です。
- 名称：体験を一言で表すタイトル
- ペルソナ：想定するユーザー像や立場
- 想定シナリオ：体験がどのようなシナリオで利用されるのか
- 利用頻度：どれくらいの頻度で発生する体験か
- ステップ：ユーザーがたどる一連の行動や操作の流れ
- リスク：失敗した場合にユーザー体験や事業価値へ与える影響
- ビジネスインパクト：売上、KPI、戦略目標にどれだけ貢献するか
- ユーザー価値：ユーザーに与えるメリット
これらの観点は、「プロダクトが提供している体験をどう構造的に捉えるか」を意識したものであり、この後 CUJ としてどれを選ぶかを議論するうえで、必要な判断軸にもなるものです。
整備した内容をもとに、ユーザージャーニーの記述はプロダクトオーナー（PO）が担当しました。
チームの中でもっともユーザー理解に近く、日頃から施策や数値とも向き合っている存在であるため、記述の一貫性や納得感も得やすくなると判断しました。
一方で、SRE としてはこの記述が「後でユースケースや SLI にどう繋がるか」を意識してレビューし、観点の抜けや構造の粗さを補うような対話も行いました。
さらに今回は、「最重要な CUJ をひとつ選ぶ」というゴールを先に定めていたため、ユーザージャーニーの起票も “網羅” を目指すのではなく、“重要そうなものに絞って” 行いました。
起票を PO が担うことで、実際に記述する前の段階から、自然と重要度のフィルターが適切に効きます。そのためこの範囲だけでも、十分な密度と粒度のジャーニーを得られると判断し、設計プロセスをスムーズに進めることを優先しました。
対象を広げる必要が出てきたときには、そのタイミングで追って整備すればよいと考えています。
ユーザージャーニーの記述は、単なるドキュメント整備ではなく、「何をどう捉え、どう守るか」を定義するうえで、私たちにとって最初の設計フェーズだったと捉えています。
ユーザージャーニーから CUJ ──いよいよ選定へ
一覧として揃ったユーザージャーニーを前に、次に向き合ったのは「どの体験を、もっとも守るべき “クリティカル・ユーザージャーニー（CUJ）” とするか」という問いでした。
SLO 設計において、すべての体験を均等に守ることは現実的ではありません。
だからこそ、「この体験だけは絶対に損なってはいけない」と言えるものを選び取る必要があります。
選定においては、まず「ビジネス上、最も重要な体験はどれか？」という観点を出発点とします。
そのうえで、それが信頼性の指標として “測れるかどうか”、あるいは他の体験と比べて “構造的に守りやすいか” といった観点も加え、最終的には総合的な判断をしていきます。
ここで注意したいのは、「測りやすさ」や「守りやすさ」といった観点を最初に持ち込んでしまうと、本来もっとも守るべき体験が候補から外れてしまうリスクがあるという点です。
計測しやすい体験のほうが選びやすく、結果的に「守りたい体験」ではなく「守れそうな体験」が選ばれてしまう──そんな逆転が起きかねません。
だからこそ、まずはプロダクトとして「何を守るべきか」を純粋に見定めたうえで、その実現可能性を後から検討するという、段階的な選定が不可欠だと考えています。
今回は、いくつかの CUJ 候補を比較するために、あらかじめ記述してもらった構造（目的・アウトカム・KPI 関連度など）が非常に役に立ちました。
定性的な議論になりすぎないよう、PO と共に以下のような判断軸を整理して合意形成を進めました。
- その体験がビジネスにおいて担っている役割
- 発生頻度やユーザー数の規模感
- 体験の途中で障害が起きた場合の影響度
- 既存の KPI との関連性・依存性
- SLI やメトリクスとして捉えられる構造を持っているかどうか
最終的に選ばれた CUJ は、すでにプロダクト内でも重要視されていたもののひとつでしたが、この議論を通じて「なぜそれが重要なのか」がチーム内でより言語化され、“守るべき価値” としての輪郭がより明確になったことは大きな意味があったと感じています。
また、今回選び取った CUJ は、今後のプロダクトの進化や KPI の変化に応じて見直される可能性もあります。
そのため、なぜこの体験がクリティカルだと判断されたのか、その選定理由や評価軸を記録として残しておくことにしました。
これは、将来的な CUJ の再検討や優先順位の見直しに備えるための布石でもあり、SLO を一過性の仕組みではなく “継続可能な設計” として育てていくための一歩だと考えています。
こうして、プロダクトにとって最も重要な体験──すなわち CUJ を選び取るところまで、私たちは歩みを進めました。
ですが、「守るべき体験」が定まったからといって、すぐに信頼性が測れるわけではありません。
次回は、CUJ を起点に、その体験を「どう分解し、どう測るか」に踏み込み、信頼性の輪郭をさらに描き出していきます。
次回の記事 → ゼロから始める SLO 設計 #3