スクラムイベントがうまくいかない時は大抵前のフェーズがうまくいっていない

読んで欲しいと思っている人

スクラムイベントがうまくいかない感じがして困っている方
スクラムイベントをもっと良くしたいと思っている方

読むとわかること

スクラムイベントを改善するための1つのアイデア
スクラムイベントは互いにインプットとアウトプットとなりながら循環していること
スクラムを改善したい時はシステム思考を勉強するとちょっと助けになること

はじめに

バックエンドエンジニアを務めている @Juju_62q です。スクラムでのロールとしては「開発者」を務めています。突然ですが質問です。

スクラムイベントがうまく改善できないという経験はありませんか？

例えば「スプリントプランニングが時間内に終わらない」という問題があるとします。この時にスプリントプランニングで効率的に意思決定を行うための実験を開始してもどうにもうまく問題が解決していかないことがあります。時間内に収めるために強引な意思決定手法を導入することもできますが、それだと開発者のコミットメントをうまく引き出せないこともしばしばあります。

こういった時に自分が気をつけていることの1つを紹介させていただければと思います。スクラムイベントが何かうまくいかないと感じている方はスクラムをやめる前にぜひ考えてみて欲しいです。

結論

まず結論から紹介させてください。スクラムイベントがうまくいっていない時は、大抵の場合別のイベント等に原因があります。要は準備やインプットが足りていません。事前条件が整っていないがゆえにチームメンバーがそれぞれ別のことを志向して意思決定がしにくかったり、不確定要素が多くてコミットメントがしにくいという現象が発生します。それぞれのイベントがうまくいかない場合に対応して改善を試みるイベントとして自分は下記を意識しています。

うまくいかないイベント	改善を試みるイベント
スプリントプランニング	リファインメント、スプリントレビュー
スプリントレビュー	スプリントプランニング、リファインメント
スプリントレトロスペクティブ	スプリントプランニング、スプリント（スプリント中の活動全般）
デイリースクラム	スプリントプランニング

スクラムイベントではありませんが、リファインメントがうまくいかない場合は大抵プロダクトゴール周辺に問題があります。

スクラムイベントは相互に関連している

スクラムガイドではスクラムイベント一つひとつの解説が載っています。しかし、それぞれのイベントは独立して存在しているわけではありません。それらはスクラムイベントのインプットとアウトプットを通じて、互いに深く関連し、循環的なフィードバックループを形成しています。

スクラムイベントを個別の事柄として捉えるのではなく、相互にインプットとアウトプットを持つシステムとして理解することが、スクラムイベントを効果的に改善する鍵となります。この循環がうまく機能しない時にスクラムイベントは機能不全に陥ります。したがって、スクラムイベントの改善を試みる際にはそのイベントが何に依存しているのかを考えることが重要です。

具体的に考えてみましょう。

スプリントプランニングがうまくいかない時

例として「スプリントプランニングが時間内に終わらない」という問題を考えてみます。時間内に終わらない原因のほとんどはチームでの意思決定がうまくできないからでしょう。

ここで、過去の自分のチームでは「どうしたらいろんな意見がある中で1つの意見にまとめられるか」という観点で実験を実施していました。例えば「スプリントプランニングで意見が割れたら最終的にはプロダクトオーナーが決める」というアイデアを採用した場合「スプリントプランニングが時間内に終わらない」という課題は解決できそうです。

しかしながらこのアイデア、実はあまり賢明ではありません。なぜかというとうまくいかなかった場合に、チームで原因を究明し改善するのが困難であるためです。この意思決定方法でスプリントに問題があった場合、レトロスペクティブでは何を振り返るのかを考えるとわかりやすいです。プロダクトオーナーの意思決定が原因だとすれば、責任を特定するのは容易ですが、チームとしての学びにはつながりにくいです。チーム全体で問題に向き合う機会が失われ、根本的な改善が見送られてしまうことになります。

一方で「なぜ意思決定ができないのか」という問いを立てると別の解決策が見えてきます。スプリントプランニングでの意思決定が滞る主な原因として、プロダクトバックログアイテム（PBI）が「生煮え」の状態であることや、チームメンバー間でプロダクトや開発の方向性に対する「目線が揃っていない」という状況が挙げられます。例えば、PBIの目的や詳細が曖昧であれば、開発者は具体的な計画を立てにくく、コミットメントも困難になります。また、チームが共通のゴールを明確に認識していなければ、どのPBIから着手するのが良いのか、プロダクトゴール達成のためのアプローチについて意見が分かれやすくなります。

これらの課題は、スプリントプランニングよりも前の段階、すなわちリファインメントが適切に行われていない、あるいはスプリントレビューで顧客から良いフィードバックが得られていないことに起因している可能性が高いです。スプリントプランニングに必要なインプットが不足しているために、その場で多くの議論が必要となり、結果として時間超過につながっています。自分のチームではそれまで任意参加だったリファインメントを必須参加とすることでプランニング時点での疑問を抑制し、スムーズに進めることができました。最適な対応かはわからないですが、スプリントプランニングの問題を解決するためにはリファインメントを改善する必要があるという一例だと考えています。

このブログを書いたきっかけ

これまでスクラムチームで開発者として活動する中で、上記のような「スクラムイベントがうまくいかない」という課題にしばしば直面してきました。当時の自分は考え方として「とにかく問題を小さくして対策を試みる」というのが癖になっていました。これを続けてもどうもうまく問題が解決していきませんでした。今思えば、この考え方はスクラムイベントが相互に関連していて互いが互いのインプットであり、アウトプットになっていることを無視していたのだろうと思います。ある時チームのスクラムマスターからひとつ前の段階の改善を提案されて実施したところ驚くほど上手に問題が解決したことをよく覚えています。

この経験を通じて、スクラムイベントは単独で存在するのではなく、インプットとアウトプットで繋がれた一つのシステムとして捉えることの重要性を強く感じました。この視点を持つことで、問題の原因を見つけやすくなり対症療法でない対策を講じることができるようになりました。

この考え方は、システム思考と呼ばれています。もしスクラムをやっていて何か改善が行き詰まっている方がいればぜひ一冊で良いので本を読んでみてください。自分が読んだ書籍を一冊紹介しておきます。

https://www.amazon.co.jp/dp/B00SUT1ODK