🔁

改めて、Agileのことを勘違いしていた。イテレーションの長さに対する違和感の正体

に公開
2026/01/09
agile
idea

前置き

こういった本を読んだり、チームで輪読したりしながらAgile開発の実践を試みています。

本記事は、弊チームのイテレーションの長さに対する違和感を言語化したものです。

本記事に、AIが生成した文は含まれていません。

「イテレーションの長さは2〜4週間」

Agile黎明期の名著 (およそ2000年代の出版) を読んでいると、イテレーションの長さは2〜4週間を想定していることが多い。例えば、Agile Estimating and Planning の Chapter 15, "Selecting an Iteration Length" は以下の文章から始まる。

The majority of the agile processes, and teams using them, have settled on iteration lengths of two to four weeks. Some teams use longer iterations but two to four weeks is an accepted standard for most teams.

一方で、これまで私が所属してきた多くの開発チームでは、1週間イテレーション (あるいは "スプリント") を採用してきた。

私はこの長さの差を、開発効率の向上によるものと解釈していた。つまり、当時から約20年が経過した現代では、計算機の性能向上、パッケージマネージャーやコンパイラ等のエコシステムの発展、CI/CD支援ツールの充実、より良い開発プロセスの普及といった様々な要因により、1週間でも十分にまとまった成果が得られるようになったと考えていた。

それもあるとは思うが、見えていなかった要素がある。

その期間で出した成果に意味があるか

一言で言えば、イテレーションの成果が細かすぎた。

理想的なAgileチームは、イテレーションを終えたとき、ユーザーはどのようなことができるようになったか、プロジェクト全体に対してどれくらい進捗したか、という問いに対する答えを持っているはずである。弊チームでは、イテレーションを終えてもこの問いに明確に答えられないことが少なくなかった。

各イテレーションで取り組むことは、単なるタスクではなく、それ単体で誰かにとって価値となる単位に切り分けている。そのため、それらを無事に終えていれば、何かしらの価値は生まれている。

しかしながら、1週間で完了できる単位に切り分けるために、必要以上に細かく分割している場合もあった。それを完了したとき、たしかにユーザーができることは増えているが、本当はユーザーが達成したい大きな流れの中の一部ができるようになっただけである。このような状況では、イテレーションの成果物に対して十分なフィードバックを得ることができず、それを元にした新しい意思決定をすることも難しい。

私の中では、Manifesto for Agile Software Development に書かれている "Working software" の working という単語が、単に「動く」という意味ではないという話とも繋がった。

また、感覚的な話ではあるが、十分にまとまった単位に取り組まないと、そのイテレーションにコミットすることの難易度が上がる。イテレーションゴールが端的に表現できないからである。ここで言うゴールとは、イテレーションで達成すべきことを述べた文である。ゴールはシンプルな方がチームで覚えやすく、チームの指針としやすい。細か過ぎる単位をゴールにしようとすると、それを表現するためにたくさんの言葉を重ねる必要が生じる。端的な言葉で表現されていないゴールは忘れ去られ、判断に使うことができない。

ユーザーができることがすこしでも増えればいいというわけではない。十分にまとまった価値を提供しないと意味がない。以前から知っていたことではあるが、実際にやってみると分割の単位は非常に難しい。

以上を踏まえると、より長いイテレーションを想定して然るべきだという気持ちになってきた。

適切なイテレーションの長さの選び方

あらゆるプロジェクトに適用可能な固定の長さは存在しない。適切なイテレーション長の選び方には、先ほども引用した Agile Estimating and Planning の Chapter 15, "Selecting an Iteration Length" が参考になる。

※ なお、最近のWeb記事等を参照すると1〜4週間を推奨していることが多い。

Discussion