LabHub

ブログ

プロジェクト振り返りを変化につなげる: 進行設計、質問、アクションアイテム

2026-03-17 · 9 分で読めます · #retrospective#agile#scrum#team-culture#facilitation#action-items#2026-03

한국어English日本語

プロジェクト振り返りを変化につなげる

はじめに

多くのチームが振り返りを行っていますが、実際にチームのやり方が変わる振り返りはそれほど多くありません。

理由は単純です。多くの振り返りは次のどちらかで終わるからです。

良い振り返りは、単に「よかった」「よくなかった」を話す場ではなく、チームの運用システムを少しでも改善する意思決定の場であるべきです。

この文章では、スプリント振り返りだけでなく、プロジェクト完了後、ローンチ後、四半期単位の振り返りにも使える進行原則を整理します。

振り返りの目的を分ける

振り返りは目的が混ざるとすぐに曖昧になります。実際の現場では次の四つが同時に混ざりやすいです。

これらを分けずに進めると、感情の強い人が会議を支配するか、逆に全員が慎重になりすぎて無難な結論しか残らなくなります。

より安定した順序は次の通りです。

  1. 何が起きたかを整理する
  2. 何が機能し、何が詰まりだったかを解釈する
  3. 繰り返し現れる原因やパターンを見つける
  4. 次に試す変化を一つか二つ決める

振り返りは議論のように見えて、実際には集団学習の流れを設計する作業です。

良い質問は人を裁かずシステムを見せる

悪い質問は人を守りに入らせます。

良い質問はシステムを見せます。

人ではなくシステムに視線を向けさせる質問が、良い振り返りの土台になります。

ファシリテーターは単なる司会ではない

振り返りの質は参加者の性格より、進行構造に強く左右されます。ファシリテーターは、安全に話し、論点を絞り、実行可能な単位まで結論を縮める役割を持ちます。

良いファシリテーターは次を行います。

解決策にすぐ飛びつくと、振り返りは原因分析のない意見戦争になりやすいです。

アクションアイテムは量ではなく質

振り返りが失敗する典型例は、次のような抽象的な結論です。

これらは意図としては正しくても、運用変更にはなりません。

良いアクションアイテムには次の四つが必要です。

  1. 担当者
  2. 完了条件
  3. 適用範囲
  4. 見直し時点

たとえば次のように具体化します。

具体性が高いほど厳しくなるのではなく、曖昧な期待を減らして実行率を上げることができます。

心理的安全性がないと情報収集段階で失敗する

振り返りは結論より前に、情報収集で成否が決まります。人が話さなければシステムは見えません。

心理的安全性を高めるには次が有効です。

振り返りで最も危険な一言の一つは「それはもう分かっていた」です。この言葉は新しい観察を止め、次から誰も話さなくなります。

よくあるアンチパターン

1. すべてを扱おうとする

範囲が広すぎると課題一覧だけが増え、優先順位が消えます。

2. 事実の説明だけで時間を使い切る

出来事の整理は必要ですが、解釈と変化設計まで進まなければ単なる報告会になります。

3. 個人非難へ滑っていく

人名が中心になると、システム学習は消えやすいです。

4. アクションアイテムを出しすぎる

一度に三つを超えると実行率は大きく落ちます。

5. 次回で前回のアクションを見ない

この状態が続くと、チームは振り返りを本気で扱わなくなります。

実務で使いやすい振り返りの流れ

最も安定した流れは次です。

  1. 範囲と目的の確認
  2. 事実の収集
  3. うまくいったこと、詰まったこと、驚いたことの整理
  4. パターンと原因の探索
  5. 次に試す一つか二つの変化を選ぶ
  6. 担当者と期限を決める
  7. 次回の最初に前回のアクションを確認する

4Ls、Start Stop Continue、timeline retrospectiveなど形式は何でも構いません。重要なのは、観察を集め、パターンを解釈し、小さな実験につなげることです。

まとめ

良い振り返りは、その場で最も内省的に見える会議ではなく、来月のチームの働き方を少し変える会議です。

特に次の四つが重要です。

チームは問題を多く語るから改善するのではなく、振り返りが運用変更につながるときに改善します。

参考資料

コメント

まだコメントはありません。

ログインするとコメントできます