スプリントゴール未達症候群に送る処方箋

SCRUM FEST Osaka 2025
https://www.scrumosaka.org/
での登壇資料です

Transcript

1. ©KAKEHASHI inc. スプリントゴール未達症候群に送る処方箋 2025/07/19 @スクラムフェス大阪 2025 清水 翔太
2. ©KAKEHASHI inc. 自己紹介 2 清水 翔太（Shota Shimizu） 株式会社カケハシ　Musubi AI 在庫管理チーム所属 2023/09 ソフトウェアエンジニアとしてジョイン Musubi AI 在庫管理の本部向けレポート機能の開発に従事 • Next.js, GraphQL でのフロントエンドの実装 • Python での API やバッチ処理の実装 • Databricks でのレポート集計の実装 好きな言語は Scala と SQL スクラムフェス新潟で刺激を受け、初プロポーザルからの初登壇 : @_smzst : smzst
3. ©KAKEHASHI inc. ©KAKEHASHI inc. 3
4. ©KAKEHASHI inc. チームを蝕む病
5. ©KAKEHASHI inc. 問診 1. 目的意識の漂流 ◦ スプリントゴールが単なるスプリントに積んだチケットの要約になっている ◦ 何のために頑張っているのか、チームの誰も自信を持って答えられない 2. 仕事の停滞 ◦ リファインメントが長引いたり迷走する ◦ バーンダウンチャートが燃え尽きない 3. チームの消耗 ◦ 特定の人ばかりが忙しく、その人がいないと仕事が止まる ◦ 常に複数のタスクを抱え、コンテキストスイッチでヘトヘトになっている こんな症状に心当たりはありませんか？ 5
6. ©KAKEHASHI inc. 解剖 すべての症状が一つの結果につながっていた 6 結果 スプリントゴール未達 根本原因 目的意識の漂流 仕事の停滞 チームの消耗 症状 属人化 フロー管理不全
7. ©KAKEHASHI inc. ゴール未達くらいで大げさな。 次のスプリントで達成すればいいじゃないか！
8. ©KAKEHASHI inc. 大事な話 スプリントゴールは… • 価値仮説の観測点 ◦ 「これを作ればユーザーはこんなによくなるはずだ」というビジネス上の仮説の実験 • チームの羅針盤 ◦ その実験で何を明らかにし、次に進むべき道を決めるための指針 そもそもスプリントゴールの達成は重要なのか？ 8 未達に終わるということは… • 届けようとした価値が本当に正しかったのか、何も学べていない • 進むべき道なのか分からない不確実性を次のスプリントに持ち越している
9. ©KAKEHASHI inc. 処方箋を探す旅
10. ©KAKEHASHI inc. 根本原因 1: 属人化 属人化から始まる負のスパイラル 10 Epic の事前調査や設計準備が特定メンバーに偏る ⇒ 他メンバーの理解が浅くなる 属人化 リファインメント 迷走 進捗の鈍化 理解の浅いメンバーが詳細な議論に入り込み、ポイント見積もりに時間がかかる ⇒ 準備不足・仕様の解像度が低いままスプリントを迎える 全体像を把握する人としない人で理解度に差が生じる ⇒ 主体的なチケット着手が難しくなり、特定メンバーに仕事が集中する
11. ©KAKEHASHI inc. Epic 担当制により責任と裁量を分散させる
12. ©KAKEHASHI inc. 根本原因 1: 属人化 • PdM・デザイナーとの合意形成 ◦ 背景・課題・解決策を一貫して理解し、なぜ今これを作るのかをチームに示す • 外部仕様の具体化 ◦ ユーザー視点の仕様を明確にしてリスクを最小化する • 技術的リスクの早期発見 ◦ 概念設計と主要部品の洗い出しでデータ・ドメインの整合性を担保し大きな手戻りを防ぐ • ユーザーストーリーの起票 ◦ どのような価値をどのような順序で提供するかを定める • 完了の基準を共有しズレを防止 ◦ 受け入れ条件を PdM と合意し、完了の定義を明確にして期待の不一致をなくす Epic 担当の役割: 仕様の起点と全体のリード 12
13. ©KAKEHASHI inc. でも、Epic 担当に知識が偏るのでは…？
14. ©KAKEHASHI inc. 根本原因 1: 属人化 • Gather での常時モブワーク ◦ モブプログラミング ◦ 技術ニュースや生成 AI プロンプトなどの雑談 ◦ テーマを絞らずなんでも話しやすい雰囲気 • 1 日 2 回の sync ◦ 朝会（デイリースタンドアップ）と夕会での共有や相談 • 図解による設計の共有 ◦ リモートワーク下における積極的なアウトプットは最重要 ◦ 分かりやすく図にまとめることで、共有・フィードバックを得る機会を得る 情報共有文化 14
15. ©KAKEHASHI inc. 根本原因 1: 属人化 アウトプットすれば助けを得られる 15 A テーブルに紐付いてるのは B テーブルかも 気になるのは A テーブルがC テーブルにリレーションして いるように見えるところくら いですかね！ それ以外はリレーションとし てはよさそうです！
16. ©KAKEHASHI inc. Epic 担当制の成果 リファインメントの質的変化: 「議論」から「意思決定」へ 16 1.0 3.0 0.0 2.0 リファインメント所要時間 平均 50 % 削減！
17. ©KAKEHASHI inc. Epic 担当制の成果 回復するスプリントゴール達成頻度 17 100% 0% スプリントゴール 達成頻度の回復！
18. ©KAKEHASHI inc. スプリントゴールを達成しても残るモヤモヤ そして謎の疲労感…
19. ©KAKEHASHI inc. 根本原因 2: フロー管理不全 19 バーンダウンチャート？ バーンダウン達成率 平均 50 %…
20. ©KAKEHASHI inc. 根本原因 2: フロー管理不全 20 バーンダウンチャート！ バーンダウン達成率 平均 90 %！
21. ©KAKEHASHI inc. 根本原因 2: フロー管理不全 • スプリントバックログアイテムの未完了が残るモヤモヤ • 並行する Epic・進行中アイテムのコンテキストスイッチによる疲弊 未完了アイテムと並行作業の多さ 21 並行する Epic 並行する進行中アイテム 残る未完了アイテム
22. ©KAKEHASHI inc. 仕掛りを 1 に制限する「1 WIP 制限」
23. ©KAKEHASHI inc. • 定期リリースとのスケジュールの噛み合わせ • リリース前のレビュープロセス（EM・PdM・QA・デザイナーレビュー） 機械的な 1 WIP 制限は機能しない 23 根本原因 2: フロー管理不全 水 木 (本番デプロイ日) 金 月 (本番デプロイ日) 火 開発 1 レビュープロセス 開発 2 開発 1 レビュープロセス 開発 3 リリース デプロイ
24. ©KAKEHASHI inc. 水 木 (本番デプロイ日) 金 月 (本番デプロイ日) 火 • 定期リリースとのスケジュールの噛み合わせ • リリース前のレビュープロセス （EM・PdM・QA・デザイナーレビュー） 機械的な 1 WIP 制限は機能しない 24 根本原因 2: フロー管理不全 開発 1 レビュープロセス 開発 2 開発 1 レビュープロセス 開発 3 デプロイ リリース コンテキストスイッチの嵐
25. ©KAKEHASHI inc. 1 WIP 制限は「目的」ではなく「結果」である
26. ©KAKEHASHI inc. 1. 日々バーンダウンするくらいの小さなチケット • 小さくすることで並行作業が起こりにくい 2. チケットの依存関係を整理 • ブロッカーを取り除きフローを妨げない順序づくり 3. ロードマップでチケットの重なりを可視化 • 同一スプリント内で並行するチケットの可視化と調整 1 WIP 制限を成功させる秘訣 26 フロー管理不全に対する打ち手
27. ©KAKEHASHI inc. 価値を保ったまま、チケットを小さくする難しさ 27 秘訣 1: 日々バーンダウンするくらいの小さなチケット 薬局の本部管理者（経理担当）が、 薬局ごとの在庫金額をレポート出力できる。 なぜなら、経理担当者が毎月月末に在庫金額を計上する必要があるからだ。 やること • レポート作成画面 • レポート作成 API、ダウンロード API • SQL の検討 • パフォーマンス計測 • … 5pt？
28. ©KAKEHASHI inc. 「ユーザー」を広く捉え、チケットを小さく 28 秘訣 1: 日々バーンダウンするくらいの小さなチケット 薬局の本部管理者（経理担当）が、 薬局ごとの在庫金額をレポート出力できる。 なぜなら、経理担当者が毎月月末に在庫金額を計上する必要があるからだ。 エンジニアが、3 秒以内のレスポンス達成に必要な作業が分かる。 PdM が、ヘッダー行のみのレポートをダウンロードできる。 PdM が、集計されたレポートをダウンロードできる。 5pt 2pt 1pt 2pt
29. ©KAKEHASHI inc. 「知る」「分かる」も価値とするチケット設計 29 秘訣 1: 日々バーンダウンするくらいの小さなチケット 薬局の本部管理者（経理担当）が、 薬局ごとの在庫金額をレポート出力できる。 なぜなら、経理担当者が毎月月末に在庫金額を計上する必要があるからだ。 エンジニアが、3 秒以内のレスポンス達成に必要な作業が分かる。 PdM が、ヘッダー行のみのレポートをダウンロードできる。 PdM が、集計されたレポートをダウンロードできる。 5pt 2pt 1pt 2pt
30. ©KAKEHASHI inc. 「全体マップ」で依存関係を可視化 30 秘訣 2: チケットの依存関係を整理 1 Epic について、どれを どのように進めるかを整理
31. ©KAKEHASHI inc. 「ロードマップ」で Epic の並行数を可視化 31 秘訣 3: ロードマップでチケットの重なりを可視化 複数の Epic の 1 スプリント あたりの並行数を整理
32. ©KAKEHASHI inc. そして、チームは生まれ変わる
33. ©KAKEHASHI inc. 完成した三輪車 33 そして、チームは生まれ変わる Epic 担当制 = ハンドル 進行方向を決定する 1 WIP 制限 = ペダル 前に進む推進力 情報共有文化 = 後輪 全体の安定感を保つ
34. ©KAKEHASHI inc. 今: 「価値の設計図」としてのゴール 昔: 「チケットの要約」としてのゴール 「タスクの作業員」から「価値の設計者」へ 34 そして、チームは生まれ変わる 要約しただけの スプリントゴール 「このスプリントの 価値は？」 価値と現実との対話 テトリスのように積むだけ
35. ©KAKEHASHI inc. ゴールは「観測点」になった 35 そして、チームは生まれ変わる レポートってどれくらいでダウンロードできるようになるんですか？ 2, 3 分なのか 30 分なのか、半日なのかくらいは分かると嬉しい。 やるやらないも含めて PdM が決めてくれるはず ログを取って、検索条件に 応じた所要時間を残そう！ 意思決定に使えるぞ。 変革前の私たち 変革後の私たち ステークホルダー
36. ©KAKEHASHI inc. そして、チームは生まれ変わる 1. 目的意識の漂流 ◦ スプリントゴールが単なるスプリントに積んだチケットの要約になっている ◦ 何のために頑張っているのか、チームの誰も自信を持って答えられない 2. 仕事の停滞 ◦ リファインメントが長引いたり迷走する ◦ バーンダウンチャートが燃え尽きない 3. チームの消耗 ◦ 特定の人ばかりが忙しく、その人がいないと仕事が止まる ◦ 常に複数のタスクを抱え、コンテキストスイッチでヘトヘトになっている 私たちが克服した症状 36
37. ©KAKEHASHI inc. あなたのチームへの「処方箋」
38. ©KAKEHASHI inc. あなたのチームへの「処方箋」 最高の処方箋の見つけ方 38 チームの歩みの 俯瞰視 と 構造化 ばらばらだった事象や課題 新たな処方箋の発見
39. ©KAKEHASHI inc. あなたのチームへの「処方箋」 本質は変わらない 39 打ち手 根 本 原因 を 解決 する た めの 具体的なアクションを考える 俯瞰 チームの現状を客観的に観察する 学習 打ち手を試し、結果から学ぶ 構造化 問題の根本原因と 因果関係を明らかにする 検査と適応
40. ©KAKEHASHI inc. チームを俯瞰し、歩みを構造化する。 そうして見つけたチームの物語が処方箋になる。
41. ©KAKEHASHI inc. PM・EM・エンジニアを積極採用中 https://kakehashi-dev.hatenablog.com/entry/2025/07/17/093000 We’re Hiring!!!