1. はじめに
私のチームでは2～4週間ごとに、チームの皆で良かった点や改善点を挙げてチームを少しずつ改善していく「振り返り」をしています。
ただ、チームの振り返りにて、経験の多いメンバーが多く発言し、若いメンバーがあまり発言しないという事はないでしょうか？
過去の私のチームはそうでした。
それを改善し、全員が発言しまくる振り返りができるようになっても、だんだん振り返りがマンネリ化してしまう事はないでしょうか？
過去の私のチームはそうでした。
また、チームに問題がなく順調すぎて、振り返りで挙がる改善アクションが些細なものになってしまう事はないでしょうか？
過去の私のチームはそうでした。
本稿は、その状態から脱却し、皆が主体的に発言するマンネリ化しない振り返りを実施し、新しいチャレンジをたくさんするようになったプラクティスを紹介します。
なお、前提として以降で紹介する振り返りはすべてリモートワークで実施しています。
2. 皆が主体的に発言するための考え方
仕事で「楽しい・嬉しい」と感じるのは、どんな時でしょうか。
色々ありますが、「主体的な行動で成果が出る」というのは、多くの人が嬉しく感じるのではないかと思います。
例えば、自分が提案して導入したツールやライブラリに対して、他の人から「便利になった」と言われると嬉しいと思います。
従って、私のチームでは 「主体的な行動で成果が出る」という体験を繰り返す事を重視しています。
しかし、「主体的に行動しましょう」と言うだけでは、なかなかできません。
それが自然にできるようになるまでは、それを促すような取り組みが必要です。
例えば、会議でメンバーが主体的に自分の考えを発言をした時は、その都度ポジティブフィードバックする事を心掛けました。
ただ若手の頃は、そもそも会議で主体的に発言する事ができないので、最初の頃は会議の中で「これについて○○さんはどう思います？」のように、その人の考えている事を話してもらい、その意見に良い点があれば、ポジティブフィードバックを行う事を繰り返しました。
そういうフィードバックを何十回も繰り返していくと、どのメンバーも徐々に主体的に会議で発言するようになりました。
それ以外にも、朝会がマネージャーへの報告会になってしまわないように、メンバー間で活発に議論するプラクティスも以下で紹介しています。
3. 全員に順番にファシリテーターを任せる(結論の決定までが責務)
3.1 ファシリテーターを任せるやり方
私は振り返りについて、参加している一人ひとりが主体性をもって振り返りに参加してくれると、充実した楽しい振り返りになりやすいと考えました。
そこで、毎回の振り返りのファシリテーター(会議を円滑に進めるための進行役)を順番に交代で任せる事を検討しました。
当時は私以外のメンバーが入社1～3年目くらいの若手でファシリテーター経験がほとんどありませんでしたが、メンバーに聞いてみたところ「やってみたい」ということだったので、やってもらいました。
ファシリテーターになった人は、振り返りを自分がやってみたいやり方で自由に決められる事にしました。
例えば、私のチームで実際にやった振り返りのやり方は、KPT、YWT、Fun/Done/Learn、Lean Coffee、Starfish、4Ls、熱気球などです(振り返りのやり方は検索すると色々見つかります)。
やり方を自由にやれるようにする事で「主体的な行動で成果が出ると嬉しい」になりやすいと考えました。
ある程度の裁量がある状況で、自分で選択したやり方で成果が出ると、嬉しく感じ、主体性が高まります。
そのため、私のチームは様々な活動の中でこのような工夫を取り入れるようにしています。
ファシリテーターの責務として明確にしたのは「議論の結論を決めること」を含めることです。
結論を決めるのは、チームに入って間もないメンバーには難易度が高いですが「ベストな結論でない場合は、後からフィードバックするので、まずファシリテーターの判断で結論を決めましょう」ということでやってもらっています。
結論を決めることまでが責務となると、ファシリテーターになったメンバーは、「どうすれば皆が意見を出してくれるだろう」「この議論の結論はどうすればいいんだろう」などの事を真剣に考えるようになります。
ただの参加者だった時とは異なり、チーム全体の事を「リーダーからの視点」で考える経験になり、成長に繋がります。
振り返り中に、私が気を付けたのはマネージャーである私がしゃべり過ぎないようにすることでした。
なるべくチームメンバーに意見を言ってもらうように心がけました。
3.2 やってみた結果
初めてメンバーがファシリテーターをやった時は、進行がつたなくもどかしく感じました。
それでもファシリテーターの一生懸命さが伝わったのか、皆が協力的になって、私がファシリテーターをしていた時よりも皆が積極的に発言してくれました。
良い振り返りができた時は、ファシリテーターをやったメンバーに嬉しそうな表情が見られました。
振り返りでの達成感は、ファシリテーターが最も大きいと思います。
ファシリテーターとしての成功体験を積むと、振り返りの楽しさを実感し、その後は参加者としても、主体的に発言するようになりました。
チームの皆がファシリテーターを経験し、振り返りで皆が主体的に発言するようになってくると、誰がファシリテーターでもどんなやり方でも盛り上がる振り返りになるため、チームに配属されて半年くらいの新人でもファシリテーターが可能になります。
なお、チームを改善するための活動という視点で見た場合にも、同じやり方をずっと続けるよりも、ファシリテーターを交代しながら様々なやり方で振り返った方が、チームを様々な視点から多角的に改善することになるため、改善効率が良いと感じています。
以下の記事に、私のチームメンバーが気に入っている「Lean Coffee」の振り返りの具体的なやり方を紹介していますので、よろしければ参照ください。
4. ぼくのかんがえたさいきょうのふりかえりを実施
4.1 マンネリ化しない振り返りにするために
全員に順番にファシリテーターを任せて、毎回異なる振り返り手法でやっても、その方式自体に慣れてくると、いつかは振り返りのマンネリ化が訪れると思います。
マンネリ化しない振り返りをするために必要なのは、変化し続けることだと思います。
私のチームで、変化し続けるために試した施策として、ユニークで面白かった施策が「各自がオリジナルの振り返り手法を考えて実施」することです。
要するに「ぼくのかんがえたさいきょうのふりかえり」をやるということです。
前提として、これを行うためには、チームで KPT、YWT、Fun/Done/Learn、Lean Coffee などの世の中の様々な振り返り手法を実施したことがあり、各自にファシリテーターの経験があることが必要です。
その条件を満たしていれば、オリジナルの振り返り手法を考えて実施する難易度は、そこまで高くありません。
具体的には、ファシリテーターを担当するメンバーが、それまでの経験をもとに、自分がやってみたい振り返り手法を考えます。
ゼロから全く新しい手法を考えても良いですが、既存の手法を少しアレンジするのがやりやすくてお勧めです。
以降で例を紹介します。
4.2 オリジナルの振り返り手法の例
Good・Bad・Thanks
以下の3つの観点で振り返り、Good または Bad で出た課題について議論し、アクションを決めます。
- Good：うまくいったこと、できたこと、嬉しかったこと
- Bad：うまくいかなかったこと、できなかったこと、モヤっとしたこと
- Thanks：お礼したいこと
以下は、これを考案したメンバーが当時にチームに説明した内容です。
Good と Bad でスプリントでの良かった点や悪かった点が挙がれば、私たちのチームなら、いつも通り議論をしてアクションを決められそうなので、よくある Try、Idea、Action のような観点は省略しました。
Good と Bad という表現は、挙げる意見に幅を持たせることで意見を出しやすくする狙いがあります。
Bad に関しては、うまくいかなかったり、できなかったわけじゃないけど、なんかモヤっとしたことも書いてもらえば、それも改善できるかもしれないという狙いがあります。
Good → Bad → Thanks の順で振り返って、ポジティブな気持ちで議論に移りたいです。
Thanks に関しては、いつも個人的にお礼を言うことは多くあっても、それを皆で共有することは少ないので、良いところや日頃の感謝を改めて伝える場にもなると良いなと思いました。
Fun/Fail/Learn
Fun/Done/Learn の Done を Fail に変更した手法で、以下の観点で振り返ります。
- Fun：楽しかったこと
- Fail：失敗してしまったこと
- Learn：学んだこと
以下は、これを考案したメンバーが当時にチームに説明した内容です。
今のチームはペアプロ・モブプロ中心なので、Done に書く内容が皆で重複しそうで、個性が出にくそうだと考えたました。
そこで、Done の代わりに Fail にしました。
このチームなら、ポジティブ思考で失敗さえも学びや楽しさに繋げられそうだと思ったからです。
ハピネスレーダーNEO
ハピネスレーダーを参考にしています。
以下の2つの観点を、開発・テスト・管理の3つに分けて振り返り、そこで挙がった課題について議論し、アクションを決めます。
- 良かったこと、うまくいったこと
- 悪かったこと、うまくいかなったこと
以下は、これを考案したメンバーが当時にチームに説明した内容です。
挙げる観点は個人的なものでも、チーム全体のものでもOKです。
今回のスプリントは、全員が開発、テスト、プロジェクト管理(タスクのやり方や優先度を見直す提案など)のすべてに関わっているので書けると思います。
DYA
GOOD, BAD, NEXT と KPT を参考にアレンジしています。
以下の3つの観点で振り返り、そこで挙がった課題について議論し、アクションを決めます。
- ドヤりたい！こと(｀・ω・´)：超頑張ったぜ！ほめてくれ！と思うこと。
- やれやれ。。。なこと┐(´д｀)┌：超大変だったぜ！つかれたぜ！と思うこと(うまくいった、いかなかったは問わず)
- 明日の自分に期待！なこと╭( ･ㅂ･)و ̑̑：次にやりたいぜ！と思うこと。もしくは心のこりになったこと。
以下は、これを考案したメンバーが当時にチームに説明した内容です。
前回の振り返りが、具体的な工程ごとに意見を出したので、今回はその逆の方向でアバウトに思ったことを挙げる手法にしました。
今回のスプリントは慌ただしかったし大変だった部分も多いと思うので(個人の感想)、ポジティブに締めたいです。
そのため、肩の力を抜いて書きやすくするために、観点の名前は「ドヤりたい」などのコミカルな感じにしました。
4.3 やってみた結果
従来のやり方よりも、意見が出て盛り上がる傾向がありました。
おそらく3つの要因があります。
1つ目は、参加者がより協力的な姿勢になったことです。
振り返りのように、正解のない活動に対しては、参加する個人の意欲が重要になります。
その点で、ファシリテーターがチームのことを考えて考案した振り返り手法なので、参加者はそれを成功させたいという気持ちが出やすく、協力的な姿勢になりやすかったと思います。
2つ目は、単純に従来のやり方よりも面白いことです。
例えば、同じ技術情報についての記事を読むとしても、公式サイトのヘルプページを読むよりも、自分が注目している技術者の個人ブログで読む方が面白く感じることはあると思います。
それと似たような感覚で、世の中で広まっているKPTの観点よりも、同じチームのメンバーが考案した「ドヤりたいこと」の観点で意見を出す方が楽しく感じました。
3つ目は、今のチームに適したやり方になりやすいことです。
ファシリテーターは、チームの特性や直近の振り返り手法の傾向から、自分なりにチームに適していると考えた手法を考えてくれたので、実際にやりやすかったです。
このように、やってみた結果は良かったので、振り返りを変化し続けるための1つの方法として「各自がオリジナルの振り返り手法を考えて実施」はお勧めです。
5. 問題が少なくて大きな改善案が出にくい時のプラクティス
チームに問題が多くあり、大きな手戻りが発生した場合などは、振り返りでその問題の解消方法を考えることで、様々な改善案が挙がりやすいです。
ただ、チームに問題が少なく順調な場合、振り返りで挙がる改善アクションが些細なものになってしまうことがあると思います。
上記のように「問題を解消する改善案」が挙げにくいなら、「あるべき姿に対して届いていない点を改善する、もしくは今よりもっと良くする」という方向で改善案を考えた方がやりやすいです。
ただ、それをやるためには、振り返りの中で数分考えた程度では時間が足らず、良いアイデアが出しづらいと感じました。
そこで私のチームでは、振り返りとは別に「提案タイム」という時間を設けています。
具体的には、月に1回、全員で同じ時間に、新しい技術・ツール・プラクティスを探したり考えたりする時間を45分間設けます。
その後、各自が5～10分でチームで試行するものを提案します。
過去に提案された内容の一例を紹介します。
- ドラッカー風エクササイズをやってみる
- 振り返りのツールとして Mural を使ってみる
- Colla という Slack アプリで、朝会の前にアイスブレイクする
- Sonar Cloud という静的解析ツールを使ってみる
- ポモドーロテクニックを皆で試してみる
このとき、チームの皆で大事にしていたのは、失敗してもいいからとにかく試行してみる事が重要という価値観です。
だから、思い付きでも効果見込みが低そうなものであっても、とにかく皆で新しいものを試行しました。
特にこの活動を始めてから1年くらいは、そうやって試行した実績を積み重ねて、チームに「新しい技術・ツール・プラクティスを試行する風土」を作る事を優先しました。
ちなみに、試行した結果、効果が高いものは継続しますが、効果が低いものはやめました。
とにかく試してみることが重要という価値観なので、やめることになっても気にせずに、どんどん試行しました。
試行を促進するために、新しいものを試行した件数を下図のようにグラフで見える化しました。
グラフで件数が積み上がっていく様が見える事で、「今月もいろいろ試行できたね」という感じにチームの皆で喜び合って、達成感を感じやすくなりました。
6. (おまけ)ネガティブな意見が出過ぎる時のプラクティス
上記とは逆に、チームが多くの問題を抱えており、振り返り時に、問題点ばかりが大量に挙がってしまうときのプラクティスの紹介です。
それは問題点などのネガティブなものを挙げる際は「改善効果が高いと思う問題を1人1つだけ」挙げてもらうことです。
問題点をたくさん挙げても、振り返りの時間内に全ての問題に対策を立てることは困難です。
例えば、50時間分の手戻りになった問題の対策の議論が不十分な状態で、数時間分の手戻りという些末な問題に議論の時間を使うのは効率が悪いです。
それに、良かったことに比べて問題点ばかりが大量にあると、場の雰囲気がどんよりしやすいため、重要な問題に絞って議論した方が良いと思っています。
7. 最後に
私のチームの振り返りで大事にしている点は、振り返りの成果は改善案を出すことだけじゃなく、各自の考えや思ったことをシェアすること自体にも価値があるという考え方です。
例えば、私のチームではマネージャー以外のメンバー同士で以下のような発言が多くあり、それはとても価値があると考えています。
「Aさんは、いつも相談の時に、選択肢を用意した上で自分はどれが良いと思うか主張していて凄い」
「私もいつもAさんは凄いと思っています」
「Bさんは、仕様を満たす動作をただ実現するだけじゃなく、もっとユーザーが使いやすくするための提案ができてて凄い」
「Cさんは、アイコンとか色とかデザイン的な部分を、感覚的なものじゃなくて顧客を納得させる論理で説明していたので見習いたいです」
各自がどんなパーソナリティや強みをもっていて、それを他の人が評価してくれているということをチームの皆で共有することは、チームビルディングを高めて次の成果に繋がる可能性があるため、これからもその考えは大事にしていきたいと思います。
ちなみに私はITエンジニア向け情報誌「Software Design」の2022年5月号から「ハピネスチームビルディング」を題材に連載記事を書いています。以下で公開していますので、よろしければ、そちらも参照ください。
Twitterでも開発に役立つ情報を発信しています → @kojimadev