TL;DR
- ベロシティを安定させたくて、4人チームでスプリントレトロを半年間回した
- 数値（達成率・標準偏差・Cycle Time）を見ることで計画と実行を改善できた
- ただし同じアジェンダではレトロは形骸化する
- 課題が見つからなくなったら「レトロのやり方」を振り返る（メタレトロ）
- レトロの目的はイベントを回すことではなく、計画→実行→改善を回すこと
はじめに
こんにちは。フォトラクション Android エンジニアのさいとうです。
ここ半年ほど4人チームでスプリントレトロを継続的に実施してきました。
この記事では、
- なぜスプリントレトロを始めたのか
- どんなやり方で回してきたのか
- 何がうまくいき、何が形骸化したのか
- そして最後に「メタレトロ（レトロのレトロ）」をやって何が見えたのか
について書きます。
「レトロって本当に意味あるの？」
「やってはいるけど、正直惰性になっている」
そんな感覚を持っている人に読んでもらえたら嬉しいです。
スプリントレトロを始めた動機：ベロシティを安定させたかった
レトロを始めた一番の理由は、ベロシティを安定させたかったからです。
- 計画したストーリーはどれくらい達成できたのか
- 計画と実行はどれくらい乖離していたのか
- なぜその乖離が起きたのか
- 次にどう改善するのか
これらをチームとしてきちんと評価・学習する場がありませんでした。
アジャイルの文脈では
「計画と実行の乖離は失敗ではなく学習の機会」と言われます。
ただ、学習するタイミングがなければ、それはただの理想論です。
また、アジャイルであろうとなかろうと、
- チームが計画し
- チームが実行し
- そこに乖離があるなら
その説明責任はチームにあります。
原因を知り、改善するところまで含めて、チームの責任だと考えています。
実際にやっていたスプリントレトロ
基本情報
- チーム規模：4人
- タイミング：スプリント終了〜次スプリントのプランニングの間
- フレームワーク：KPTは使わず、Notionに作った固定アジェンダ
- 目的：感想ではなく「計画と実行の差分を分析し、次に活かす」
KPTはどうしてもダレやすく、「良かった」「困った」で終わりがちだったため、
あらかじめ問いを固定したアジェンダ制にしました。
レトロのアジェンダ概要
1. 留意点の確認
- 実装の詳細や技術の深掘りはしない
- SPイベントでどう修正できるかを話す
- 自分たちがコントロールできる範囲の話に限定する
- 外部依存は現状共有まで
- 同じ問題を何度も出さないための改善を考える
- 大きな問題は分割して扱う
2. カンバン（恒久ルール置き場）
レトロで決まった「恒久的に守るルール」を記載する場所です。
一時的な対処ではなく、
今後もずっと効くルールを残すために設けました。
後に、
ルールの多くがリファインメント関連だと分かり
「リファインメントルールブック」として別ドキュメントに切り出しました。
3. 前回の Next Action の確認
- 前回決めた改善アクションは実行されたか？
- 実行されていないなら、なぜか？
4. ベロシティレポートの確認
- JIRA のベロシティレポートを確認
- 計画 / 実績 / 達成率を記録
数字を見ずに振り返ることはしませんでした。
5. ベロシティの標準偏差
- 過去5スプリントの標準偏差を算出
- チーム目標：10以下
- 未達の場合は原因分析
「平均」ではなく「ブレ」を見るためです。
6. Findy Team+ による開発フロー分析
- Cycle Time を確認
- Open → Review
- Review → Approve
- それぞれ平均24時間以内を目標
スプリント内での滞留がなかったかを確認しました。
7. 振り返り（目標達成）
- スプリント開始時に設定した目標は達成できたか
- 未達なら、なぜか
8. 計画と実績の所感共有
- 各メンバーがスプリントの所感を記入
- うまくいかなかった点を中心に分析
9. 次のスプリントまでの Next Action
- 次回までにやる改善を決める
- 実行することを約束する
レトロをやってよかったこと
一番大きかったのは、
- 計画の立て方
- リファインメントのやり方
を構造的に改善できたことです。
具体的な改善例
リファインメントはキックオフから1スプリント以内に終わらせる
- 問題：リファインメント精度が低い
- 分析：キックオフ時の説明が忘れられている
- 改善：リファインメント完了期限を明確化
見積もりはチームでプランニングポーカーを行う
- 問題：ストーリーの認識ズレ
- 分析：「どこまでやるか」の理解が人によって違う
- 改善：必ずチームで見積もる
結果として、
- 課題を見つける力
- 計画と実行に対する責任感
がチーム全体に生まれたと感じています。
そして形骸化した
6月から始めたレトロは、11月頃には初期に作ったアジェンダでは改善点が見つかりにくくなりました。
- 毎回同じ項目
- 大きな問題はすでに潰れている
- 「特にないですね」で終わる空気
レトロ自体が悪いわけではなく、やり方が今のチームに合わなくなっていたのだと思います。
メタレトロ：レトロを振り返る
レトロはスプリントの結果を振り返る場
メタレトロは、その振り返り方を振り返る場
現状のレトロアジェンダをすべて棚卸ししました。
やったこと
- Miro 上にアジェンダを並べる
- 各項目を10点満点で評価
- コメントを書いてもらう
- 合計点が低いもの、不要と感じられているものを削除
メタレトロで得た気づき
レトロを通じて、チームの共通認識はかなり揃ってきていると感じました。
だからこそ、同じ切り口では新しい課題が見えなくなっていました。
しかしこれは悪いことではなく、チームが成熟してきたサインだと思っています。
メタレトロ後に変えたこと
アジェンダを更新して「達成率に影響したこと」という項目を追加しました。
- スプリントレポートをより丁寧に見る
- 気になる点があれば、そこを深掘りする
有効かどうかはまだ分かりませんが、「有効か分からないが試す」という意思決定自体がレトロの成果だと思っています。
おわりに
計画したら、
- 達成したかどうかを見る必要があります
- 結果の責任は、計画したチームにあります
- 未達なら、原因を知る必要があります
- 改善する必要があります
- それもチームの責任です
この改善が回るなら、必ずしもレトロスペクティブである必要はないと思っています。
大事なのは名前ではなく、計画・実行・振り返り・改善 が回っているかどうか。
もしレトロに「意味ある？」と感じているなら、
それはやめ時ではなく、変え時なのかもしれません。
みなさんはレトロが効かなくなったときどうしていますか？ 👀
今回、レトロが形骸化してきたタイミングで
「レトロのやり方自体を振り返る（メタレトロ）」をやってみました。
個人的には、
- 課題が出なくなった＝レトロが不要 ではなく
- 課題が出なくなった＝切り口が今のチームに合っていない
という状態だったのかなと感じています。
ただ、これはあくまで自分たちのチームでの話です。
- レトロをやめたことがある人
- レトロの頻度を減らした人
- KPT 以外でうまく回っているやり方がある人
- レトロという名前にこだわらず改善を回している人
もしよければ、
「レトロが効かなくなったとき、どうしているか」 をコメントで教えてもらえると嬉しいです。
