品質と信頼性を地続きにする

Transcript

1. 品質と信頼性を地続きにする 〜 Holistic Testing x SRE Engagement 〜 Tamachi.sre #6 株式会社 Topotal / Wataru Tsuda（@gr1m0h）
2. Wataru Tsuda @gr1m0h SWE, SRE @ Topotal, Inc. - 複数社で SRE の技術⽀援に従事 前職で QA と SRE の統合チームを経験 コミュニティ活動 - SRE Lounge Hiroshima / SRE Magazine - SORACOMUG Hiroshima Website: grimoh.net
3. Agenda 今⽇話すこと 1. 品質保証の空⽩ — マトリクスに空⽩がある 2. QA と SRE の相似性 — 似た構造を、違う観点で扱っている 3. QA と SRE のコラボレーション — 前職の経験と、業界の実践から
4. SRE as a Service - 技術⽀援 私たちは Cross-Company Embedded SRE として、課題を解決する。クライアントが変わっても、SRE とし てやるべきことは変わらない。 SRE のプロフェッショナルを、 今すぐチームに。 事業成⻑を続ける SRE の仕組みづくりを プロフェッ ショナルが並⾛サポート
5. Waroom - SaaS Slackで完結できる。AI による情報⾃動収集‧ポストモーテム⾃動⽣成。蓄積したインシデント情報の可視化 と分析。 つらいインシデント対応を楽に、 学びに、そしてゼロに。 迅速な復旧と学びを得るための インシデントマネジメン トサービス
6. 01 / The Quality Gap 品質保証の 空⽩
7. The Quality Gap マトリクスにすると、境界で観点が抜けやすい 機能要件 Dev（開発環境） Prod（本番環境） △ ⼟台 ◦ QAが主に⾒る △ 空⽩② 機能‧UXの継続検証 ⾮機能要件 △ 空⽩① 性能‧可観測性などの設計‧検証 ◦ SREが主に⾒る オブザーバビリティやデータは、それぞれの領域には存在していても、分断されている 開発から本番まで横断して⾒る⼟台になっていない ※ QA / SRE の役割定義ではなく、分業したときに起きやすい観点の偏りを単純化したモデル。
8. Two Gaps 空⽩は 2 つ。実害の出⽅が違う 空⽩① Dev × ⾮機能 空⽩② Prod × 機能 開発段階で性能やリソース特性を継続的に計測していな い → 劣化に気づくのがリリース後になり⼿戻りが⼤きい 可⽤性‧レイテンシ中⼼の監視だけでは機能が正しく動 いているか、期待するUXを提供できているかを捉えきれ ない → 問い合わせやユーザー⾏動から初めて問題を検知する 2 つに共通しているのは、ユーザーから⾒た基準が、計測まで繋がっていないこと ① 「どの程度の性能なら許容できるか」を決めていない → 計測しても判断できない ② 「どんな体験なら期待どおりか」を決めていない → 本番で何を検証‧観測するか決められない 不⼗分な ⼟台 基準を決め、更新するには材料が必要 「どこが壊れたか」「ユーザーにどう影響したか」「どこまでなら許容されたか」 その材料が、QA とSRE の管理するデータに分かれていると、 機能‧⾮機能を横断した弱点が⾒えにくい。だから基準を決めにくい。
9. 02 / Same Structure, Different Perspectives QA と SRE の 相似性
10. Same Structure, Different Perspectives 扱う構造は似ている。違うのは向ける観点 やろうとしていること QA — 主に機能‧UX観点 SRE — 主に⾮機能‧運⽤観点 観点を定義する テスト設計 SLI / SLO 設計 問題を扱う 不具合管理 インシデント管理 変更の影響を⾒る リグレッションテスト カナリアリリース（新旧の⽐較） 重要フローを通す E2E テスト 合成モニタリング（重要フローの実⾏） 結果を定量化する 不具合流出率 リリース前に捕まえられなかった割合 エラーバジェット消費率 開発ライフサイクルに関わる枠組み Holistic Testing SRE Engagement ⽬的や構造には相似性がある。ただし、指標や⼿法の定義が同じということではない。 QAとSREの観点を重ねると、⽚側だけでは⾒えなかった領域まで扱える。
11. Holistic Testing テストを 開発ライフサイクルの 全フェーズ に置く 従来のテスト — フェーズとしてのテスト 開発する テストする → → デプロイ 確かめるのが後段に寄る。気づくのが遅れて手戻りが大きくなる Holistic Testing — 開発ライフサイクルの全フェーズに置く discover 気づき › plan 計画 › understand 理解 › build ビルド › deploy デプロイ › release リリース › observe 観察 learn の次は、また discover 起点も終点もない。observe / learn で得たことが、次の discover に戻る ここで言う「テスト」は、テストの実行だけを指していない 要件を問い直す 設計をレビューする 本番の挙動を観察する discover / plan understand / build observe / learn どのフェーズにも 基準に対して確かめる行為 がある Janet Gregory「Testing from a holistic point of view」(2021) https://janetgregory.ca/testing-from-a-holistic-point-of-view/ › learn 学び
12. Holistic Testing x SRE Engagement 開発ライフサイクル全体にアプローチする考え⽅ discover → plan フェーズ build → understand → build → QA — Holistic Testing テストを独⽴したフェーズではなく、 開発ライフサイクルの全フェーズに置く deploy → release → observe → learn SRE — SRE Engagement 設計‧開発から本番運⽤まで、信頼性の観点で関与する テスト設計‧⾃動テスト 信頼性設計‧計装‧構造化ログ‧トレース deploy / release リリース判定‧受け⼊れ Production Readiness‧カナリア / ロールバック 計画 observe / learn 本番での挙動観察‧振り返り SLI/SLO‧アラート‧ポストモーテム 起点は違っても、対象は開発ライフサイクル全体。 同じフェーズでも、QA は機能‧UX観点、SRE は⾮機能‧運⽤観点 で対応は違う。フェーズで区切らない設計思想が重なる。 Gregory & Crispin, Holistic Testing (Agile Testing Fellowship, 2023) / Google SRE Book Ch.32
13. 03 / Collaboration in Practice QA と SRE の コラボレーション
14. My Case — Why We Merged 今⽇の話に関わるのは、この 3 つ 1. 学習の統合 2. 開発ライフサイクルを ⼀貫して ⾒る 3. アプローチを 組み合わせる 両⽅を並べて学べる体制を作り、不 安なくリリースできる状態にする。 構想‧開発‧運⽤のどこかで切らず に、通して品質を担保する。マトリ クスの空⽩を埋める話と同じ。 どちらか⼀⽅に寄せず、QA の⼿法 と SRE の⼿法を掛け合わせる。 ビジョン:「不具合やインシデントから学 べる体制の構築によって、不安なくリリー スできる体制を確⽴する」 ミッション:「構想段階‧開発段階‧運⽤ 段階に⾄るまで、⼀貫した情報の共有を⾏ う」 ミッション:「エンジニアリング的アプ ローチと探索的アプローチを統合し、戦略 的に実⾏する」 「担保にかかるリソースや⼼理的負荷を最適化する」— 別々にやると⾮効率、という前提がここに出ている。 gr1m0h「QAとSREが統合したQualityチームの挑戦」(Zenn, 2025) ※ 引⽤は社名部分を伏せた抜粋。
15. My Case — Practices 統合チームで空⽩を両側から埋める 統合の動機 対応した部分 やったこと‧考えていたこと 1. 学習の統合 不⼗分な⼟台 不具合とインシデントの統合分析 2. 開発ライフサイクルを⼀貫して⾒ る 空⽩① Dev × ⾮機能 ⾮機能検証のShift-left 3. アプローチを組み合わせる 空⽩② Prod × 機能 機能‧UX検証 のShift-right gr1m0h「QAとSREが統合したQualityチームの挑戦」(Zenn, 2025)
16. Practice 1 — The Problem & The Approach 定義が揃っていないと、並べても会話にならない 課題 - 「不具合」と「インシデント」の定義が曖昧で、チーム内‧部内で会話が成⽴しない - それぞれの対応フローがバラバラで認知負荷が⾼く、分析も別々 → 弱点が組織横断で⾒え ない 不具合 (Defect) インシデント (Incident) 開発環境で発⽣したもの サービス提供に⽀障がある、または UX を著しく下げる 問題。 N=1 でもユーザー影響があれば含む 検知経路と対応フローを整理し、不具合とインシデントが地続き で扱えるようになった。 CUJ 関連は High‧Critical と重篤度基準を明⽂化。 gr1m0h「QAとSREが統合したQualityチームの挑戦」(Zenn, 2025)
17. Practice 1 — Wiring the Data データを 1 か所に寄せて、弱点を横断で⾒る 収集 不具合 → GitHub Issues インシデント → Waroom 集約 → 分析 BigQuery に送る 同⼀スキーマで 扱う → 社内 BI で統合分析 ビジネス KPI と突き合わせ 不具合流出率が横断指標になる どこが弱点かが⾒える QAの不具合とSRE のインシデントを合わせると、機能‧ ⾮機能を横断して分析できる どの機能で不具合‧インシデントが起きやすいか どの体制‧プロセスに課題があるか 不具合流出率：⾒つけた不具合のうち、リリース前に捕 まえられなかった割合 QA と SRE がどこに重点を置くべきか の判断材料になる ⽚⽅だけでは⼀部しか⾒えない。両⽅あるとどこを厚くするかが決まる。 gr1m0h「QAとSREが統合したQualityチームの挑戦」(Zenn, 2025)
18. Practice 1 — The Industry Practices 開発の記録と本番の記録を繋ぐ実践はすでにある DORA - 標準指標 2024年にDeployment Rework Rate を追加し、デリバリ指標が5つになった Change Failure Rate / Deployment Rework Rate は、デプロイと本番で起きた結果の記録の対応付けが必要 → 開発イベントと本番で起きた結果を繋げられることが重要 両側を同じ置き場に（dora-team/fourkeys） テストと本番が同じ規約に（OpenTelemetry） DORAチームのOSS。開発イベントもインシデントも、 events_rawという1つのテーブルへ そこから changes / deployments / incidents をビューと して派⽣し、何をインシデントとみなすかはビュー定義 で決める → 同じ置き場に寄せてから分類する構成 これまでCI‧テストのデータと本番のテレメトリは別々の 規約で扱われていた semconv v1.27.0で cicd / vcs / test / deployment の規約を 追加（CI/CD Observability SIG） → 共通の Semantic Conventions で扱う流れが進⾏中 ※ dora-team/fourkeysの算出対象は元の4指標。2024-01アーカイブ。 DORA, Accelerate State of DevOps(2024) / State of AI-assisted Software Development(2025) / dora.dev “A history of DORA’s software delivery metrics” / dora-team/fourkeys(Apache-2.0) / OpenTelemetry Semantic Conventions v1.27.0
19. Practice 2 — The Problem & The Approach ⾮機能検証を、もっと⼿前に持ってくる 課題：開発段階の⾮機能検証が不⼗分 拠り所：Production Readiness / Holistic Testing - フェーズで区切らず、開発ライフサイクル全体で品質を担保する - ⼿始めに⾮機能検証のShift-left ⾮機能検証だけでなく、機能検証のShift-leftも不⼗分だった - 両⽅を⼿前に寄せる Production Readiness Checklistの運⽤ - 品質⽔準の⽬安 = チェックリストを統合チーム内の指針として作成する - 開発者には押し付けず、⾃動化によって⾃然にこれを満たす形にする ※ Holistic Testing は原典では、 shift-left / shift-right が想起させる直線的な⾒⽅を避けるために無限ループで描かれている。 ここでは着⼿順として shift-left と呼ぶ。 gr1m0h「QAとSREが統合したQualityチームの挑戦」(Zenn, 2025)
20. Practice 2 — Where We Started ⼿前で測るために、まず環境の差異を減らす ブロッカー やったこと 開発環境と本番で実⾏条件が異なる インフラの差異があると、⼿前で測った数字を本番と⽐ 較しづらい Cloud Run Functions の 最⼩インスタンス数を本番に合 わせる コスト配慮で、特定の時間帯だけ本番と同等にする shift-left の前提条件として、まずブロッカーを外すことから始める。 gr1m0h「QAとSREが統合したQualityチームの挑戦」(Zenn, 2025)
21. Practice 2 — Where the Checks Go フェーズごとに、チェックを置く場所を決める フェーズ 置きたいチェック discover / plan PRD / ADR を、Production Readiness の観点を持った AI がレビューする コーディング前に問題を⾒つける build 静的解析、⾃動テスト（パフォーマンス‧E2E‧負荷）、AI ⽀援コードレビュー deploy / release エラーバジェット残量 でリリース可否、カナリアの⾃動判定 ロールバック⼿段の⽤意 全フェーズに 共通 どこで引っかかっても検知してタスクにする PdM の⽬を通し、サービス状況によっては「対応しない」選択も残す 肝はタスク化。アラートで終わらせないことで、対応しない選択も判断として残せる。 gr1m0h「QAとSREが統合したQualityチームの挑戦」(Zenn, 2025)
22. Practice 2 — The Industry Practices Production Readinessは、レビューから継続評価‧プラットフォームへ ⼿動Production Readiness Review → スコアカード （Datadog） SREがサービスオーナーと対⾯で、⻑いチェックリスト を消化していた → サービス数の増加でスケールしない → ⼀度通れば終わりで、その後の開発で基準から外れて いく スコアカードとして、開発ライフサイクル全体での継続 評価に置き換え 評価カテゴリ：Production Readiness / Observability Best Practices / Ownership & Documentation 基準はテンプレートに埋め込む（CNCF/IDP） CNCF Platforms White Paper / Platform Engineering Maturity Model golden pathは「ゲート」より「ガードレール」に近い - 守らせるのではなく、既定で満たされる状態にする 基準を開発者の努⼒に置かず、テンプレート側に持たせ る = shift-downとも捉えられる Cortex / Port / Roadie Tech InsightsもScorecard機能を 提供 → ⼈が⾒るものから、プラットフォームが持つものへ 基準を守るのを開発者個⼈の努⼒に任せず、プラットフォーム側にも持たせる Datadog Blog “How we use Scorecards to define and communicate best practices” / CNCF TAG App Delivery, Platforms White Paper & Platform Engineering Maturity Model(2023)
23. Practice 3 — The Problem & The Approach 機能‧UX検証を、本番まで伸ばす 課題：運⽤段階の機能‧UX検証が不⼗分 - 通常の監視だけでは、機能‧UXの異常を捉えきれない 拠り所：Shift-right / Testing in Production - 機能‧UXの検証を本番側まで広げる - 本番でしか現れない機能‧UXの問題を、影響範囲を制御して確かめる ブロッカー - どこを本番で確かめるのかが決まっていない - QAとSREがそれぞれ違う観点で機能の重要性を判断していた - どこが重要かを揃える必要がある gr1m0h「QAとSREが統合したQualityチームの挑戦」(Zenn, 2025)
24. Practice 3 — Where We Started まず、どの機能‧UXが重要かを揃える QA の機能優先度表（どの機能をどこまで担保するかの⼀覧）と SRE が PdM と合意済みの CUJ をマッピングする 優先度 品質保証のやり⽅ CUJ（例：検索 → 申し込み → 決済、のような必須フロー） 最も厳密なテスト 最重要な機能 ⾃動化された回帰テスト 重要な機能 定期的な⼿動テスト リソースは有限。どこを本番でも重点的に確かめるかの判断軸が、Testing in Production の前提になる。 gr1m0h「QAとSREが統合したQualityチームの挑戦」(Zenn, 2025)
25. Practice 3 — Testing in Production 本番でしか分からないことを、影響範囲を制御して確かめる 実データ‧実トラフィック‧実ユーザーなど、本番固有の条件でしか出ない問題は、⼿前のテストでは拾えない。 Progressive Delivery — 出し⽅を段階に分けることで、影響を抑えたまま本番で確かめられる。 フィーチャーフラグ 特定セグメント ダークローンチ / シャドー トラフィック ユーザー影響を抑える カナリアリリース トラフィックの⼀部 A/B テスト セグメントを分けて⽐較 障壁 低 — 設定ベース 障壁 ⾼ — 並列実⾏ 障壁 ⾼ — トラフィック分岐 障壁 ⾼ — 指標設計が必要 出し⽅の制御とは別系統として、本番で能動的に確かめる ⼿段もある 合成モニタリング（重要フローを本番で継続実⾏）∕カオスエンジニアリング（意図的に壊して回復性を確かめる） A/B テストは、本番のユーザー⾏動で機能‧UXの効果を⽐べる。空⽩②（本番 × 機能）に踏み込める。 AI⽀援で変更が速く、多くなるほど、本番環境で確かめる⼿段の重要性も上がっていく。 gr1m0h「QAとSREが統合したQualityチームの挑戦」(Zenn, 2025) / Google SRE Book (Release Engineering)
26. Practice 3 — The Industry Practices テスト資産を本番で回す、その結果で合否を決める E2E テストを本番モニターに（Checkly） 合否をコードで決める（Argo Rollouts） SRE Workbook は SLO を CUJ を使ってユーザー中⼼の SLOを考えることを勧めている 計測元には複数の選択肢があり、合成モニタリングもそ のひとつ AnalysisTemplateに判定条件を宣⾔ 結果は Successful / Failed / Inconclusive / Error など Checkly は既存の Playwright テストを書き直さず、本番 モニターとして実⾏できる（monitoring as code） → QAのE2Eシナリオを本番での機能検証にも再利⽤で きる Inconclusive = どちらの条件にも当てはまらない、⾃動で 進めず⽌まり、⼈の判断へ メトリクスの取得元はPrometheusのほか Datadog も公 式対応 → 曖昧な判定だけが⼈に回る ※ Kayenta (Netflix x Google, 2018)は、同じ判定を統計検定で⾏って いた 既にあるテスト資産を本番に転⽤し、曖昧な判定だけを⼈に残す。 Google SRE Workbook (Implementing SLOs) / Checkly Docs「Playwright Check Suites」 / Argo Rollouts Docs 「Analysis & Progressive Delivery」 / Netflix TechBlog (2018)
27. Filling the Gap 空⽩は、両側から埋めにいける 機能要件 ⾮機能要件 Dev（開発段階） ◦ QA ◦ 実践2: ⾮機能検証のShift-left Prod（運⽤段階） ◦ 実践3: 機能‧UX検証のShift-right ◦ SRE ◦ ⼟台 実践1: 不具合とインシデントの統合分析 両者を同じ定義‧同じ置き場で扱い、横断で分析できるようにしている 必要な⼿段の多くは既にあった。QA と SRE の境界を超えると、互いの視界の外まで⾒える。
28. Where to Start 全部やらなくていい。いちばん障壁の低いところから ⼟台：オブザーバビリティ（構造化ログ‧メトリクス‧分散トレーシングなど） - 開発ライフサイクル全体の品質観点の分析 - 本番での継続検証や⾃動判定を⽀える 実践1 から 「QA と SRE が集まって、不具合とインシデントを並べて⾒る場を 1 回作る」 実践2 から 「PR テンプレに「計装の説明」欄を 1 ⾏⾜す」 実践3 から 「重要フローを 1 本だけ、合成モニタリングにする」 空⽩は、⼀マスずつ埋められる。チーム統合は前提ではない。
29. Summary まとめ 役割の境界では、観点が抜けやすい - 開発 × ⾮機能と、本番 × 機能‧UXは、観点として漏れがち QAとSREは似た構造を違う観点で扱っている - Holistic TestingとSRE Engagementは、どちらも開発ライフサイクル全体へ観点を広げる ⼀緒に進めると弱点の構造が⾒えてくる ⼟台はオブザーバビリティとデータの集約 - ⼟台として表の全てに横断的に効果がある - それぞれのマス（機能要件x開発段階など）で満たしていても、効⼒は弱い ３つの実践 - 不具合とインシデントの統合分析‧⾮機能検証のShift-left‧機能‧UX検証 のShift-right 変更が速くなるほど、越境の必要性が上がる - 開発ライフサイクルが速くなるほど、品質保証と⾮機能要件の担保が追いつかない - 今⽇触れていないセキュリティも同じ コラボレーションするために「チーム統合」は前提ではない - 今からすぐ始められる！
30. 品質と信頼性を、地続きに 株式会社 Topotal · @gr1m0h · ご清聴ありがとうございました
31. References 参考⽂献 - Janet Gregory, Testing from a holistic point of view (2021) - https://janetgregory.ca/testing-from-a-holistic-point-of-view/ - Gregory & Crispin, Holistic Testing (Agile Testing Fellowship, 2023) - https://agiletestingfellow.com/download_mini_book - Google, Site Reliability Engineering, Ch.32 The Evolving SRE Engagement Model - https://sre.google/sre-book/evolving-sre-engagement-model/ - Google, Site Reliability Engineering, Ch.8 Release Engineering - https://sre.google/sre-book/release-engineering/ - Google, The Site Reliability Workbook, Ch.2 Implementing SLOs - https://sre.google/workbook/implementing-slos/ - gr1m0h「QAとSREが統合したQualityチームの挑戦」(Zenn, 2025) - https://zenn.dev/luup_developers/articles/sre-gr1m0h-20251125 - DORA, A history of DORA's software delivery metrics - https://dora.dev/insights/dora-metrics-history/ - DORA, Accelerate State of DevOps Report 2024 - https://dora.dev/research/2024/dora-report/
32. References 参考⽂献 - DORA, State of AI-assisted Software Development 2025 - https://dora.dev/research/2025/dora-report/ - dora-team/fourkeys (Apache-2.0, 2024-01 Archive) - https://github.com/dora-team/fourkeys - OpenTelemetry, CI/CD Observability SIG (semconv v1.27.0) - https://opentelemetry.io/blog/2025/otel-cicd-sig/ - Datadog, How we use Scorecards to define and communicate best practices - https://www.datadoghq.com/blog/scorecards-dogfooding/ - CNCF TAG App Delivery, Platforms White Paper - https://tag-app-delivery.cncf.io/whitepapers/platforms/ - CNCF TAG App Delivery, Platform Engineering Maturity Model - https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/ - R. Seroter, Shifting left is for suckers. Shift down instead (2023) - https://cloud.google.com/blog/products/application-development/richard-seroter-on-shifting-down-vs-shifting -left - Checkly, Playwright Check Suites - https://www.checklyhq.com/docs/detect/synthetic-monitoring/playwright-checks/overview/
33. References 参考⽂献 - Argo Rollouts, Analysis & Progressive Delivery - https://argo-rollouts.readthedocs.io/en/stable/features/analysis/ - Netflix TechBlog, Automated Canary Analysis at Netflix with Kayenta (2018) - https://netflixtechblog.com/automated-canary-analysis-at-netflix-with-kayenta-3260bc7acc69