プロジェクトの振り返りが次に生きない：実行前に変える手順と役割

案件が終わり、報告会で反省点を並べる。共有フォルダーへ資料を置き、解散する。ところが翌月の別案件でも、同じ引き継ぎ漏れが起きる。前回はきちんと振り返ったのに、なぜ仕事が変わらなかったのだろう。

欠けていたのは、反省の深さだけではないかもしれない。報告を受けた頃には、次の案件の担当者も手順も決まっていた。資料を読む人はいても、変更する権限を持つ人がいなかった。振り返りは、過去を説明する会議であると同時に、次の実行を変えるための意思決定である。 ならば、案件が全部終わるまで待つべきなのか。この問いを研究と具体例から考える。

振り返りを増やせば、成果も増えるのか

TannenbaumとCerasoliの2013年のメタ分析は、46標本・2,136の参加単位を統合し、振り返りを行う条件で、比較条件より高い成果を報告した。平均の標準化効果量はd＝0.67だった。医療、軍事、その他の領域にまたがり、実際の作業とシミュレーション、個人とチームを含む。

ただし、多くの研究は準実験であり、振り返りに参加した集団が、最初から成果を出しやすかった可能性を完全には排除できない。主観的評価を使う研究と客観的指標を使う研究で、平均効果にも違いがあった。原論文の限界の説明は、因果推論と未公刊研究の不足に注意を求めている。

これを「反省会を開けば、売上が一定割合で増える」と読むのは飛躍だ。研究の成果指標は統一された売上ではなく、dは増収率ではない。まして、毎週開催と案件終了後の開催のどちらが優れるかを、この平均値は直接答えない。本稿が提案するタイミングは、効果研究を踏まえた業務設計上の判断である。

失敗だけを集めると、何を見落とすか

EllisとDavidiの2005年の研究は、イスラエル軍の地上ナビゲーション訓練を扱った。原論文による対象は、二つの中隊に属する18～20歳の男性兵士98人。失敗だけを振り返る群と、失敗に成功の検討も加える群を比べ、後者でその後の訓練成績がより改善した。

成功だけの群や、振り返りをしない群は設定されておらず、民間の事業案件への無作為実験でもない。「成功だけ見ればよい」とも「成功と失敗を同じ時間ずつ扱えばよい」とも言えない。示唆は、うまくいった作業にも、再現するために説明すべき条件があることだ。

実務では、納期を守った案件ほど、そのために何を消費したかが隠れやすい。特定の専門家が夜間に調整した、顧客が例外的に早く回答した、別部署が予定を後回しにした。これらは本稿の例であり、論文の実測事例ではない。同じ手順を別の案件へ移すなら、成功の裏側にあった条件を一緒に移せるかが問題になる。

次に変える仕事に合わせて、会議の型を選ぶ

KeiserとArthurの2021年のメタ分析は、61研究の結果を整理した。構造化された振り返りが軍事領域で有利な一方、医療では構造化の程度が異なっても同程度の効果を示すなど、運営の条件が相互に作用していた。2020年のオンライン初出と、2021年の掲載年を区別しておきたい。

次の切替で何を直すかが決まっても、会議の型まで一律には決まりません。チームの成果と個人の技能のどちらを扱うか、作業記録を使えるかに応じて運営を選びます。振り返りの価値を否定する留保ではなく、細かい型や外部進行役を必須にする根拠が不足しているという説明です。研究ごとに評価基準が違うため、平均効果の違いも年代による進歩とは読めません。

振り返った技能が、長く残るとは限らない

Muñozらの2022年の研究では、チリの大学生96人を初期標本とし、振り返りあり・なしへ無作為に割り付け、PC上の火災対応シミュレーターを練習させた。約12週間後に戻った84人の再評価で、振り返りが技能の低下を防ぐ効果は支持されなかった。成績の低下と再学習の差も、小さく統計的に有意ではなかった。

学習直後の改善を扱う研究と、長い不使用期間を挟むこの研究は、測っているものが違う。振り返りは無意味とも、忘却を防ぐとも決めつけられない。本稿の提案も、学びを次の実行へ近づける設計に限定する。久しぶりに行う重要な作業では、以前の振り返り資料だけで技能が残っていると判断せず、実行できるかを別に確認したい。

開催日は、次に変えられる仕事から逆算する

ここからは編集上の提案である。振り返りを置く場所は、週次や月次というカレンダーだけで決めず、次に同種の仕事が始まり、まだ手順を変えられる場所を探す。

一つの導入案件の中で、拠点ごとに同じ切替を繰り返すなら、最初の拠点が終わった時点に学習の機会がある。全拠点の終了後では、次の実行へ反映する余地を失う。一方、最終成果を見なければ評価できない仕事では、途中の印象だけで方法を変えると、まだ結果の出ていない案を失敗扱いしかねない。

この二つを混ぜない。途中では「実行手順の何を変えるか」を扱い、終了後には「事業として何を得たか」を評価する。短い振り返りを何度も行っても、事業成果の検証を代替したことにはならない。

仮想例：早めるべき場面と、待つべき場面

複数の事業所へ受注システムを導入する計画を考える。最初の切替では、操作は予定どおり終わったが、権限の準備漏れで一部の利用者が翌日まで仕事を始められなかった。次の事業所の準備はまだ変えられる。ここでは全社導入の完了を待たず、権限を誰がいつ確認するかを決め直す。振り返りの成果は議事録ではなく、次の切替の準備手順と担当の変更になる。

条件を変える。同じシステムの目的が、数か月後の在庫の改善だったとする。切替直後には操作時間が延びたが、まだ繁忙期を経験していない。これだけで「導入は失敗」と総括して元へ戻す理由は弱い。操作上の問題は直す一方、事業効果は適切な期間と比較条件を待って評価する。早い振り返りが有効でも、早い結論が常に有効とは限らない。

さらに、重大な不正の疑いが見つかったなら、自由な意見交換で関係者の記憶をそろえる前に、必要な記録を保全して調査の担当へ渡す。本稿の学習会と、事実認定や責任判断の手続きは役割が違う。何でも振り返り会へ集めるのは、適切な設計ではない。

会議に持ち込むのは「感想」より、食い違い

会議には予想・実績・食い違いの説明を分けて持ち込む。多数決で原因を確定せず、次の実行で変える箇所、維持する役割、未確認の仮説を決める。記録がないなら詳しい物語を作るより記録方法を直す。事故時の防御を調べる方法は事故の振り返りへつなぎ、ここでは次の実行に間に合う修正と、事業結果を待つ評価を分ける。

プログラム全体では、誰が学びを引き受けるか

案件ごとの改善を、別案件へ自動的に適用するのは危険だ。前提が違うからである。しかし「条件が違う」で放置すれば、何も移らない。プログラムを管理する側は、教訓そのものより、適用する条件と確認する責任者を受け取る。

例えば、「切替前に全員の権限を確認する」という学びでも、個別権限を持つシステムと、共通端末だけで動くシステムでは方法が違う。どの利用者が何を開始できれば準備完了かを共有し、その判定を各案件が具体化する。共通の目的と現場の方法を分けると、単なる横展開の通達より、変更を実行しやすい。

最後に、次の実行で変更が行われたかを確かめる人を置く。改善の担当者が別案件へ移り、提案が宙に浮くなら、プログラムの側で引き受ける。振り返りの開催率が高くても、次の仕事が変わらなければ、学習の仕組みとしては未完である。

次の試行へ変化を入れられ、比較できる事実があるなら、案件終了を待たず節目で振り返る。結果がまだ成熟していなければ、観察と仮説の整理にとどめ、全体評価を待つ。 反省会を早めるというより、変えられる判断に学びを間に合わせる。その設計が、案件の経験を組織の能力へ変える入口になる。