以下の内容はhttps://tech.layerx.co.jp/entry/2025/04/11/122639より取得しました。


スプリントレトロスペクティブを改善した話

こんにちは、バクラク債権管理 & 債務管理 エンジニアの @noritama です!

アジャイル開発におけるスプリントレトロスペクティブは、チーム運営を改善し成果を最大化していくための重要なプラクティスです。 しかし、運用方法によって形骸化してしまったり、期待した効果が得られなかったりすることもあります。

私たちのチームでは、以前はKPTフレームワークを用いたシンプルな振り返りを実施していましたが、いくつかの課題を抱えていました。 今回は、振り返り会のアジェンダを見直すことで振り返りの改善をした話をします。

以前の振り返りが抱えていた課題

従来のKPTによる振り返りでは、主に以下の3つの課題がありました。

1: Keep/Problemが定性的になり納得感が得られにくい

メンバーから出されるKeepやProblemが、「なんとなく良かった」「ちょっとやりにくかった」といった主観的・感覚的なものが多くありました。 具体的な事実やデータに基づかないため、他のメンバーが共感しにくく、議論が深まらなかったり「本当にそれが問題なのか?」という疑問が残り、納得感を得にくい状況でした。

2: ProblemからTryを決める議論が白熱し、時間内に収まらない

Problemとして挙がった課題に対して、具体的なTryを決める段階になると、様々な意見が飛び交い議論が発散してしまうことがありました。 それぞれのメンバーが課題に対する考えを持っているので、議論が白熱するのは良い面もありますが、限られた時間内に合意形成を図ることが難しく延長や中断してしまうケースが発生していました。

3: Tryが具体化せず、アクションに移せないままになってしまう

時間内に議論がまとまらなかったり抽象的なTryしか設定できず、具体的なアクションプランに落とし込めないことがありました。 誰がいつまでに何をするのかが曖昧なまま振り返りが終了し、Tryが実行されないまま放置されてしまう。 そして、次の振り返りで同じようなProblemが繰り返し挙げられる…という悪循環に陥っていました。

このような課題は、チームの改善サイクルを停滞させ、振り返り自体の意義を薄れさせてしまう可能性がありました。 そこで、私たちはこれらの課題を解消して、より効果的で生産的な振り返りを実現するためにアジェンダの見直しを行いました。

新しい振り返りのアジェンダと工夫

課題解決のため、私たちは以下の点を重視して新しいアジェンダを設計しました。

  • 事実に基づいた振り返りの促進
  • 明確なゴール設定と時間管理
  • Tryの具体化と実効性の担保

以下で、アジェンダの各ステップとその狙いを説明します。


1: 目的とゴールの明確化 (0min)

まず、ミーティングの冒頭で、振り返り会の目的とゴールを全員で確認します。

目的: スプリント内で行ったプロセスを振り返り、共有・議論を行うことで、次回以降のスプリントの品質やパフォーマンスを高めること。
ゴール: 次回スプリントで取り組むTryとそのオーナーを決定すること。

これを最初に宣言することで、参加者全員が「この会議の中で何を目指すのか」を意識し、議論が脱線しにくくなります。

2: 事実ベースの振り返り(スプリントの出来事)(10min)

次に、そのスプリントで「何が起こったか」という客観的な情報を共有します。これは、定性的な議論に偏りがちだった課題への対策です。

あったこと: 事前にSlackでスプリント中に印象的だった出来事を募集しておきます。(例:「〇〇機能のリリースが無事完了した」「△△で予期せぬ手戻りが発生した」など)
SP (ストーリーポイント) 実績: スプリントチケットから見積SPと実績SPをグラフで可視化して共有します。計画通りに進んだか、見積もりとの乖離があったかなどを把握します。
Released (リリース実績): 本スプリントでリリースされた機能や修正内容をリストアップして共有し、チームの成果を確認します。

このステップで全員が同じ事実情報を認識することで、その後のKPTでの議論をより具体的で建設的なものにする土台を作ります。

3: KPTの実施とTry決定 (40min)

ここが振り返りの中心部分です。従来のKPTをベースにしつつ、課題解決のための運用ルールを加えています。

KPTのゴール設定: 次回までに取り組むTryを1〜2個に絞って具体的に決定します。 Tryは、できる限り具体的なアクションプランにまで落とし込みます。 決定したTryはNotionに記録し、オーナーを明確にします。

進め方:
1: KPT記入
NotionDBにKeep/Problem/もやもやを記入します。

  • Keep: チームとして取り組み続けたいこと
  • Problem: チームとして改善したいこと
  • もやもや: 個人として気になっていること

2: 発表
1人ずつ記入内容から特に伝えたいことをピックアップして発表します。

3: 共感
他の人の意見で共感するものには、「わかる」ボタンで意思表示します。

4: Try決定
共感度が高いProblemを中心に、具体的なTryを議論して決定します。

実際のKPTで使用しているNotionDB

工夫点:

  • 「もやもや」カテゴリで、小さな懸念も拾い上げやすくしつつ、チーム課題とわけることで議論を発散しにくくしています。(「もやもや」に書いたものが意外と共感され、実はチームで取り組むべき課題だったということがわかることもあります。)

  • 「共感度」で議論の優先順位をつけることで、時間内に効率的にTryを決定できるようにしています。以前はすべてのKPが集まってからカテゴライズして関心の高いものに投票する、という形式をとっていたのですが、発表を聞きながら「わかる」を押すことでリアルタイムに優先順位がつけられるので時短ができています。

  • Tryの数を絞り、具体的なアクションとオーナーを明確にすることで実行可能性を高めています。

4. Tryの進捗確認と実行性の担保 (10min)

Tryがアクションに移せず形骸化してしまう課題に対する解決策として、最後にこの時間を設けています。

前回の振り返りで決定したTryについて、オーナーに進捗状況を確認します。 状況に応じてステータス(未着手、進行中、完了など)を更新します。

このステップにより、「決めただけ」で終わらせず、改善サイクルを確実に回していくことを目指しています。
オーナーに進捗報告を求めることで、Tryに対する責任感も生まれます。


改善による効果と変化

1: 議論の質が向上し、納得感が高まった
事実やデータに基づいた議論が増え、メンバー間の認識齟齬が減り、Problemに対する納得感が高まりました。

2: 時間内にTryを決定できるようになった
明確なゴール設定、時間配分、共感度による優先順位付けにより、限られた時間の中で効率的に議論を進めTryを決定できるようになりました。

3: Tryが具体的なアクションに繋がり、改善が進むようになった
Tryのオーナー明確化と進捗確認の仕組みにより、Tryの実行性が向上し、改善サイクルが回るようになりました。 また、同じProblemが繰り返し挙げられる頻度が減りました。

まとめ

スプリントレトロスペクティブは、やり方次第でチームの成長を大きく左右します。
私たちのチームでは、以前のKPT運用における課題を特定し、アジェンダを見直すことで効果的な振り返りを実現することができました。

もし、振り返りの運用に課題を感じているようでしたら、今回ご紹介したアジェンダや考え方が参考になれば幸いです。
振り返りは一度決めたら終わりではなく、それ自体も改善し続けていくことが大切です。チームに合った最適な形を見つけて、継続的な改善をしていきましょう!




以上の内容はhttps://tech.layerx.co.jp/entry/2025/04/11/122639より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14