小中新規開発グループ (a.k.a. tara チーム) の qsona です。
tara チームでは、スタディサプリ中学講座というプロダクトを開発しており、約1年前 (2022-02) に本リリースして以来、継続してプロダクト開発を続けています。
tara チームのプロダクト開発は、基本的にスクラムの手法にのっとる形で行っています。ビジネス的な境界により分けられた3つのスクラムチームが存在します。
スクラムの運用については、それぞれの現場において悩みごとが起きがちだと思いますが、tara チームでもご多分に漏れず、うまくいっていること・いっていないことが存在します。今回は、その3つのうちの1つのチームである「学習コアチーム」において存在した、Sprint Planning に関する (あるいはそこから掘り出された) 課題と、それに対してどう対処したかについて書きたいと思います。
なお、本記事中のスクラムに関する用語は、なるべくスクラムガイド(2020年版)に沿った意味として利用しています。
課題: Sprint Planning が効果的でない
私たちのチームでは、Sprint の期間を2週間とし、基本的にはスクラムガイドに則るような形で継続的にイテレーションを回していました。その中で、「Sprint Planning が効果的に行えていない」という課題に直面しました。
以下、その課題について説明していきます。
我々の Sprint Planning で行っていること
まず前提として私たちは、Product Backlog の Refinement は、おおむね Sprint Planning とは別の場で、事前に行っています。ここでの Refinement とは、以下のような内容を指します:
- Product Backlog Item (PBI) の作成と、大まかな優先順位付け
- 基本的に「ユーザーストーリー」形式で作成し、誰にどんな利益があるのかを明示する
- いわゆる INVEST を指針としている
- PBI に対する見積もり
- プランニングポーカーを利用し、相対見積もりを行う
- PBI の洗練化を兼ねる (曖昧な点を減らす)
- 見積もりを利用して、優先度を調整する
- 例: 簡単なタスクと予想してバックログの一番上に入れていたが、見積もりを行った結果大きいと判明したので、優先度を下げる (あるいはその逆)
以上が完了しているという前提のもと、Sprint Planning を行います。
Sprint Planning では、この Sprint で取り組む PBI の集合を定めます。
基本的には、優先度が高い PBI を、この Sprint 内でチームとして達成できそうな分だけピックアップします。
Sprint Planning の課題 (1): 時間と労力がかかる
Sprint で取り組む PBI をピックアップする上で、もっとも単純なやり方は、以下のような手法です。
- これまでの傾向から、2週間で達成できる合計ポイントの予測値を定める。
- Product Backlog の上から(=優先度の高い順に)PBIをピックアップする。合計ポイントが予測値を超える手前まで入れる。
上に書いたようなやり方で良ければ、非常に機械的な作業のように思えます。
しかし、実際には以下のような理由でそう簡単ではなく、チームの時間・労力がかかっていました。
待ち時間が長くなりがちな PBI の存在
PBI のうちのいくつかは、他のチームとのコミュニケーションを通して進めていく必要があります。そういった PBI では、「待ち」の状態で数日間止まってしまうことがあります。
タスクが待ち状態になる可能性が最初から見込まれる場合、実際の予測ベロシティよりも多くのタスクを積むなどを考慮する必要がありますが、この予測は難しく、Planning を難しくする一因になっていました。
以下、そのような PBI の種類の一例を説明します。
新規顧客層の開拓を見込んで、ビジネスのフィジビリティスタディが活発な時期などは、技術調査を行い、やりたいことを実現することができるのか、どれくらい難しいのか、代替手段はあるのか、などを提示するという任務があります。
私たちのチームではこういったタスクも PBI として扱い見積もりポイントを振って進めています。この技術調査は、ビジネス上重要な意思決定の材料になるので、そのための十分な材料が集まったと判断されてから、完了することにしています。
この完了条件については、合理性があり、納得感もある (ビジネスチームとの信頼関係は強いです) のですが、自チーム内だけで完了と判断できないため、待ちの時間が長くなりがちです。待ち状態であることを明確化すればオーバーヘッドは大きくありません。しかし、待ち状態のときは、別のタスクに着手する必要が出てきます。さらに、待ち状態のまま次のスプリントに持ち越されることがあります。
前スプリントからの繰り越し
これはあまりスクラムのプラクティス的にほめられたことではありませんが、現実問題としては、PBI がスプリント中に完了せずスプリントをまたぐことが多く発生していました。
原因の一つは、一つ上で示した、待ち状態のままスプリント終了を迎えるタスクですが、それ以外にも、大きめの PBI などが繰り越されることが多くありました。
繰り越しが多い状態でなるべく正確に予測して Planning するため、その繰り越しの分がどれくらいなのかの計算していました。例えば 8 ポイントの PBI が 3 ポイント分程度進捗していると考えて、今スプリントでは 5 ポイントとして扱う、というような具合です。
個人的にはこの処理は煩雑すぎるのと、完了前の時点で進捗度合のポイント分を見積もるのはずれやすい (一般的に進捗を多く見積もりがち) ので、できればやめたいと思っていましたが、とはいえこの時は本当に繰り越しが多かったので、現実的には仕方ないとも感じていました。
チームメンバーのスキルセット
チームメンバーのスキルセットや技術的育成といったトピックは、スクラムガイドで特に語られていませんが、実際には重要です。
スクラムチームは、その目標を達成するための能力をすべて有している必要があり、私たちのチームもその点は十分考慮して編成させています。しかし当然ながら、メンバーごとに得意な領域やそうでもない領域はあります。例えば、Product Backlog の上位にあるアイテムがすべてバックエンド開発中心だった場合、フロントエンド領域を得意とするメンバーは十分に力を発揮することができません。
自分の専門でない領域のタスクもカバーしていくことは、スクラムの良いプラクティスの一つだと思います。しかし、チーム状況やメンバーの指向性によっては、専門領域に近いタスクに注力したほうがうまくいくこともあります。
また、コードベースの健全な進化や、メンバーの技術的育成といった見地に立つと、ある開発者が、一定期間以上、特定の領域の開発を続けたほうがよい、ということがあります。特定の領域上のコードをいろんな人がひっきりなしに触るよりも、一人で長く触ったほうが、長期的視点を持って設計するインセンティブが生まれます。その結果、コードベースに良い設計が生まれ、また個人の視点でも設計力を伸ばすことができます。
これらの理由により、優先度を入れ替えるべき場面がある、と個人的には考えています。すると、Planning でタスクを積むためにそういった点の考慮も必要でした。
... これらを、2週間先まで見通して計画を立てる難しさ
上で示した様々な事情があっても、「今日何をどこまでやるか?」を決める上ではある程度勘案して考えることができますが、2週間先まで決めるには十分不確実性が多く、難しすぎると感じていました。
2週間がだめなら1週間にすればよいのでは? と思った方もいるかもしれません。実際このチームでは、Sprint Planning から1週間経過したときに、計画の内容を見直す、ということをやっていました。
しかし、1週間にしてしまうと、よりスプリントをまたいで繰り越される PBI の割合が増えてしまいそうです。また、2週間単位の振り返りサイクルにはチームとして満足していたのもあり、単にスプリントを1週間にするのが良いとも思えませんでした。
Sprint Planning の課題 (2): メリットが少ない
Sprint Goal の「確約」のメリットが少ない
スクラムガイドでは、Sprint で達成すべきゴールを定め「確約」することの意義が示されています。
個人的な経験としても、Sprint Goal が大きな意味をなしたことがあります。一行で示されるような明確な Goal のもと、技術的に多岐に渡る PBI 群を、チームの結束のもと2週間でクリアしたという経験です。このように、チームを一致団結させるような目標設定ができると非常にハマると思います。
しかし、最近の私たちのチーム開発では、新規開発・改善・調査などのタスクが満遍なく存在していて、それらを結束するようなゴールの制定というのは難しい状況でした。
したがって Sprint Goal というのは単に、「取り組むべき PBI の集合」になりがちです。これを計画するのがそもそも難しいことは既に述べました。したがって、「確約」しようとするとより小さい集合になり、あまりチームをモチベートするような目標にはなり得ません。
また、スクラムガイドではあまり語られてませんが、「確約」することには、プロダクトオーナーやチーム外のステークホルダーに対して説明できるという意味もあるのではないかと思います。
しかし、我々のチームにおいては、この意味での確約はそもそも必要性が薄いと感じていました。まず、2週間 (あるいは1週間や1ヶ月) でリリースしたい、というような、期日が厳しいタスクというのは、私たちのチームには多くありません。あるのは以下のような欲求です。
- 一つ一つをできるだけ早くリリースすること (リードタイムを短くする)
- もっと長期的なスパンでビジネス計画を立てられるようにすることと、その計画に沿って開発が進むこと
したがって、スクラムガイドで示されている「確約」を行う意義はあまり大きくないと考えました。もっとも、タスクの期日等に関して一定の目標を持って取り組むことは仕事において大事だと思いますが、それは2週間単位での目標設定以外の方法でも実現できそうです。
イテレーションとリリースは分離されている
スプリントの成果物(インクリメント)単位でリリースを行なっている場合は、スプリントの計画=スプリント完了後のユーザーへの価値提供の計画となります。
我々のチームではサービスのデプロイ作業を簡略化したり、E2E自動テストを充実させるなどにより、具体的には tara チーム全体でみると1日平均1回以上のデプロイを行なっています。したがって、もともとスプリントのサイクル単位でリリースを行っていたわけではなく、完了したものから順次リリースしていました。したがって、この意味においてもスプリントゴールは特に意味がありません。
個人的な見解ですが、スクラムが広まった時代においては、今よりもデプロイのコストが高く、2週間に1回などの単位でまとめてリリースするような戦略が一般的だったのではないかと思います。現在でもクライアントサイドのネイティブアプリ等は一定そういった性質があります。その場合はよりスプリントという概念がしっくり当てはまるのですが、毎日デプロイするのが当然になっている現代では、スプリントというサイクルの価値がやや下がったのではないかと思います。
Sprint Planning がなくてもベロシティは計測できる
スプリントゴールの意義として、スプリント終了時の振り返りに利用できるという側面はありそうです。定めたゴールに対して (どれくらい) 達成できたのか、を知ることができます。
しかし、2週間単位での計画が厳密でなくても、2週間分の成果を確認することは可能です。スプリントの振り返り時の観点としても、「計画を達成したか/達成しなかったか」ではなく、「達成したベロシティはいくつか/それは過去と比べてどうか」と考えることができます。
ベロシティが計測できていれば、より長期の計画を立てることができます。例えば、チームのベロシティが2週間で平均15ポイントであれば、2ヶ月後には約60ポイント分の成果が期待できるといった具合です。これは必ずしもスプリントゴールを定めなくても可能です。
Sprint Planning の課題のまとめ
総じて言うと、私たちの Sprint Planning に対し、私は以下のような課題感を持っていました。
- 難しい、多くの時間がかかっている
- 意義が薄い
...もし本当そうなのであれば、そのようなイベントはなくすべきです。ということで、この説についての検証に取り掛かりました。
課題に対する Try
Sprint Planning をやらない
以上のような問題提起をチームで行ってみたところ、チームのプロダクトマネージャーやスクラムマスターが持っていた課題感とかなり重なるところがあることがわかりました。
まずプロダクトマネージャーは 「Sprint Planning の準備に時間がかかっている」という課題を持っていました。これはシンプルに Sprint Planning をなくせば解決します。
次にスクラムマスターは「同時に並列で進む PBI の数が多すぎるのではないか (=仕掛かり制限を設けたい)」という課題を持っていました。これについては Sprint Planning が直接悪さをしているわけではありません。逆に、PBI の並列度が高いことにより、スプリントをまたぐ PBI の数が多くなり、Planning が難しくなる、という関係性にあります。
ですが、目の前のものをチームとして日々着実に終わらせていく、ということが重要なのであり、そのためには、2週間先のゴールはむしろ不要なのではないか、と考えました。
それであれば一旦 Sprint Planning はなくしてみよう、とチームで合意できました。
Product Backlog の整備は今まで通り行う
優先順位づけられたユーザーストーリーのリストである Product Backlog はこれまで通り非常に有用です。これを整備するイベントである Product Backlog Refinement についても、これまで通り、必要に応じて定期的に行うこととしました。
Daily のミーティングで、必要に応じて新たに取り組む PBI をピックアップし、必要に応じて計画する
Sprint Planning でそのスプリント分の PBI を定めて計画する代わりに、Daily のミーティングを利用することにしました。
具体的には、手が空いた人がいた場合、以下のいずれかを行います:
- Product Backlog の上位の方にある Product Backlog Item (PBI) をアサインする
- PBI を自分にアサインした人は PBI Lead として、その PBI の完了までリードする責務を持つ
- すでに他の人がリードしている PBI を手伝う (PBI に紐づくタスクをアサインする)
ここで、新規の PBI に着手するときは、チームでその内容や完了条件を確認しています。その大きさや複雑度によっては、タスク分解をアサインされた人に任せず、チームで議論するかもしれません。
つまり、もともと Sprint Planning で2週間分の計画を行っていたかわりに、Daily のミーティングを利用して PBI 単位での計画を行っているということができます。
またこのタイミングで、PBI Lead の役割を明文化しました。一言でいえば PBI をリリースまで持っていくための責任を持つ人で、PBI に関するタスクを全て行う必要はありませんが、タスク分解や進行管理、リリースの段取りなどはこの人が行うものとしました。
Sprint Retrospective は引き続き2週間単位で行う
Sprint Retrospective は、今まで通り、2週間サイクルで最後の金曜日に行います。
- 2週間分のベロシティの確認
- チームの振り返り (KPT)
この振り返りの内容や周期に関してはチームとして全く不満がなく、うまく回っていたため、当然に継続することになりました。
なお、ステークホルダーへの成果物の説明は、tara チーム全体で週1回のプロダクトに関わる人が集まる会の中で行われています。
振り返り
以上の Try を行ってから約9ヶ月が経ちました。(9ヶ月間ブログ記事を完成させずに放置してしまっただけとも言いますw)
現在においても、このチームでは Sprint Planning は廃止されたままになっています。
9ヶ月の間も、チームでは定期的な振り返りを通して新たな課題に対処していっていますが、結果として Sprint Planning を復活したいという声は一度も起きなかったので、Sprint Planning をなくすことは少なくとも現場における現実解だったと考えています。
平均的なベロシティの推移を追っても、Sprint Planning 廃止以降に下がったということはなく、むしろ上がっています。上がった要因はこれ以外の改善活動によるものが大きく、Sprint Planning 廃止によってベロシティが上がったとは言えません。が、少なくとも、「Sprint Goal を立てなくなったことにより求心力が下がりベロシティが下がった」というようなマイナスの事柄は起きませんでした。
一方で、スクラムにおいて Sprint Goal をうまく定められているときに比較すると、計画性の面では弱さがあるかもしれません。基本的に PBI 単位での計画を毎度しっかりやれれば理論的には変わらないはずと思っていますが、現実的には、Daily ミーティングでどこまで時間をとってやるのか迷うなど、やや運用に難しさがあります。
考察とまとめ
今回の改善は、Sprint Planning をうまくやるのが難しいという課題から出発したものですが、結果的にその後の状況は、アジャイルにおける「カンバン方式」として整理されている方法に似通っていることに後から気づきました。
カンバン方式について調べていると、「スクラム vs カンバン」のように別物として整理している記事を多く見つけましたが、それはどうもあまり意味がないように見えます。たとえば、「カンバンでは作業を単体でいつでもリリースできるが、スクラムはスプリントの完了後にまとめてリリースする」という言説は、スクラムをやりながらでも毎日リリースできるので、やや時代遅れな考えといえるでしょう。
つまり、私たちとしてやるべきことは、「スクラム」か「カンバン」かあるいはその他の何かを一つ選択するだけではなく、その中の個々の手法を学んだりその背景を理解し、チーム状況に合わせて選択的に取り入れることなのではないでしょうか。
たとえば「カンバン」方式を一旦採択するとしても、Product Backlog を整備することや、一定期間の振り返りをチームで行うことは、基本的には有用なプラクティスなはずです。
ことスクラムにおいては、"それは正しくスクラムのプラクティスを実践すれば解決する" というような論調もよくみますし、この記事にも一定そのような反応はあるでしょう。しかし、スクラムはどんな場面でも万能で使える銀の弾丸ではありませんし、チームのことは最終的にはそのチームの人にしかわかりません(この記事でも残念ながら書ききれていないコンテキストがたくさんあります)。
私たちが直面した課題は、みなさんのチームにおいての課題と全く同じであることはないでしょうが、「プラクティスの背景を理解しつつ、実際の課題に適応させるために適切にアレンジする」という選択を持ってよいと私は考えており、それにはソフトウェアの設計をするのと同じような面白さもあります。この記事が背中を押すきっかけになればよいな、と思っています。
