私達の所属する部署ではプロダクト開発の手法として、複数チームでスクラムを導入しています。
今回は、有志でスクラムガイドを読み合わせし、そこから得た気づきを紹介します！
読み合わせをしたスクラムガイドはこちら
（本文中の引用は、以下のリンクからのものです）
スクラムガイド読み合わせの概要についてはこちら
別トピックの記事も書いています！
トピック3: スクラムガイドの読み合わせによって、組織の目標と課題が明確になった？！
スプリントレビューの⽬的は、スプリントの成果を検査し、今後の適応を決定することである。スクラムチームは、主要なステークホルダーに作業の結果を提⽰し、プロダクトゴールに対する進捗について話し合う。
「作業の結果を提示」することは、当たり前に感じられ（作業したことを示さずにスプリントの成果は検査できないですから）、深く意識せずにできていそうでした。
一方、「プロダクトゴールに対する進捗について話し合う」から気付かされることがありました。果たして自分のチームはプロダクトゴールに対する進捗を話し合えているのだろうか。
その点について意見を交換していると、大きなアクション・結果が生まれました。
感想
次のような感想がポンポンと出てきました。
- レビューでプロダクトゴールではなくチームのOKRについて進捗を話しているがいいのか？
※OKR：Objectives and Key Results（目標と主要な結果）。ここでは簡単のため目標≒ゴールと解釈して書いています。 - チームのOKRは3ヶ月先で設定しているが、プロダクトゴールはより長期的で抽象的なものになりそう
- 組織のゴール→プロダクトゴール→OKR→スプリントゴール→デイリーゴールの階層になっていて、それぞれ上のゴールとの整合性も検査しないといけないよね。
- あれ、組織のゴールってなんだ。前に読んだ本に上位のOKRからチームのOKRを作りましょうって書いてあったけど、今のチームのOKRは組織のゴールと紐づかずに独立してしまっている気がする…
- 「私のチームも同じですね」「僕のチームも」
その結果、参加者は気づきました。
- 会社の目標って「売上伸ばす」「安心して使えるサービスを提供する」「コストを削減する」でしたっけ？チームのOKRはこの目標とつながっている感じがしないなあ…
- 組織の目標（スタートとしての土台）が欲しい！
アクション
ここで出た感想を踏まえてCTOに直談判しました。
「組織のOKRがないとレビューでプロダクトゴールについて話し合えません」
理解のあるCTOは急いで組織の今年度の目標と課題を整理し直し、このスクラムガイド読み合わせ会の参加者との話し合い・確認の場を持ってくれました。
話し合いを踏まえて、組織の今年度の目標と課題をエンジニア全体に共有することで、各チームが組織のゴールを基に、チームのゴールを立てることができる環境になりました。
めでたしめでたし
トピック4: リファインメントの重要性
一般的にスプリントの流れとしては下記のような形になると思います。
- プロダクトバックログからスプリント期間中に達成したいストーリーを選定
- プランニング内で議論しつつスプリントバックログの各タスクに落とし込む
- 落とし込んだタスクをスプリント期間内に消化し成果物を作成
- デイリースクラムでタスク状況などの情報を共有
- スプリントレビューで成果物の検査と今後の方針を決定
- レトロスペクティブでスプリント内での改善点や継続したほうが良い点などを確認し、チーム共有を行う
私はこの勉強会を通して上記の中でも、1と2の間に行うリファインメントが重要であると強く感じました。
議論前に感じていた問題
上記の流れの中で、私のチームがスクラムを始めてまず感じたことはプロダクトバックログ内に書き出したストーリー内に粒度が荒いストーリーがあるという事でした。
具体的にはプラニングでやると決めたストーリーをこなす中で仕様を再確認する必要が出てきたり、その結果として調査のタスクが発生したり…
また調査結果によっては別のタスクが発生してしまったりするなど想定外のタスクが発生し、想定より工数がかかってしまうなどのケースがありました。
感想
chatGPTを叩きに使い、このスクラムガイド読み合わせ会の参加者とも話し合う中で 「プロダクトバックログのリファインメントが不十分だとスプリント中に新たなタスクや優先順位が変わることがあり、これがスプリントゴールに影響を与える可能性がある」 という意見が出てきました。
スクラムガイドでは 「プロダクトバックログを必要に応じてリファインメントする」 と記載があり、また 「リファインメントの活動を通じて、選択に必要な透明性を獲得する。プロダクトバックログアイテムがより⼩さく詳細になるように、分割および定義をする活動である。これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。」 とも書いてあるものの、最初は具体的にどのタイミングで何がどこまで明確になるまで行うものなのかが今ひとつ理解できませんでしたが、議論を進める中で 「タスクに取り組む前にチーム全員がどういう方法でタスクを進めるのかが分かる状態になるまでリファインメントに取り組む必要がある」 という事を感じるようになりました。
これは透明性のひとつのケースになると思いますが、確かにどんなタスクをいつまでにどういう方法で開発するのかを全員がわかっている状態にしないとある程度正しい工数は見積もれませんし、プランニングの時間だけでそれを明確にするのはプランニングの時間が長くなりすぎてしまったり、難しい部分もあると思います。
そのため、仕様が変更された時や調査してみないとタスクの進め方がわからない場合などはリファインメントを行い、それについて調査のタスクをあらかじめ切っておいたり、仕様変更に伴いどういう方法でタスクを進めるのかを明確にする必要性を強く感じました。
アクション
私はこの勉強会を通じて出た意見をチームに持ち帰り議論した結果、チームでデイリーの後にリファインメントの必要があるかを確認するなど、適切なタイミングでリファインメントを実施できるようにする仕組みを取り入れました。
これにより、以前よりもプランニングでのストーリーの粒度を上げ、想定どおりの工数で開発を進められるパターンも増えてきました。
まとめ: スクラムガイドの読み合わせで組織の課題とプロセス改善の重要性を再認識
本記事では、プロダクトゴールと組織目標の関係性・リファインメントの重要性について紹介しました。
組織の目標との整合性やプロダクトゴールの重要性を再認識し、さらにリファインメントの適切な実施がスプリントの精度を高めることを学びました。
以下に簡単なまとめを記します。
- スプリントレビューの目的は「作業の結果を提示すること」だけでなく、「プロダクトゴールへの進捗を話し合うこと」にある。
- 組織のゴールが不明確だと、チームのOKRが独立してしまい、目標が空中分解するリスクがある。
- 組織→プロダクト→チーム→スプリントといった目標の整合性を検査する視点が重要。
- リファインメントを適切に行わないと、スプリント中に想定外のタスクが発生し、計画が乱れる。
- リファインメントの目的は、チーム全員がタスクの進め方を理解できる状態にすること。
アクション
- CTOと対話し、組織のOKRを明確にする場を設け、全体に共有。
- スプリントレビューの際に、プロダクトゴールとの整合性を意識するようにする。
- デイリースクラム後にリファインメントが必要かを確認するステップを導入。
- プランニング前にストーリーの粒度を上げるためのリファインメントを実施し、調査タスクを適切に切る。
スクラムのフレームワークを活用しながら、組織の目標とチームの目標の適切なリンクを強化し、より計画的かつ効果的な開発を進めていきたいと思います！
ブログ協力者
本記事は以下のメンバーで執筆を行いました！
Discussion