レトロの付箋がGood/Badで止まる。Keep/Problemに変えるまでの深掘りの話

「〇〇ための勉強会を開こう」——またこのTRYか、と思いながら付箋を貼ったことがある。

私のチームのレトロでは、「スプリントゴールを達成できた/できなかった」「作業がスムーズに進んだ」「コーディングにAIを使えた」といった事実としてのGood/Badは出てくるのに、そこから先のKeep/Problemにうまくたどり着かず、毎回無理やりTRYをひねり出していた。今日はその正体と、そこからどう抜け出そうとしているかについて書いてみる。

「スケルトンコードがまたBad」——同じ話が繰り返される感覚

私のチームでは、レトロで出てくる付箋の内容が、事実の列挙で終わることが何度も続いていた。

• 「スプリントゴールを達成できた/できなかった」

• 「作業がスムーズに進んだ」

• 「コーディングにAIを使えた」

こうした付箋が並んだ後、そこから無理やりTRYをひねり出す、という流れが定着してしまっていた。「スクラムの知識のための勉強会を開こう」「15分のタイムボックスを作って作業してみよう」といったTRYが、その典型だ。

本来レトロスペクティブは検査と適応の場で、「スプリントゴール達成に何が役立ったか・何が妨げたか」という観点で振り返り、次スプリントに活かすTRY（小さな実験）につなげるものだと思っている。でも、そこには明らかにギャップがあった。

そんな中、あるスプリントで一つのPBIに焦点を当てたレトロを実施したことがある。進め方をタイムライン上に可視化して、「どこが問題だったか」をチームで話し合った。その結果、また同じ現象が起きた。「認識合わせのための設計（チーム内では『スケルトンコードの作成』と呼んでいた）が良くなかった」というBadに、再び焦点が当たったのだ。

Good/Bad止まりは、チーム固有の話じゃなかった

この「Good/Bad止まりでKeep/Problemに至らない」傾向は、たぶんうちのチームだけの話ではない。

Aino Corry著『Retrospective Antipatterns』という書籍でも、同種のアンチパターンが「Wheel of Fortune」として紹介されている。本を読んで、「これ自分たちのことだ」と感じた。

Wheel of Fortune——表面的な症状にそのまま解決策を当ててしまう

この本で語られているのは、大まかに言うとこういう話だと理解している。

• ファシリテーターが時間的な制約の中で手軽なアクティビティを選びがちになる

• その結果、出てきた表面的な課題に対して、深く考えずに直接的な解決策をそのまま当ててしまう

• 症状に対する早すぎる収束（Premature convergence）が起き、根本原因を掘らないまま絆創膏を貼って終わる

これがWheel of Fortuneというアンチパターンの中身だ（詳細はぜひ書籍を読んでみてほしい）。

私なりの解釈では、自チームで起きていたGood/Bad止まりの付箋は、まさにこの「表面的な問題」に相当する。手法をKPTからSailboatに変えたところで、この現象そのものは変わらない。器を変えても、中身（深掘りの浅さ）が変わらなければ同じ現象が形を変えて出てくるだけなのだと思う。

「なぜ毎回同じ話をしているんだろう」という違和感

Wheel of Fortuneが起きているときの兆候について、書籍側ではこんな話が挙げられている。

• 「なぜ毎回同じ話をしているのか」という不満が出る

• 付箋の色が変わるだけで、何も改善された感覚がない

• 根本原因が放置されるため、同じ問題が繰り返し議論される

自チームでも、これに近い感覚があった。レトロで「よかったね」「悪かったね」という話が出た後、どうやってTRYを出すかという話になる。本当に変えたい・続けたいという内発的な気持ちからTRYが生まれてくる雰囲気ではなく、無理やりTRYを作っている感覚があった。

絆創膏を貼り続けても、根っこの傷は治らなかった

書籍側の話で言えば、たとえば「ペアプロが少ない」という表面的な課題に直接的な解決策を当ててしまうと、メンバーが実施しない本当の理由（やり方がわからない、心理的安全性が低い、1人の時間が必要、など）は放置されたままになる。次スプリントでも状況は変わらない。

自チームでの実例も、これに近かった。

• 「スクラムの知識のための勉強会を開こう」

• 「15分のタイムボックスを作って作業してみよう」

こういったTRYが実際に出たことがあったが、実行を忘れてしまったり、数スプリント後に同じような問題がまたレトロで取り上げられたりした。結局のところ、絆創膏を貼り続けているだけで、傷口そのものには一度も触れていなかったのだと思う。

「なぜ」を4回掘ったら、言葉の認識齟齬に行き着いた

スケルトンコードの話題が再びBadとして焦点になったとき、一つの仮説を試すことにした。

「Good/Badの内容をなぜGoodなのか/BadなのかHows/Whysで深掘りすれば、何が役立った（Keep）か、何がチームの推進を妨げた（Problem）かの特定に近づけるはずだ」という仮説だ。

実際にやってみたのは5Whysだった。深掘りを重ねると、こんな連鎖が見えてきた。

• 「スケルトンコードが問題だった」

  • なぜ？ → そのスケルトンコードが、実はスケルトンコードではなかった（実装を含んでいた）

    • なぜ実装を含んでいるとまずいのか？ → どう実装するかは、まだDEV同士で決定できていなかったから

      • なぜ決定できていないのに進めてしまったのか？ → 「スケルトンコード」という言葉の意味合いに、チーム内で認識の相違があったから

表面的な事実（Bad）から出発して、深掘りを重ねることで、チーム内の言葉の認識齟齬という、具体的で扱えるProblemにたどり着けた。「スケルトンコードが良くなかった」で止まっていたら、次に出てくるTRYはきっと「スケルトンコードのルールを決めよう」くらいの、また絆創膏的なものになっていたと思う。

正直に書いておくと、書籍側では「Whyは犯人探しになりがちだから、Howで聞くことを推奨している」という話が出てくる。ただ、私が実際に自チームでやったのは5Whysであり、体感としては犯人探しっぽい空気にはならなかった。なので今回は、体験していない5Howsをやったかのように書くのではなく、実際にやった5Whysのまま書いている。5Howsが本当に効くのかは、私自身まだ検証できていない。

以降、付箋の内容が表層的だと感じたときは、5Whysや単純な「それってなんで？」という質問で、本当の要因を深掘りすることを続ける方針にしている。

おわりに

理想を言えば、SMが毎回都度深掘りしなくても、DEV自身が表層的な内容ではなく本当の要因をレトロの場で挙げられるようになってほしい。今はまだそこまで至っていないけれど、5Whysで一段深く掘る、という小さな習慣を積み重ねることが、そこに近づく一歩になるんじゃないかと思っている。

もしレトロの付箋がGood/Bad止まりで、TRYを無理やりひねり出しているような感覚があるなら、一度その付箋を「なぜ？」で数回掘ってみることをおすすめしたい。

自分が今スクラムマスターをしているチームについてはこちらの記事で触れているので、興味があればあわせて読んでもらえたらうれしい。