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

by KAKEHASHI

Slide 1

Slide 1 text

©KAKEHASHI inc. スプリントゴール未達症候群に送る処方箋 2025/07/19 @スクラムフェス大阪 2025 清水翔太

Slide 2

Slide 2 text

©KAKEHASHI inc. 自己紹介 2 清水翔太（Shota Shimizu）株式会社カケハシ　Musubi AI 在庫管理チーム所属 2023/09 ソフトウェアエンジニアとしてジョイン Musubi AI 在庫管理の本部向けレポート機能の開発に従事 ● Next.js, GraphQL でのフロントエンドの実装 ● Python での API やバッチ処理の実装 ● Databricks でのレポート集計の実装好きな言語は Scala と SQL スクラムフェス新潟で刺激を受け、初プロポーザルからの初登壇 : @_smzst : smzst

Slide 3

Slide 3 text

©KAKEHASHI inc. ©KAKEHASHI inc. 3

Slide 4

Slide 4 text

©KAKEHASHI inc. チームを蝕む病

Slide 5

Slide 5 text

©KAKEHASHI inc. 問診 1. 目的意識の漂流 ○ スプリントゴールが単なるスプリントに積んだチケットの要約になっている ○ 何のために頑張っているのか、チームの誰も自信を持って答えられない 2. 仕事の停滞 ○ リファインメントが長引いたり迷走する ○ バーンダウンチャートが燃え尽きない 3. チームの消耗 ○ 特定の人ばかりが忙しく、その人がいないと仕事が止まる ○ 常に複数のタスクを抱え、コンテキストスイッチでヘトヘトになっているこんな症状に心当たりはありませんか？ 5

Slide 6

Slide 6 text

©KAKEHASHI inc. 解剖すべての症状が一つの結果につながっていた 6 結果スプリントゴール未達根本原因目的意識の漂流仕事の停滞チームの消耗症状属人化フロー管理不全

Slide 7

Slide 7 text

©KAKEHASHI inc. ゴール未達くらいで大げさな。次のスプリントで達成すればいいじゃないか！

Slide 8

Slide 8 text

©KAKEHASHI inc. 大事な話スプリントゴールは… ● 価値仮説の観測点 ○ 「これを作ればユーザーはこんなによくなるはずだ」というビジネス上の仮説の実験 ● チームの羅針盤 ○ その実験で何を明らかにし、次に進むべき道を決めるための指針そもそもスプリントゴールの達成は重要なのか？ 8 未達に終わるということは… ● 届けようとした価値が本当に正しかったのか、何も学べていない ● 進むべき道なのか分からない不確実性を次のスプリントに持ち越している

Slide 9

Slide 9 text

©KAKEHASHI inc. 処方箋を探す旅

Slide 10

Slide 10 text

©KAKEHASHI inc. 根本原因 1: 属人化属人化から始まる負のスパイラル 10 Epic の事前調査や設計準備が特定メンバーに偏る ⇒ 他メンバーの理解が浅くなる属人化リファインメント迷走進捗の鈍化理解の浅いメンバーが詳細な議論に入り込み、ポイント見積もりに時間がかかる ⇒ 準備不足・仕様の解像度が低いままスプリントを迎える全体像を把握する人としない人で理解度に差が生じる ⇒ 主体的なチケット着手が難しくなり、特定メンバーに仕事が集中する

Slide 11

Slide 11 text

©KAKEHASHI inc. Epic 担当制により責任と裁量を分散させる

Slide 12

Slide 12 text

©KAKEHASHI inc. 根本原因 1: 属人化 ● PdM・デザイナーとの合意形成 ○ 背景・課題・解決策を一貫して理解し、なぜ今これを作るのかをチームに示す ● 外部仕様の具体化 ○ ユーザー視点の仕様を明確にしてリスクを最小化する ● 技術的リスクの早期発見 ○ 概念設計と主要部品の洗い出しでデータ・ドメインの整合性を担保し大きな手戻りを防ぐ ● ユーザーストーリーの起票 ○ どのような価値をどのような順序で提供するかを定める ● 完了の基準を共有しズレを防止 ○ 受け入れ条件を PdM と合意し、完了の定義を明確にして期待の不一致をなくす Epic 担当の役割: 仕様の起点と全体のリード 12

Slide 13

Slide 13 text

©KAKEHASHI inc. でも、Epic 担当に知識が偏るのでは…？

Slide 14

Slide 14 text

©KAKEHASHI inc. 根本原因 1: 属人化 ● Gather での常時モブワーク ○ モブプログラミング ○ 技術ニュースや生成 AI プロンプトなどの雑談 ○ テーマを絞らずなんでも話しやすい雰囲気 ● 1 日 2 回の sync ○ 朝会（デイリースタンドアップ）と夕会での共有や相談 ● 図解による設計の共有 ○ リモートワーク下における積極的なアウトプットは最重要 ○ 分かりやすく図にまとめることで、共有・フィードバックを得る機会を得る情報共有文化 14

Slide 15

Slide 15 text

©KAKEHASHI inc. 根本原因 1: 属人化アウトプットすれば助けを得られる 15 A テーブルに紐付いてるのは B テーブルかも気になるのは A テーブルがC テーブルにリレーションしているように見えるところくらいですかね！それ以外はリレーションとしてはよさそうです！

Slide 16

Slide 16 text

©KAKEHASHI inc. Epic 担当制の成果リファインメントの質的変化: 「議論」から「意思決定」へ 16 1.0 3.0 0.0 2.0 リファインメント所要時間平均 50 % 削減！

Slide 17

Slide 17 text

©KAKEHASHI inc. Epic 担当制の成果回復するスプリントゴール達成頻度 17 100% 0% スプリントゴール達成頻度の回復！

Slide 18

Slide 18 text

©KAKEHASHI inc. スプリントゴールを達成しても残るモヤモヤそして謎の疲労感…

Slide 19

Slide 19 text

©KAKEHASHI inc. 根本原因 2: フロー管理不全 19 バーンダウンチャート？バーンダウン達成率平均 50 %…

Slide 20

Slide 20 text

©KAKEHASHI inc. 根本原因 2: フロー管理不全 20 バーンダウンチャート！バーンダウン達成率平均 90 %！

Slide 21

Slide 21 text

©KAKEHASHI inc. 根本原因 2: フロー管理不全 ● スプリントバックログアイテムの未完了が残るモヤモヤ ● 並行する Epic・進行中アイテムのコンテキストスイッチによる疲弊未完了アイテムと並行作業の多さ 21 並行する Epic 並行する進行中アイテム残る未完了アイテム

Slide 22

Slide 22 text

©KAKEHASHI inc. 仕掛りを 1 に制限する「1 WIP 制限」

Slide 23

Slide 23 text

©KAKEHASHI inc. ● 定期リリースとのスケジュールの噛み合わせ ● リリース前のレビュープロセス（EM・PdM・QA・デザイナーレビュー）機械的な 1 WIP 制限は機能しない 23 根本原因 2: フロー管理不全水木 (本番デプロイ日) 金月 (本番デプロイ日) 火開発 1 レビュープロセス開発 2 開発 1 レビュープロセス開発 3 リリースデプロイ

Slide 24

Slide 24 text

©KAKEHASHI inc. 水木 (本番デプロイ日) 金月 (本番デプロイ日) 火 ● 定期リリースとのスケジュールの噛み合わせ ● リリース前のレビュープロセス（EM・PdM・QA・デザイナーレビュー）機械的な 1 WIP 制限は機能しない 24 根本原因 2: フロー管理不全開発 1 レビュープロセス開発 2 開発 1 レビュープロセス開発 3 デプロイリリースコンテキストスイッチの嵐

Slide 25

Slide 25 text

©KAKEHASHI inc. 1 WIP 制限は「目的」ではなく「結果」である

Slide 26

Slide 26 text

©KAKEHASHI inc. 1. 日々バーンダウンするくらいの小さなチケット ● 小さくすることで並行作業が起こりにくい 2. チケットの依存関係を整理 ● ブロッカーを取り除きフローを妨げない順序づくり 3. ロードマップでチケットの重なりを可視化 ● 同一スプリント内で並行するチケットの可視化と調整 1 WIP 制限を成功させる秘訣 26 フロー管理不全に対する打ち手

Slide 27

Slide 27 text

©KAKEHASHI inc. 価値を保ったまま、チケットを小さくする難しさ 27 秘訣 1: 日々バーンダウンするくらいの小さなチケット薬局の本部管理者（経理担当）が、薬局ごとの在庫金額をレポート出力できる。なぜなら、経理担当者が毎月月末に在庫金額を計上する必要があるからだ。やること ● レポート作成画面 ● レポート作成 API、ダウンロード API ● SQL の検討 ● パフォーマンス計測 ● … 5pt？

Slide 28

Slide 28 text

©KAKEHASHI inc. 「ユーザー」を広く捉え、チケットを小さく 28 秘訣 1: 日々バーンダウンするくらいの小さなチケット薬局の本部管理者（経理担当）が、薬局ごとの在庫金額をレポート出力できる。なぜなら、経理担当者が毎月月末に在庫金額を計上する必要があるからだ。エンジニアが、3 秒以内のレスポンス達成に必要な作業が分かる。 PdM が、ヘッダー行のみのレポートをダウンロードできる。 PdM が、集計されたレポートをダウンロードできる。 5pt 2pt 1pt 2pt

Slide 29

Slide 29 text

©KAKEHASHI inc. 「知る」「分かる」も価値とするチケット設計 29 秘訣 1: 日々バーンダウンするくらいの小さなチケット薬局の本部管理者（経理担当）が、薬局ごとの在庫金額をレポート出力できる。なぜなら、経理担当者が毎月月末に在庫金額を計上する必要があるからだ。エンジニアが、3 秒以内のレスポンス達成に必要な作業が分かる。 PdM が、ヘッダー行のみのレポートをダウンロードできる。 PdM が、集計されたレポートをダウンロードできる。 5pt 2pt 1pt 2pt

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

©KAKEHASHI inc. 今: 「価値の設計図」としてのゴール昔: 「チケットの要約」としてのゴール「タスクの作業員」から「価値の設計者」へ 34 そして、チームは生まれ変わる要約しただけのスプリントゴール「このスプリントの価値は？」価値と現実との対話テトリスのように積むだけ

Slide 35

Slide 35 text

©KAKEHASHI inc. ゴールは「観測点」になった 35 そして、チームは生まれ変わるレポートってどれくらいでダウンロードできるようになるんですか？ 2, 3 分なのか 30 分なのか、半日なのかくらいは分かると嬉しい。やるやらないも含めて PdM が決めてくれるはずログを取って、検索条件に応じた所要時間を残そう！意思決定に使えるぞ。変革前の私たち変革後の私たちステークホルダー

Slide 36

Slide 36 text

©KAKEHASHI inc. そして、チームは生まれ変わる 1. 目的意識の漂流 ○ スプリントゴールが単なるスプリントに積んだチケットの要約になっている ○ 何のために頑張っているのか、チームの誰も自信を持って答えられない 2. 仕事の停滞 ○ リファインメントが長引いたり迷走する ○ バーンダウンチャートが燃え尽きない 3. チームの消耗 ○ 特定の人ばかりが忙しく、その人がいないと仕事が止まる ○ 常に複数のタスクを抱え、コンテキストスイッチでヘトヘトになっている私たちが克服した症状 36

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

©KAKEHASHI inc. あなたのチームへの「処方箋」本質は変わらない 39 打ち手根本原因を解決するための具体的なアクションを考える俯瞰チームの現状を客観的に観察する学習打ち手を試し、結果から学ぶ構造化問題の根本原因と因果関係を明らかにする検査と適応