ブログ

ryuzeeによるブログ記事。不定期更新

アジャイルコーチはなぜ1週間スプリントを勧めるのか

みなさんこんにちは。@ryuzeeです。

職業柄スクラムを始めたばかりのチームを支援することがよくあります。 そのような状況で、ロールの明確化や初期のプロダクトバックログの準備とあわせて話題にのぼることが多いのが、スプリントの期間をどうするかです。 そして、多くの場合、1週間スプリントを提案しています。 今回はなぜ1週間スプリントが良いのか見ていきましょう。

1週間スプリントがよい理由

1週間スプリントがよい理由を列挙すると以下のようなものがあります。

  1. レトロスペクティブ(ふりかえり)が頻繁にあるので改善が進む
  2. 計画の精度が高くなる
  3. 例え失敗しても一週間で済むので実験しやすい
  4. ベロシティの数字がすぐ出るのでやる気になる
  5. 中だるみする余裕がない・リズムがよい
  6. 一週間で収まるサイズのプロダクトバックログアイテムにするので明確な完成を定義しやすい。従ってプロダクトオーナーの受け入れを取りやすい
  7. スパイクが必要なプロダクトバックログアイテムが明確になる
  8. プロダクトオーナーが変更を我慢しやすい
  9. ごまかしが効かない

順番に見ていきましょう。

レトロスペクティブ(ふりかえり)が頻繁にあるので改善が進む

大きな理由の1つがレトロスペクティブの回数です。 たとえば、スプリントに使える期間が3か月だとすると、4週間スプリントはスプリントが3回、2週間スプリントで6回、1週間スプリントで12回となります。 改善の基本的な考えとして、うまくいったかどうかを判断しうまくいかない場合は元に戻す、一度にたくさんのことを変えないという点が挙げられます。 つまり毎回劇的な変化を加えるのではなく緩やかに変化していくことになります。 このとき改善の機会が少なければ少ないほど、試行錯誤して改善する機会が減ってしまい、最初と最後での変化は少なくなってしまいます (言い換えると上手くなる前に期限が来てしまいます)。 したがって、慣れていないうちほど、改善の機会をたくさん用意した方がよく、短いスプリントの方がその機会は多くなります。

計画の精度が高くなる

計画づくりは難しいです。もちろん見積りも難しいです。 そしてこれらは規模が大きければ大きいほど難易度が上がります。 また、始めたばかりの段階だと、スクラムチーム全体がやり方に慣れていない、過去にどれくらいの速度で開発できていたのかというデータがないといった要因も、影響を与えます。 したがって、特に慣れるまでは、なるべく小さい単位で計画をたてて、計画と実際の差がどのくらいなのかを見ながら微調整していくことが重要になります。 1週間の計画を立てられないのに4週間の計画を立てられるということはないので、まずは短い範囲でいいので確度の高い計画を立てられるようにしてください。 そうすることで、プロダクトオーナーはプロダクトの今後の見込みや予測をしやすくなります。 予測がしやすければしやすいほど、ビジネス面での計画も立てやすくなります。

例え失敗しても一週間で済むので実験しやすい

計画の精度が高くなる、というのと多少相反しますが、万が一そのスプリントが何らかの理由でうまくいかなかったり、成果が少なかった場合でも、スプリントの期間が短ければ短いほど影響は少なくなります。 あるプロダクトバックログアイテムでいろいろハマってしまい、想定の時間以上をかけても完成しなかった場合のことを考えてみましょう。 この場合、スプリント期間が長いと延々とハマってしまい、長いタイムボックスを使いきってしまうリスクもあります。 一方で、1週間スプリントの場合は、すぐにスプリントが終了します。 そして着手中だろうがあとすこしで終わりそうだろうが強制的に当該プロダクトバックログの作業は停止されます。 仕掛中のプロダクトバックログアイテムについては、次のスプリントで継続して取り組むのか、それとも先送りにするのか、もうやめるのかを判断する機会もあります。 そう考えると短いスプリントの方がリスクが少ないことが分かります。

また、同様の理由で、プロダクトオーナー側の観点としても、挑戦的なプロダクトバックログアイテムをスプリントに投入しやすくなります。

ベロシティの数字がすぐ出るのでやる気になる

これは大した理由ではないのですが、スプリントが短いとベロシティの数値がすぐに見える化されます。 過去のベロシティとすぐに比較できるので、成長を実感したり停滞に気づいたりするのが簡単になります。

中だるみする余裕がない・リズムがよい

1週間スプリントでは、例えば以下のような週間スケジュールになります。

  • 水曜日午後にスプリントプランニングを2時間のタイムボックスで実施し、完了後に夕方からスプリント開始
  • 金曜日か月曜日くらいにプロダクトバックログリファインメントを実施して次のスプリントを準備
  • 火曜日の夕方に翌日の準備をして、水曜日の午前中にスプリントレビューを1時間、スプリントレトロスペクティブを1〜2時間実施

毎週同じ曜日の同じ時間にイベントが行われることになるので、スケジュールを考えたり調整したりする必要がなく、リズムが出やすくなります。 イベントをオープンスペースでできないような場合でも、単純に毎週繰り返しで会議室予約をしておけばよいだけです。 何曜日の何時くらいにどういう状態だったら、マズイとか大丈夫そうだ、というのも分かりやすくなります。 スプリント期間が長くなると、スプリントプランニングのあとや翌日などはペースダウンしがちです。 またスプリントの後半に向けて追い上げ型にもなりがちです。 ところが、1週間の場合は後半も何も、そもそも時間が短いので追い上げが効かず、いつも同じペースで着実にこなしていくことになります。

一週間で収まるサイズのプロダクトバックログアイテムにするので明確な完成を定義しやすい。従ってプロダクトオーナーの受け入れを取りやすい

スクラムでは、スプリント単位で、完成の定義と受け入れ基準にしたがってプロダクトバックログアイテムを完成させなければいけません。 プロダクトバックログアイテムが大きいので、複数スプリントにまたがって1つのプロダクトバックログアイテムに着手しようとしてはいけないのです。 つまり、スプリント期間が短ければ短いほど、プロダクトバックログアイテムのサイズは小さくなるのが普通です (1つのスプリントに投入するプロダクトバックログアイテムが1つということはなく、大きくてもスプリント期間の半分以下で終わるようなサイズのプロダクトバックログアイテムを複数個投入するのが一般的です)。 時間が短くプロダクトバックログアイテムが小さいということは必然的に中身が明確であることにつながります。

スプリントに投入したプロダクトバックログに関してスプリント開始後にたくさん不明点が出てくるような状況だと、そのプロダクトバックログアイテムは完成しない確率が高くなります。 長いスプリント期間であれば、とはいえ、なんとか頑張って吸収するということができるかもしれませんが、それは本来やるべき事前準備不足を隠してしまうことにもなります。 一方で、1週間スプリントだと、もし不明点がでてその時すぐにプロダクトオーナーと会話ができないような待ちが発生するとどうにもならなくなります。 したがって、プロダクトバックログリファインメントで事前に次以降のスプリントに投入される可能性のあるプロダクトバックログアイテムが本当にReadyなのかを精査するようにもなります。 そして1週間の半分くらいの規模のプロダクトバックログアイテムであれば、「なにができれば完成なのか」の認識は比較的容易に合わせられるはずです。 認識があっていれば、プロダクトオーナーの受け入れ確認も容易になります。

スパイクが必要なプロダクトバックログアイテムが明確になる

上の項目に関連して、スプリント期間が長いほど、あるプロダクトバックログアイテムを実装するのにあたって、調査系のタスクも一緒に含めてしまいがちです。 完成とは何なのかは合意できていても、それをどうやるのかはスプリントに入ってから調査して進めていってしまうのです。 一方で、1週間スプリントのような短い期間では、特定のプロダクトバックログに関する調査をスプリントに入ってからやっていたのでは、プロダクトバックログアイテムが完成しないリスクが高くなります。 つまり事前に調査まで終わらせておいて、開発チームが自信をもって作れる状態までもっていくような力が働きます。 プロダクトバックログリファインメントなどで、調査が必要なプロダクトバックログアイテムを明らかにして、バッファを使って事前調査したり、場合によってはプロトタイプなどを作るプロダクトバックログ(タイムボックス上限を定める)を事前にこなすようになっていきます。 こうすることで、プロダクトバックログアイテムがスプリント期間中に完成する確率が上がっていきます。

プロダクトオーナーが変更を我慢しやすい

プロダクトオーナーはステークホルダーと協働し、開発チームのパフォーマンスを踏まえて、プロダクトをどうしていくかシビアな判断が必要になります。 そして、ビジネスの状況は刻一刻と変化します。 長いスプリントになればなるほど、ステークホルダーからの要求やビジネスの状況との乖離の影響を受けて、プロダクトバックログアイテムを入れ替えたいという欲求が強まります。 一方で、スプリント期間中のプロダクトバックログアイテムの入れ替えは、プロダクトオーナーと開発チーム間の調整が必要です。 単に追加のプロダクトバックログアイテムを依頼したり、着手中のプロダクトバックログアイテムの受け入れ条件を変更したり、といったことは開発チームの合意なしではできません。 一方で、プロダクトオーナーとしては変更したい理由があるのに、それが受け入れられないのを我慢しなければいけないことにもなります。

ここでスプリント期間が短ければ、現状は受け入れた上で、次のスプリントで軌道修正をかければよいと割り切ることができます。 その割り切りによって開発チームは割り込みを受けること無く集中して作業を進められます。

なお、プロダクトオーナーにはスプリントをキャンセルする権限が認められているので、どうしてもという場合はスプリント期間に関わらずスプリントを途中中止して構いません。 ただし、いつもそれをやっているとプロダクトは何もできず、開発チームのモチベーションにも影響があるので、数か月に1度といった頻度までが限界です。 プロダクトオーナーとしての準備を怠ったが故のキャンセルは許されません。

ごまかしが効かない

最後になりますが、ここまで見てきた内容全体によって、スプリント自体のごまかしが効きにくくなります。 事前準備をきちんと行い、ムダなく着実に進めていかないと、成果がでない状況になります。 つまり、長いスプリントではなんとか吸収しきれていた問題は、短いスプリントだと大きな問題として露見していくことになります。 長いスプリントによって隠れていた本当の問題が露見すれば、それを改善することで、より成果が出やすくなります。

短いスプリントの弊害

1週間スプリントの利点ばかり説明してきましたが、いくつかの弊害や考慮ポイントがあります。 最後にそれを説明しておきます。

複数開発チームがある状況では、結合が間に合わない

それなりの規模の開発で、開発チームが複数ある場合、1週間のスプリントではそれぞれの開発チームの成果物の結合が間に合わない可能性があります(Nexusなどでも毎スプリントの結合が求められています)。 複数開発チームが存在する場合、コミュニケーションのオーバーヘッドがどうしても避けられず、またどこか一箇所の問題が全体に影響を与えやすくなります。 したがって、バッチサイズを多少大きくして確実に結合していく必要がでてくるかもしれません。

いつも追い立てられている気がする・ゆっくり考える時間がない気がする

1週間という短い期間に区切ると、どうしても残り日数や時間を意識する回数が増えます。 したがって人によっては、いつも追い立てられていると感じることもあります。 持続可能なペースで働くことが重要なので、その場合は、バッファの比率を見直すのも1つの手です。 また、プロダクトの状況次第では、祝祭日の絡む週のスプリントをときどきスキップする、という選択もできるかもしれません(あまりお勧めはしませんが)。 別の要因として、外部からプレッシャーがかかっていることもあります。 持続不能なペースで働くこと、決めたことを全て達成することを約束しているわけではないので、組織内で別のよくない力学が働いていないかどうかを確認し、それを改善していくとよいでしょう。

それでは。

アジャイルコーチングやトレーニングを提供しています

株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。

詳細はこちら
  • スクラム実践者が知るべき97のこと
  • 著者/訳者:Gunther Verheyen / 吉羽龍太郎 原田騎郎 永瀬美穂
  • 出版社:オライリージャパン(2021-03-23)
  • 定価:¥ 2,640
  • スクラムはアジャイル開発のフレームワークですが、その実装は組織やチームのレベルに応じてさまざまです。本書はスクラムの実践において、さまざまな課題に対処してきた実践者が自らの経験や考え方を語るエッセイ集です。日本語書き下ろしコラムを追加で10本収録
  • プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
  • 著者/訳者:Melissa Perri / 吉羽龍太郎
  • 出版社:オライリージャパン(2020-10-26)
  • 定価:¥ 2,640
  • プロダクト開発を作った機能の数やベロシティなどのアウトプットで計測すると、ビルドトラップと呼ばれる失敗に繋がります。本書ではいかにしてビルドトラップを避けて顧客に価値を届けるかを解説しています。
  • SCRUM BOOT CAMP THE BOOK 【増補改訂版】
  • 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎
  • 出版社:翔泳社(2020-05-20)
  • 定価:¥ 2,640
  • スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
  • みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
  • 著者/訳者:Matt LeMay / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン(2020-3-19)
  • 定価:¥ 2,640
  • アジャイルで本当の意味での成果を出すには、開発チームだけでアジャイルに取り組むのではなく、組織全体がアジャイルになる必要があります。本書にはどうやってそれを実現するかのヒントが満載です
  • レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 著者/訳者:David Scott Bernstein / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン( 2019-9-18 )
  • 定価:¥ 3,132
  • レガシーコードになってから慌てるのではなく、日々レガシーコードを作らないようにするにはどうするか。その観点で、主にエクストリームプログラミングに由来する9つのプラクティスとその背後にある原則をわかりやすく説明しています。
  • Effective DevOps ―4本柱による持続可能な組織文化の育て方
  • 著者/訳者:Jennifer Davis、Ryn Daniels / 吉羽 龍太郎、長尾高弘
  • 出版社:オライリージャパン( 2018-3-24 )
  • 定価:¥ 3,888
  • 主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します
  • ジョイ・インク 役職も部署もない全員主役のマネジメント
  • 著者/訳者:リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸
  • 出版社:翔泳社( 2016-12-20 )
  • 定価:¥ 1,944
  • 米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています
  • アジャイルコーチの道具箱 – 見える化の実例集
  • 著者/訳者:Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也
  • 出版社:Leanpub( 2016-04-12 )
  • 定価:$14.99
  • この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集です
  • カンバン仕事術 ―チームではじめる見える化と改善
  • 著者/訳者:原田騎郎 安井力 吉羽龍太郎 角征典 高木正弘
  • 出版社:オライリージャパン( 2016-03-25 )
  • 定価:¥ 2,138
  • チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍。カンバンの原則などの入門的な事柄から、サービスクラス、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。
  • Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド
  • 著者/訳者:Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳
  • 出版社:アスキー・メディアワークス( 2013-03-08 )
  • 定価:¥ 1,680
  • スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明
  • How to Change the World 〜チェンジ・マネジメント3.0〜
  • 著者/訳者:Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳)
  • 出版社:達人出版会
  • 定価:500円
  • どうすれば自分たちの組織を変えられるだろう?それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック