# SLI-SLO 段階的導入 ## 定義 SLI/SLO の段階的導入とは、SLI/SLO を最初から完璧な形で組み込もうとせず、小さな価値検証から始めてフィードバックループを回しながら組織全体へ広げていくアプローチである。SLI/SLO には定義・運用・定着の 3 つの固有の難点があり、一気に完成形を目指すと合意形成や計装に多大な時間がかかり形骸化しやすい。SRE 自体の段階的導入フレームワーク（小さく始める→チームを支援する→スケールする→データドリブン思考を具体化する）を援用することで、この障壁を下げられる (Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]])。 ### 3 つの難点 | 難点 | 理想 | 現実 | |---|---|---| | 定義 | 最適な SLI/SLO がサクッと決まる | CUJ〜SLO までの合意形成・追加計装に時間がかかりすぎる | | 運用 | 健全な SLI/SLO が維持される | メンテ時間の除外されない・新機能が考慮されない・見直しが行われない | | 定着 | SLI/SLO をもとに意思決定が行われる | SRE チームしか興味がない・SLI/SLO 会議がやや気まずい | (Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]] p.17) ### 段階的導入の 4 ステップ Takamura が提案する「段階的な SLI/SLO 導入（改）」のフレームワーク: 1. **特定のチーム内で価値検証を行う**: 自チームのみで達成可能な課題に取り組み、小さな成果を積み重ねる 2. **SLO 違反時に行う小さなアクションを定める**: 極端なアクション（開発停止等）ではなく最小限のアクションから始める 3. **ユーザー満足度に関わる指標の一部を SLI/SLO に反映し、運用する**: 必要に応じて SLO ドキュメント・エラーバジェットポリシーを作成 4. **ユーザー満足度に関わるすべての指標を特定し、SLI/SLO に反映し、運用する** (Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]] p.25) ### SLO 違反ポリシーの 5 段階拡大 | レベル | アクション | |---|---| | Level1 | なにもしない（様子を見る） | | Level2 | SRE チームが原因を特定と対策を行う | | Level3 | SRE チームが原因を特定し、開発チームが対策を行う | | Level4 | 各チームに SLO 正常化の責任（原因特定〜対策やしきい値検討）を移譲する | | Level5 | 上記に加え、イテレーションあたりの開発スケジュールやリリースタイミングの意思決定に SLO を組み込む | (Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]] p.36) ### SLI-SLO 成熟度モデル（3 軸 × 5 段階） SLI/SLO の状態を「定義」「運用」「定着」の 3 軸で評価し、各軸を 5 段階に分類する。現在地と目標についてのディスカッションの起点として機能する。 **定義を育てる**: | レベル | 状態 | |---|---| | Lv1 | SLI/SLO が存在しない、または担当者の経験則で定義されている | | Lv2 | 可用性などの代表的な SLI を用いて各サービスで SLI/SLO を定義できる | | Lv3 | SLI/SLO の設計プロセスが標準化され、SLO Document などで管理されている | | Lv4 | CUJ や顧客満足度との関係が測定され、SLI/SLO の妥当性を定量的に評価できる | | Lv5 | 事業目標やユーザー行動の変化に応じて SLI/SLO を継続的に改善している | **運用を育てる**: | レベル | 状態 | |---|---| | Lv1 | SLI/SLO は存在するが活用されていない | | Lv2 | 定期的な SLO レビューや振り返りが特定の担当者によって実施されている | | Lv3 | Error Budget Policy やレビュー手順が文書化され、チームで運用されている | | Lv4 | Error Budget 消費率や SLO 達成率などを継続的に計測し、改善活動へ反映している | | Lv5 | 運用結果をもとにポリシーや運用フローを継続的に改善している | **定着を育てる**: | レベル | 状態 | |---|---| | Lv1 | SRE チームのみが SLI/SLO を利用している | | Lv2 | 一部の開発チームが SLI/SLO を参照し改善活動へ参加している | | Lv3 | SLI/SLO の活用方法が組織標準となり、複数チームで利用されている | | Lv4 | リリース判断や改善優先度の決定に SLI/SLO が利用されている | | Lv5 | 信頼性が組織の共通言語となり、事業・開発・運用の意思決定に組み込まれている | (Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]] p.44-46) ### SLO Document チームを巻き込む際に有効な文書化手段。以下の項目を含む: - サービスの名前・SLO の定義 - サービスの概要 - SLI/SLO - 見直しのスケジュール - エラーバジェットポリシー 参考: O'Reilly「SLO サービスレベル目標」、[[SRE Workbook]] Appendix A。(Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]] p.39) ## 横断的知見 - **SRE Workbook の導入事例（Evernote・The Home Depot）も段階的・外部化アプローチを採用している**: SLO Engineering Case Studies は、顧客信頼性エンジニアリング（CRE）を通じた外部組織への SLO 導入で、最初から完全な実装を求めず、運用チームと開発チームが SLO をもとに対話する土台を先に作ることを重視した。Takamura の「特定チームで価値検証してからスケール」という戦略と同じ方向性を持つ (Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]], [[@2018__Google SRE Workbook__SLO Engineering Case Studies]])。 - **新規サービスへの SLO 導入では「実績がない」問題をプローバーで解決できる**: Lawson の COS 事例では、まだユーザートラフィックが少ない新規サービスに対して 4 週間プローバーを稼働させて SLI データを収集し、それを初期 SLO の推定に使った。Takamura の「最初のステップは代表的な SLI を仮決めすること」と対応しており、仮決め SLI の実績を短期間集中収集してから SLO を公開する流れが確認できる。(Source: [[@2019__SREcon19Americas__Case Study - Implementing SLOs for a New Service]], [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]]) - **SLO 公開ドキュメントは利用者がサービス適合性を自己判断するためのもの**: Lawson は SLO 公開の効果として「ユーザーが SLO を見て自サービスへの適合性を自己判断できる」を挙げた。これは Takamura の「SLO 文書化→チームを巻き込む」のステップと同じ方向だが、対象が内部開発チームではなくサービスの外部利用者（内部 API ユーザーやバックアップ担当チーム）である点が異なる。インフラ型サービスへの SLO 展開では、内部ステークホルダーと外部（内部）ユーザーを同時に対象にする必要がある。(Source: [[@2019__SREcon19Americas__Case Study - Implementing SLOs for a New Service]], [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]]) - **データ集約型サービスでは「ステークホルダーが無関心」という問題が SLO の次元不足から生じる**: Booking.com の検索サービスでは、可用性・レイテンシ SLO を最初に設定したが開発・ビジネスステークホルダーは無関心だった。検索サービスのステークホルダーが気にしていたのはデータの一貫性・新鮮性という「データ品質」であり、SLO の対象次元がユーザー（ステークホルダー）の関心と合っていなかった。段階的導入の文脈では「ステークホルダーが価値を見出す次元を先に特定する」ことの重要性を示している (Source: [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]])。 - **グッドハートの法則への対処として「3 次元 SLI/SLO/SLA」フレームワークが有効**: Coulter（2020）は、単一次元の技術指標 SLO が「棍棒（cudgel）」になると、チームはシステムを改善せず指標を操作するようになると論じた（例：キュー深度 SLO に対してメッセージ削除でゲームする）。対処として Code（トランザクション成功率）・Infrastructure（パフォーマンスカーブ SLO）・Business & CX（行動ベース SLI）の 3 次元で SLI/SLO/SLA を評価することで、単一次元のゲーミングを別次元が露出できるようにする。段階的導入の観点では、最初に Code 次元（技術指標）から始め、CX 次元（ユーザー行動）を後から加えることで「定着 Lv4（リリース判断への組み込み）」へ進みやすくなる可能性がある (Source: [[@2020__SREcon20Americas__Avoiding Goodhart's Law]])。 - **SLO 交渉を反復的プロセスとして制度化することが「定着 Lv5」への橋渡しになる**: Coulter（2020）の「Prepare to Engage → Warmup → Test Drive → Assess → Propose → [RECUR] → Agree」フローは、SLO を一回合意して終わりにせず RECUR（繰り返し再交渉）する設計である。Takamura の 5 段階ポリシー拡大と対応しており、Level2 から Level5 へ移行するにつれて SLO の交渉相手が「SRE チーム内」から「開発チーム」「事業意思決定者」へ広がる。Coulter の交渉フレームをポリシーレベルの移行と組み合わせると、どの段階でどのステークホルダーと交渉するかのロードマップが描ける (Source: [[@2020__SREcon20Americas__Avoiding Goodhart's Law]], [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]])。 - **非技術ステークホルダーへの「暗順応期間」の必要性は導入戦略に影響する**: [[サービスレベル目標]] の横断的知見で記録されているように（Smith SREcon22）、営業チームなど非技術部門は「可用性 = 稼働率」から「良い体験の割合」への認知転換に時間を要する。Takamura の「SLO の認知と価値が伝わるにつれてアクション範囲を広げる」5 段階ポリシーは、この暗順応問題への実践的な対処法として読める (Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]])。 - **SLO Policy の Rationale フィールドが定義成熟度「Lv3→Lv4」の具体的差分になる**: Stanke（2020）の SLO Policy は "Error rates greater than .05% correlate with significant increase in customer support tickets" という Rationale フィールドを含み、技術閾値とビジネス指標の対応関係を SLO ドキュメント内に文書化する。Takamura の成熟度モデル「定義 Lv4: CUJ や顧客満足度との関係が測定され、SLI/SLO の妥当性を定量的に評価できる」を SLO ドキュメントの 1 フィールドとして実装した形式と読める。Rationale フィールドを SLO Document の必須項目として位置づけると、Lv3（標準化・文書管理）→Lv4 の差分が「ユーザー行動シグナルと SLO 閾値の相関を定量的に示す記述を持つか否か」になる (Source: [[@2020__SREcon20Americas__Squish Level Objectives]], [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]])。 - **SLO の分割軸を「サービス単位」→「API × リージョン」→「顧客（プロジェクト）単位」へ進化させることが大規模 IaaS での定着 Lv5 への道**: [[Alex Palcuie]]（SREcon22 EMEA）の GCE 事例は、30 SLO（リージョン × 3 指標）→ 約 1,000 SLO（API メソッド × リージョン × 3 指標）→ 3,000 万 SLO（さらに顧客単位）という 3 段階の進化を 6 年間で実践した最大級の本番事例である。Takamura の成熟度モデルの「定着 Lv5: 信頼性が組織の共通言語となり事業・開発・運用の意思決定に組み込まれている」は組織内部の話だが、Palcuie の per-customer SLO は「外部顧客にも自分の SLO 逸脱を可視化する」という定着の外向き拡張として読める。SLO 数の増加は「何次元で切るか」という設計判断の変遷であり、大規模マルチテナント IaaS での次の自然なステップが顧客単位の粒度であることを示す (Source: [[@2022__SREcon22EMEA__Going-from-30-to-30-Million-SLOs]], [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]])。 - **SLO 導入の失敗律速は「技術」より「組織・人・プロセス」（socio 側）であることが実務で繰り返し確認されている**: [[Rob Durst]]（Spring Health、SREcon25 EMEA）は 4 度の試みを通じて、オブザーバビリティ基盤が整っていても所有権・標準プロセス・保護時間が揃わなければ SLO 導入は頓挫することを示した。Takamura の「SLO 採用は社会技術的問題」という主張を、実際の失敗系列（担当者交代による TAG IN、空白テーブル、STOP）で補強する証拠となる (Source: [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]])。 - **「SLO 準備度チェックリスト」は段階的導入の前提条件診断ツールとして機能する**: Durst の 4 条件（オブザーバビリティ基盤・ノミナル所有権・標準プロセス・保護時間）は、Takamura の「4 ステップフレームワーク」や SRE Workbook の「SLO 文書化」より前の*前提条件*を整理したものである。「条件が揃わないうちに SLO を定義しようとする」ことが失敗パターンであり、段階的導入の第 0 ステップとして準備度診断を行うべきという主張として読める (Source: [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]])。 - **担当者交代（TAG IN）問題は所有権の曖昧さの症状であり、Attempt #2 の失敗（異なる SLI 定義の非互換）は標準プロセス欠如の症状である**: 段階的導入の文脈では、「SLO を書いた人が変わっても同じフォーマットで続けられる」という標準化レベルに達するまでは、どれだけ良い SLO を定義しても持続しない。Takamura の成熟度モデルの「定着 Lv3（標準化・文書管理）」到達がこれに対応する (Source: [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]], [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]])。 - **エラーバジェット起点のコードフリーズが「承認」まで到達した事実は、SLO が組織意思決定に組み込まれた（定着 Lv5）証拠として読める**: Durst が RFC: Error Budget Based Code Freeze（Holidays '25）を経営承認まで通したことは、Takamura の成熟度モデルで「定着 Lv5: 信頼性が組織の共通言語となり事業・開発・運用の意思決定に組み込まれている」に到達した実例である。小規模スタートアップ（8 SRE）でもこのレベルへの到達が可能であることを示す (Source: [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]])。 - **SLODLC は SLO 導入を「プロジェクト」から「継続的ライフサイクル」へ変換するフレームワーク**: [[SLODLC]] の 5 フェーズ（INITIATE→DISCOVER→DESIGN→IMPLEMENT→OPERATE）は、Takamura の 4 ステップ（特定チームで価値検証→小さなアクション→ユーザー満足度の一部→すべてのユーザー満足度指標）と並列に読める。SLODLC の INITIATE（ビジネスケース・ステークホルダー・成果目標の定義）が Takamura の前提整備と、DISCOVER（ジャーニー優先化・依存分析・挙動観察）が「代表的 SLI を仮決めする」作業と対応する。OPERATE に「Review Periodically」を含み、段階的導入の「育てながら定着させる」サイクルが制度化されている (Source: [[@2023__SREcon23EMEA__9 Things You Should Do When Starting to Use SLOs]])。 - **SLO 文書化に WWWWHW（What/Where/Who/When/How/Why）の 6 要素を明示することで「誰でも保守できる」状態になる**: Furino は SLO 文書化の要素として「この SLO は何か・どこに展開されているか・誰が所有するか・いつから運用するか・どう修正するか・なぜこの指標が重要か」の 6 要素を挙げた。SRE Workbook の SLO Document と Stanke（2020）の SLO Policy（Rationale フィールド）に加わる整理軸として、組織記憶に残る形での文書化基準を示す。Durst（2025）の Attempt #2 失敗要因「担当者交代時の所有権喪失・異なる SLI 定義の非互換」を防ぐ実践的対処として機能する (Source: [[@2023__SREcon23EMEA__9 Things You Should Do When Starting to Use SLOs]])。 - **クライアントサイド SLO では「文化醸成・運用の軌道乗せ」が技術実装よりも難しい**: [[Luup]]（[[Wataru Tsuda]]、SRE NEXT 2024）はクライアントサイド SLO を CUJ 再設定 → SLI 設定 → 文化醸成 → SLO 設定の順で進めたが、「文化醸成や運用を軌道に乗せる部分が一番重要」と述べた。Takamura の成熟度モデルの「定着」軸と対応しており、SRE 初出身（バックエンド/インフラ）者がクライアントの信頼性に馴染みのない組織では定着が律速になりやすいことを裏付ける (Source: [[@2024__SRENext2024__Enabling Client-side SLO]])。 - **PdM・SWE・SRE の三者でユーザージャーニーマトリクスを作ることが CUJ 再設定の有効な手法**: Luup は PdM が Figma でユーザージャーニー一覧を作成し、それを基に PdM・SWE・SRE が議論してユーザージャーニーマトリクス（UserJourney / SRE Activities / Priority / SLO / TraceName / 関連WebAPI などを列とする表）にまとめた。単に「SRE が CUJ を決める」のではなく、PdM の製品視点とSWEの実装知識を組み合わせることで CUJ の妥当性と SLO の意味が組織横断で共有される。Takamura の段階的導入の「特定チームで価値検証」の前提として三者合意のプロセスを置くのが実務上有効と読める (Source: [[@2024__SRENext2024__Enabling Client-side SLO]])。 - **クライアントサイドの Latency SLI の %ile 設定に Web 標準（Core Web Vitals）を参照することで合意コストを下げられる**: Luup は p75 を選んだ根拠として Core Web Vitals の Good LCP Score が 75th percentile を採用していることを挙げた。SRE が独自に閾値を提案すると PdM・SWE との合意が困難になるが、業界標準を参照することで「なぜ p75 か」の議論を省けた。この手法は Latency SLI の %ile 設定に限らず、組織外部の権威を根拠として使うことで SLO 合意コストを下げる一般的なパターンとして読める (Source: [[@2024__SRENext2024__Enabling Client-side SLO]])。 - **Multi-tiered SLOs（Upside/Downside/Actual）はフェーズ移行の見取り図と PdM 向け説明の両方として機能する**: Luup は 1 つの SLI に Upside（理想：99%/1sec）/ Downside（割りたくない：99%/3sec）/ Actual（現実：99%/5sec）の 3 段階 SLO を設定した。Downside を割っている間のみ Actual を作成し、将来的に Actual を廃止して Downside だけを見る状態を「Future」として定義している。段階的導入の文脈では、「今の自分たち（Actual）・守るライン（Downside）・目指す姿（Upside）」を一つの表に示すことで、PdM が意思決定に使う SLO とSWEが運用する SLO を役割別に整理できる (Source: [[@2024__SRENext2024__Enabling Client-side SLO]], 参考: Alex Ewerlöf Notes)。 - **技術的な成熟度モデルは「誰を・どの順序で説得するか」という同意獲得(buy-in)の手前の課題を扱わない**: Takamura の 3 軸成熟度モデル(定義・運用・定着)は SLI/SLO が組織に根付いた後の状態を段階的に評価するのに対し、Rensin(『SLO サービスレベル目標』6 章)は根付かせる**以前**に必要な、開発・製品・運用・QA・法務・経営幹部という利害関係者ごとの説得話法と「開発運用→製品→経営幹部→法務→QA」という説得順序を具体的に示す。「定着 Lv1: SRE チームのみが利用」から Lv2 以降へ進めるための最初の一歩(誰にどう同意させるか)を、Takamura の成熟度モデルは前提としてしか扱わないが、Rensin の章はそこを主題として具体化しており、両者を並べると段階的導入は「技術的成熟度を上げる工程」と「組織的同意を積み上げる工程」の 2 本の軸を持つことが見える。(Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]], [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 6 同意の獲得]]) - **初めてのエラーバジェットポリシー発動という「最初のテスト」は、定着 Lv3→Lv4 の移行を試す具体的なイベントとして読める**: Takamura の成熟度モデルは「Lv3: Error Budget Policy が文書化されチームで運用されている」から「Lv4: Error Budget 消費率を継続的に計測し改善活動へ反映している」への移行条件を明示しないが、Rensin は「初めてエラーバジェットを使い果たしてポリシーを適用する瞬間」こそが SLO 採用の真の転換点であり、ここで例外を作らず完全に従うかどうかが組織的な定着を左右すると論じる。これは成熟度モデルの抽象的なレベル間移行に、「最初のポリシー発動を例外なく遵守する」という具体的な行動基準を与える。(Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 6 同意の獲得]]) - **『SLO サービスレベル目標』16 章のクロール・ウォーク・ランは、Takamura の 4 ステップフレームワークと「何を段階化するか」の軸が異なる**: Takamura の 4 ステップ(特定チームで価値検証→小さなアクションを定める→一部指標を反映→すべての指標を反映)は、SLI/SLO ポリシーの適用範囲と厳格さそのものをチーム内で段階的に広げる軸である。一方 16 章のクロール(基礎構築)→ウォーク(他チームへの拡張)→ラン(継続的改善)は、SLO 提唱者(advocate)という個人・少人数チームの活動範囲と成果物(文書・トレーニング・ケーススタディライブラリ・エキスパートコミュニティ)を組織全体へ広げる軸であり、個々のサービスの SLI/SLO ポリシーの厳格さそのものには立ち入らない。両者を並べると、SLI/SLO の段階的導入には「ポリシーの厳格さを段階化する軸」(Takamura)と「導入を推進する体制・成果物を段階化する軸」(16 章)という独立した 2 本の軸があり、実際の導入では両方を並行して進める必要があることが見える。(Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]], [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 16 SLOの提唱]] §16 冒頭) - **16 章の「サービス選定基準」は、Takamura の「特定チームで価値検証」という第一ステップに、選定の具体的な物差しを与える**: Takamura の 4 ステップは最初に取り組むチームをどう選ぶかを明示しないが、16 章のウォーク段階(§16.2.1)は次に支援するサービスを複雑さ・チームの協力性・システムの重大性・人間のユーザーとの距離の近さという 4 基準で選ぶことを推奨する。この基準は Durst の「SLO 準備度チェックリスト」(オブザーバビリティ基盤・所有権・標準プロセス・保護時間)と役割が異なり、Durst が「導入して良い状態か」を診断するのに対し、16 章の基準は「複数の候補の中でどれを優先するか」を選ぶ相対評価である点で補完関係にある。(Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 16 SLOの提唱]] §16.2.1, [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]]) - **Takamura の「SLO Document」5 項目は、15 章の 9 セクション構成の簡約版として読める**: Takamura が挙げる SLO Document(サービス名・SLOの定義、サービスの概要、SLI/SLO、見直しのスケジュール、エラーバジェットポリシー)は、Hidalgo が 15 章で示す SLO 定義ドキュメントの 9 セクション(所有権・承認者・定義の状態・サービスの概要・SLOの定義と状態・論拠・再検討のスケジュール・エラーバジェットポリシー・外部リンク)のうち、サービスの概要・SLI/SLO・見直しのスケジュール・エラーバジェットポリシーの 4 項目とほぼ一致する一方、Takamura 版には所有権(責任者)・承認者・定義の状態(提案日/最終更新日/次の再考日)・論拠・外部リンクという説明責任と鮮度管理に関わる 5 項目が明示的には含まれない。15 章はこの 5 項目こそが「定義ドキュメントが形骸化せず更新され続ける」ための骨格だと位置づけており、成熟度モデルの「定義 Lv3(標準化・SLO Document 管理)→Lv4」の間には、5 項目の有無という具体的なチェックポイントを置けることが分かる。(Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]] p.39, [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 15 発見可能で理解可能なSLO]] §15.1.1) - **15 章の「発見可能性」は、成熟度モデルの「定着」軸には無い独立した評価軸を示唆する**: Takamura の 3 軸成熟度モデル(定義・運用・定着)は SLI/SLO が組織内でどう使われているかを評価するが、定義そのものが「見つけられるか」は問わない。15 章はドキュメントリポジトリの一元化・ツールによる自動同期・定期レポート・ダッシュボードという、定義ドキュメントの存在そのものを周知する施策を独立した課題として扱う。良い定義(定義軸で高レベル)を書いても、リポジトリが分散していれば定着は進まないと考えられ、「発見可能性」は 3 軸モデルを補う第 4 の観点になりうる。(Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 15 発見可能で理解可能なSLO]] §15.2, [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]]) - **14 章の「再検討のスケジュール」は、Takamura の成熟度モデルの運用 Lv2(定期的な SLO レビュー)・定着 Lv3(レビュー手順の文書化)に、レビューで実際に何を確認すべきかという具体的なチェックリストを与える**: Takamura の成熟度モデルは「定期的な SLO レビューや振り返りが実施されている」ことを運用 Lv2 の条件として挙げるが、レビューの中身までは規定しない。Hidalgo(『SLO サービスレベル目標』14 章)は、再検討のたびに確認すべき典型的な契機として、利用率の増減・依存対象とプラットフォームの変化・インシデント・ユーザーの期待と要求の変化・計測/計算ツールの変化を挙げ、たとえ短時間で「変更不要」と結論づけても定期的な再検討自体に価値があると論じる(§14.10.1)。これは Takamura の抽象的なレベル定義に、レビュー会議で実際に何を点検するかという実務的な中身を与える (Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]], [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 14 SLOの進化]])。 - **付録AのSLO定義テンプレートは、15章が概念として列挙した9要素を、承認者ごとの合意状況や日付欄まで含めた具体的な記入様式として実装したものである**: 15章(§15.1.1)は所有権・承認者・定義の状態などを要素名として挙げるにとどまるが、付録AのA.1は元の提案日・最後の更新日・承認日・次の再考日という4種類の日付欄と、承認者ごとに「はい/いいえ/保留」のステータスを記録する表を具体的に提示する。これは Takamura の SLO Document 5 項目には含まれない、所有権と承認プロセスの進捗管理という運用上の骨格を可視化しており、成熟度モデルの「定義 Lv3(標準化・SLO Document で管理)」に到達した組織が実際に運用すべき記入項目の具体例を与える (Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Appendix A SLOの定義のテンプレート]], [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 15 発見可能で理解可能なSLO]])。 - **13 章の 6 段階の道筋は、本 concept が別々に蓄積してきた 3 つの軸を 1 本の時間軸へ並べ直したものとして読める**: Treen(『SLO サービスレベル目標』13 章)は SLO の文化的定着を「同意を得る→最優先化する→実装する→活用する→反復する→他者へ提唱する」という 6 段階として提示する。この列は、6 章の同意獲得(第 1 段階)、Takamura の 4 ステップと成熟度モデルの定義・運用軸(第 3〜4 段階)、14 章の再検討スケジュール(第 5 段階)、16 章のクロール・ウォーク・ラン(第 6 段階)という、これまで独立に積み上げてきた知見の適用時期を一続きに配置する。特に「他者への提唱」を最終段階に置くことは、16 章が提唱者の存在を前提としていた点(下記の未解決の問い)に対し、提唱は導入の出発点ではなく自チームで一巡させた後の活動だという順序の答えを与える。ただし Treen 自身は「SLO はプロジェクトではなくプロセスであり終着点はない」と述べており、6 段階は一度通れば終わる工程ではなく反復する円環として提示されている点で、直線的な成熟度モデルとは性格が異なる。(Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 13 SLO文化の構築]], [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 16 SLOの提唱]], [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]]) ## 未解決の問い - Rensin の「開発運用→製品→経営幹部→法務→QA」という説得順序と、Takamura の 3 軸成熟度モデルによる現状診断は、実際の導入プロジェクトでどう組み合わせるべきか。診断を先に行うべきか、同意獲得を先に行うべきかは本 concept の現ソース群では未検証。 - クライアントサイド SLO でユーザー側都合（ネットワーク・端末・途中キャンセル）をどう除外するか、またはどこまで SLO に含めるべきか。Luup は p75 で外れ値を緩和する方針としたが、除外ロジックの詳細は未明（transcript なし）。 - Multi-tiered SLOs の Upside/Downside/Actual はどのように数値を決めるか。Luup の発表ではプロセスの説明のみで具体的な決定フローは公開されていない。 - 成熟度モデルの 3 軸（定義・運用・定着）は独立して育てるべきか、連動させるべきか。例えば「定義 Lv3、運用 Lv1」という状態は有効か。 - SLO 違反ポリシーの Level1（なにもしない）から Level2（SRE チームが対応）への移行タイミングはどう判断するか。 - 成熟度モデルを組織診断ツールとして使う場合、自己評価と外部評価の乖離をどう扱うか。 - CUJ（Critical User Journey）の特定が難しい複雑なシステムで、Lv2（代表的な SLI を仮決め）からどう Lv4（CUJ との関係を測定）へ進化させるか。 - The Art of SLOs で推奨される CUJ 特定手法は具体的にどのようなものか（本スライドでは参考として言及のみ）。 - SLO Rationale フィールドに「ユーザー行動シグナルとの相関」を記述する際、どの粒度・どの観察期間のデータが根拠として十分か。Stanke の例（エラー率 0.05% 超 → サポートチケット増加）はシンプルだが、行動指標とエラー率の関係が非線形または遅延を持つ場合の扱いはどうなるか。 - SLO が「棍棒」として使われているかどうかを組織的にどう診断するか（SLO 指標だけ達成していてシステム改善が停滞している状態を成熟度モデルのどの軸で検出するか）。 - Coulter（2020）の 3 次元 SLI/SLO フレームワークを段階的に導入する場合、Code・Infrastructure・CX の 3 次元をどの順序でどの成熟度レベルから導入するのが効果的か。 - Durst の 4 条件「SLO 準備度チェックリスト」を組織自己評価ツールとして使う場合、各条件の「充足」をどう判定するか（特に「ノミナル所有権の概念」と「標準プロセスの確立」の境界は曖昧）。 - ハイパーグロース環境での「保護時間（protected time）」はどう確保するか。Sprint への組み込み・ロードマップ入り・四半期 OKR との連動など複数の制度設計があるが、どれが最も効果的か。 - 16 章の「ポリシーの厳格さを段階化する軸」(Takamura)と「推進体制・成果物を段階化する軸」(16 章のクロール・ウォーク・ラン)は、どちらを先に立ち上げるべきか。16 章は SLO 提唱者の存在を前提にしており、提唱者自身がまだいない組織では両軸のどちらから着手するのが妥当かは本 concept の現ソース群では未検証。 ## 関連 - 概念: [[サービスレベル目標]] / [[エラーバジェット]] / [[SRE]] / [[SREの提唱]] - エンティティ: [[Narimichi Takamura]] / [[Topotal]] / [[Dave Stanke]] / [[Google]] / [[Rob Durst]] / [[Spring Health]] / [[Wataru Tsuda]] / [[Luup]] / [[Daria Barteneva]] / [[Eva Parish]] - 概念: [[グッドハートの法則]]（SLO ゲーミングの原因と対策） - ソース: [[@2022__SREcon22EMEA__Going-from-30-to-30-Million-SLOs]] / [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]] / [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]] / [[@2018__Google SRE Workbook__SLO Engineering Case Studies]] / [[@2019__SREcon19Americas__Case Study - Implementing SLOs for a New Service]] / [[@2020__SREcon20Americas__Avoiding Goodhart's Law]] / [[@2020__SREcon20Americas__Squish Level Objectives]] / [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]] / [[@2023__SREcon23EMEA__9 Things You Should Do When Starting to Use SLOs]] / [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 6 同意の獲得]] / [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 16 SLOの提唱]] / [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 15 発見可能で理解可能なSLO]] / [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 14 SLOの進化]] / [[@2023__OReillyJapan__SLO サービスレベル目標 - Appendix A SLOの定義のテンプレート]] / [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 13 SLO文化の構築]] - エンティティ: [[Alex Palcuie]] / [[Dave Rensin]] / [[Harold Treen]] - 関連 MOC: [[structures/SRE - MOC]] ## 出典 - [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 16 SLOの提唱]]（クロール・ウォーク・ランの3段階モデル、セールストーク、文書・トレーニング教材、ケーススタディライブラリ、SLOエキスパートコミュニティ、Daria Barteneva・Eva Parish） - [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 6 同意の獲得]]（利害関係者別の同意獲得(buy-in)話法、説得順序、初めてのエラーバジェットポリシー設計、David K. Rensin） - [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]]（3 つの難点・4 ステップフレームワーク・5 段階ポリシー・成熟度モデル・SLO Document） - [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]]（段階的 SLO 構築、ステークホルダー合意、継続改善） - [[@2018__Google SRE Workbook__SLO Engineering Case Studies]]（外部組織への SLO 導入パターン） - [[@2019__SREcon19Americas__Case Study - Implementing SLOs for a New Service]]（Squarespace COS への 6 ステップ新規サービス SLO 実装・プローバー活用・SLO 公開ドキュメント） - [[@2020__SREcon20Americas__Avoiding Goodhart's Law]]（グッドハートの法則の SRE 文脈応用・3 次元 SLI/SLO フレームワーク・反復的 SLO 交渉プロセス） - [[@2020__SREcon20Americas__Squish Level Objectives]]（SLO Policy への Rationale フィールド追加・顧客行動データによる SLO 根拠づけ・エラーバジェットの UX 実験活用） - [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 15 発見可能で理解可能なSLO]]（SLO 定義ドキュメントの9セクション構成、発見可能性のためのリポジトリ・ツール・ダッシュボード） - [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 14 SLOの進化]]（SLO 再検討の6トリガー分類、定期的な再検討スケジュールの意義、野心的SLOの段階的引き上げ） - [[@2023__OReillyJapan__SLO サービスレベル目標 - Appendix A SLOの定義のテンプレート]]（SLO定義ドキュメントの記入様式、承認者ステータス・4種類の日付欄）