スクラムの内側より外側で決まる、「何を作らないか」
スクラムは強いフレームワークです。ただ、スプリントが順調でも、そもそもやるべきだった仕事とは限りません。Scrum.org の資料では、プロダクトゴールがチームに焦点を与え、プロダクトバックログの文脈を提供する、と説明されています。同時に、プロダクトゴールが曖昧だと何が起きるかも繰り返し語られています（公式ブログ）。私は企画・要件定義・スクラムのリードに関わるなかで、プロセスの健康とプロダクトの健康を同列にしないようにしています。 スクラムが回っているのに空回りするチームには、だいたい共通点がある。外側の約束が一行も書けていない。
スクラムイベントが回っているのに成果が薄いとき、原因はメンバーの努力不足ではなく、外側で決まっていない約束であることが多いです。何を作らないか、誰のためのプロダクトか、いつまでに何を学ぶか。ここが宙に浮いたまま、バックログは増え続けます。本稿は、スクラムの「内側」より前に置く焦点の守り方と、現場で使った問いです。
プロセスが健康でも、プロダクトが迷子になる理由
スプリントの完了は「正しさ」の証明ではない
完了は、やるべきことをやった証拠に過ぎません。やるべきだったかは別問題です。私はスプリントレビューで、デモの前にプロダクトゴールを一文読み上げる時間を十秒だけ取りました。
プロダクトゴールが曖昧なときに起きること
曖昧さは、バックログの膨張として現れます。私はウィッシュを別ビューに隔離し、月一でしか合流させないルールにしました。
「作らない」を儀式にする
今週捨てたことを先に称賛する
増やした話ばかりだと、チームは疲れます。私はレトロで、捨てた・延期したを先に称賛しました。
Ready は学びを遅らせていないか
遅らせているなら、細部の取り方を疑ってください。
スケールの前に単一チームの焦点
チームを増やすほど、プロダクトゴールの翻訳コストが上がります。私はスケールの前に、一チームでプロダクトゴールを一枚にできるかを確認しました。
まとめ
スプリントの速さは、方向の正しさを証明しない——ただの燃費だ。
スクラムは手段。目的はユーザー価値と事業の持続。内側を磨く前に、プロダクトゴールと作らない約束が揃っているかを疑え。順番が違うと、どれだけ丁寧にスプリントを回しても空回りする。
計画の前に十五分。「プロダクトゴールに背いているバックログ項目はどれか」——声に出して読む。違和感が言葉になる。うまくいかなかった週のメモのほうが、四半期の資産になる。
仕上げのための自問（現場メモ）
記事にするほどではないが、私が自分用に残している自問です。全部に答えなくてよいです。
いまの議論は、次の一週間の行動に落ちるか
落ちないなら、まだ抽象度が高い。
反対意見を一行で言語化できるか
言えない反対は、ただの不安であることが多いです。
休む予定を入れたか
持続可能性はスローガンではなく、カレンダーの実装です。
参考・出典
- Scrum.org, Product Goal, https://www.scrum.org/resources/product-goal （参照: 2026-04-06）
- Scrum.org, "The Product Goal is Not... The Product Goal is...", https://scrum.org/resources/blog/product-goal-not-product-goal （参照: 2026-04-06）
- Scrum.org, "27 Product Backlog and Refinement Anti-Patterns", https://www.scrum.org/resources/blog/27-product-backlog-and-refinement-anti-patterns （参照: 2026-04-06）