[スクラム]スプリントレトロスペクティブの定義と運用事例（後編）（2024 Advent Calendar 9日目）
この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の9日目の記事です。このアドベントカレンダーは「ある機能開発チームでスクラム, XP, DevOps を一度に実践したら真のアジャイル開発ができた」という内容です。執筆者は全てプログラミングをするパンダです。
スプリントレトロスペクティブで改善したこと
後編ではレトロスペクティブで共有された課題とその改善策を5つ紹介します。
- デイリーの形式化を防ぐために、デイリースクラムの質問事項を適宜変更する
- コミュニケーション不全を解消するために、デイリースクラム後に情報共有の時間を設ける
- 毎日進捗を出すために、作業をバッチ単位に細かく分割する
- 業務外のコミュニケーション機会を増やすために、雑談の時間を設定する
- 夜遅くまで働くことを回避するために、時間が来たらキリの悪いところであっても作業を切り上げる
改善その1: デイリーの形式化を防ぐために、デイリースクラムの質問事項を適宜変更する
チームがスクラムに慣れてくると朝会がマンネリ化し始めました。
朝会（デイリースクラム）は検査と適応を目的とした場です。当初はエッセンシャルスクラムに掲載されている3つの質問「昨日は何をしましたか」「今日は何をしますか」「進捗の妨げとなる障害物は何ですか」をスクラムマスターがチームに尋ねていました。しかし、カンバン形式のスプリントバックログを見るだけで全員の進捗状況が誰でも把握できることから、進捗共有を促す質問は次第に行われなくなりました。
代わりに、確認不足や勘違いによるミスコミュニケーションを防ぎ、メンバーにスプリントゴールを意識させるための新しい質問が取り入れられるようになりました。それらの質問は全て、振り返りで得られたチームの新しい試みをデイリースクラムの質問に落とし込んだものです。それぞれの質問には、チームが学び取った経験や失敗からの反省が背景にあります。
以下は、プロジェクト最終段階の朝会での質問の一部です。
・ポイントを変更するべきタスクはありますか？ ・タスクを進める上で困っていることはありますか？ ・スプリントゴールの達成に影響があるアイテムはありますか？
「ポイントを変更するべきアイテムはありますか？」という質問は、スクラムを始めたばかりの頃にアイテムを消化しきれず大量のポイントを残したままスプリントを終えてしまった苦い経験が元になっています。当時の振り返りでは、スプリントゴールを達成するためにどうすれば良かったのかを議論し、スクラムマスターが「次回は適切なタイミングで進捗状況を見直し、ポイントを振り直すべきではないか」と提案しました。
このスプリントではアイテムのポイントが着手後に見積もり時より大きいということがわかってもポイントを変えていなかったからです。アイテムのポイント数が変わらないため、形式上はそのスプリント内で全てのアイテムに対応できることになっていたのです。
これをきっかけに、スプリント中でもアイテムのポイントを調整したり、タスクを追加・分解する柔軟な対応をしてもいいんだ、むしろそうするべきだという意識がチーム全体で共有されました。
この新しい質問は進捗が芳しくないという朝会で少し気が引ける共有であっても、以前より気軽に話せるようにする効果を生みました。メンバー全員がこの質問を聞くたびに「あのときの失敗を繰り返さないようにしよう」と意識するようになったのです。
ただし、この質問はあくまで自分たちのチーム特有の経験から生まれたものです。別のチームの朝会で最初からこの質問を取り入れてもうまく機能しないかもしれません。デイリースクラムの質問は、各チームが自分たちの経験を活かして自分たち流にアレンジしていくことが大切です。
チームメンバーは朝会の各質問がどのような背景から設定されたのかを覚えています。レトロスペクティブでは個人が取り組んだアイテムのゴールを達成できなかった場合でも、その原因をチームみんなで考えます。そして、次スプリント移行で同じようなアイテムに取り組む際に同じ失敗を繰り返さない仕組みを作ります。デイリーの質問こそ再発防止の仕組みなのです。
朝会の質問は上から形式的に尋ねていけばいいという単なるチェックリストではなく、チーム全体の学びの結晶化です。デイリースクラムを通じてチームは自己組織化を進め、徐々にスクラムの成熟度を高めます。興味深いことに、振り返りを経るたびに質問の数は増えたものの、朝会にかかる時間はむしろ短縮されました。それは全員が質問の意図を深く理解し、より効率的に朝会を進められるようになった結果です。この改善プロセスとその成果こそがチームの成長の証なのです。
改善その2: コミュニケーション不全を解消するために、デイリースクラム後に情報共有の時間を設ける
スクラムを始めた当初、チームの朝会では他チームで行われていた一般的な形式を踏襲し、各メンバーが順番に「前日にやったこと」「当日にやること」「進捗に支障が出る不安要素や確認事項」について報告していました。朝会の時間は11時45分から12時までの15分間と設定されており、当初は時間内に終わっていました。しかし、開発が進むにつれて確認事項や相談事項が増え、次第に15分では収まりきらなくなりました。
スプリントレトロスペクティブでこの問題が話し合われた際、あるチームメンバーが「朝会の時間を30分に延長してはどうか」と提案しました。それに対し、スクラムマスターは次のように説明しました。「エッセンシャルスクラムにはデイリースクラムは必ず15分以内にすると書かれています。また、デイリースクラムの目的は、あくまでスプリントゴールを達成するための検査と適応の場です。だから、デイリースクラムの時間は変えずにいきましょう。その代わり、朝会の後にもう15分間、相談や共有のための時間を設けるのはどうでしょうか？」
この提案はチームに受け入れられ、朝会終了後に設けられることになった追加の時間は「一言共有会」と呼ばれるようになりました。一言共有会は、相談事項がある場合にはチーム全員で議論する場として機能しますが、特に相談がない場合には雑談をすることも許容されています。この取り組みが始まってから、デイリースクラムでは話が脱線することがなくなり、目的であるスプリントの「検査」と「適応」に集中できるようになりました。一方、一言共有会ではデイリースクラムで話しきれなかった懸念事項や開発者同士の相談など、徹底的に議論できるようになりました。
一言共有会で話し合われる内容には、例えば以下のようなものがあります。プロダクトオーナーからのアナウンスや、他チームへの相談結果の共有、データベース設計の相談や新しい概念ができたためユビキタス言語を考え直そうといった議題、大きめのリファクタリングの方針共有などです。こうした具体的な相談や共有は、デイリースクラムの15分には収まりません。一言共有会という追加の時間があることで、これらの重要な議題について時間を気にせず十分に話し合うことが可能となりました。
結果的に、デイリースクラムはより効率的になり、本来の目的である「スプリントゴール達成のための検査と適応」に専念できる場になりました。一方、一言共有会を通じてチームの連携やコミュニケーションはさらに強化され、スプリント全体の成功にも寄与しています。この取り組みは、形式やルールに縛られるのではなく、チームが直面した課題を振り返り、柔軟に改善を行うというスクラムの本質を体現するものだと言えるでしょう。
改善その3: 毎日進捗を出すために、作業をバッチ単位に細かく分割する
スプリントを繰り返すうちに、アイテムのポイントが5を超えたら見積もりの精度が悪くなることがチーム内で共通認識となりました。そこでリファインメントによって5以下に分割するルールが導入されました。
この方針はチーム全体に共有され、8以上と見積もられたアイテムについては、スプリントプランニング前かデイリースクラム後にリファインメントを実施するようにしました。その結果、アイテムのポイントサイズが小さくなり、多くのアイテムが1日や2日で完了するようになりました。
コンスタントにアイテムを消化することでベロシティが安定し、アイテムがスプリントレビュー直前に一気に駆け込みで消化されるような事態を回避できるようになりました。スプリント中、毎日更新されるバーンダウンチャートも綺麗な右肩下がりを描くようになり、安心感を持って毎日を迎えられました。
一つのアイテム単位が小さいので、デプロイ頻度も向上しました。するとチーム内では「毎日進捗がある」という達成感が広がり、チーム全員のモチベーションが目に見えて上がりました。チーム全体が「小さな成功体験を積み重ねる」という習慣を定着させることができ、結果的にチームの生産性と士気の向上に寄与したのです。
改善その4: 業務外のコミュニケーション機会を増やすために、雑談の時間を設定する
あるレトロスペクティブで「仕事ばかりで事務的な関係だから雑談をしたい」という課題が挙げられました。ペアプロをしているため朝から夕方まで仕事に関する会話は頻繁に行われているものの、業務外でのコミュニケーションが不足しているという意識が背景にありました。そこで、毎日夕方18:45から15分ほど雑談をする「夕会」を始めるというアイデアが採用されました。
この夕会は任意参加であり、参加を強制される雰囲気は全くなく、気軽に参加できる場となっています。ただ、リモート勤務下で雑談会を何度か繰り返すうちに話題が尽き、天気の話しか出てこないという問題を耳にしたことがありました。そのため、チームではスプレッドシートを用意し、事前に雑談テーマを記載しておく仕組みを取り入れました。雑談テーマは質問形式です。スプレッドシートに質問を投稿する際、質問者が特定されないようにラジオネームを使って記入するルールとしました。これにより、気軽に多様な話題が集まり、会話が盛り上がる工夫がされています。
（添付画像：雑談の「お便りボックス」スプレッドシート）
この仕組みのおかげで、その日のテーマを全員で共有して各自が順番に答えるスタイルが定着しました。話題が事前に準備されているため会話がスムーズに進み、参加者全員がリラックスして雑談を楽しめるようになっています。
ただし、チーム外の方との雑談については、まだ良い方法を模索中です。以前、レビュー会に参加する法務チームやセキュリティチームのメンバーを夕会に招待したことがありました。この取り組みは一度だけ実施され、カジュアルな雰囲気で行われたものの、それ以降チーム外の人が夕会に参加することはありませんでした。チーム外の人が気軽に参加できる場を作るには、さらなる工夫が必要であると感じています。ただ、他チームの会に参加すること自体にそもそもハードルがあるのかもしれません。
この取り組みについてTwitter（当時）で紹介したところ大きな反響がありました。雑談会という形式は簡単に始められるため興味のある方はぜひ試してみてほしいと思います。
https://twitter.com/Panda_Program/status/1544671306599505920 （添付画像：Twitter投稿のスクリーンショット）
改善その5: 夜遅くまで働くことを回避するために、時間が来たらキリの悪いところであっても作業を切り上げる
雑談をする夕会を1日の終わりに設定したことで、作業を途中でも区切り、退勤する習慣がチーム内で定着しました。
それまでは、作業をキリのいいところまで進めようとするあまり、退勤時間が時折22時や23時にまで及ぶメンバーがいました。また、スプリントレビューの前日には、全てのスプリントゴールを達成するために夜遅くまで作業するメンバーも少なくありませんでした。
しかし、プロダクト開発は短距離走ではなくマラソンのようなものです。残業過多によるメンバーの燃え尽きやモチベーションの低下を避けつつ、3ヶ月や半年以上の長期的なスパンで持続的に開発を続けていく必要があります。プロジェクトはそこで終わってもその会社で働く時間はもっと長い年単位です。プロジェクトのために頑張るいい人が燃え尽きて退社してしまうことを一番避けなければなりません。
そこで、夕会の時間を作業の区切りとして活用し、雑談が終わったら退勤するという新しい習慣をチーム全体で取り入れることにしました。
この取り組みによって、メンバーは仕事を切り上げるタイミングを意識的に作れるようになり、疲労感を持ち越すことなく翌日にフレッシュな状態で業務に取り組むことが可能になりました。結果として、チーム全体のパフォーマンスが向上し、無理なく持続的にプロダクト開発を進められる環境が整ったのです。
夕会は単なる雑談の場としてだけでなく、働き方の見直しを促進する重要な役割を果たしています。このような仕組みが、メンバーの健康と生産性の両方を支える好例であるといえます。
スクラムのまとめ：スクラムとは軽量級のフレームワークであり、チーム独自のプラクティスを実践する場である
レトロスペクティブは、チーム独自のプラクティスを生み出す可能性を秘めています。実際、自分のいるチームでは「デイリーの後の一言会」と「雑談をする夕会」という独自の手法を編み出しました。他のチームでも、それぞれの課題やニーズに応じて独自のプラクティスを生み出していることでしょう。
エッセンシャルスクラムは次のように述べてスクラムがチームごとに独自の形を取ることを指摘しています。
スクラムは標準化されたプロセスではない。（中略）スクラムは作業をまとめ上げ、管理するためのフレームワークだ。このスクラムフレームワークは価値、原則、プラクティスに基づいている。それらを基礎として、組織にあったエンジニアリングプラクティスや、スクラムのプラクティスを実践するための具体的なアプローチを追加できる。その結果として現れるのは、あなた独自のスクラムである。 （エッセンシャルスクラム p.14。太字は筆者）
スクラムは標準化されたプロセスではなくフレームワークとして設計されています。フレームワークであるため、スクラムの価値・原則・実践をチームや組織に適した独自の方法で実現することが想定されています。こうした独自の実践によって現れるのが「あなた独自のスクラム」です。
ただし、この柔軟性には注意点もあります。スクラムガイドに記載されているスクラムフレームワークの一部そのものを削って「軽量化」することは推奨されていません。独自プラクティスの追加は許容されていますが、スクラムフレームワークそのものは不変であるべきです。スクラムガイドはこの点を以下のように説明しています。
スクラムは無料であり、本ガイドで提供されるものである。ここで概要を述べたように、スクラムフレームワークは不変である。スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない。すべてを備えたものがスクラムであり、その他の技法・方法論・プラクティスの入れ物として機能するものである。 （スクラムガイド）
したがって、スクラムを実践する際にはフレームワークそのものを損なうことなく、必要に応じて独自プラクティスを追加することでチームに最適な形を作り上げるべきです。デイリーでの質問をチーム独自のものに変更したり、「一言会」や「夕会」もスクラムの価値や原則を守りつつ、チームの働き方を改善するための具体的なアプローチの一例です。
スクラムフレームワークを基盤としつつ、自分たちに合った新しいプラクティスを試行錯誤し、独自のスクラムを作り上げる。それこそがスクラムが本来持つ柔軟性と力強さを活かす方法なのです。
Happy Coding 🎉
