レトロスペクティブ(a.k.a レトロ)。アジャイル開発の中で良く見かける言葉。スプリントの振り返りの時間として、何が良かったか悪かったかの議論の場であり、これからどのように進めていくかが、ここで話されています。新しいことに取り組んだり上手く回ってないことを止めたり継続的にチームを改善していく重要な場になっています。

ただ、ある時、改善の場であるはずのレトロスペクティブ自体があまり変わらなかったことにチームが気づきました!フラグが立ちました。社内には「変わり続けるために、学び続ける」のバリューがあります。変わらないことはスタグネーションのリスクが高くて、将来の新たな課題に直面したときに耐えられないかもしれません。

私たちは、昔のスタイル(Keep-Problem-Try)から離れて、称賛 を重視する Celebration Grid を取り入れました。この記事はその変化の学びを共有していきます。特に、新しい取り組みでレトロスペクティブの細かなニュアンスをより正確に掴め、今まで発見できなかったことを発見し、より実のある行動に繋げることができています。

私は2017年に大学を卒業し、ソフトウェアエンジニアになりました。2019年に日本に渡り、ビズリーチでHRMOS組織診断サーベイと他の新機能の開発に務めさせていただきました。チーム開発が好きで、働いている中でいつも素晴らしいチームと恵まれ、一緒に成長していきてます!バックエンドと古いネタ雑談が好き。

以前の Keep-Problem(More)-Try も回ってはいた

我々のスプリントは一週間ごとです。こまめに振り返りはできます。一週間だけなので、チーム内で起きていることなら、お互いのハードルが大体認識されています。ただ、短期的にどのように対応していくかはレトロで決めました。世の中で見かけるKeep-Problem-Try方式と似てる方式を使いました。我々は失敗をブレームレスに対応していることを大事にしているからこそ、言葉的に「Problem」を使わずに「More」を使っていました。

Keep-More-Tryスタイル

Keep-More-Try型レトロだと、最初の10分を使って、共通スプレッドシートにみんながそのスプリントの続いていきたい行動と改善したいきたい行動を洗い出します。リアルな例を見せます。

KMTをスプレッドシート上で実施

みんなが項目を書いた後に、チームメンバーの一人が当日ファシリテーターとしてKeepを振り返って、お互いに拍手を送ります。そしてMoreも共有します。その後、それぞれの気になるトピックを深堀り、課題対策のためのTryを作れるかどうかを書きます。それを固めて、具体的なTryを残しています。項目の隣に何が起こった(what)だけではなくて、なぜ(why)と因果関係も書けます。

上記の会の時のTryが主に動作確認を強調したかったことになりました。「起きたこと」を全部読むと、バグの話もあるし、テスト漏れとかの話もあります。チームでTryになり得るものを選び、追跡できそうな行動に落とします。

自分はチームで一番長いメンバーで、Keep-More-Try形を数年やっていました。別に困っていなかったのですが、進化していなかったことがおかしかったです。プロセスを疑って、本質の価値を適用しているかどうかの分析をチームで大事にしています。そのため、レトロに衝撃を与えてみました。新しいやり方を試しました。

定期的に「色々変わってきたけど、なんかレトロかわらないな」という感想が出ました。特に困っている・困っていないの判断にするより、レトロやり方を疑いはじめました。「なんで周りを改善し続けているなのにレトロは変わらない?」、「これでいいんだっけ?」、「変わり続けていたないものがスタグネーションしているんじゃない?」みたいな悩みになって、チームとして対策を探していました。とりあえず新しい仕組みを試すようになりました。

セレブレーショングリッド is 何?

セレブレーショングリッドは Management 3.0 によって提唱されたフレームワークであり、実験を通じて得られたアウトカムをビジュアルに表現することができ、成功しても失敗しても学びが得られるようになっています。更にその名が表すとおり、称賛することを強調するものとなっています。

Celebration Grids are a visual way to present the outcome of an experiment whether that experiment has succeeded or failed. It shows us where we can celebrate the good practices, which result from a positive outcome and where we can learn something from our failures.

私は個人的には、「称賛」よりも「祝い」のほうがしっくりきます。成功であれ失敗であれ、私たちは学び、一歩ずつ前に進んでいると思います。それを認識してしっかりお祝いできることは素晴らしい文化ではないでしょうか。ここからは敢えて “祝” という単語を使っていきたいと思います。

横の行動軸には「間違い(Mistakes」) / 「実験(Experiments)」 / 「習慣(Practices)」に分かれていて、縦の成果軸に「成功 (Success)」/ 「失敗 (Failure)」に分かれています。シンプルすぎると言うと、右上の方が良さげて、左下の方が良くないです。それぞれの組み合わせで学べられることはありますが、学びが類型化され分散されています。

「間違い・失敗 (Mistakes・Failure)」(赤)には実験の失敗と違って、予想されていなかった失敗となります

実験のカラム(緑)にチームの実験(Try)の成果を載せて、失敗や成功問わずに学びが多いです

「習慣・成功 (Practices・Success)」(緑)にチームのプラクティスが上手く活かされていることの証明になります。

「間違い・成功 (Mistakes・Success)」や「習慣・失敗 (Practices・Failure)」(灰色)は運が良かった・悪かっただけの可能性が高く、学びが少ないです。

セレブレーショングリッドの実例

数回回してから、上記のようなことになりました。オンラインホワイトボードツールMiroを利用して、最初の10分を使って、チーム全員が付箋を貼りながら話題を載せます。Keep-More-Tryと同じように、議論を拾いながら、深掘りできます。Tryの付箋を貼っていて、次のスプリントでその取組は追えます。

セレブレーショングリッドを使って実感した3つのメリット

「失敗しても大丈夫、ミスは学びの元」という雰囲気が形成される

レトロは簡単にネガティブな雰囲気に陥ります。ミスに集中してしまい「直さなきゃ」の汗が湧いてくる。セレブレーショングリッドなら、失敗があっても、実験ならそれを祝うべきことになります。新たな習慣化がうまく成功したら、それももちろん祝うべきこと。良さげな実験が成功しても、やはり祝うべきです。失敗しても大丈夫、ミスは学びの元であることを重視してくれます

複数スプリントに渡って、より意味のある追跡ができる

「動作確認を改善する」Tryがワークしてます。ただ、これは一週間のTryで完成させるフローではなくて、Tryして、実験欄に投入して、成功したか・失敗したかの振り返りチャンスになります。前回やろうとしたことのインパクトがより図りやすくなって、あるTryが進化していける可能性もあります。動作確認フローが改善した理由は毎回上手くいったところを残して、上手く行かなかったことが成功できるように工夫したからだ。それに、Tryをやってみて、あまり効果なさそうこと、思ったより大変なことなどを辞めます。

視覚的な構成によって、議論が明確になる

実験欄があるからこそ、引き続きフォローできます。それに、スプレッドシートと違って、各人から載せている話題のまとめ形とかはしやすくなります。後、それぞれのカテゴリあるからこそ話のニュアンスが可視化されていて、より深い話に近づけるのは簡単です。セレブレーショングリッドの類型化によってチームの暗黙パターンが第三者みたいに分析しやすくなります。Miroとかなら、付箋をまとめたり、矢印を描いたりすることで以前よりお互いの共通認識がそりやすくなりました。

失敗から学んだ、このフォーマットに意味がある

スプレッドシートでやってみた

セレブレーショングリッドを投入した時に、ミニマムに投入しようとして、スプレッドシートでやろうとしました。話題のグルーピングとかは不自然すぎて運用しづらかったです。

ホワイトボードだと中長期の振り返りが難しい

その後にMiro版になりましたが、基本的にリモートな我々は物理的にオフィスに出社して一緒にやってみました。リアルなホワイトボードを使いました。オンラインで前回の管理とかもやっていて、そのバージョン管理が少し崩れました。個人的な問題は、日本語が第二言語として、自動変換に頼り過ぎて、ペンで漢字を書くのは苦手です。 😇

ホワイトボードの写真は気まずいよねー

我々らしくした

レトロにセレブレーショングリッドの投入で終わるより、他の組み方で拡大しようとしているし、レトロ以外の振り返り会に利用しています。

Try管理シートの投入

レトロスペクティブがスプリント毎の振り返りのためになります、Tryが生まれます。ただ、Tryが数週間試してみないといけないと、フォロー方法が特になかったです。そのため、Tryをフォローできるシートが生まれました。レトロの最後の5-10分で更新と管理をしてます。もっと難易度が高いTryを追えるようになり、Tryを保っても大丈夫なので、実験案も生まれやすくなります。

Monthly Check-In

レトロだけではなくて、振り返り会全部セレブレーショングリッドを使えるようになりました。月ごとでチームの中長期の振り返りが行い、チームの目標や個人目標の進捗を振り返ります。チームにあるトレンドの反省になって、抽象度高い鳥瞰図から数スプリント分のパターンがわかります。具体例を共有すると我々色々ドキュメント書いて、簡単に「お、これも追加していった方がいいよね!」のTryが生まれ、ドキュメントが長くなって、情報はありがたいけど書くことが大変になります。Monthlyで「最近ドキュメント書くにわたって壁がないですか?」の話になって、ドキュメントがより書きやすくなるように対策を考えました。Tryから生まれた行動は、今ワンクリックでドキュメントにテンプレートが移され、構成とかを意識せず目の前のタスクの詳細だけを考えていけるようになりました。それでドキュメントへの抵抗も減って、フォーマットがあるからこそメンテしやすくなりました。

セレブレーショングリッドを使うと、 Monthly Check-Inに中長期のTryが生まれて効果があって便利です。

まとめ

レトロスペクティブにセレブレーショングリッドを投入した結果、議論が深ぼりやすくなり、よりポジティブな改善と振り返り議論ができるようになりました。実験も作りやすくなって、Tryになっていて、行動に反映されています`。レトロだけに適用できることではなく、振り返り会であればセレブレーショングリッドは向いていると思います。セレブレーショングリッドを投入した後に我々も個別で対応いれてみたり、実験を進めた結果、Try管理シートや月一振り返り会でチームの成長ができました。ぜひ試してみてください!

アウル エンジニア(Owl Engineer)
アウル エンジニア(Owl Engineer)

HRMOS 事業部のエンジニア。頭は360度に回る