チームのふりかえりで大事なことを社内で発表した話

この記事はふりかえりアドベントカレンダーの17日目です。素晴らしい企画に参加できたことを嬉しく思います。

現在、SaaSなどの社内プロダクト開発でバックエンドを担当しています。 好きな言葉は「最高のプロダクトは最高のチームから生まれる」で、チームの心理的側面や開発プロセスの改善などを任されています。

チームのふりかえりについて全社員の前で発表した時の経験をふりかえろうと思います。 既にふりかえりを実践している方が、これから他チームや組織にふりかえりを伝えようとした時に「自分ならどうするか？」を考えながら読んでいただけると嬉しいです。

当日の発表スライドです

PLAN-Bでは複数のプロダクトで、チームのふりかえりをする習慣ができています。「どうすれば効果的なふりかえりがチームでできるか」について、全社員向けの事例共有の時間で発表をする機会をいただきました。スクラムマスターの社内コミュニティに参加しており、意見をいただきながら発表内容を考えました。

ターゲットは誰か

発表するにあたり、「誰」に「何」を伝えたいかを考えます。

伝えたい人を具体的にイメージして、その人にどんなプレゼント(自分の現場に持ち帰ってもらうもの)を送りたいかを決めます。 プレゼントを受け取る人が、実際にどんな気持ちになるのかを想像することが大事です。

ふりかえりアドベントカレンダーからこの記事を訪れた人であれば、ふりかえりに馴染みのある人や興味がある人だと思います。エンジニアであれば、アジャイルやスクラムの文脈で、聞いたことや経験したことがあるでしょう。
しかし、今回はやや領域の違う人がターゲットです。
プロダクト開発に関わっていない人や、ふりかえり自体をしたことがない人もいます。

未経験者や初心者に加えて、そもそもふりかえりに対して、いいイメージをもっていない人もいるかもしれないという仮説を立てました。

• そもそもふりかえりをしたことがなく、ふりかえりの効果を感じたことがない
• 個人の悪いところを指摘するふりかえりばかり経験して、責められる場だと認識している
• ふりかえりの経験はあるがうまくいかず、時間の無駄だと感じるようになった

などがありそうです。

ふりかえりって難しいですよね。 僕自身、ふりかえりにチャレンジしつつも、有意義な時間を作れなかった失敗をしたことがありました。同じような失敗をした結果、ふりかえりは「ただの反省会」や「無駄な話し合いの時間」と思ってしまった方はいそうです。

そこで発表の目的を「ふりかえりをやったことがない人が、ふりかえりの効果を知り、ふりかえりをやってみる」ではなく「ふりかえりをやったことはあるが、うまくいかなかった経験を持つ人が、ふりかえりのコツを知ることで、改めて現場でふりかえりをする」にしました。

伝えたいことは何か

自分の経験を通して、ふりかえりには訓練が必要であり、闇雲にやってもいい効果を得られないことを学んできました。1年間試行錯誤した結果、僕が感じた「チームのふりかえりで特に大事」だと思ったことが以下の3つです。

• 時間を確保すること
• 設計をすること
• ふりかえりのふりかえりをすること

初版スライドの作成を行い、レビューをしてもらったところ、「ふりかえりのプロセス」の説明に時間を使いすぎていることがわかりました。ふりかえりの手順のようなレクチャー部分を削り、自分の具体的な体験談と共に、3つのポイントを伝えることにフォーカスしました。

時間を確保すること

アジャイルレトロスペクティブでは、チームでのふりかえりは、 週のふりかえりなら60分、月単位やプロジェクト単位であれば、90分~120分程度必要と言われています。ふりかえりに慣れていないチームはもっと必要な場合があります。

去年、新規プロダクトチームができた時に30分でふりかえりをしてみたことがあります。 意見の共有だけで時間が終わってしまい、アクションの決定までたどり着きませんでした。 1年間ふりかえりをしてきましたが、僕自身も経験的に妥当な時間だと感じています。 30分以下の短時間でやろうとすると、余程成熟したチームか、スキルのあるファシリテーターがいないと、ふりかえりの効果を最大化できません。

ふりかえりにより小さな改善を繰り返すのは価値のある習慣で、長期的な投資になります。 目の前の短期的なタスクに精一杯になってしまいがちな中で、週1時間でも確保するのは、かなり勇気のいる行為です。
だからこそ、定期的に「立ち止まる時間を作る勇気」を持ってほしいと思い、このトピックを選びました。

設計をすること

「よかったこと悪かったことを発表し、次にやることを決める」というプロセスだけのふりかえりをしたことがある人は多いかと思います。

しかし大事なのはその前後の工程にあります。

漠然とした目的のまま始めてしまうと議論が拡散し抽象的になりすぎてしまいます。 そのため事前に、何を解決したいのか、課題があることを示すファクトは何かなどを考えることが大事です。

使用するツールの決定なども設計に含まれます。 最近はオンラインでやることも多いので、PowerPointやMetro Retroなどをホワイトボード代わりに使うことが多いです。

発表では、僕が別チームのふりかえりの設計・ファシリテーションを頼まれた時の経験を元に、設計の流れをお伝えしました。

依頼元チームの開発リーダーからのヒアリングから始め、解決したい課題を検討・決定しました。課題解決に必要なワークや問いを決め、当日使うオンラインツールの準備を事前に行いました。実際に行ったふりかえりでは狙っていた効果を出すことができました。アクションも決まり、メンバーからもやってよかったという声を聞くことができました。

何かしらの仕事をする際は事前設計をしていると思いますが、ふりかえりでも同様です。ふりかえりを効果的にするためには、事前にこれだけ考える必要があることを絶対に伝えたいと思いました。

ふりかえりのふりかえりをすること

ふりかえり自体にも鍛錬が必要です。
自分たちのふりかえりがどうだったのかをふりかえる機会をふりかえりの中に組み込みます。 例えば、次にふりかえりをするなら改善できるポイントを付箋に記入していきます。 例えば、ワークやファシリテーションの問題ではなく「単純に時間が足りなかった」などの課題があれば、次回は時間を多くとるか、意見をあらかじめ付箋に書くなどで、ふりかえりを改善することができます。

ふりかえりを始めた当初、議論やアウトプットの質があがらないことに悩んでおり、どうすればもっとふりかえりがうまくできるか考えていました。チームでふりかえりを改善すると同時に個人でも、設計やファシリテーションをふりかえり、改善点をあげてきました。 毎回のふりかえりがどうだったかを記録して、次回どうするかを考えるようにしています。

誰でも最初はうまくいかないものです。ふりかえりのふりかえりをふりかえりですることでふりかえりのスキル・質を継続的に高めていくことが重要です。

全社員向け発表後の感想

エンジニア向けの技術的なLTをしたことはありましたが、 ふりかえりに馴染みがない人にふりかえりについて伝えるのは、具体例の選定や言葉選びが難しく、今までで一番制作に苦労しました。

狙っていたターゲットであるふりかえり経験のある方からはとてもいい反応を得られました。

全社員向けの発表であることで、「ふりかえりの設計」や「ふりかえりのふりかえり」が社内での共通的な言葉・概念として使われるようになりました。

発表をするために今までの経験を整理したことで、改めて自分がやってきたふりかえりを抽象的に捉え言語化するいい経験になりました。

最後まで読んでいただきましてありがとうございます。
皆さんがふりかえりで大事だと思うことは何ですか?