意識の問題にしない

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

今日はTwitter経由で頂いた質問に回答したいと思います。質問は以下になります。

スプリントで『自分が最初に取り組むプロダクトバックログアイテム（PBI）を終わらせば自分の仕事は終わり』という意識のメンバーが多いです。そのため、PBI每に担当を決めて複数のPBIを並列で進めているのですが、インクリメントが0になる可能性があるのでできればやめたいと思っています。スプリントプランニングで決まったPBIすべてをチームで協力して終わらせるという意識に変えるためにはどうしたらよいでしょうか？
例えば、AさんとBさんとCさんが最初にPBI-1をやる場合、スプリントでPBI-1を終わらせればよい、PBI-2とPBI-3は自分たちのタスクではないという意識になってしまっているという感じです。

ということで考えていきましょう。

スプリントでの開発者の仕事は何か？

スクラムガイド（2020）を見ると、以下のように書いてあります。

スプリントゴールはスプリントの唯一の目的である。スプリントゴールは開発者が確約する（略）開発者がスプリントで作業するときには、スプリントゴールを念頭に置く。

スクラムガイドにあるように、スプリントで目指すのは、スプリントゴールの達成です。開発者はスプリントゴールを達成するために必要な作業を行います。

つまり、スプリントでは選択したプロダクトバックログアイテムは必ずしもすべて完成しなくてもよいこともありますし、スプリントバックログに含めた個々のタスクもすべて実施しなくてもいいかもしれません（もちろん完成の定義は守らなければいけません）。

明確なスプリントゴールを設定した上で、そのゴールを達成するための方法に柔軟性を持たせることで、達成の可能性が上がるわけです（つまり「選択したプロダクトバックログアイテムをすべて完成させる」というスプリントゴールは無意味です）。

質問の状況において、1つだけ完成したプロダクトバックログアイテムによってスプリントゴールが達成できているならよいですが、そもそも「スプリントゴールを設定していない」可能性が高そうです。

スプリントゴールの解説については、こちらも参照してください。

開発者はプロダクトバックログアイテム消化マシーンではない

スプリントゴールもなく、たくさんのプロダクトバックログアイテムを作ることを開発者に求めるのは意味がありません。

これはフィーチャーファクトリーと呼ばれるもので、なかには外部委託や海外オフショアの開発者を集めてこれを実現しようとするような分かっていない例もよく見かけます。

プロダクトバックログアイテムを完成させても、次のプロダクトバックログアイテムがどんどん来るだけなので、何のために作っているのかが分からなければモチベーションが上がることはありません。

スプリントレトロスペクティブで改善をしてもその分追加の仕事が来る、スプリントで早めにすべてが終わったらおかわりを要求される、という状況ではまずいわけです（夏休みの宿題を早めに終わらせたら追加の宿題が出るとしたら、みんなギリギリまでやらないか、適当にペースをコントロールしますよね）。

意識の問題にしない

「意識の問題でうまく進まない」と言いたくなる気持ちは分かるのですが、これは本当の問題を表していないことがほとんどです。スクラムマスターとしては、どんな事実に起因しているのかを深堀りする必要があります。それを抜きにアクションしても、本当の問題は解決せず、かえって問題を大きくしてしまう可能性もあります。

今回の質問を例にすると「プロダクトバックログアイテムを1つ終わらせれば自分の仕事は終わりという意識」なので「プロダクトバックログアイテムを個人に割り当てればそれでもたくさん完成するはず」というロジックのようですが、深堀りすべきなのは「なぜ前者のように考えるのか」なのです。

単純にスクラムに対する理解不足（スプリントで達成すべきことを分かっていない）であれば、スクラムチームでスクラムガイドの読み合わせをしたり、研修に参加したりすればよいでしょう。経験上、基礎的な教育受けたり学習したりせずに、なんとなくスクラムを始めるチームがかなり多いです。しかし、この始め方をしてしまうとイベントや作成物、責任の有機的な関係性をまったく理解していないため、過去の経験や考え方をそのまま持ち込んでしまい、よくわからないことになってしまいます。知識や考え方のベースラインを揃えるのに時間を使っておけば将来の問題やムダを省けるので、ぜひ学習に時間を使いましょう。

開発者が消化マシーンのように扱われているのが理由なのであれば、プロダクトオーナーやステークホルダーへの働きかけも必要です。つまり、実は開発者が問題でない可能性もあるということです。

なお、理想的にはスプリントレトロスペクティブでこういう話ができるとよいですが、問題を表明しにくい環境の場合は、1on1などで開発者個別に話を聞いたほうがよいこともありますので、適宜使い分けてください。

ほかに質問がありましたら、ぜひこちらよりお気軽にどうぞ。

それでは。

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料）