---
title: Sprint Goal! アウトカム思考のMiro&GitHub活用術
tags:  #アジャイル #スクラム #スプリントゴール  
author: [Takahiro Ito](https://docswell.com/user/TakahiRoyte)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/K74WP2XPE1.jpg?width=480
description: Sprint Goal! アウトカム思考のMiro&GitHub活用術 by Takahiro Ito
published: August 21, 26
canonical: https://docswell.com/s/TakahiRoyte/Z9NLPL-sprint-goal-miro-github
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/K74WP2XPE1.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/LJ1Y9MNXEG.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/GJWGQ34K72.jpg)

ゴールへの経路は、最初には仮説でしかない
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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/4EZLWV2N73.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/Y76WG5V97V.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/G75MVYDD74.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/9J293YMMER.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/DEY41GXPJM.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/VJNY2G1M78.jpg)

実際のやり方: 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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/YE9P1W5WJ3.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/GE8D4NYRED.jpg)

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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/LELM6P427R.jpg)

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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/4JMY54K9JW.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/PJR93WX979.jpg)

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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/PEXQ4P63JX.jpg)

全体のフィードバックループ
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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/3EK9ZD1NED.jpg)

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