- Authors
- Name
- Youngju Kim
- @fjvbn20031
- はじめに
- 振り返りの目的を分ける
- 良い質問は人を裁かずシステムを見せる
- ファシリテーターは単なる司会ではない
- アクションアイテムは量ではなく質
- 心理的安全性がないと情報収集段階で失敗する
- よくあるアンチパターン
- 実務で使いやすい振り返りの流れ
- まとめ
- References
はじめに
多くのチームが振り返りを行っていますが、実際にチームのやり方が変わる振り返りはそれほど多くありません。
理由は単純です。多くの振り返りは次のどちらかで終わるからです。
- 感情整理としては意味があったが、次の行動が残らない
- アクションアイテムは出たが抽象的すぎて実行されない
良い振り返りは、単に「よかった」「よくなかった」を話す場ではなく、チームの運用システムを少しでも改善する意思決定の場であるべきです。
この文章では、スプリント振り返りだけでなく、プロジェクト完了後、ローンチ後、四半期単位の振り返りにも使える進行原則を整理します。
振り返りの目的を分ける
振り返りは目的が混ざるとすぐに曖昧になります。実際の現場では次の四つが同時に混ざりやすいです。
- 感情の整理
- 事実の整理
- 原因の探索
- 改善行動の設計
これらを分けずに進めると、感情の強い人が会議を支配するか、逆に全員が慎重になりすぎて無難な結論しか残らなくなります。
より安定した順序は次の通りです。
- 何が起きたかを整理する
- 何が機能し、何が詰まりだったかを解釈する
- 繰り返し現れる原因やパターンを見つける
- 次に試す変化を一つか二つ決める
振り返りは議論のように見えて、実際には集団学習の流れを設計する作業です。
良い質問は人を裁かずシステムを見せる
悪い質問は人を守りに入らせます。
- なぜまた失敗したのか
- 誰がその判断をしたのか
- なぜまた遅延したのか
良い質問はシステムを見せます。
- どこで情報が遅れて届いたのか
- どの判断は当初は合理的だったが後半では高コストになったのか
- どの繰り返し作業が自動化されていなかったのか
- どのシグナルを早く見ていれば結果が変わったのか
人ではなくシステムに視線を向けさせる質問が、良い振り返りの土台になります。
ファシリテーターは単なる司会ではない
振り返りの質は参加者の性格より、進行構造に強く左右されます。ファシリテーターは、安全に話し、論点を絞り、実行可能な単位まで結論を縮める役割を持ちます。
良いファシリテーターは次を行います。
- 振り返りの範囲を明確に区切る
- 事実と解釈を分ける
- 発言が少ない人の観察も引き上げる
- 議論を再びシステムとプロセスへ戻す
- 終了前にアクションアイテムの質を確認する
解決策にすぐ飛びつくと、振り返りは原因分析のない意見戦争になりやすいです。
アクションアイテムは量ではなく質
振り返りが失敗する典型例は、次のような抽象的な結論です。
- コミュニケーションを改善する
- テストを強化する
- スケジュール管理を徹底する
これらは意図としては正しくても、運用変更にはなりません。
良いアクションアイテムには次の四つが必要です。
- 担当者
- 完了条件
- 適用範囲
- 見直し時点
たとえば次のように具体化します。
- プラットフォームチームの担当者が3月24日までに
release.mdにデプロイ前確認項目8つを追記し、その後2回のリリースで実際に使われたかを確認する
具体性が高いほど厳しくなるのではなく、曖昧な期待を減らして実行率を上げることができます。
心理的安全性がないと情報収集段階で失敗する
振り返りは結論より前に、情報収集で成否が決まります。人が話さなければシステムは見えません。
心理的安全性を高めるには次が有効です。
- 開始時にblame-freeの原則を明言する
- 事実と解釈を分ける
- 役職が高い人が最初に意味づけしない
- 防御的な反応が出たらプロセスの質問に戻す
- 敏感なテーマは匿名入力や事前アンケートを使う
振り返りで最も危険な一言の一つは「それはもう分かっていた」です。この言葉は新しい観察を止め、次から誰も話さなくなります。
よくあるアンチパターン
1. すべてを扱おうとする
範囲が広すぎると課題一覧だけが増え、優先順位が消えます。
2. 事実の説明だけで時間を使い切る
出来事の整理は必要ですが、解釈と変化設計まで進まなければ単なる報告会になります。
3. 個人非難へ滑っていく
人名が中心になると、システム学習は消えやすいです。
4. アクションアイテムを出しすぎる
一度に三つを超えると実行率は大きく落ちます。
5. 次回で前回のアクションを見ない
この状態が続くと、チームは振り返りを本気で扱わなくなります。
実務で使いやすい振り返りの流れ
最も安定した流れは次です。
- 範囲と目的の確認
- 事実の収集
- うまくいったこと、詰まったこと、驚いたことの整理
- パターンと原因の探索
- 次に試す一つか二つの変化を選ぶ
- 担当者と期限を決める
- 次回の最初に前回のアクションを確認する
4Ls、Start Stop Continue、timeline retrospectiveなど形式は何でも構いません。重要なのは、観察を集め、パターンを解釈し、小さな実験につなげることです。
まとめ
良い振り返りは、その場で最も内省的に見える会議ではなく、来月のチームの働き方を少し変える会議です。
特に次の四つが重要です。
- 人ではなくシステムを見る質問
- 事実、解釈、アクションの段階分離
- 担当者と完了条件を持つアクションアイテム
- 前回の約束を必ず見直す習慣
チームは問題を多く語るから改善するのではなく、振り返りが運用変更につながるときに改善します。