スプリントプランニングのはじめ方、進め方─ “とはいえ”シリーズ #2「スプリントプランニング編」（後編）

“とはいえ”シリーズは、スクラムに取り組む現場で起こる様々な「とはいえ」をピックアップし、それぞれどのようにアプローチしていけばいいのか、レッドジャーニーの経験豊富なアジャイルコーチがざっくばらんに語るシリーズです。

「スクラムガイドにはこう書いているし、よくブログではこういう事例を見かけるんだけど、とはいえ…」と困ってしまったり、チームで対話しても道筋が見えてこなかったりということはありませんか？
そんな時、ここでのお話が何か一つでもヒントになれば幸いです。

今回のテーマは「スプリントプランニング」です。後編では、時間やタスクの効果的な配分方法についてお話します。

前編はこちら

チームで臨むスプリントプランニング─ “とはいえ”シリーズ #2「スプリントプランニング編」（前編）

“とはいえ”シリーズは、スクラムに取り組む現場で起こる様々な「とはいえ」をピックアップし、それぞれどのようにア…

redjourney.jp

スクラムガイドについて

スクラムは、複雑なプロダクトを開発・提供・保守するためのフレームワークです。1990年代初頭、Ken Schwaber と Jeff Sutherland によって開発されました。
スクラムに取り組む際の拠り所となるのが、スクラムの定義やルールを示した「スクラムガイド」です。2010年に最初のバージョンが発表され、その後アップデートが加えられながら進化し続けています。
全18ページ（2020年版）という小さなガイドですが、目的や理論から実践まで分かりやすくまとめられており、スクラムの本質が理解できるようになっています。

今回のテーマ「スプリントプランニング」について、スクラムガイドにはこのように解説されています。

スプリントプランニングはスプリントの起点であり、ここではスプリントで実行する作業の計画を立てる。結果としてできる計画は、スクラムチーム全体の共同作業によって作成される。

プロダクトオーナーは参加者に対して、最も重要なプロダクトバックログアイテムと、それらとプロダクトゴールとの関連性について話し合う準備ができているかを確認する。スクラムチームは、アドバイスをもらうためにチーム以外の人をスプリントプランニングに招待してもよい。

スプリントプランニングは次のトピックに対応する：
トピック１：このスプリントはなぜ価値があるのか？
プロダクトオーナーは、プロダクトの価値と有用性を今回のスプリントでどのように高めることができるかを提案する。次に、スクラムチーム全体が協力して、そのスプリントになぜ価値があるかをステークホルダーに伝えるスプリントゴールを定義する。スプリントゴールは、スプリントプランニングの終了までに確定する必要がある。

トピック２：このスプリントで何ができるのか？
開発者は、プロダクトオーナーとの話し合いを通じて、プロダクトバックログからアイテムを選択し、今回のスプリントに含める。スクラムチームは、このプロセスの中でプロダクトバックログアイテムのリファインメントをする場合がある。それによって、チームの理解と自信が高まる。

スプリント内でどれくらい完了できるかを選択するのは難しいかもしれない。しかしながら、開発者が過去の自分たちのパフォーマンス、今回のキャパシティ、および完成の定義の理解を深めていけば、スプリントの予測に自信が持てるようになる。

トピック３：選択した作業をどのように成し遂げるのか？
開発者は、選択したプロダクトバックログアイテムごとに、完成の定義を満たすインクリメントを作成するために必要な作業を計画する。これは多くの場合、プロダクトバックログアイテムを1日以内の小さな作業アイテムに分解することによって行われる。これをどのように行うかは、開発者だけの裁量とする。プロダクトバックログアイテムを価値のインクリメントに変換する方法は誰も教えてくれない。

スプリントゴール、スプリント向けに選択したプロダクトバックログアイテム、およびそれらを提供するための計画をまとめてスプリントバックログと呼ぶ。

スプリントが1か月の場合、スプリントプランニングのタイムボックスは最大で8時間である。スプリントの期間が短ければ、スプリントプランニングの時間も短くすることが多い。

出典：スクラムガイド

…とはいえ、実際の現場では大変なことが様々あると思います。ガイド通りには進みませんし、そもそも書かれていないような事態も多々起こります。そうした「とはいえ」に、どのようにアプローチしていけば良いでしょうか。

話し手

プロダクトバックログとスプリントバックログの見積もりはどうやってやるの？

新井：
スクラムガイドには見積もりについて具体的に書かれているわけではありませんから、言ってしまえば「やりたいようにやればいい」ということなんですけど（笑）
プロダクトバックログの見積もりは、ポイントやプランニングポーカーで相対値を出すことが多いですよね。
スプリントバックログの見積もりでは、そこからある程度タスクバラシしていって絶対値の時間を見立てるというイメージでしょうか。

中村：
「見積もり」という言葉の意味や狙いが少し違いますよね。
プロダクトバックログアイテムは「相対見積もり」で、チームメンバーの間で認識の差が大きいものを素早く見つけるためのものだと思います。だから、精緻な見積もりというよりも相違点を素早く見つけるものという意味合いが大きい。
一方、スプリントバックログの方はより具体的で、本当の「計画作り」だと思います。どうやって進めれば自分たちの持ち時間内でうまくゴールにたどり着けるのかを考える。

新井：
たしかに、ちょっと切り口が違いますよね。

中村：
プロダクトバックログの方がまだ分からないことが多いから、相互学習でみんなの知見や経験を寄せようという感じかな。スプリントバックログの方は比較的分かっていることが多いから、絶対時間で見積もれます。

参加者コメント：
プロダクトバックログとスプリントバックログで出した見積もりがマッチしないことがあります。

中村：
マッチしないものと思っておいた方がいいかもしれませんね。プロダクトバックログはあくまでも相対見積なので、細かくしていっていろんなことが分かった結果、途中で変わることはよくあります。

参加者コメント：
Tシャツサイズだとベロシティって計算できないですかね？

中村：
数値に変換してみるのはどうでしょう。結局、ベロシティも絶対値ではなくて、自分たちの過去のペースと比べてどうかということなので、比べる「ものさし」さえ変わらなければ自分たちの現場に合った形でやっていけばいいと思います。

クオーター単位で大きな計画を立て直すため、クオーター最後のスプリントでリリースプランニング要素がたくさんあり、成果出しの追い込みができない

新井：
大きい会社だとクオーター単位の報告があって、そのタイミングで大きな計画を立てなくてはなりませんよね。
次のクオーターを視野に入れてプランニングをしつつ、今期としての成果も上層部に報告しなくてはならないという状況はよくあるんじゃないでしょうか。

中村：
ラストワンマイルが次のクオーターの準備と一部重なってしまうわけですね。
対策としては、事前に備えておくことが大事だと思います。
例えば7月から次のクオーターになる場合、6月末まであると思っていると重なっちゃうので、4月くらいの早い段階で「6月の2週目が最後のスプリント」というつもりで計画を立てておくんです。残りの2週間が余ったら「ボーナスステージ」と思えばいいですよね。

新井：
「アジャイルマニュフェスト」の12の原則の中に「持続可能なペース」というのがあります。その原則を大事にするのが一つの作戦です。
年末商戦など繁忙期のタイミングでは残業も致し方ないかもしれませんが、それが終わったらその分を取り戻すくらい多めに休むようにしないと、ずっとパンパンで働いていたら持続可能なペースにはなりません。
常に一定ペースである必要はなく山あり谷ありでもいいので、メンタルに負荷がかかり過ぎないように調整していけるといいですよね。

スプリント期間中の割り込みや緊急トラブルが多く、予定したことが全然終わらない。が、メンバーは楽観的でスプリントプランニングでは終わると思ってしまう（言ってしまう）

中村：
前のスプリントではいろいろあって予定したものが終わらなかったけれども、次のスプリントでは同じ内容ができると思ってしまう…どうしてだろう（笑）

新井：
プレッシャーや忖度、上司の圧力があって本音が言えないこともあるかもしれませんね。

中村：
なるほど。マネージャーのいないところで本音を聞き出してみると、実は全然違ったりするかもしれませんね。

新井：
あとは、毎スプリントでどれくらい割り込みが入ってくるかを考慮した上でキャパシティプランニングしておくのが大事です。
早く終わったらプロダクトバックログアイテムの優先順位が高いものから「おかわり」してくればいいだけですし、ビーチに行ったっていいんですから（笑）

中村：
まだ手元に残っているのに「おかわり」しちゃだめですよね。自分の分が終わったら仲間を助けに行きましょう。

新井：
そうですね。タスクボードの「処理中」のところにタスクがたまってしまうことがよくありますが、「完了」まで到達して初めて価値が生まれます。「処理中」のものは在庫でしかなくて、まだ顧客の手元まで届いていないので何も価値を生み出せていない状態です。

中村：
スクラムを始めてチームの透明性が高まっていくと「Doing」にタスクが溜まっている状態が見えてきますよね。どれも「Done」になっていない、一人で何とかしなきゃいけない状況に陥っているというのはよく通る道だと思います。
きちんと最後まで流して価値を生み出すという「カンバン」の概念を、チームで確認し合えるといいですね。

参加者コメント：
自分の社内での評価、という観点が入ってしまいそうです。

中村：
個人での評価という話になってくると、アジャイルの場合はちょっとややこしくなってきますね。
チームとしてはプロダクトのアウトカムや結果的に間に合うことが大事なので、安定的に進めていく方がゴールにたどり着ける確率は高くなります。さすがに最終スプリントだとどうしようもないかもしれませんが…

参加者コメント：
土壇場になってからの「それもうわかってたでしょ？」を防ぐ取り組みアイデアがあれば知りたいです！
「これ本当に終わる？」と気づくのが遅れることが度々あります。

中村：
大前提として見える化がされていて、という話ですよね。答えになっているか分かりませんけど、動くものをデイリースクラムで見せるというのは一つの方法です。そういうものを見ることで防げることは多いと思います。
最近はあまり使いませんけど、バーンダウンチャートなんかで可視化するのもいいのかな。

新井：
レビューの時にデモが間に合わないとか、言われてみればよくありますよね。

中村：
起きている出来事について認知はしているものの、それにどう対処すればいいかが分からないという場合もあるのかな。「どうせ間に合わないし」っていう学習性無気力の状態になっているとか、早く終わると余計タスクが積まれるからギリギリまでやっているとか、違う方向にモチベーションが向いているのかもしれませんね。

新井：
これもシグナルかもしれませんね。表層で起こっていることと根本原因が乖離しているというか。
今日終わった成果を5分くらいみんなで少し見てみようというような感じでもいいと思います。アジャイルマニュフェストじゃないけど、動くものを基準にするということかな。

中村：
実験的に「もし早く終わったら遊んでいいよ」と言ってみてもいいかもしれませんね（笑）
それで結果が変わるんだったら、そこにインセンティブが働いていると分かります。

新井：
私たちの大師匠にあたる人が以前言っていたことですが、カイゼンして生まれた隙間時間はチームが自由に使っていいんです。そこにまた新たなタスクを放り込まれたら、メンバーは絶対にカイゼンしようと思わないですから。

中村：
みんなでビール飲みに行くとかね。それで早く終わってみんなも楽しくて、モチベーションが上がって次のスプリントも元気にやれたらハッピーですよね。たくさんやることがいいわけじゃないですから。

メンバーがサインアップしてくれないので、アサイン型になってしまう

新井：
「アサイン」という単語はスクラムではあまり使わないんですけど、プロダクトオーナーやスクラムマスターが役職者だったり権限が強かったりする場合、どんどん「アサイン」していっちゃうことがありますね。その方が早く終わるからいいと思うかもしれませんが、そうすると自律した組織には育っていきません。

中村：
サインアップしないからアサインされちゃうのか、先にアサインしちゃってるからサインアップしてくれないのか、どっちもありそうですよね。

新井：
サインアップしてくれるのを待てないということもあるでしょうね。チームの関係性がそうなっちゃっているところに根本原因があるのかもしれません。

中村：
自分が取った結果できなかったらどうしようという不安や、「マネージャーが決めること」という思い込みもあるかもしれませんね。

参加者コメント：
おおかたの「とはいえ」の発生を分解していくと、その原因は「結局これだよね」に収束されるという傾向があったりするのでしょうか？例えば、チームと組織上位者との認識齟齬とか。

中村：
いくつかの類型があるとは感じますが、その中の一要因だけがそれを引き起こしているということはあまりなくて、複合的に絡んでいるものだと思います。終わってみてパターンが見えることは結構あります。

ただ、アジャイルコーチとして「どうせこれでしょ」と限定はしないようにしています。思い込みや決めつけから間違えた推測が働いてしまうので、仮説は持ちつつも一旦脇に置いて、よく観察し話を聞いた上で何が起きているのかを見るようにしています。

新井：
私も同じ意見です。人間の営みなので、一個の原因に収束するというよりは複数の要素が強弱ありつつ絡み合っている状態が多いのではないでしょうか。何か一つ解決すればすべてうまくいくっていうのは、なかなかないかな。

参加者コメント：
知識や分かっている仕様が一人に集中していて、そもそもプランニングで発言もできない（分からないので）ということがけっこうあります。

中村：
これもまさにいい「シグナル」ですよね。
アジャイルやスクラムに取り組んでいると、チームで相互学習することに対して「いいこと」という前提がありますが、世間一般ではみんながそうとは限りません。もしかしたら、知識を分け与えることで自分の優位性が損なわれるという不安を感じる人もいるかもしれませんし、単純に一人でやる方が早い、早さが正義、と思っている人もいます。

一人に集中している状況についてどう思うか、一旦みんなに聞いてみたらどうかな。チームとして望ましい状態なのか、一年後もこうありたいかどうか。腹を割って話してみるのも一つの方法じゃないでしょうか。

新井：
チーム自体も成果物の一つとして捉えて、長期的視点で考えたいですよね。
このスクラムチームで長期的にパフォーマンスを出していくためにはどうすればいいか？　と考えれば、一人に集中するのではなくスキル転換や育成が必要だと分かるはずです。

中村：
今日もありがとうございました。あっという間の60分でしたね。

新井：
ありがとうございました。

次回もお楽しみに。

参加者の方からのご感想

• チームも成果物の一つ、なるほどです…！
• 前回同様とてもためになる＋一瞬の1時間でした。またぜひ次回参加させていただきたいです！色々拙い質問だったのですが、拾っていただいて助かりました。ありがとうございました！
• 気楽に話を聞くことができました。組織にも展開して紹介します！

関連情報

レッドジャーニーでは、経験豊富なアジャイルコーチ陣によるオンラインイベントを開催しています。

▼イベント開催予定はこちらをご覧ください。

レッドジャーニー | Doorkeeper

redjourney.doorkeeper.jp