# Squish Level Objectives: How SRE can Help Align Technical Work to User Benefit
Navigation: [[index]] | [[サービスレベル目標]] | [[SLI-SLO段階的導入]] | [[エラーバジェット]]
登壇者: [[Dave Stanke]](@davidstanke)
所属: [[Google]](Google Cloud Platform Developer Advocate)
イベント: SREcon20 Americas(バーチャル開催)/ 2020
動画: https://www.youtube.com/watch?v=WWXfYvZe1HE
---
## 概要
Google Cloud Platform Developer Advocate の Dave Stanke が、「スクイッシュ(squishy = ぐにゃぐにゃ)な人間」である顧客を中心に据えた SRE 実践を論じた SREcon20 Americas のトークである。「プラットフォームエンジニアは顧客接点がない」「プロダクトを作っていない」「フィーチャーを作っていない」という 3 つの神話を打ち破り、SRE 原則「信頼性は最も重要な機能」と「システム信頼性はユーザーが決める」を顧客視点へ拡張する。顧客理解の 3 手法(Talk・Be・Mess with them)と、SLO Policy に Rationale(ユーザー行動根拠)を付与する手法を実践的に示す。
## 主要メッセージ
- **神話 #1「私は顧客接点がない」**: プラットフォーム Ops・Platform Dev・App Ops・App Dev のすべてが、最終的には顧客へとつながる縦のスタックに組み込まれている(p.4)。
- **神話 #2「私はプロダクトを作っていない」**: 製品とは「誰かが他の選択肢の代わりに選ぶもの」。そしてあらゆる製品は——たとえ箱入り商品ですら——ユーザーの心の中にある認知的構築物である(p.5〜10)。
- **神話 #3「私はフィーチャーを作っていない」**: セキュリティ・テクデット解消・エンジニアの幸福まで、すべては顧客のためである(p.28〜35)。
- **SRE 原則 #1 **: 信頼性はあらゆるサービスの最重要フィーチャーである(p.11)。
- **SRE 原則 #2'**: 製品の品質をわれわれは決められない。顧客が決める(p.16)。
- **顧客理解の 3 手法**: Talk(定性 UXR、N>1)/ Be(ドッグフーディング、共感セッション、競合体験)/ Mess with them(エラーバジェットを使った UX 実験)(p.19〜27)。
- **Customer-oriented SLO + Rationale**: 設計フェーズにはペルソナ・JTBD・プロトタイピング、実装フェーズには顧客指向マイルストーン・CAB・信頼テスター、運用フェーズには Rationale 付き SLO Policy を置く(p.36〜41)。
## 視覚的に重要な図表
**p.4 組織スタック図(神話 #1 反論)**
![[_attachments/2020__SREcon20Americas__Squish-Level-Objectives/page-004.png]]
Platform Ops→Platform Dev→App Ops→App Dev という縦のスタックが、最終的に "YOUR CUSTOMER" へとつながることを矢印と "Hi!" で示す。技術組織のどの層も顧客の前に立っている。
**p.9 Product = 認知的構築物**
![[_attachments/2020__SREcon20Americas__Squish-Level-Objectives/page-009.png]]
箱に入っていない(クラウドサービスなどの)製品も、実体はユーザーの心の中にある。Colgate の例: 成分は違っても「コルゲートらしさ」という認知がブランドを成立させる。
**p.13 価値 × 時間グラフ**
![[_attachments/2020__SREcon20Americas__Squish-Level-Objectives/page-013.png]]
フィーチャーが生み出す perceived value(知覚価値)は time 軸との積として示される。フィーチャーを届けるとは「価値を時間軸に沿って積算する」こと——信頼性の低下はその積を削る。
**p.26 「すべては顧客のため」スター図**
![[_attachments/2020__SREcon20Americas__Squish-Level-Objectives/page-026.png]]
中央に ☺(顧客)、周囲に DEV・PLATFORM・PRODUCT・INFRA・OPS が配置された星形図。組織機能のどれもが顧客という中心を指向していることを視覚化する。
**p.37 SLO Policy with Rationale**
![[_attachments/2020__SREcon20Americas__Squish-Level-Objectives/page-037.png]]
```
SLO Policy Last updated: 2020-03-14
SLI Target
Page loads < 1500ms 99.95% (28 day window)
Rationale:
Error rates greater than .05% correlate
with significant increase in customer
support tickets
```
SLO Policy に "Rationale" フィールドを加え、技術閾値を顧客行動データ(サポートチケット増加率)で根拠づけた具体例。
**p.39 Recipe for success**
![[_attachments/2020__SREcon20Americas__Squish-Level-Objectives/page-039.png]]
- 顧客が価値を置くものによって製品を定義する → Research & Empathy
- その定義に従って一貫して提供する → SRE
## 口頭説明・補足
(YouTube 自動字幕より)
- **「Squish」の語源**: 「スクイッシュな人間(squishy humans)」——顧客は非合理で感情的でぐにゃぐにゃ(squishy)な存在。Squish-Level Objectives は、そのような人間の知覚に根差した SLO を意味する。
- **価値の積算を信頼性が守る**: 「信頼性が低いサービスはすぐに使われなくなる。どれほど大きな価値を持つフィーチャーでも、稼働していなければ価値は 0 になる」(トランスクリプト補足)。
- **エラーバジェットを UX 実験に使う**: 「レイテンシを 2 倍にしたらユーザーは本当に気にするか?やってみよう(Error Budget で実験する)」——SLO の Rationale を更新するためのデータ収集手段としてエラーバジェットを位置づける。
- **Colgate lifestyle**: 製品は「コルゲートのライフスタイル」のように——その製品を使う自分というアイデンティティを含む認知的構築物。
- **ペルソナをデスクに置く**: ユーザーペルソナを「トレーディングカード」として印刷してデスクに置く、という実践例。常に顧客像を手元に置く。
- **SPEC over the wall**: Product が Dev に SPEC を投げる形(Spec Over the Wall)は、CODE over the wall(Dev→Ops の片方向)と同型の問題。コードと顧客の間の壁を取り除くために顧客指向マイルストーン・CAB・信頼テスターが機能する。
- **SLO Rationale の決め方**: UX スタディ、関連文献調査、ユーザー行動シグナル(サポートチケット・CSAT・離脱率等)から相関を探す。
## Q&A
(トランスクリプト範囲に Q&A の明確な区切りなし。字幕終盤に "first steps" への言及あり)
> "1. Find your customer. 2. Learn what they value. 3. Write it down. 4. Deliver it."
## 概念・実体への接続
- [[サービスレベル目標]]: SLO Rationale としてユーザー行動データを使う実践例。Gangatirkar(2018)の S 字曲線「痛みのしきい値を特定する」の実装形式
- [[SLI-SLO段階的導入]]: SLO Policy に Rationale フィールドを持つことが成熟度「定義 Lv4」への具体的ステップ
- [[エラーバジェット]]: UX 実験のバジェットとして使う拡張用途
- [[Dave Stanke]]: 登壇者(Google Cloud Platform Developer Advocate)
- [[Google]]: 登壇者所属組織
## 限界・不確実点
- p.35 のペルソナカード("Happy Car..."、"The Pr... 21%")は解像度の制約で部分的にしか読めない。カード全体の内容は不明。
- `date_published` は SREcon20 Americas の開催期間(2020 年 12 月)の特定日まで追えていない(SLO Policy の "Last updated: 2020-03-14" は当日の日付ではなくスライド内例示文書の更新日)。
- YouTube 自動字幕(機械精度)を使用。固有名詞・技術用語の誤認識が一部ある可能性がある。
- SLO Rationale の "correlate with" が相関なのか因果関係なのかをスライドのみでは判定できない(口頭でおそらく補足されたが字幕では明示なし)。