現チームでのふりかえりについて
みなさん、チームでふりかえりしてますか？私生活は恥が多すぎてふりかえれない私ですが、チームでは定期的に(なるべく)ふりかえりをするようにしています。というか、今のチームを担当させてもらう上で、一番最初に実施することを決めたのはふりかえりです。
先日のポストに味を占めたので、前職も含めて何度かチームに対するアクションをしてきた中でなんとか自分でもモノになってきた感のあるふりかえりについて少しまとめてみようかと思います。今のチームで気をつけたことですが、だいたい毎回同じようなアプローチで行っています。
なお、やっているのはシンプルにKPTです。
「とりあえず生」くらいの感覚で始められるふりかえり
現チームに限らず思ったことですが、チームの状態を良くする、改善するとなった場合にまず始めると良いのがふりかえりです。そう思う理由は以下の4点。
- 準備にほとんどコストがかからない
- コミュニケーションがとれる
- どの文化でもマッチしやすい
- (最初期は)あまり理想的にならなくても良い
なお、ふりかえりはチーム状態が悪いからやる訳ではないです*1。どんな状態のチームでも、導入コストや継続的な効果の面で非常におすすめできる活動です。
上記の理由についてそれぞれ少しずつ補足します。
準備にほとんどコストがかからない
リモートのメンバーがいないので、必要なものは会議室とホワイトボードとマーカーくらいです。ほとんどの会社で備品としてあるものですよね？
だいたい、何かを始めようとする時に、言い出しっぺが稟議を書いたりしなきゃいけないような活動はハードルが高すぎます。「やろうぜ」という勢いをそがれずに以下に始めるところまで持っていけるか、が継続するための鍵だと思っているので、導入のためのコストは非常に重要です。
コミュニケーションがとれる
私が「ふりかえりしようぜ」と言い出すのは、自分がチームに関わり始めるタイミングです。まだメンバーと十分なコミュニケーションがとれていないので、チームになじむためには雑談ではない会話量を意識的に増やす必要があります。
課題に向き合っている中での反応を見ながら、この人はどういう思考をして、課題に対してどういうアプローチをする人だろう、という知見が得られることがふりかえりの利点です。
どの文化でもマッチしやすい
チームミーティングという名目で始められますからね、だいたいどの文化でも潜り込ませることができます。
私が現チームに対して取り入れたい、テストの自動化とかCIとかドキュメントを適切に捨てていくとか文化を変えていくためのことは様々ある訳ですが、そういうものをいきなりトップダウンでやると言うと文化がないチームでは戸惑うはずなんです。その戸惑いを無視して強引にするのではなく、あくまでチームから取り組む空気にしたいという気持ちがあります。
その点、ふりかえりはトップダウンでやると決めてもチームミーティングの進行の仕方を変える程度の受け止め方をしてくれることが大きな利点です。メンバーに「こいつ何か面倒なことしようとしている」という印象を与えなくて済むわけです。
(最初期は)あまり理想的にならなくても良い
現チームで特に強く感じたことです。
ふりかえりでは、チームの課題解決をなるべく取り組みやすい単位に分解して対処していくことです。そして短い周期で改善結果をフィードバックして軌道修正していきます。そして、それを積み重ねていくことでチームの理想的な姿に近づいていくことが大目的です。
ですが、チーム状態によってはまず目の前の大きな課題をなんとかしないと理想どころではないということがあり得ます。現チームに入ったときがまさにこの状態で、諸々の理由で自信を失い、パフォーマンスも出せない状態でした。この状態では、理想的なチームの姿を最初に持つことはギャップが大きすぎてモチベーションを下げてしまうのではないかと考えて、まずは課題を解決することにしました。そうやって、メンバーが本来持ってるパフォーマンスが出せるようにしてから「理想のチームとは？」という問いかけをしてみようと思いました。
ふりかえりは小さなフィードバックサイクルで行うので、どちらのフェーズでも同じように継続できます。ProblemやTryの判断基準に「理想的なチームに向かう」という強いバイアスがかかるようになるだけです。これらの各フェーズで同じやり方を使えるというのは利点です。
現チームのファシリテーションで気をつけていること
そんなに細かいことを気にしているわけではないです。
「進捗どうですか？」
先週のTryの進捗は最初に確認します。で、やってないのなら継続してTryにあげ続ける価値があるかどうか検討します。
私は「時間がなかったから」というのも十分な理由だと思っていて、本当にその改善に時間をかける価値があるのかという判断にして良いと思っています*2。もしかしたらそのTryは「今やることじゃない」ということがわかったのかも知れませんし、そうであればその判断をしたことも一つの進捗です(強引)。
ともあれ、Tryで挙げたことは実施状況とその成果からのフィードバックを確認しないと、チーム状態がどれだけ良くなってるかが実感できません。この実感こそが自信を取り戻すために一番効果があることですから。
Keepの口火を切る
チーム状態良くないところから始まるとKeepってなかなか出てこないんですよ。うまく行ってないところがメンバー自身目につくようになってるから状態が良くないわけで。
ただ、先ほどの実感の話になりますが、Keepとして良くなっていることが実感として上がらないと自信は持てないんです。チームが自信持って仕事するためにはKeepなしのふりかえりとかあり得ないわけです。
そのため、メンバーからKeepが出てこなさそうなときは私から口火を切るようにしています。もちろん、なぜKeepだと思ったかもセットにして。ちなみにこれは上記の効果とは別に「俺はこのくらいチームをよく見てるよ」という新米マネージャの小賢しいアピールとしても機能するのでおすすめです。
Problemで愚痴っても良い
愚痴だけなら別でやってくれという話にはなるんですが、愚痴の中には自分たちが変われば少し状況を変えられるものが往々にしてあります。課題を掘り下げて整理してないけど、不快感はあるから愚痴になっているという可能性もあります。
そのため、Problemで愚痴出しても良いというローカルルールを設けてます。Problemで愚痴っぽいのが出たらどうするかというと「それ、俺たちで手をだせる？」と聴いてみます。その問いかけをしてからProblemを分割してみて、チームで取り組めそうな領域がなければProblemから外します。
外されたものはどうするか？放っておきます。というかどうにもできないことにいつまでも関わっている訳には行かないので、できることに手を付けます。
Tryとアサインを別にする
「言い出しっぺの法則」で出てくる心のハードルをなるべく避けるため、です。ということにしていますが、実を言うと効果のほどはよくわかってないです。結果的に言い出しっぺの法則が発動したようなアサインになる事態が多々有るので。。。
今後の課題
ふりかえりの進行について、いろんなレベルでの「慣れ」が何か悪影響を与えているのではないか、という懸念があります。
具体的に言うとProblemに上がっていることに対して「本当に？」「なんでそれが問題？」という掘り下げが不足している気がし始めています。それは、ファシリテーションする立場の人間(私)がチームの内情まで知ってきて、あえて言語化しなくてもわかっているだろう、ということが若干増えてきた気がします。これはファシリテータが私一人に集中していることもあるのではないかと。
というわけで、一回他のチームのメンバーにファシリテーションをお願いしてみようかな、と思ってます。Problemの掘り下げに新鮮味が出てくれば面白いな、と。
まとめ
ふりかえり簡単だし、チームに合う方法で導入すれば良いと思います。コスト以上の効果が見込めますよ、きっと。
