スクラムマスターのPO支援プロダクトリサーチのモヤモヤ

今日話すことスクラムマスターはPOの支援の一環としてプロダクトのリサーチをします。その中で最近モヤモヤしていることを共有します。

👤 自己紹介・前提名前：櫻井健（@monotalk_xyz）役割：スクラムマスター（某建設SaaS 🏗️）リサーチ?のスキル：個人ブログでのアクセス解析（GA / GSC）統計検定2級、機械学習・分析の基礎
B2B SaaSのMOps（GTM・解析ツール運用）

スクラムマスターのリサーチ ScrumMasterWay レベ本来の焦点ルリサーチの対象・問い Level 1: My Team
チーム改善・自己組織自分・チーム（心理的安全性・ボトルネッ化ク） Level 2: Relationships 外部・POとの関係改善プロダクト・PO （顧客の声・情報サイロ化） Level 3: Entire System 組織全体のアジリティ組織文化・市場（評価制度・市場適応）プロダクトリサーチは Level 2（PO支援）に該当

プロダクトリサーチでの個人的「」と「Δ」 ➕ ➕）成果が出たもの（ユーザーアンケートの分析・レポーティングユーザー行動ログのリサーチモヤモヤ・課題（Δ） SLO（応答速度）策定のためのリサーチ
👉 今回は「SLO策定のモヤモヤ」にフォーカス

そもそもSLOとは？ SLO（Service Level Objective：サービスレベル目標）サービスが達成すべき信頼性・性能の数値目標例：可用性 99.9% / 応答速度 99%が100ms以内
チームの現状外部SLO・内部SLOともに未設定

なぜSLOが必要なのか？契機：顧客からの「画面が遅い」問い合わせで急遽対応直面した課題問い合わせ起点の「後手（リアクティブ）対応」事前に手を打つ「プロアクティブな改善」ができなかった

なぜ事前に気づいて行動できなかったのか？スロークエリ監視で遅延自体は検知できていた動けなかった2つの理由 1. 検知過多: スロークエリ多すぎ 2. 基準不在: POへ相談・改善を優先する客観基準がない
対話の共通基準として SLOが必要だと実感した

モヤモヤ① トップダウンSLO設定はムズカシイ「エラーバジェット」等のSLO(SRE的な考え方)はビジネス側に伝わりにくい現在のアプローチ事象ベースの帰納法的アプローチを採用改修機能の性能レポートをPOに共有しすり合わせ

モヤモヤ② 基本統計量（P90等）と現場の乖離全体統計（p90等）では困っている姿が伝わらない「具体的に誰が遅い？」「問い合わせはある？」対話を通じて、フォーマットを変更顧客別のレイテンシーを提示具体的な利用イメージと影響度を持ってもらう

モヤモヤ③ 問い合わせバイアス（問い合わせ駆動）「問い合わせがない＝問題なし」と判断されがちジレンマサイレントマジョリティを見落とすリスク定量データと顧客の声（定性）のバランスの難しさ

モヤモヤとの今後の向き合い方 1. 問題駆動での判断経験を積むルール化の前に、データを共有して議論する機会を増やす 2. パフォーマンスレポートの可視化と共有計測値を見える化し見ることを習慣化する.評価・判断をチームに委ねる

スクラムマスターのPO支援プロダクトリサーチのモヤモヤ

スクラムマスターのPO支援プロダクトリサーチのモヤモヤ

monotalk.xyz

More Decks by monotalk.xyz

Other Decks in Research

Featured

Transcript