ミーティング自体は簡単

#

構造は拍子抜けするほどシンプルです。スプリントやプロジェクトの区切りごとにチームで集まって、三つの質問に答えるだけ。

1. 何がうまくいったか？
2. 何がうまくいかなかったか？
3. 何を改善できるか？

以上です。本質はフィードバックループにあります。定期的に立ち止まり、実際に起きたことを眺めて、働き方に反映する。立ち止まらないチームは、同じことを繰り返すだけです。

有益なふりかえりと、ただのガス抜きの違い

#

まずは率直さです。本当の問題を口に出せるのは、それが自分に跳ね返ってこないと確信できるときだけ。だから場の安全性は、どのフォーマットを選ぶかより重要です。それに、いちばん鋭い観察はたいてい静かなメンバーから出てきます。リーダーだけが喋るふりかえりは、手間の増えたステータス会議でしかありません。

もう半分は、議論のあとに何が起きるかです。直す価値のある問題は、担当者と期限のついたアクションアイテムとして会議室を出るべきです。そして——ここを飛ばすチームが多いのですが——次回のふりかえりは、前回のアクションアイテムの確認から始めます。アクションアイテムがただの飾りだと全員が静かに気づいた瞬間ほど、ふりかえりを早く殺すものはありません。

可能なら数字も持ち込みましょう。「今回のスプリントは遅かった気がする」という感想は堂々巡りになりますが、グラフが一枚あれば大抵決着します。

よくある失敗パターン

#

間近で見てきたのは三つです。個人への非難に変わってしまうケース（直すべきはシステムであって人ではない）。一年間まったく同じフォーマットを使い続けて全員が自動操縦になるケース（変化をつける）。そしてフォローが一切ないケース。前述のとおり、最後のものが致命傷です。

ちなみに、これはソフトウェア開発に限った話ではありません。マーケティングキャンペーン、イベント運営、研究プロジェクト、製造業。サイクルが繰り返される仕事なら何でも、同じループが効きます。ただ、どこでやるにしても判定基準は同じです。次のふりかえりまでに、実際に何かが変わったか。変わっていないなら、それはただ喋っていただけです。