チーム改善を 「やって終わり」にしない

https://confengine.com/conferences/scrummatsuri-2026/proposal/50662

Transcript

1. チーム改善を 「やって終わり」にしない naga (Yukinaga Oishi) 2026-10-24 スクラム祭り福井トラック ©MIXI 1
2. 改善案を試したあと、 続ける 変える やめるまで 判断できていますか？ 2 ・ ・ ©MIXI
3. 改善する中で直 した課題と 「やって終わりにしない」ために 合意しておくことを整理 3 面 ©MIXI
4. naga - Yukinaga Oishi 株式会社MIXI 『家族アルバム みてね』 デジタル課 個 開発チームエンジニア（2026/05〜) ：コーヒー屋をやっています 昨年に 九頭 湖〜岐 お を買いたい 産で黒 をドライブ • X: @_subnaganaga • mixi : @naga 4 阜 竜 金 龍 2 人 土 ©MIXI
5. 家族アルバム みてね ｜サービス概要 家族アルバム みてねはスマホで撮った どもの写真や動画を家族と共有し、 コミュニケーションして楽しむ家族アルバムサービスです。 5 子 ©MIXI
6. チームについて • みてねプレミアムなどのデジタル課 • 開発プロセスにスクラムを採 開発を担当 。現在は1週間スプリント 6 金 用 ©MIXI
7. チーム改善の定義 ©MIXI 7
8. チーム改善の定義 • チーム改善 ＝ 「仕事の進め プロセス」のアップデート ◦ 例：ふりかえりのTry、バックログの運 ルール 「チームの仕事の進め 」をどうやって適応させていくか 事例と共に紹介 8 用 ・ 方 方 ©MIXI
9. ① ストーリーポイントと リードタイムの乖離を直す ©MIXI 9
10. ポイント定規の 直し： 的 • スプリントが2週間→1週間になった • ポイント定規の尺度「1スプリントで終わるか」の基準がずれた ◦ 当時の実態：3ポイントのリードタイムが8〜46 定規から時間表記を削り、定規を絶対評価できる指標にする 10 日 目 見 ©MIXI
11. ポイント定規の 直し：現実 「運 しながら調整する」とだけ決めて り出した 2か 後：効果があったのか誰にも分からない 11 走 見 用 月 ©MIXI
12. ポイント定規の 直し：現実 • 「運 しながら調整する」とだけ決めて り出した。 2か 見るべき指標が無いと、 検証自体ができない 後：効果があったのか誰にも分からない 12 走 見 用 月 ©MIXI
13. ② 価値提供のボトルネックを 分析 解消したい 13 ・ ©MIXI
14. 価値提供のボトルネック分析： 的 • 専任のスクラムマスターがいない →レビューやレトロが本当に価値提 供につながっているのか？ AIスクラムマスター AI現場役が 議事録 アナリティクス を バックログ て評価する ボトルネック分析を実施 14 目 ・ ・ ・ 見 ©MIXI
15. AIからの返事 「開発や計測は問題ない」 「数字がレビュー時の判断に 活 できていない」 • 現実：Looker のダッシュボー ドがほぼ開かれていない 用 ©MIXI 15
16. AIからの返事を受けて これからのスプリントレビューでは、 ダッシュボードを開いて、数字を確認して、施策判断をしよう 次のスプリントレビューでやろう…！ ©MIXI 16
17. 次のアクションが曖昧なまま 実態：「ダッシュボードを 優先度が上がらず、誰が り出した結果 よう」とは合意したものの、 いつ どう組み込むかを決めないまま放置 その後9回のスプリントレビューで、Lookerのダッシュボード は 度も開かれなかった 17 ・ 走 見 ・ 一 ©MIXI
18. スプリントレビュー 既にあるやりたいこと • スプリントで出来上がった機能のデモ • 他チームの 善意や余 実 線でFB収集… に頼るだけでは、既存の運 条件が曖昧な改善は、 常の運 に埋もれて実施されない 18 用 用 日 目 力 ©MIXI 行 に埋もれてしまう
19. スプリントレビュー 既にあるやりたいこと • スプリントで出来上がった機能のデモ • 他チームの 線でFB収集… 実行条件が決まっていなければ、 善意や余 に頼るだけでは、既存の運 に埋もれてしまう 検査は運用に埋もれる 実 条件が曖昧な改善は、 常の運 19 用 用 日 目 力 ©MIXI 行 に埋もれて実施されない
20. ③ 施策を出した後の成果から、 迷いなく進退を判断したい ©MIXI 20
21. プロダクトバックログに るべき指標を紐づける • 施策後に検証されないまま完了にしないように • →「 購 るべき指標」と「確認タイミング」をPBIに記載 率が改善した施策は すぐに意思決定 しかし… 21 見 見 入 ©MIXI
22. 「有意差なし」の意思決定が宙に浮く みてねプレミアムのアップグレードを提案するLPの改修で「有意差なし」 統計的に有意な差を確認できなかったた め、翌 に再評価 ※ による再評価は妥当だが、「いつ 数不 何をもっ て判断を終えるか」が未定だった 22 ・ 月 足 母 ©MIXI
23. 「有意差なし」の意思決定が宙に浮く みてねプレミアムのアップグレードを提案するLPの改修で「有意差なし」 結果に応じた進退の基準がないと、 統計的に有意な差を確認できなかったた 判断は様子見に流れる め、翌 に再評価 ※ 数不 による再評価は妥当だが、「いつ 何をもっ て判断を終えるか」が未定だった 23 ・ 月 足 母 ©MIXI
24. ④ 複数の改善 施策を 同時に検証し意思決定したい 24 ・ ©MIXI
25. 変数がぶつかり、因果関係が不明瞭に… • みてねプレミアムページの改修 • キービジュアルの刷新 • 新プランのリリース 施策の都合はありつつ、 改善 新施策が同時に った 25 走 ・ ©MIXI
26. 変数がぶつかり、因果関係が不明瞭に… • 結果の数字が動いた！ • →「どの施策が効いたのか」…？ 効果の切り分けが難しい その後の判断に影響 ©MIXI 26
27. 変数がぶつかり、因果関係が不明瞭に… • 結果の数字が動いた！ • →「どの施策が効いたのか」…？ 変数の切り分けができないと 効果の切り分けが難しい 定量成果で判断・決定できない その後の判断に影響 ©MIXI 27
28. なぜこれらの詰まりが発 するのか？ 28 生 ©MIXI
29. プロダクト開発を3層に分けてみる 【目的】 ユーザーへの持続的な価値提供 【適応】 【下 え】 学びを持ち帰り 運 が整っているから ルールを改める 価値提供を加速できる 【現場の施策】 機能開発 / ABテスト 【適応】 詰まりを検知して 運 を 直す 【下 え】 判断できる ルールを敷く 【チーム運用】 ふりかえり / スクラムイベント 29 見 支 支 用 用 ©MIXI
30. プロダクト開発を3層に分けてみる 【目的】 ユーザーへの持続的な価値提供 【適応】 有意差なし 判断先送り （＝適応の不全） 【下 え】 学びを持ち帰り 運 が整っているから ルールを改める 価値提供を加速できる 【現場の施策】 機能開発 / ABテスト 【適応】 詰まりを検知して 運 を 直す 【下 え】 判断できる ルールを敷く 【チーム運用】 ふりかえり / スクラムイベント 30 見 支 支 用 用 ©MIXI
31. プロダクト開発を3層に分けてみる 【目的】 ユーザーへの持続的な価値提供 【適応】 【下 え】 学びを持ち帰り 運 が整っているから ルールを改める 価値提供を加速できる 【現場の施策】 機能開発 / ABテスト 【適応】 施策が問題ではなく 詰まりを検知して 判断軸や場の不足 運 を 直す （運用の課題） 【下 え】 判断できる ルールを敷く 【チーム運用】 ふりかえり / スクラムイベント 31 見 支 支 用 用 ©MIXI
32. プロダクト開発を3層に分けてみる 【目的】 ユーザーへの持続的な価値提供 【適応】 【下 え】 学びを持ち帰り 運 が整っているから ルールを改める 価値提供を加速できる チーム運用の層で 【現場の施策】 機能開発 / ABテスト ループが止まっている 【適応】 施策が問題ではなく 詰まりを検知して 判断軸や場の不足 運 を 直す （運用の課題） 【下 え】 判断できる ルールを敷く 【チーム運用】 ふりかえり / スクラムイベント 32 見 支 支 用 用 ©MIXI
33. 透明性・ これどこかで聞いたような…？ 検査・適応 ©MIXI 33
34. 透明性・ 検査・適応 ©MIXI 34
35. 「適応（やめる 変える）」の準備をしないまま動き出していた ダッシュボードを見る ポイント定規の見直し → 「場がない 」 有意差なし → 「見るべき指標がない」 複数同時施策・改善 → 「進退のルールがない」 →「因果関係が不明」 効果の測り を決めずに り出してしまった 確認する場を押さえず/ るべきものが不明瞭 グレーな結果を想定せず 「透明性」の欠如 「検査」の不全 「適応」の不全 基準がなく検査できない 機会と正確さが担保不足 再評価・進退の条件が未合意 スクラムガイド2020 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf ・ ©MIXI 方 見 走 詰まりをスクラムの3本柱で読み解くと 35
36. 私たちに不 • 課題を していた最 の準備とは える化し、数字を測る（透明性と検査）まではトライ ↓ • 結果が出た時の「適応」への備えが不 チーム改善が「やって終わり」になる 最 の理由 36 足 大 足 見 大 ©MIXI
37. 「やって終わり」にしないために どうしていくか ©MIXI 37
38. • ってから「このルールやめよう」と決断するのはコスト↑ ↓ • 例：「何 経って数字が動かなかったら、元に戻す！ （やめる）」という合意をチームで事前に取る 38 ©MIXI 日 走 撤退基準（やめどき）を握る
39. 原則 1期間 • 意欲の 1変数 い時「あれもこれも試したい！」 →変数が混ざる • 結果「何が効いたか分からない…」 「同じ指標を動かす改善は同じスプリントにぶつけない」 ルールを合意する 39 ・ 高 ©MIXI
40. バッティングしそうになったら • 勇気を持って を次のスプリントにずらす • → 急ぐために同時並 するのではなく、1つずつ 結果としてチームの改善 事後の意思決定は 黒つける 速化する 40 高 白 ・ 行 方 片 ©MIXI
41. 検査の場は決めておく 「2週間後に数字を → て考えよう」 常業務に流されやすい 既存のスクラムイベントの中に『決める5分』を、改善を始め ると同時に決めておく 例「2週間後のレトロスペクティブの冒頭5分」など 41 見 日 ©MIXI
42. . なぜ なにを動かすか（変数の宣 ） . どうなったら続けるのか 変えるのか やめるのか（成 功基準と撤退基準） . 誰がいつ、どの場で進退を決めるか（場の予約） 42 ・ 言 ・ ©MIXI ・ 1 2 3 「やって終わり」にしないを実現する
43. 『やめどき』と『判断の場』を合意し 適応までやり切ること ©MIXI 43
44. プロダクトの仮説検証と同じように チームの改善施策も検証する ©MIXI 44
45. チーム改善を 「やって終わり」にしない naga (Yukinaga Oishi) 2026-10-24 スクラム祭り福井トラック ©MIXI 45