アジャイルにおけるイテレーションの期間を変更する影響とは？
今回は、アジャイルのイテレーション（開発期間）についての記事になります。
皆さんは、アジャイルのイテレーション（開発期間）をどのようにお考えですか？一度決めた期間をあとから変更してよいのかどうか悩まれたことはないでしょうか。影響度を把握しておくことで判断にも自信がもてます。
今回は、イテレーションの期間を変更する影響について解説していきたいと思います。
アジャイルのイテレーション（開発期間）とは
アジャイルは、固定の開発期間を設け、この期間を繰り返しながら進めます。この期間をアジャイルでは、”イテレーション”と呼びます。（スクラムでは、スプリントと呼びますが同義です）
イテレーションは、１週間〜２ヶ月という単位が一般的です。（スクラムガイドでは、スプリントは１ヶ月以内と定義されています）
イテレーションを設ける主な目的は、プロジェクトの最終目的を把握し、最短で変化に適応しながら到達するためです。そのために各イテレーション内に４つのイベントを設け、透明性を保ちながら検査と適応を繰り返し、開発を進めます。（スクラムガイドでは、検査と適応のための４つのイベントを包含したものをスプリントと定義しています）
イテレーションの期間が長すぎると、頻繁にイベント（特に過去と未来を見直すイベント）を回すことができないです。また、複雑さが増し、手戻りや機会損失等も含め、プロジェクトのリスクを高める可能性があります。
ちなみに下図は、開発手法別のプロジェクト規模における成否の相関表です。規模が大きくなることによってリスクが高まることはアジャイルにおいても同じです。
例をあげるなら、旅中に目的地に向かって正しく進めているかを地図上で確認するようなものです。定期的にこれまでの進路が問題なかったか、より早く進むために改善の余地があるか、今後の進行方向が目的地の方角と合っているかなどを確認します。ひょんなことから目的地が当初から大きく変わるかもしれません。そのような場合であっても定期的に確認していれば対応できます。
この正確な情報を取得し、現状の確認や改善点の洗い出し、今後の計画を検討することが、イテレーション内のイベントに該当します。そして一連のイベントを行うサイクル（期間）が、イテレーションというわけです。
１歩１歩進むたびにこのイベントを行っていたら、たまったものではありません。また、目的地目前と思われるところで現状を確認し、目的地と真逆に進んでいたと分かれば、これまでの努力が徒労に帰すわけです。
したがって、時宜を得たイベントの実施時期（ひいては、イベントを包含する期間）というのは、”ちょうど良い頃合い”を見計らって行うということになります。
この”ちょうど良い頃合い”というのは、プロダクトやチームの規模、求められる品質などを考慮する必要があるため、一概に決められません。ちなみに私の経験上は、２週間単位のイテレーションで行っている企業が多い印象です。
イテレーションの期間を変更する影響とは？
イテレーションの期間を変更する局面は、大きく２つあります。アジャイルに取り組み始めた初期における変更とアジャイルに慣れた安定期における変更です。
アジャイル導入初期における開発期間の変更
アジャイルに取り組み始めると、数回イテレーションを実施したところで期間を変更しようか悩まれる方が多いです（結果として期間を延ばすことが多い）。よくある理由は、イテレーション内に開発やイベントが間に合わないためです。
期間を変更する際のポイントは、前述の”ちょうど良い頃合い”をどのように判断するかということです。以下のカテゴリごとに改善の余地があるのであれば、改善後の判断が適切だと考えています。
・各イベントの実施方法（例：デイリースタンドアップを１５分以上続けている）
・開発および作業方法（例：過剰なドキュメントを作成している、個々人で開発していてブラックボックス化している）
・バックログアイテムの粒度（例：タスクボードのタスクが数日間動いていない）
・その他ボトルネック（例：指示待ちのメンバがいる、タスクの選り好み）
これらの項目に改善の余地があるということは、そもそもアジャイル（スクラム）を適用できていないことが考えられます。アジャイル（スクラム）を適用できていないという理由で、イテレーションの期間を延ばすというのはナンセンスに感じます。
これは基本の型が身についていない状態で技の練習時間を延ばしたところで非効率なのと同じ考えです。基本の型を習得していた場合、技の習得にかかる時間は、シンプルにその技の難易度などを考慮しながら見込んで取り組むことができます。したがって、型を習得したうえで、”ちょうど良い頃合い”を判断することを推奨します。
アジャイル（スクラム）の型を習得したうえで（上記を改善したうえで）、どうしてもイテレーション内に収まらない場合は、変更も致し方ないと思います。具体的には以下です。
・プロダクトに求められる品質基準レベル的に設計書やテストに費やす時間を増やす必要がある場合
・スクラムチームが増えたため、リリース前に必要なチーム間のインテグレーションにかかる時間を確保する必要がある場合
・チーム全体の開発スキルを考慮する場合 など
アジャイル導入後の安定期における開発期間の変更
アジャイルに取り組み始めて月日が経ち、運用が安定してきた頃にイテレーションの期間を変更することがあります。
退職や異動などの事情などにより経験者が抜け、補填に勉強も兼ねた若手がジョインする場合などは良い例です。この場合、チーム全体のスキルとベロシティが下がるので期間を変更しようとする気持ちが働きやすいのでしょう。
これまで安定したアジャイル開発を実施できているチームにおけるイテレーション期間の変更は極力しないことを推奨します。理由は、これまでのベロシティが使えなくなるからです。これによって過去との比較および今後の見通しが難しくなります。
ベロシティというのは、イテレーションで消化したストーリーポイント（機能の規模）のことです。各イテレーションのベロシティから全体のベロシティ平均値を算出することができます。ベロシティ平均値を用いて今後必要なイテレーション数を見通すことができます。
必要なイテレーション数＝予定しているストーリーポイントの合計値／チームのベロシティ平均値
しかし、イテレーションの期間が変わってしまうと、過去のベロシティと単位が一致しないため、用いることができなくなってしまうのです。（１日あたりのベロシティを算出したうえで計算する手もなくはないですが）
イテレーションの主な目的は、プロジェクトの最終目的を把握し、最短で変化に適応しながら到達するためだと冒頭で述べました。この目的には、ベロシティから今後のイテレーション数を見通すことも含まれているということを意識する必要があります。
（補足）全てのイテレーションでリリースする必要があるかどうか
そもそも全てのイテレーションでリリースする必要があるかどうかという点ですが、基本的にリリースする前提になります。ただし、リリースをしないイテレーション（技術的負債を消化するためのイテレーションなど）が必要になる場合もあるため、リリースがマストということでもありません。
そのため、一定の基準を設けている会社もあるようです（例：全体の80％はリリースする）。この基準は、イテレーションの期間および運用状況を見直すキッカケとしても有効です。
イテレーションの期間を変更する影響まとめ
イテレーションの期間を変更する局面は大きく２つあることをお話しました。
・アジャイル導入初期における変更
・アジャイル導入後の安定期における変更
アジャイル導入初期における変更は、アジャイルを正しく運用できていないことによってイテレーション内に間に合わないことが多いです。期間を変更する前に一度アジャイルの活動自体を見直したほうが良いです。
安定期における変更は、変更することによって過去のベロシティを用いることが難しくなります。メリットとデメリットを天秤にかけて判断する必要があります。
変更による影響度を把握し、自信をもって判断できるようになりたいですね。
【合わせて読みたい】
ーーーーーーーーーーーーーーーーーー
いかがでしたでしょうか。
ぜひスキとフォローもお願いします！
では、また！
※本記事の内容は個人の見解であり、私が所属する組織とは一切関係ありません。
この記事が気に入ったらサポートをしてみませんか？