振り返りはしている。でも、なぜ変わらないのか
プロジェクト終了後、チームで振り返りを実施した。付箋がホワイトボードを埋め、活発な議論が生まれた。「次回はコミュニケーションを密にしよう」「タスク管理ツールをもっと活用しよう」——そんな言葉が並ぶ。
そして、次のプロジェクトが始まる。同じ問題が起きる。
多くのPMが経験するこの「振り返りループ」。問題は、振り返りの質でも頻度でもない。振り返りで生まれた「気づき」が、具体的な行動の連鎖に変換されていないことにある。
本記事では、振り返りを「感想の共有会」から「組織を変える行動設計のプロセス」へと転換するための、実践的な技法を解説する。
なぜ「行動が続かない」のか——構造的な原因を見る
振り返りで決めた改善策が定着しない理由は、多くの場合、次の3つの構造的欠陥に起因する。
① 改善項目が「抽象的な意志」で終わっている
「連携を強化する」「早めに報告する」——これらは意志の表明であり、行動の設計ではない。誰が、いつ、何をするかが定義されていない改善策は、実行されないまま忘れられる。
② オーナーシップが「チーム全員」に分散している
「みんなで気をつけよう」という改善策に、実質的なオーナーはいない。責任が全員に分散するとき、それは誰にも属していないのと同じだ。
③ 振り返りが「プロジェクトの外」に存在している
振り返りで決めた改善策が、次のプロジェクト計画や日常のオペレーションに組み込まれていない。振り返りが独立したイベントとして存在する限り、それは現場に影響を与えない。
「行動の連鎖」を生むレトロスペクティブの設計
ステップ1：事実レベルで課題を特定する
振り返りの冒頭では、「よかったこと・悪かったこと」を感情レベルで話し合う前に、プロジェクトのデータを見る習慣をつけたい。スケジュール遅延は何日発生したか、バグの発生タイミングと工程の相関はどうだったか、ステークホルダーからのフィードバック回数は想定通りだったか——数字と事実が、感想を「課題」に変える。
実践Tips：振り返り前に「プロジェクトサマリーシート」を準備する。主要マイルストーンの予実、品質指標、コミュニケーションログの概要を1枚にまとめ、全員が同じ事実を見た状態で議論を始める。
ステップ2：「なぜ」を1回深掘りする
課題が特定できたら、「なぜそれが起きたか」を一段掘り下げる。ここで重要なのは、深掘りは1回でよいという割り切りだ。「5 Whys」は強力な手法だが、振り返りの場で多用すると議論が迷宮入りしやすい。まず「直接的な原因」を1つ特定することに集中する。
例：「テスト工程が遅延した（事実）」→「テスト仕様書の完成が2週間遅れたから（直接原因）」。この直接原因に対して改善策を設計すると、行動が具体的になる。
ステップ3：改善策を「SMART+O」で定義する
改善策は、次の要素を必ず定義することをルール化する。
- 具体的なアクション（Specific）：「テスト仕様書のレビュープロセスを設計し、Confluenceに標準テンプレートとして登録する」
- 期限（Time-bound）：「次のプロジェクトキックオフまでに（＝○月○日まで）」
- オーナー（Owner）：「QAリードの田中さんが担当」
オーナーを「個人」に紐づけることが最重要だ。チームの合意を得た上で、一人の名前を書く。これだけで実行率は劇的に変わる。
ステップ4：改善策を「次のプロジェクト計画」に物理的に組み込む
振り返りで決まった改善策は、次のプロジェクトの計画書・WBS・チェックリストに直接追記する。「意識する」ではなく、「プロセスに埋め込む」。これが振り返りを現場に着地させる唯一の確実な方法だ。
実践Tips：「レトロアクションログ」をプロジェクト管理ツール上に作成し、全ての改善アクションを一元管理する。各アクションの進捗を、次のプロジェクトの定例ミーティングで月1回確認するアジェンダを固定する。
PMが担うべき「振り返り後」の役割
振り返りのファシリテーションが終わったとき、PMの仕事は実は始まったばかりだ。決めた改善策が実行されているかをフォローし、うまくいかなければ障壁を取り除く——これが「行動の連鎖」を維持するPMの本質的な役割である。
振り返りは、チームが「学んだ気になる」イベントではなく、組織が実際に変わるための設計図を描く場だ。その設計図に血を通わせるのは、PMの継続的な関与にほかならない。
「今回の振り返りで何を変えるか」ではなく、「今回の振り返りで誰が何をいつまでにやるか」——この問いを振り返りの場に持ち込むことから、あなたのチームの変化は始まる。
