不格好エンジニア

wordpress.comから引っ越しました。

【本場でも通じるふりかえりテクニック】アンチパターンとその対策

本場ってどこやねん。。。

"改善MTG(ふりかえり)"あるある

プロジェクトの節目に行うふりかえりMTG、改善MTG
これって、盛り上がらなかったり、自然消滅してしまう事も多いですね。その原因となるアンチパターンや対策について考えてみました。
上からメセニストとしてではなく、自戒を込めて書いています。

ふりかえる必要性を感じているメンバーがいない

本当に、ふりかえる必要性を感じているメンバーがいないのであれば、そのチームは完全無欠で理想的な状態にあるのかもしれません。ただ、そんなチームあるのかな。。。

ふりかえった事がなくてキョドる

いきなり"ふりかえりMTGやりましょう"と言われたら、ほとんどの人がどうしていいかわからない。
ただ、ちゃんと探せば、やり方まとめてくれてる人がいるんですね。勉強しようっと。
下のリンクは、めっちゃわかりやすいです。

ふりかえり会のススメ(進捗会議編)
http://objectclub.jp/download/files/pf/RetrospectiveMeetingScenario.pdf

一度のみ振り返り

こういうものは、一度で効果が出る方がむしろ稀なので、繰り返さないと駄目ですね。そもそも一度だけ振り返っても効果が計測できないですし。
自戒を込めて書きました。

効果がない(改善案が生かされない、実行に移されない)

プロジェクトの最後にふりかえりを行ってしまうと、こうなりがちですね。
この手のMTGは、プロジェクトの途中、まさに問題に直面している過程で定期的に行う方が良さそうです。結果をどう生かすのか、まずメンバー間で共有してからMTGを始めなければいけないのだと、お仕事を通じて学びました。

どうやって進めればいいのかわからない

何となく改善MTGを導入すると、一人一人が反省点を口にして、何となく終わってしまう。未来につながるお話にならない。そこでKPT。「型」を導入する事で、進め方をまず共有する。

批判の応酬、責任のなすり付け合いになってしまった

これ、僕もやってしまった事があります。。。そもそも、うまくいっていないチームだと、こういう場を設けた時に、一気に不満が噴出する事があります。これは解決が難しそうですが。。。
まずMTGの始めに、"keep(これからも続けたい、良い取り組み)"を挙げて、自分たちの成長を認め合うこと。

あとは、"**のせい"という論調になりかけた時に、「自分ならどうする?」「これからはどうする?」と自責で、未来志向で考えられるように声がけを行う事でしょうか。不思議なもので、第三者がこういった声がけを行うだけで、ほとんどの発言者は無意識のうちに自責で考え、未来に向けた思考を行えるようになるものです。僕自身も、何度もこの言葉に救われた気がします。

言葉の持つ力を甘く見てはいけないですね。

また、不満を抱えているメンバーには、MTGが始まる前に個別にお話をして、ガス抜きをする事も重要かもしれません。

Keep飛ばし

いきなり"Problem(問題)"から言及して、みんなどよーんとする。お通夜MTGの幕開け。
対策は、まずMTGの始めに、"keep(これからも続けたい、良い取り組み)"を挙げて、自分たちの成長を認め合うこと。まずMTGの始めに、"keep(これからも続けたい、良い取り組み)"を挙げて、自分たちの成長を認め合うこと。大事な事なので、2度書きました。

メンバー大杉

聞いている時間の長いMTGは、集中力が薄れがち。メンバーをむしろ3,4人に絞った方が良いのかも。あとは、発言者の時間を強制的に区切るとか、ポストイットを使うとか。

ほとんどのメンバーが効果を感じていない or 楽しくない

では、なぜ、メンバーが効果を感じていないのか。効果が目に見えないから、もしくはフィードバックを受け取るまでのサイクルが長過ぎるからではないでしょうか。
効果が計測できて、フィードバックまでのサイクルを短くする事ができれば、やっているうちに楽しくなってくるはず。では、どうすれば可視化できるのか、フィードバックを短くできるのか。

考えられる解決策としては、このあたりでしょうか。

  1. 可視化できるものを目標にする。
  2. フィードバックサイクルが長過ぎるものは、短く分割して、短期間にフィードバックを得られるようにする。

なげっぱなし、言いっぱなしのTry

誰が何時、何時までに、何をどうする。などより具体的で明確な内容に落とし込む。場合によっては、実行されたかどうかの確認方法まで盛り込む。
。。。。というより、こういう風に具体的に落とし込めないものは諦めて、本当に出来そうなものだけ、3つだけTryする、というのが良いかも。
短期間で、そんなに5個も10個もTryしながら、改善活動できない気がする。

【参考】

Project Facilitation From Hiranabe


アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE)