Sprint Goal! アウトカム思考のMiro&GitHub活用術

Spr int Goa l , M iro & Git Hub Sprint Goal! アウトカム思考のMiro&GitHub活用術 2026/08/21 Sprint Goal & GitHub 01

資料全体で伝えたいこと スクラムは、最初に決めた計画を 効率よく消化するための仕組みではない。 ゴールに向かって短い周期で「検査と適応」を繰り返し、 その時点で最も良いパスを選び続けるための仕組み。 ここからSprint Goalの必要性を説明します Sprint Goal & GitHub 02

ゴールへの経路は、最初には仮説でしかない Project / Phase Goal は「最終的にここへ到達したい」を示す。 しかし最適な経路は、進みながら学ぶしかない。 Project / Phase Goal Sprint 3 / Goal C Sprint 2 / Goal B Sprint 1 / Goal A 実行・学習 → 検査と適応 → 次のゴールを決める 現在地 Task → Sprint Goal → Project Goal という積み上げではない Sprint Goal & GitHub 03

よくあるスクラム このようなスクラムの状態になっていませんか？ 最初にPBLを作る PBIを詳細化する ストーリーポイントを 見積もる Velocityを測る Velocity分だけ Sprintに詰める Taskに分解 Taskを消化する 全部終わった？ この運用では、スクラムのイベントを使っていても、マネジメントモデルとしてはかなり計画駆動。 Sprint Goal & GitHub 04

こうなると、各イベントの「問い」はこうなる 計画の消化が目的になると、スクラムのイベントは進捗確認の場に変わる。 Sprint Planning Daily Scrum Sprint Review 「次のスプリントで 何ポイントできますか？」 「進捗どうですか？ 予定通り進んでいますか？」 「予定したものは完成しまし たか？完成したものはどうで すか？」 結果として「最初に決めた計画をいかに正確に実行するか」がチームの目的になりやすい そんなアウトプット思考になってませんか？ Sprint Goal & GitHub 05

問題は「最初には正解のパスが分からない」こと 暗黙の前提 実際のプロダクト開発 Goalまでの正しいパスは決まっている パスは分岐し、進むにつれ最善は変わる ユーザー・技術・制約が分かる これを全部やればGoalに着く、という発想 想定の誤りが分かる より良い方法が見つかる 未来のTaskを精緻にすることより、次に何を達成するかを明確にすることで、ゴールに近づく。 それが、Sprint Goal。 Sprint Goal & GitHub 06

今回の説明に合うSprint Goalの定義 上位Goalに近づくために、現在分かっていることから判断した、 次のSprintで達成すべき最も価値のある状態 ＝ 事前計画の分割ではなく、いま持っている情報に基づく「次の一手」の宣言。 Sprint Goal & GitHub 07

検査と適応は、複数のGoalレイヤーで回る どんな価値・状態を実現したいのか。 最も外側の、最もゆっくり回るループ。 1 Product Goal 長期 2 Project・Phase Goal このPhaseで何を実現するか。 Product Goalへの中間地点。 数ヶ月 3 Monthly Goal 今月 今月どこまで進むか。 Roadmapを現実に合わせて調整する単位。 4 Sprint Goal 次の一手 最も内側で最も速く回るループ。 ここでの学びが外側のGoalへ伝わる。 アラインメントは上から下へ。学びは下から上へ。 Sprint Goal & GitHub 08

実際のやり方: MiroとGitHubの役割を明確に分ける ツールでGoalを分断しているのではなく、時間軸に応じた解像度で扱っている。 Miro GitHub Project 上位Goalと中長期のPath仮説 中長期視点 Sprint Goalと現在の実行Plan 短期視点 Product / Project Goal Sprint Goal / Backlog Items Monthly Goal Tasks / Status Candidate PBI・中長期のPath いま何をやっているかが分かる Sprint Goal & GitHub 09

Miroの役割: 現時点で考えているパス ロードマップを「この順番ですべて実行するProject Plan」として扱わない。 8月 9月 10月 Project Goal 直近ほど詳細で具体的、未来ほど粗い。時期が近づいたらRefinementする。経験主義。 Sprint Goal & GitHub 10

GitHub Kanbanの役割: Sprint Goals達成に向けた計画 Sprint Goals → Backlog Item → Tasks が可視化されていることが、今回のBoardの特徴。 Sprint Goals Backlog Items Tasks 最重要はスプリントゴール Goal #1 PBI Task 「このSprintで我々は何を達成しよう としているんだっけ？」 Goal #2 PBI Task Goal #3 PBI Task このPBIはまだ必要？ 別のことをやった方がいい？ このTaskはGoalに近づく？ 普通のKanban（Todo → Doing → Done）だと、Dailyの問いは「どのTaskが止まっている？」になってしまう。 Sprint Goal & GitHub 11

Sprint Planningでは「価値仮説」を作る スプリントプランニング＝スプリント単位の価値仮説づくり。 1 現在地を見る プロジェクトゴール＋Miro Roadmap＋前Sprintの学び＋現在の状況 2 Sprint Goalを決める 次のSprintで何が実現できれば、Goalに向けて最も価値のある前進か？ 3 Goal達成の計画を考える Miro上の候補を使ってもよいし、新しく作ってもOK 4 必要なところまでTask化 PBIごとに、いま必要な粒度でTaskへ降ろす PBIからSprintを組み立てるのではなく、Sprint GoalからPBI、Taskまで降りていく。 Sprint Goal & GitHub 12

Daily ScrumではSprint Goalに対する検査と適応 Daily Scrumは単なる進捗報告の場にしない ありがちなDaily Scrum 今回やりたいDaily Scrum PBI AのTask A どうですか？ Sprint Goalは達成できそう？ PBI BのTask B どうですか？ 現在最大のリスクは？ ◯◯さんの持ってるTaskは？ Backlog Itemは適切？ おさまらないから次に回しましょう 計画(PBI/Task)を変える必要は？ 見るのはTaskの進捗ではなく、Sprint Goalに対する現時点での計画の妥当性（検査と適応）。 Sprint Goal & GitHub 13

Sprint Reviewでは価値仮説を検証する Sprint PlanningとSprint Reviewを対にすると分かりやすい。 Sprint Planning Sprint Sprint Review 「これを実現すればGoalに近づけ るのでは？」＝ 価値仮説 Build / Learn 「実際どうだった？」→ 次の判断へ Reviewで問うのは「PBIを全部Doneにできたか？」だけではない Sprint Goalは達成されたか？ 仮説は正しかったか？ 何が分かったか？ PathについてMiroの何を変えるべきか？ その結果はMiroのRoadmapにも戻る（検査と適応）。 Sprint Goal & GitHub 14

全体のフィードバックループ OneHubチームのオペレーティングモデル プロジェクトゴール Miro Sprint Planning GitHub Project どこへ向かうのか 現時点のPath仮説 Sprint Goalと 達成方法の計画 Goal達成の計画ボード ▼ ▼ 3つの層へ適応 Sprint Review Increment Daily Scrum Plan / Roadmap / Product Goal 仮説を検証 動くもので学ぶ Sprint Goalの検査と適応 内側のループの学びが、外側のGoalレイヤーを更新していく。 ループは閉じている ─ 学びが必ずPlanとGoalに反映される。 Sprint Goal & GitHub 15

一番大事なメッセージ Sprint単位でもGoal、 アウトカムを意識的に目指し検査と適応を続ける。 Project / Product Goalは、私たちがどこへ向かうのかを示す。 Sprint Goalは、今分かっていることをもとに「次にどこまで進むか」を決める。 Backlog ItemとTaskは、そのGoalを達成するための現時点での最良の進め方にすぎない。 だから、最初にすべての作業を決めてそれを消化するのではなく、 Sprintごとに、そしてDaily Scrumのたびに、検査と適応を行う。 Sprint Goal & GitHub 16