※この記事はAgileStudioに掲載した記事の転載です。
元記事：「今じゃないな...」ふりかえりで出たTryが忘れ去られ、同じ課題を繰り返していたチームの試行錯誤（トナリノ）

「このTry、いい案だと思うけど、今はそのタイミングじゃないかな」

あるスクラムチームのふりかえりで、何度もそんな言葉が交わされていました。

今回ご紹介するのは、KPTAでふりかえりを回しているとあるチームです。このチームは、ふりかえりで「今じゃない」と判断したTryが、実行されないまま忘れ去られ、また同じ課題に直面するサイクルに悩んでいました。

この記事は、そんなチームの試行錯誤の記録です。

トナリノは、隣のチームの泥臭い試行錯誤をそのまま届けるコミュニティです。

様々なチームの「うまくいかなかったこと」「試してみたこと」「今の現在地」を記録しています。正解やTipsではなく、あるチームのリアルな試行錯誤をお届けします。

👉 トナリノの詳細を見る

「今じゃない」と言ったあの案、次のスプリントでは？

KPTAでふりかえりを回しているチームです。Tryから具体的なActionを考えていくなかで、こんな結論になることが多々ありました。「これはいい案だと思うけど、今はそのタイミングじゃないかな」と。

仕込みが必要なもの、他の課題が片付いてからでないと着手できないもの、今のスプリントでは優先度が合わないもの──理由はさまざまです。チームとして「今じゃない」と判断したTryは、今回のActionからは外れます。

問題は、そのあとでした。

実行できるタイミングがないまま時間が経つと、その案は静かに忘れ去られていきます。そして数スプリント後、同じ課題がまたProblemとして上がります。気づけば、同じ議論を繰り返していました。

このチームで「今じゃない」になりがちだったのは、たとえばこんなTryです。

ドキュメント不足の問題へのTry
システム仕様書が少なく実コードを見ないとわからない状態に対して、「将来を見越して整備したほうがいい」という話は出ます。でも、改修自体は終わっているし、緊急性も低く、「余裕が出た時にやろうね」という結論になって、そのまま流れていきます。

コード改善・リファクタリング系のTry
たとえば環境依存のコードがあって、デプロイできる人が特定のメンバーに属人化していました。できないわけではないのですが、特定の人しかできません。レガシーコードだから改修に時間がかかります。「動いているから壊さないでおこう」──技術的負債はわかっているけど、着手するほどの状況じゃない、というものです。

どれも「やったほうがいいよね、でも、今はこれしかできないから」で諦める。そのサイクルが続いていました。

なぜ忘れてしまうのか

このチームのKPTAには、TryをActionに引き上げる流れが決まっていました。やったほうがいいものを絞り込み、その中から次のスプリントでできるものを選ぶ、という2段階です。

ただ、「やったほうがいいけど、次のスプリントではやらないもの」を後回しにするという仕組みが、フレームワーク上に存在しませんでした。やったほうがいい、でも今はできない、そういうTryが毎回宙に浮き、スプリントが終わると一緒に流れていきました。問題はTryの質ではなく、記録される場所がなかったことでした。

「今じゃないもの専用の貯蔵庫」を作った

チームはKPTAのフレームワーク内に 「TryAction Backlog（やりたいけど、今じゃないもの）」 という枠を新設しました。

ただ、最初からすべてのルールが設計されていたわけではありません。運用しながら、少しずつ整備されていきました。

バックログへの保存
「今じゃない」と判断したTryは、「いつごろなら着手できそうか」という想定と一緒にTryAction Backlogへ移動させます。時期を明示しないままTryAction Backlogに移動するものもありますが、それでも期限は後述の棚卸しルールで管理しています。

アクションの選定
次のスプリントで実行するActionは、「今回のふりかえりで出た新規のAction」と「TryAction Backlogから持ってきたAction」の2種類から選びます。

個数制限（重要）
ここが一番試行錯誤した部分です。最初は個数を決めずに運用していましたが、新規のActionはMAX5個・TryAction Backlogからは数未定、という時期を経て、今は トータルでMAX5個（新規3個、Backlog2個） に落ち着いています。なぜここまで絞ったか。Actionが多いと結局やれません。やれないとモチベーションが下がる、いわば「Action疲れ」です。制限を設けることで、選ぶ真剣さが変わりました。

定期的な棚卸し
TryAction Backlogは気を抜くと「ゴミ屋敷」になりやすいです。ツールはMiroを使っていますが、エリアが散乱してスペースがなくなっていく感覚がありました。拡張は先延ばしなだけで何も解決しない、と判断してルールを設けました。 賞味期限は1ヶ月 。TryAction Backlogに1ヶ月滞留したActionは、「やらないんじゃない？」とチームで判断する機会を設けています。時期を書かずに。TryAction Backlogへ移動したものも、この棚卸しで定期的に整理します。

「忘れない」が、ふりかえりを変えた

TryAction Backlogを導入してから、アイデアが霧散する感覚がなくなりました。「今じゃない」と判断した案も、TryAction Backlogに残っていれば次のスプリントで選択肢として検討できます。

もう一つ、予想外の効果がありました。 後回しにしたActionは、あとで冷静に判断できます 。「本当に必要か？」をもう一度考えられるから、無駄なことをしなくて済む感覚があります。

実際に、TryAction Backlogから復活して実行されたTryもあります。

環境依存のコードで、デプロイできるメンバーがWindowsユーザーに限られていた問題です。やらなくても業務は回ります。だからTryAction Backlogに残っていました。それを実行に移すことができました。結果として脱属人化につながっています。

ただ、やろうと思っていたタイミングが来ても、状況が変わって「これはもう効果がない」と判断するケースもあります。TryAction Backlogに移すことが「いつか必ずやる」の約束ではなく、「もう一度冷静に見る」機会を作ることだと、このチームは捉えています。

それでも定期的な棚卸しで整理できているのが、今のチームの現在地です。アイデアを全部消化することが目標ではなく、「今じゃない」が「永遠に今じゃない」にならないようにすること。それがこの取り組みの本質でした。

「今じゃないTry」、あなたのチームでは今どこにありますか？

あなたのチームのふりかえりで、「今じゃない」と判断されたTryは今どこにありますか？

次のスプリントで思い出せますか？

このチームの試行錯誤が、皆さんのチームへの「問い」になれば嬉しいです。

この記事は、「トナリノ」から生まれた試行錯誤の記録です。
様々なチームの泥臭い試行錯誤を、定期的に届けています。

他のチームの話も気になった方は、フォローしてもらえると嬉しいです。
Xでも同じテーマで発信しています → X（@はんそで）