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

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

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

今回のテーマは「スプリントプランニング」です。前編では、スクラムに臨むチームが心得ておきたいことについてお話します。

スクラムガイドについて

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

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

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

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

スプリントプランニングは次のトピックに対応する：

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

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

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

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

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

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

出典：スクラムガイド

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

話し手

トピック１，２，３をいつの間にか忘れてしまう

新井：
冗談みたいな話ですけど、実際はこういうことってよくあると思うんですよ。
特に、トピック１で示されている「WHY」の部分がいつの間にか抜けてしまいがちです。細かく計画を立て過ぎて、それをスプリントという区切りの中でただ片付けていくだけになってしまう。

中村：
詰まれたバックログを順番にこなしていくだけの「タスク消化マシン」のようになってしまうんですよね。

新井：
「プロダクトゴールや目指すべきところはどこだっけ？」というところからブレイクダウンしていかないと、視野が狭まってミクロの作業に終始しがちです。「誰のために作っているんだっけ？」ということを思い出す機会が減ってしまいますよね。

中村：
トピック２で期待される「何をすればいいのか？」「こっちの方が良いのではないか？」といった会話は、トピック１を実現するためのものですから、本来はトピック１なくして２は決められないはずなんですよね。

新井：
そうですね。トピック１→２→３と一直線に行けるわけではないと思うし、行きつ戻りつしながら進むのも全然ありです。

中村：
トピック２に取り組む中でスプリントゴール（トピック１）が変わることもあるし、トピック３を進める中で取り組み（トピック２）の範囲が変わるということもありますね。

新井：
チームでスプリントプランニングの会話をすることによって解像度が高まりますから、その都度アップデートしていけばいいと思います。

タスクのネーミングやスプリントゴールの表現も変えちゃいけないわけでは決してなくて、分かった時点で変えればいいんですよ。
初めはうまく言語化できなくても何かしらの言葉を置くからこそ会話が進みますし、会話が進むことで解像度が高まってアップデートできます。
うまく言語化できていないことを申し訳なさそうにされることが時々ありますが、全然謝るようなことじゃないんですよ。

参加者コメント：
まさにそうなっていて、特にその状況に疑問を持っていない状況かも…

中村：
そういう時は「このバックログが終わるとどうなるんだっけ？」と、スプリントゴールの話を提示できるといいですね。

新井：
スプリントプランニングのアジェンダの中にトピック１，２，３の要素を盛り込んでおくといいかもしれませんね。

参加者コメント：
PO（プロダクトオーナー）とSM（スクラムマスター）ともにDEV（開発者）との兼任です。スプリントプランニングのタイミングで完了条件をしっかり確認して進められていない状態です。作りながら固めているのが現状で、もうちょっと効率的に進められないか気になっています。

中村：
この場合は最後の言葉をそのまま指摘してみてもいいかもしれませんね。

プランニングポーカーをやると時間がかかりすぎて、管理職としてやらせたくない

※プランニングポーカーとは
アジャイル開発で用いられる見積もり手法の一つ。カードゲームのように数人でカードを使って見積もりポイントとその理由を出し合い、ユーザーストーリーの完了までに必要な工数を見積もる。参加者が同時にカードを出すことで他の参加者からの影響を受けにくい。

新井：
スクラムチームとはちょっと離れたところにいる管理職をイメージしてみると、プランニングポーカーはただ遊んでいるように見えてしまうかもしれませんね。管理職としては生産性が気になるでしょうし、とにかく作りきってほしいという思いが強いんじゃないかな。

中村：
みんなで見積もりしなくても誰かが決めればいいという考え方があるのでしょうか。

新井：
そうかもしれませんね。誰か「偉い人」が全部決めた方が早いんじゃないか、という。

中村：
「経験がある人は正解を知っている」という思い込みが前提にあるのかなと思います。
継続的な相互学習の重要性が軽視されていると、こういう状況が起こってしまうのかもしれませんね。

新井：
スクラムイベントはチームのコラボレーションの場であり、属人化の解消やノウハウの伝授など、対話を通して相互学習や育成をし成長する機会でもあります。もちろんチームビルディングの要素も含まれています。

属人化やコミュニケーション不足といった問題を抱えている組織は多いと思いますが、スプリントプランニングを丁寧にやることで先手を打てるんじゃないでしょうか。
昔ながらのやり方で「背中を見て覚える」というのがありますが、なかなか難しいと思います。言語化したり暗黙知を伝えることは大事ですよね。

中村：
プランニングポーカーに取り組むチームのスタイル次第とも言えるかもしれません。相互学習の場として活きるには、自分とは違う考えを持つ相手に対して関心とリスペクトを持って接することが必要です。
関係性が悪い中でプランニングポーカーをしてもうまくいきませんし、かえって非効率で悪循環に陥ってしまう可能性もあります。

参加者コメント：
見積もりを相互で行い半日以上プランニングを行っているチームもあるという噂を聞いたことあります。

中村：
プランニングポーカーをしても全然揃わないということは、何か根本的な情報が足りていないことが多いと思います。漫然と続けるよりは早めに調査することをおすすめします。

新井：
経験の格差による知識の差がある場合はペアプログラミング、モブプログラミングなどで一緒に解決するのもいいですね。

参加者コメント：
プランニングポーカーをやる前にタスク分解してタスクをカンバンにおいて、どれくらいの規模感か意識合わせをしています。そのため、プランニングポーカーで各自のポイントがそれほどずれない状況です。そこまでやる必要あるのという疑問は感じております。

中村：
プランニングポーカーに期待する効果は、相互学習できることや認知の違いを素早く見つけられることなので、別のプロセスで充分カバーできるのであれば必ずしも必要かというとそうではないかなと。

新井：
相対的な違いや関係性が分かればどんな方法でもいいので、手軽に見積もっていけるといいですよね。

参加者コメント：
調査が必要なタスクについて上手く扱えていません。対応内容が調査内容次第、といった感じになって、プランニングポーカーをやってもバラバラになったり、一旦つけないでおいて…といった事態になってしまっています。

中村：
スクラムではスプリントに投入するプロダクトバックログアイテムは「Ready」（準備ができている状態）である必要があります。 
リファインメントやスパイクといった「Readyにするための活動」は、そもそも見積もれないんですよね。

ではどうするかというと、まず「分かりたいこと」「分からないこと」が何かを書き出してみましょう。それを例えば1〜2時間くらいかけてやってみるんです。
そうして分かったことに基づいて、「Ready」にできるならばプランニングで見積もりしようとか、無理だったらもう少し調べようとか、時間で区切るのは良い方法だと思います。

新井：
時間を区切ってやるのはいいかもしれませんね。調査系のタスクって次から次に芋づる式に対象が出てきちゃうので、エンジニア魂としては無限に知りたくなっちゃうんですよね。

スプリントプランニングが開始できる条件、状況になっていない

中村：
スプリントプランニングに臨むのにバックログが最新の状態になっていないことってよくあると思います。あるいは、自分たちがどれくらいできるのかのキャパシティが分かっていなかったり、ベロシティが計算できていなかったり、前のスプリントで残ったものの取り扱い方を決めていなかったり。
そんな風にプランニングの会話を開始できる条件が揃っていないとき、どうすればいいでしょうか。

新井：
スプリント１の開始前であれば、助走期間や準備期間をある程度丁寧に用意できるとベターかな。
スプリントが走り出してからであれば、一旦立ち止まって考えてみてもいいかもしれません。なあなあで進めるよりは、みんなで立て直す方がいいですよね。

中村：
「シグナル」と考えてみるといいんじゃないでしょうか。
例えば、プロダクトオーナーがプランニングまでにプロダクトバックログの順番を並び替えられないという出来事があったとき、そこに対して向き合えていないということを示しているかもしれません。忙しいとか、別のことに追われているとか。
開発者たちが自分たちのベロシティやキャパシティを整理できないほど日々のバグ対応や問い合わせに追われているのであれば、それはそれで別の問題のシグナルと考えられます。

新井：
根本的な原因がどこかにあるはずですよ、ということですよね。応急処置で済ませられるものではないかもしれない。

中村：
ベロシティ、キャパシティ、バックログの準備をしていないから、プランニングが始まってから時間を取ってやることがありますが、そうすると当然プランニングの時間が減るわけです。結果的にプランニングがちゃんと終わらず大体は時間がオーバーする。そのまま始めてスプリントでコケるというパターンは多い気がします。
スプリントプランニング前の準備ってどんなものがあるかな？　と考えてみるといいんじゃないかな。

「タスクにばらすこと」が目的になる

中村：
「タスクばらし」が良くないわけではないんですよ。あくまでも手段の一つであって目的ではないということですよね。

新井：
アジャイルコーチとしては難しいところです。
大きい粒度のままでは進められませんから、「ばらす」ことを推奨はしますが、それがメインの目的ではないんですよね。

中村：
例えば、ホワイトボードにちょっとした絵を描いて、みんなで順番を確認するだけでもいいと思うんです。今はいろいろと便利なツールもありますが、使っていくうちにタスク管理が仕事のようになってしまって「全部終わっているか？」と検査する視点になりがちです。
大事なのは、バックログアイテムがちゃんとインクリメントに変わったかどうか？　もっと言うと、それによってスプリントゴールが達成できているか？　という視点で捉えることです。

新井：
スプリントレビューから逆算して考えられるといいのかもしれませんね。
ばらしたタスクを全部片付ければ、その合計値としてプロダクトバックログが完成するはずではあるんだけど、やっているうちにショートカットできる方法が分かるかもしれません。そんなとき、「ここって端折っても大丈夫じゃない？」っていう会話をデイリースクラムでやってほしいですね。
「手抜き」とか「ショートカット」とかでスプリントゴールを達成できるならありなんですよね。「やらなくちゃいけない」と思いこんでいる固定概念をどんどん見直せるといいですよね。

中村：
タスク管理にとどまらず、本来の目的であるインクリメントやその先のスプリントゴールを達成することにフォーカスして会話をすることで、チームの視座が変わるかもしれません。

後編へ続きます

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

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

redjourney.jp

関連情報

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

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

レッドジャーニー | Doorkeeper

redjourney.doorkeeper.jp