ソニックガーデンさんの記事、「ふりかえり」を効果的にするための実践的なトライの出しかた 〜 TRYを掛け声で終わらせない を読んでいて、「よくまとまっていい記事だなぁ」と思ったのですが、「でもちょっと違うところもあるなぁ」と思ったので、その辺について書きます。

ふりかえりについて

僕のところでも、ふりかえりは実施していて、一般的な KPT でやっています。KPTについて、説明するのは面倒なので、先ほどの記事から引用させてもらいます。

KPTは、Keep/Problem/Tryの略で、「Keep＝よかったこと」「Problem＝悪かったこと」「Try＝次に試すこと」を洗い出すシンプルな方法です。

僕のチームでは、1週間のスプリントで開発をしていて、火曜始まり月曜終わりなので、月曜のレビュー(スプリントレビュー)が終わった後に、ふりかえりを実施しています。

で、ふりかえりでは、Problem(問題や困ったこと)を中心に色々意見を出し合ったりして、Try を考えています。で、最後に実施したい Try を決めてふりかえりを完了させています。ちなみに時間は最大1時間、1週間スプリントなので、連休とかあってあまり作業時間が取れない時は短く終わることもあったりしますが、大抵目一杯時間使っています。

Try について、「Try が Try されない問題」

さて、前掲の記事にあるようなイメージで頑張って Try を考えたりしていたのですが、初めの頃は「Try が Try されない問題」が割とよく起こりました。ひどい場合だと、翌々週くらいに全く同じ Problem が出て、「あ…これ前も同じこと言ってね？」とか。。。

これを僕達のチームでは「Try が Try されない問題」と呼んでいます。

原因は大きく分けて 2 つだと考えています。

1. 忘れる
2. 課題が大きすぎて結果的に何もできなくなってしまう

人間ですからね。仕方ないですね。

あらためて、ふりかえりについて

スクラムにおいては、「ふりかえり」はチームを強くするために実施するプロセスです。冒頭、「ちょっと違う」と書いたのは、なんかこれって個人毎に実施する内容っぽくね？って思ったからです。(冒頭の記事はスクラムのプロセスとしてではなく、メンターとしてふりかえりを活用って書いてあるから仕方ないのかもしれないけど。)

結果的に一人しか作業できないタイプのタスクはもちろんありますが、スクラムチームを組んでいる限り、タスクであれば基本的にはチームの誰かがやれば良いし、ルールなら全員が守るべきものです。だから、ふりかえりからフィードバックされた内容は、個人のものではなく、チームとして取り組むべきものである、と僕達は考えました。

解決策っぽいこと

チームとして取り組むべきであれば、それはチームのタスクです。そこで、ふりかえりの内容(特にTry)を振り返るタイミングを、「次回のふりかえり」ではなく、「次回のタスクを決めるタイミング」に変えました。スクラムでは計画ミーティングの2部で、チームとして取り組むタスクの洗い出しと決定をします。

なので、ふりかえりの内容を計画ミーティング2部で振り返って、チームのタスクに反映させています。

計画ミーティングの冒頭では、以下2つのことをやっています

• 前回の Try の確認
• 今回の Try の確認

なぜ2回分？と思われるかもしれませんが、これは元の「課題が大きすぎて結果的に何もできなくなってしまう」問題に対応するためです。今回の分(直前のTry)は割とサクサクとタスクとして登録していくのですが、その中で残ってしまったもの(すなわち前回のTry)は、「実はそんなに深刻でないから放置された」ものか、「課題がでかすぎて何もできなかった」ものである可能性が非常に高いです。

そこで、前回の Try を確認しつつ、残った問題について、より細かいタスクに分割するとか、重要ではないから放置 or 削除する、といった事を決めています。

まとめっぽいこと

と、いうわけで、ふりかえりの確認を翌週のふりかえりではなく、直後の計画ミーティングでタスク決めするときに一緒にやるといいかも、と言うお話でした。僕は絶対こっちの方がいいと思うのだけど、ふりかえりとかKPTとかスクラムについて書かれた本を読んでも、「計画ミーティングでやる」っていうの見たことないのですが、どうしてなんでしでしょう、謎です。