スクラムの「スプリント」はなぜ2週間なのか：Jeff Sutherland『SCRUM』

スクラムを導入したはずなのに、チームのスピードが上がっていない——この状況は珍しくない。多くの場合、スクラムの「型」は実装されているが、各儀式の「意図」が理解されていないことが原因だ。

Jeff Sutherland の『SCRUM 仕事が4倍速くなる世界標準のチーム戦術』は、スクラムの共同考案者が書いたビジネス書だ。技術的なプラクティスの解説よりも、なぜそのプラクティスが有効なのかという背景に多くのページを割いている。

1. スプリントの長さはなぜ重要か

2週間のスプリントは慣習ではなく、心理的な設計だ。

1週間だと計画と振り返りのオーバーヘッドが大きくなりすぎる。1ヶ月だと方向修正が遅くなる。2週間は「集中して動く」と「立ち止まって学ぶ」のバランスが取りやすい単位だ。

スプリントの終わりに「動くソフトウェア」を届けることを義務づけるのは、完成の定義を曖昧にしないためだ。「80%完成」は存在しない——動くか動かないか、という判断基準にする。

flowchart LR
    PB["プロダクト\nバックログ"] --> SP["スプリント計画\n（2週間単位）"]
    SP --> DEV["開発\n（デイリースクラム）"]
    DEV --> REV["スプリント\nレビュー\n動くものを届ける"]
    REV --> RET["レトロスペクティブ\n（振り返り・改善）"]
    RET --> PB
    style SP fill:#e8f4fd,stroke:#4a9eda
    style DEV fill:#e8f8e8,stroke:#4caf50
    style REV fill:#fff8e1,stroke:#f5a623
    style RET fill:#f3e5f5,stroke:#9c27b0

2. デイリースクラムの3つの問い

毎日15分の同期ミーティングには3つの問いがある。

• 昨日、何を達成したか
• 今日、何をするか
• 障害になっているものは何か

3つ目の問いが機能しているかどうかが、チームの成熟度を測る指標になる。障害を公言できる環境があるかどうか、そして障害が報告されたときに即座に取り除く仕組みがあるかどうかが問われる。

障害を報告したが何も変わらなかった経験が積み重なると、チームはこの問いに正直に答えなくなる。

3. ベロシティの意味

チームが1スプリントで完了できる作業量（ベロシティ）を計測する目的は、予測にある。

ベロシティは「早く働く」ために使うのではない。過去の実績から未来を見積もるための尺度だ。チームAのベロシティとチームBのベロシティを比較しても意味がない。同じチームの時系列変化を見ることで、改善の傾向を把握する。

ベロシティが下がったとき、それは問題のシグナルだ。上位からの圧力でベロシティの数字を操作するチームは、この早期警戒機能を失う。

4. レトロスペクティブが「学ぶ組織」を作る

スプリント終了時に行うレトロスペクティブ（振り返り）は、チームの改善メカニズムだ。

うまくいったこと・うまくいかなかったこと・次のスプリントで試すことを議論する。重要なのは「試すこと」を1つ決めて実行することだ。問題を発見して終わりにしないこと、また改善策を多く挙げすぎて何も実行しないことを避ける。

本書が「幸福度（ハッピネス指数）」として紹介する概念も印象的だ。チームメンバーの幸福度を定期的に計測し、生産性との相関を見る。幸福度が下がるとベロシティが下がる傾向があり、逆に言えば幸福度を維持することが持続的な生産性に直結する。

5. 「マルチタスクは罪」という主張

本書が繰り返し強調するのは、同時進行プロジェクトのコストだ。

2つのプロジェクトを並行するとき、切り替えのコスト（コンテキストスイッチ）によって実質的なアウトプットが下がる。本書はこのコンテキストスイッチのコストを複数の研究から示している。

集中することをチームの設計として実装する——それがスプリントの構造だ。

6. この本が効く場面

「デイリースクラムが進捗報告会になっていて、障害が上がってこない」「ベロシティを上に報告したら来週は倍にできるかと詰められた」——スクラムの型は入れたのに速くならないと感じるとき、詰まっているのはプラクティスの手順ではなく、その意図の共有であることが多い。

本書は各儀式が「なぜ有効か」を背景から説明する。読む前は「2週間スプリントもデイリーも回しているのに成果が出ない」と原因を切り分けられなかった状態から、読後は「うちのデイリーは3つ目の問い（障害）が機能していない」「ベロシティを操作して早期警戒を失っている」と、形骸化しているのはどの儀式のどの意図かを名指しできるようになる。

7. 向いている人・向いていない人

向いている人:

• スクラムの型は導入済みだが、デイリーやレトロが形骸化していると感じるスクラムマスター・チームリーダー
• 「なぜこの儀式をやるのか」をメンバーやマネジメントに説明する言葉を持ちたい人
• スプリントの長さやベロシティを慣習として受け入れていて、その設計意図を掴みたい人

向いていない人:

• スクラムの導入手順・ツール操作・見積もり技法の逆引きを今すぐ知りたい人。本書は技術的なプラクティスの解説より、なぜ有効かという背景に紙幅を割くため、手順書としては物足りない
• 各儀式の原理まで理解して実践しているチーム。本書の主眼は意図の腹落ちにあり、そうした読者には再確認が中心になる

8. 読んだ後の最初の一歩

読み終えてすぐ試せる行動を、本書の主張に沿って1つに絞ると効果が出やすい。

まず次のデイリースクラムで、3つの問いのうち「障害になっているものは何か」だけに注意を向けてみる。報告された障害が翌日までに実際に取り除かれたかを追い、取り除かれていなければ、それを取り除く担当と仕組みを決める。これは本書が指摘する「障害を報告しても何も変わらない経験が積み重なると、チームは正直に答えなくなる」という悪循環への具体的な対処になる。

もう一段進めるなら、進行中のプロジェクトやタスクを数え、コンテキストスイッチが起きている箇所を1つ減らす。レトロでは改善案を1つだけ決めて次スプリントで実行し、多く挙げて何もしない状態を避ける。

9. よくある誤解

「4倍速くなる」というタイトルから、スクラムの型を導入すれば自動的に生産性が上がると読まれがちだ。本書の主張はむしろ逆で、速さは各儀式の意図を理解し「集中」をチームの構造として設計した結果として生まれる。型だけの導入では効かない。

ベロシティも誤解されやすい。数字を上げること自体が目的化すると、上位への報告のために操作が起き、問題を早期に知らせる警戒機能が失われる。本書のベロシティは「速く働く」ための号令ではなく、過去の実績から未来を見積もるための尺度だ。

もう一つは、マルチタスクを能力の高さと捉える見方だ。本書はコンテキストスイッチのコストを研究から示し、並行作業は実質的なアウトプットを下げると述べる。

筆者の体験から

テックリードとしてスクラムを導入して半年ほど経った頃、型は回っているのに速くなっている実感がなく、デイリースクラムは進捗報告会と化し、レトロスペクティブも「うまくいかなかったこと」の列挙で終わる状態が続いていた。共同考案者本人が書いた本だと知り、手順ではなく根本を勘違いしているのではと思い読んだ。

読後、デイリーの3つ目の問い「障害になっているものは何か」に注目し、出た障害を翌日までに解消したか自分で追い、担当を決めて対処するようにした。レトロも「次に試すこと」を1つに絞るルールに変えたところ、実行率が明らかに上がった。

一方で「マルチタスクは罪」という主張は、少人数チームでは兼任せざるを得ない現実との折り合いが必要だと感じている。幸福度の計測も試したが、質問項目がすぐ形骸化してしまった。

読んだ直後のデイリーで、若手が特定環境のセットアップで詰まっていると3つ目の問いで初めて口にした場面が印象に残っている。担当を決めて翌日確認するようにしただけで、以降の障害の申告が明らかに増えた。

---

本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。