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

Transcript

1. スクラムマスターのPO支援 プロダクトリサーチのモヤモヤ
2. 今日話すこと スクラムマスターはPOの支援の一環としてプロダクトの リサーチをします。 その中で最近モヤモヤしていることを共有します。
3. 👤 自己紹介・前提 名前：櫻井健（@monotalk_xyz） 役割：スクラムマスター（某建設SaaS 🏗️） リサーチ?のスキル： 個人ブログでのアクセス解析（GA / GSC） 統計検定2級、機械学習・分析の基礎 B2B SaaSのMOps（GTM・解析ツール運用）
4. スクラムマスターのリサーチ ScrumMasterWay レベ 本来の焦点 ル リサーチの対象・問い Level 1: My Team チーム改善・自己組織 自分・チーム（心理的安全性・ボトルネッ 化 ク） Level 2: Relationships 外部・POとの関係改善 プロダクト・PO （顧客の声・情報サイロ化） Level 3: Entire System 組織全体のアジリティ 組織文化・市場（評価制度・市場適応） プロダクトリサーチは Level 2（PO支援） に該当
5. プロダクトリサーチでの個人的 「 」と「Δ」 ➕ ➕） 成果が出たもの（ ユーザーアンケートの分析・レポーティング ユーザー行動ログのリサーチ モヤモヤ・課題（Δ） SLO（応答速度）策定のためのリサーチ 👉 今回は 「SLO策定のモヤモヤ」 にフォーカス
6. そもそもSLOとは？ SLO（Service Level Objective：サービスレベル目標） サービスが達成すべき信頼性・性能の数値目標 例：可用性 99.9% / 応答速度 99%が100ms以内 チームの現状 外部SLO・内部SLOともに 未設定
7. なぜSLOが必要なのか？ 契機：顧客からの「画面が遅い」問い合わせで急遽対 応 直面した課題 問い合わせ起点の「後手（リアクティブ）対応」 事前に手を打つ「プロアクティブな改善」ができなかっ た
8. なぜ事前に気づいて行動できなかったの か？ スロークエリ監視で遅延自体は検知できていた 動けなかった2つの理由 1. 検知過多: スロークエリ多すぎ 2. 基準不在: POへ相談・改善を優先する客観基準がない 対話の共通基準として SLOが必要だと実感した
9. モヤモヤ① トップダウンSLO設定はムズカシイ 「エラーバジェット」等のSLO(SRE的な考え方)は ビジネス側に伝わりにくい 現在のアプローチ 事象ベースの帰納法的アプローチを採用 改修機能の性能レポートをPOに共有しすり合わせ
10. モヤモヤ② 基本統計量（P90等）と現場の乖離 全体統計（p90等）では困っている姿が伝わらない 「具体的に誰が遅い？」「問い合わせはある？」 対話を通じて、フォーマットを変更 顧客別のレイテンシーを提示 具体的な利用イメージと影響度を持ってもらう
11. モヤモヤ③ 問い合わせバイアス（問い合わせ駆動） 「問い合わせがない＝問題なし」と判断されがち ジレンマ サイレントマジョリティを見落とすリスク 定量データと顧客の声（定性）のバランスの難しさ
12. モヤモヤとの今後の向き合い方 1. 問題駆動での判断経験を積む ルール化の前に、データを共有して議論する機会を増や す 2. パフォーマンスレポートの可視化と共有 計測値を見える化し見ることを習慣化する.評価・判断を チームに委ねる