# イテレーションの長さ ## 定義 ### イテレーションの長さとは イテレーションの長さ(iteration length)は、アジャイルプロジェクトが1回のイテレーションに割り当てる期間である。主要なアジャイルプロセスや、それを採用しているチームの多くは2〜4週間を標準としているが、あらゆる状況下のすべてのチームが使える長さというものは存在しない。チーム編成が同じであっても、プロジェクトが変われば適切なイテレーションの長さも変わりうる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]] §1 冒頭 p.181) ### イテレーションの長さを決める7つの要因(§1) イテレーションの長さを決めるにあたって考慮すべき要因は以下の7つである。各項目にあらかじめ定められた優先順位はなく、どの項目を重視すべきかはプロジェクトごとにまったく異なることもある。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]] §1) 1. **リリースまでの期間(§1-1)**: 短期間のプロジェクトなら、イテレーションも短いほうがよい。イテレーションの長さは、ソフトウェアをリリース可能な形で見せられる頻度、進捗を計測する頻度、プロダクトオーナーとチームが軌道修正できる頻度を左右する。著者の目安は、プロジェクト期間中にこうしたチャンスを少なくとも4、5回用意することであり、プロジェクト期間が4ヶ月以上なら1イテレーションを4週間や1ヶ月にしてもよい。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]] §1-1) 2. **不確実性の高さ(§1-2)**: 顧客・ユーザーの要望、チームのベロシティ、プロジェクトの技術的側面など、不確実性が高くなればなるほどイテレーションの長さは短くすべきである。イテレーションを短くすることで、ベロシティの計測やステークホルダーからのフィードバックを得る機会を増やせる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]] §1-2) 3. **フィードバックの得やすさ(§1-3)**: イテレーションの長さは、チーム全体へのフィードバックの量・頻度・即時性が最大になるように選ぶべきである。組織によって、非公式なフィードバックを得やすい/事前調整済みの正式なレビューに参加者を集めやすいの傾向が異なる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]] §1-3) 4. **優先順位が安定している期間(§1-4)**: プロダクトオーナーがイテレーション中に優先順位を変えず、外部の干渉からもチームを守れるようなイテレーションの長さを検討する観点。重要な検討ポイントは、よいアイデアが実際に動作するソフトウェアとして結実するまでにかかる時間である。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]] §1-4) 5. **外部からのフィードバックの必要性(§1-5)**: チームが外部からのフィードバックを得る頻度が低くなればなるほど、判断を誤る可能性が高くなり、誤ったときの損失も大きくなる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]] §1-5) 6. **イテレーションのオーバーヘッド(§1-6)**: イテレーションを繰り返すこと自体にかかるコスト(完全な回帰テストなど)がかさむなら、イテレーションを4週間と長めにしてもよい。成功しているアジャイルチームは、このコストを減らす(理想的にはゼロにする)ことを目標の1つにする。チームの初期段階のイテレーションは特にコストがかさみがちである。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]] §1-6) 7. **切迫感を感じ始めるまでの時間(§1-7)**: 期日が先になればなるほどプレッシャーを感じにくくなり、期日が近づくとプレッシャーを感じて一生懸命働くようになる(著者の同僚ニールス・マロタクスの指摘)。日々の作業で感じるプレッシャーの総和が、イテレーションの期間を通じて均一に分布するような長さを選ぶべきである。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]] §1-7) ### 図15.1: アイデアからソフトウェアになるまでの遅延 4週間のイテレーションを採用するチームで、新しいアイデアが一定の確率でイテレーション中のどこでも発生するとすると、平均するとイテレーションの真ん中で思いつくことになる。次のイテレーションで着手されるとすると、着手までに半イテレーション=2週間かかり、さらにそのイテレーション1回分=4週間でリリース可能なソフトウェアになる。合計すると平均6週間、すなわち1イテレーション(4週間)の1.5倍の時間を要する。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]] §1-4) ![[wiki/sources/_attachments/agile-estimating-and-planning-ja/ch15-fig15.1-idea-to-software-lag.png]] (図15.1 アイデアがソフトウェアになるまでには平均1.5イテレーションの時間を要する。Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]] §1-4) ### 長さごとのトレードオフと著者の推奨(§2) 著者が理想的だと考えるイテレーションの長さは2週間である。 - **1週間(あるいはそれ以下)**: 忙しすぎて気疲れする。次の締め切りが常に4日以内であり、メンバーの病欠やトラブルが起きても立て直す余裕がない。プロジェクトが完全に自動化された、システム全体をカバーするテストを備えている場合を除いて勧められない。 - **4週間**: 短いイテレーションに比べて創造的なソリューションを追求する時間的余裕がある。経験豊富なアジャイルチームで、プロジェクトに実験と探求が必要な段階なら使いこなせるかもしれない。ただし序盤・中盤・終盤という区別が生まれ、序盤はのんびりして終盤に慌てるという落差が生まれる。4週間にわたって優先順位を変えずに続けるのはかなり難しい。 - **2週間**: 計画とテストにかかるオーバーヘッドを分散させてならしやすい。1週目と2週目の違いは4週間の場合ほど大きくならない。大抵の組織は(きちんとトレーニングを積めば)2週間であれば優先順位を固定できる。 (Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]] §2) ### リズムを安定させる(§2 コラム) いったんイテレーションの長さを決めたら、それを維持したほうがよい。あまり頻繁に長さを変えるのはよくない。同じ長さのイテレーションを繰り返すうちにチームに自然なリズムが生まれる。著者は初期のSCRUMでイテレーションごとに長さを変えていた経験を振り返り、作業に合わせてイテレーションの長さを決めるよりも、イテレーションの長さに合わせて作業を決めたほうがずっとよいと学んだと述べる。同僚のサイモン・ベイカーは「規則的な鼓動が生命を保つのと同じように、長さの固定されたイテレーションはソフトウェアの開発(そして提供)に規則的なリズムをもたらす」と説明する。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]] §2 コラム「リズムが安定するまでイテレーションの長さは変えない」p.185) ### 「2×6+1」サイクル(§2 コラム) 2週間のイテレーションを果てしなく繰り返すと、チームが精神的な負担を感じることがある。この負担を軽減するテクニックが「2×6+1」サイクルである。2週間のイテレーションを6回繰り返した後に、1週間のイテレーションを挟む。2週間のイテレーションではプロダクトオーナーが優先順位づけした仕事をこなし、1週間のイテレーションではチームが自分たちで選んだ作業(リスクの大きいリファクタリング、使えそうな新規技術の調査、手動テストの自動化、検討不足なフィーチャの調査、技術的負債の返済など)に取り組む。通常のイテレーションから溢れた作業の後始末に使ってはならない。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]] §2 コラム「2×6+1」p.186) ### ケーススタディにみる長さの選択(§3) 著者は2つの実例(詳細の一部は変更済み)で検討要素の作用を示す。 - **ナパプロジェクト(§3-1)**: 7名編成、社内向けクライアント/サーバアプリケーション、期間13ヶ月と見積もられたプロジェクト。イテレーションの長さは4週間。プロジェクトが少なくとも6ヶ月続くと確信できたこと、不確実性がそれほど高くないこと(開発者全員が採用技術に経験あり)、CEOをはじめ経営層の注目により優先順位を4週間維持できたこと、ユーザーが3都市に分散し会社の急成長でユーザー接触の時間を取りにくかったことから4週間が選ばれた。 - **グッドマンプロジェクト(§3-2)**: 18名(2チーム)、エンタープライズ向け商用アプリケーション、期間1年、半年後に一部ユーザーへ事前リリース予定のプロジェクト。イテレーションの長さは2週間。プロジェクトの不確実性が高く(対象ユーザー・価格戦略の方針が二転三転)、社外に販売する商用製品で社内にユーザーがおらずフィードバックを得にくかったこと、優先順位が数日で変わってしまっていたこと、株式公開直後で切迫感の維持が重要だったことから2週間が選ばれた。テストの自動化によりイテレーションのオーバーヘッドを軽減できたことも、短いイテレーションを可能にした一因である。 (Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]] §3-1, §3-2) ### 四半期末を避ける(§3 コラム) イテレーションの終わりを月末に合わせると、3イテレーションごとに四半期末の決算と重なる。上場企業では四半期ごとの売り上げ目標達成に大きなプレッシャーがかかる。著者は、9ヶ月間で唯一のリリースを2000年3月31日に予定していたプロジェクトで、リリース直前にプロダクトオーナーが不在になったことなどが原因で1週間遅延し4月7日にずれ込んだ結果、当初3月31日に予定していた製品の売り上げが次の四半期に計上されることになった経験を紹介する。この経験以来、著者は月末にリリースする計画は立てないようにしている。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]] §3 コラム「四半期末を避ける」p.189) ## 横断的知見 - **『ウェブオペレーション』16章(2011年)は、運用チームのタスク管理にタイムボックス化されたイテレーションではなくカンバン(流れ・プルベース)を推奨しており、15章が体系化するイテレーション方式が万能ではないことを、対象領域を変えた独立ソースから示す**: 15章は、イテレーションの長さを決める7つの要因(リリースまでの期間・不確実性・フィードバックの得やすさ等)を挙げ、2〜4週間を標準としつつ状況に応じて調整する枠組みを提示する。この枠組みは開発チームのソフトウェア開発を暗黙の対象とする。一方『ウェブオペレーション』16章の著者(Andrew Clay Shafer)は、運用チームのタスク管理には「タイムボックス化されたイテレーション」よりも「すべてのタスクをカンバンボードで表現し、各ステージの進行中タスクを制限し、完了したものからプルベースで引き取る」カンバン方式が向いていると明言し、「ソフトウェア開発の考えがシステム管理に当てはまるとは思っていない。むしろ、当てはまるべきではないと思っている」と、開発向けのイテレーション計画をそのまま運用へ持ち込むことに慎重な立場を取る。両ソースを並べると、15章が精緻化する「イテレーションの長さ」という設計変数そのものが、対象がソフトウェア開発から運用(オペレーション)に変わると、タイムボックスという枠組み自体の妥当性が問われる場合があることが分かる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]] §1, §2, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 16 アジャイルインフラストラクチャ]] §16.2.1.14) - **『ウェブオペレーション』4章(2011)が一般理論として整理する「バッチサイズを小さくする4つの利点」は、本concept が扱う「イテレーションの長さ」・「カンバン対イテレーション」という2つの軸を、開発計画とデプロイという異なる工程で貫く共通の設計変数の存在を示す**: 本concept の既存知見は、15章の「イテレーションの長さを決める7つの要因」(開発計画の時間区切り)と16章の「カンバン(流れ・プルベース)対イテレーション(タイムボックス)」(運用タスク管理の方式)を対比してきたが、両者に共通する「作業をどれだけの単位でまとめるか」という設計変数そのものの理論的分析までは行っていなかった。[[バッチサイズ]] concept が集約する4章(エリック・ライズ)は、この設計変数を「バッチサイズ」として一般化し、小さくすることの4つの利点(フィードバックの速さ・問題の局所化・リスクの低減・オーバーヘッドの削減)を整理する。15章の7要因のうち「フィードバックの得やすさ」「イテレーションのオーバーヘッド」は4章の「フィードバックが早い」「オーバーヘッドを減らす」利点とほぼ対応しており、16章がカンバンを推す理由(タイムボックスに縛られない流れ)は、4章が主張する「バッチサイズは小さいほど良い」という極限をほぼそのまま体現する。イテレーション(時間で区切る一定のバッチ)とカンバン(バッチサイズを最小化する流れ)の対立は、4章の一般理論に照らすと「バッチサイズをどこまで小さくするか」という同一の軸の両端として位置づけられる。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] §4.1〜§4.4, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]] §1, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 16 アジャイルインフラストラクチャ]] §16.2.1.14) - **『LeanとDevOpsの科学［Accelerate］』第7章のWIP制限に関する実証知見は、16章が理論的に推すカンバン(進行中タスクの制限+プルベース)が「なぜ運用に向くか」を、大規模横断調査による定量データで補強する**: 本concept は、16章の著者が運用チームには「タイムボックス化されたイテレーション」よりも「各ステージの進行中タスクを制限しプルベースで引き取る」カンバンが向くと明言することを記録してきた。Accelerate 第7章は、WIP制限を「リーン思考の実践コミュニティでおなじみの手法」と位置づけ、「WIP制限が単独ではデリバリのパフォーマンスの有力な予測尺度になりえない」こと、ビジュアルディスプレイおよびモニタリングツールからのフィードバックループとの併用で初めて強力な効果を発揮することを、業種・組織規模を問わない大規模調査で実証する。16章はカンバンが運用に向く理由を「ソフトウェア開発の考えがシステム管理に当てはまるとは思っていない」という定性的な立場から述べるにとどまるが、Accelerate 第7章はWIP制限(カンバンの中核要素)の効果を統計的に検証しており、単独運用ではなく可視化・フィードバックとの併用が前提条件であることを明示する点で、16章が触れなかった「カンバンが機能するための付帯条件」を補う。ただし Accelerate 第7章はソフトウェア開発チーム一般を対象としており、16章が論じる「開発対運用」という対象領域の違いには踏み込まない。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 7 ソフトウェア管理のプラクティス]] ch.7 §7.1, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 16 アジャイルインフラストラクチャ]] §16.2.1.14) ## 未解決の問い - 複数チームが協調して1つのリリースを開発する場合、すべてのチームが同一のイテレーションの長さを採用すべきかは本章では明示されていない。18章「複数チーム編成プロジェクトの計画づくり」で扱われる可能性がある。 - 7つの要因が互いに矛盾する結果を示唆する場合(例: 不確実性の高さは短いイテレーションを求めるが、イテレーションのオーバーヘッドの大きさは長いイテレーションを求める)、優先順位をどうつけるかは「あらかじめ定められた優先順位はない」とされるのみで、具体的な判断基準は示されていない。 - イテレーションの長さの選択がベロシティの見積り精度にどう影響するかは、16章「ベロシティの見積り」の担当範囲であり、本ページはまだ扱っていない。 - カンバン(流れ・プルベース)とイテレーション(タイムボックス)のどちらを選ぶべきかを分ける条件は何か。『ウェブオペレーション』16章は運用対開発という対象領域の違いを理由に挙げるが、15章の7つの要因(不確実性・フィードバックの得やすさ等)のうちどれがカンバン/イテレーションの選択に対応するかは、本ページの現ソース群では未整理。 ## 関連 - 概念: [[イテレーション計画づくり]] / [[リリース計画づくり]] / [[DevOps]](カンバン対イテレーションの対比の背景) / [[バッチサイズ]](イテレーションの長さ・カンバンを貫く一般理論) / [[リーンマネジメント]](WIP制限の実証データをハブとして集約するconcept) - 書籍: [[wiki/entities/アジャイルな見積りと計画づくり|アジャイルな見積りと計画づくり]] - source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 16 アジャイルインフラストラクチャ]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] / [[@2018__Impress__LeanとDevOpsの科学 - Chapter 7 ソフトウェア管理のプラクティス]] ## 出典 - Mike Cohn 著, 安井力・角谷信太郎 監訳, 『アジャイルな見積りと計画づくり』, マイナビ, 2009, 15章. - Nicole Forsgren, Jez Humble, Gene Kim 著, 武舎広幸・武舎るみ 訳, 『LeanとDevOpsの科学［Accelerate］』, インプレス, 2018, 第7章(WIP制限の実証効果)。 - アンドリュー・クレイ・シェーファー, 「アジャイルインフラストラクチャ」, 『ウェブオペレーション ―サイト運用管理の実践テクニック』, オライリー・ジャパン, 2011, 16章, §16.2.1.14. - エリック・ライズ, 「継続的デプロイ」, 同書, 2011, 4章, §4.1〜§4.4.