見出し画像

自分の考えたオリジナルの振り返り手法で楽しい振り返りに(#18)

この記事の初出は、Software Design 2023年9月号です。


振り返りのマンネリ化

筆者のチームでは2~4週間ごとに、チームの皆で良かった点や改善点を挙げてチームを少しずつ改善していく「振り返り」をしています。

過去の筆者のチームの振り返りは、経験の多いメンバーが多く発言し、若いメンバーがあまり発言しないという事がありました。
その対策を、本連載の第3回「ファシリテーターを皆に任せて楽しい振り返りに」で紹介しました(以下参照)。

具体的には、全員に順番にファシリテーター(会議を円滑に進めるための進行役)を任せた上で、やってみたい振り返り手法(KPT、Fun/Done/Learn、ハピネスレーダーなど)を選択して実施してもらいました。
その結果、各自が振り返りで主体的に発言してくれるようになりました。

ただ、そのように全員が積極的に発言する振り返りができるようになっても、だんだん振り返りがマンネリ化してしまうことはあると思います。
今回は、そのマンネリ化を防止する施策を紹介します。

変化し続ける振り返りに

振り返りをマンネリ化させないために必要なことは変化し続けることです。

そういう点では、先に挙げた毎回ファシリテーターや振り返り手法を変える方法も有効です。
その他に、ユニークで面白かった施策が今回紹介する「ファシリテーターがオリジナルの振り返り手法を考えて実施する」です。

前提として、これを行うためには、チームで様々な振り返り手法を実施したことがあり、各メンバーがファシリテーターをやったことがある方が良いです。
その条件を満たしていれば、オリジナルの振り返り手法を考えて実施するのはそこまで難しくありません。

具体的には、ファシリテーターが、それまでの経験をもとに、自分がやってみたい振り返り手法を考えます
ゼロから全く新しい手法を考えても良いですが、既存の手法をアレンジする方がやりやすくてお勧めです。
以降で筆者のチームメンバーが考えてくれた例を紹介します。

例1:Good・Bad・Thanks

KPT を参考にアレンジしています。
以下の観点で振り返り、Good と Bad で出た内容について議論し、アクションを決めます。

  • Good:うまくいったこと、できたこと、嬉しかったこと

  • Bad:うまくいかなかったこと、できなかったこと、モヤっとしたこと

  • Thanks:お礼したいこと

図1:Good・Bad・Thanks

以下は、これを考案したメンバーが当時にチームに説明した内容です。

Good と Bad で良かった点と悪かった点を挙げれば、私たちのチームなら、いつも通り議論して改善アクションを決められそうなので Try の観点は省略しました。
Keep/Problem でなく Good/Bad と表現した理由は、挙げる意見に幅を持たせることで意見を出しやすくする狙いがあります。
Bad に関しては、うまくいかなかったり、できなかったわけじゃないけど、なんかモヤっとしたことも書いてもらえば、それも改善できるかもしれないという狙いがあります。
Thanks に関しては、いつも個人的にお礼を言うことは多くあっても、それを皆で共有することは少ないので、良いところや日頃の感謝を改めて伝える場にもなると良いなと思いました。

例2:Fun/Fail/Learn

Fun/Done/Learn のアレンジで、Done を Fail に変更した手法です。
以下の観点で振り返ります。

  • Fun:楽しかったこと

  • Fail:失敗してしまったこと

  • Learn:学んだこと

図2:Fun/Fail/Learn

考案したメンバーの説明は以下です。

今のチームはペアプロ・モブプロ中心なので、Done に書く内容が皆で重複しそうで、個性が出にくそうだと考えたました。
そこで、Done の代わりに Fail にしました。
このチームなら、ポジティブ思考で失敗さえも学びや楽しさに繋げられそうだと思ったからです。

例3:ハピネスレーダーNEO

ハピネスレーダーを参考にアレンジしています。
以下の2つの観点を、開発・テスト・管理の3つに分けて振り返ります。

  • 良かったこと、うまくいったこと

  • 悪かったこと、うまくいかなったこと

図3:ハピネスレーダーNEO

考案したメンバーの説明は以下です。

挙げる観点は個人的なものでも、チーム全体のものでもOKです。
今回のスプリントは、全員が開発、テスト、プロジェクト管理(タスクのやり方や優先度を見直す提案など)のすべてに関わっているのでそれぞれの内容を書けると思います。

例4:DYA

KPT を参考にアレンジしています。
以下の3つの観点で振り返ります。

  • ドヤりたい!こと(`・ω・´):超頑張ったぜ!ほめてくれ!と思うこと。

  • やれやれ。。。なこと┐(´д`)┌:超大変だったぜ!つかれたぜ!と思うこと(うまくいった、いかなかったは問わず)

  • 明日の自分に期待!なこと╭( ・ㅂ・)و ̑̑:次にやりたいぜ!と思うこと。もしくは心のこりになったこと。

図4:DYA

考案したメンバーの説明は以下です。

前回の振り返りが、具体的な工程ごとに意見を出したので、今回はその逆の方向でアバウトに思ったことを挙げる手法にしました。
今回のスプリントは慌ただしかったし大変だった部分も多いと思うので(個人の感想)、ポジティブに締めたいです。
そのため、肩の力を抜いて書きやすくするために、観点の名前は「ドヤりたい」などのコミカルな感じにしました。

やってみた結果

従来のやり方よりも、意見が出て盛り上がる傾向がありました。
おそらく3つの理由が考えられます。

1つ目は、参加者がより協力的な姿勢になったことです。
振り返りのような正解のない活動に対しては、参加する個人の意欲が重要になります。
その点で、ファシリテーターがチームのことを考えて考案した振り返り手法の場合、参加者はそれを成功させたいという気持ちが出やすく、協力的な姿勢になりやすかったと思います。

2つ目は、単純に従来のやり方よりも面白いことです。
例えば、ある技術についての記事を読むとしても、公式サイトのヘルプページを読むよりも、自分が注目している技術者の個人ブログで読む方が面白く感じることはあると思います。
それと似たような感覚で、世の中で広まっているKPTの観点よりも、チームのメンバーが考案した「ドヤりたいこと」などの観点で意見を出す方が楽しく感じました。

3つ目は、今のチームに適したやり方になりやすいことです。
ファシリテーターは、チームの特性や直近の振り返り手法の傾向から、自分なりにチームに適していると考えた手法を考えてくれたので、実際にやりやすかったです。

このように「各自がオリジナルの振り返り手法を考えて実施」はマンネリ化を防止しつつ良い効果がありました。
ぜひ皆さんも試してみてください。

はてなブックマークへの登録はこちらです


連載「ハピネスチームビルディング」の次回の記事はこちら↓

前回の記事はこちら↓


読んでいただき感謝です!何か参考になる事があれば、スキを押していただけると励みになります。毎月チームビルディングの記事を投稿してます。 Twitterもフォローしていただけると嬉しいです。 https://twitter.com/kojimadev