振り返りは、反省会ではない
プロジェクトが終わったあと、あるいは何か問題が起きたあとに「振り返り」を行うことがあります。
ただ、その場がいつの間にか反省会になってしまうことがあります。
誰が悪かったのか。
なぜできなかったのか。
次から気をつけよう。
もちろん、失敗から目をそらさないことは大切です。
しかし、振り返りの目的は、誰かを責めることではありません。
振り返りの目的は、起きたことを整理し、次に活かせる形に変えることです。
うまくいかなかったことは、次に同じ失敗をしないために整理する。
うまくいったことは、次も再現できるように整理する。
そのために、感想ではなく、まず事実から見ていきます。
まず事実を並べる
最初にやることは、評価や解釈を入れずに、起きた事実を並べることです。
この段階では、良い悪いを判断しません。
たとえば、次のように書き出します。
- 予定よりもリリースが3日遅れた
- 初回レビューで仕様の認識違いが見つかった
- テスト工程で想定より多くの修正が発生した
- ユーザーから画面がわかりやすいという反応があった
- 事前に作ったチェックリストが役に立った
ここで重要なのは、失敗だけを拾わないことです。
振り返りというと、つい問題点ばかりを探してしまいます。
しかし、うまくいったことも事実です。
うまくいったことを拾わないと、次に何を続けるべきかがわかりません。
まずは、起きたことをフラットに並べます。
他責で考える
事実を並べたら、次に「外部要因」を見ます。
ここでは、あえて他責で考えます。
他責という言葉には悪い印象がありますが、ここでいう他責は、責任逃れではありません。
自分たちの努力だけでは変えにくい条件を整理する作業です。
たとえば、次のようなものです。
- 依頼内容が途中で変わった
- 関係者の確認タイミングが合わなかった
- 使う予定だったツールに制約があった
- 前提となる情報が不足していた
- 繁忙期と重なり、十分な時間が取れなかった
これらを無視して、すべてを自分たちの努力不足にしてしまうと、対策がずれます。
環境の問題なのか。
前提の問題なのか。
外部との調整の問題なのか。
まずは、自分たちの外側にあった要因を正しく見ます。
自責で考える
次に、自分たちで変えられたことを見ます。
ここで初めて自責で考えます。
ただし、自責も「自分たちが悪かった」と落ち込むためのものではありません。
次に変えられる行動を見つけるためのものです。
たとえば、次のように考えます。
- 最初に仕様の認識合わせをもっと丁寧にできたのではないか
- 早い段階で小さく動くものを見せられたのではないか
- レビュー観点を事前に決めておけたのではないか
- リスクが見えた時点で早めに共有できたのではないか
- 作業の優先順位をもっと明確にできたのではないか
外部要因を見たあとで自責を見ると、無理な反省になりにくくなります。
「全部こちらが悪い」でもなく、
「自分たちは悪くない」でもなく、
変えられる範囲を見つける。
それが自責で考える目的です。
対策を決める
原因を整理したら、次に対策を決めます。
ここで気をつけたいのは、「気をつける」で終わらせないことです。
- 次から気をつける
- もっと丁寧にやる
- 早めに確認する
- 意識を高める
これらは、対策のように見えますが、実際には行動が変わりにくいです。
対策は、次に同じ状況になったとき、具体的に何をするかまで落とします。
たとえば、次のようにします。
- 着手前に確認項目を5つに絞って合意する
- 初回レビューは完成後ではなく、30%時点で行う
- 仕様変更が出たら、影響範囲をその日のうちにメモする
- リリース前チェックリストを作り、毎回同じ順番で確認する
- 判断に迷う項目は、担当者ではなく意思決定者に確認する
対策は、気合いではなく仕組みにします。
人が毎回がんばらなくても、同じミスが起きにくくなる形にする。
それが、振り返りを次に活かすということです。
うまくいったことも振り返る
振り返りでは、失敗だけでなく、うまくいったことも必ず見ます。
これは意外と抜けやすい観点です。
問題が起きたときは原因を探すのに、うまくいったときは「よかった」で終わってしまうことがあります。
しかし、うまくいったことにも理由があります。
- 早めに試作品を見せたから、認識違いが小さく済んだ
- 事前にチェックリストを作ったから、漏れが減った
- 相談相手を決めていたから、判断が止まらなかった
- 作業範囲を小さく区切ったから、手戻りが少なかった
- ユーザーの反応を見ながら調整したから、使いやすくなった
うまくいった要因を言語化できれば、次も再現できます。
振り返りは、失敗を減らすためだけのものではありません。
良かったやり方を残すためのものでもあります。
振り返りの基本フォーマット
実際に振り返るときは、以下の順番で整理します。
1. 事実
まず、起きたことをそのまま書きます。
- 何が起きたか
- いつ起きたか
- どの工程で起きたか
- どんな反応があったか
- 何がうまくいったか
この段階では、評価や原因分析は入れません。
2. 他責
次に、自分たちだけではコントロールしにくかった要因を書きます。
- 外部条件
- 依頼側の事情
- ツールや環境の制約
- スケジュール上の制約
- 前提情報の不足
責任逃れではなく、条件を正しく見るために整理します。
3. 自責
次に、自分たちで変えられた行動を書きます。
- 早めに確認できたこと
- 事前に決められたこと
- 小さく試せたこと
- 共有できたこと
- 仕組みにできたこと
ここでは、反省よりも改善可能性を見ます。
4. 対策
次回から変える行動を決めます。
- 何をするか
- いつするか
- 誰が確認するか
- どのタイミングで判断するか
- 何をチェックリスト化するか
「気をつける」ではなく、具体的な行動にします。
5. 継続すること
最後に、うまくいったことのうち、次も続けることを書きます。
- 続ける進め方
- 再利用できる資料
- 効果があった確認方法
- 役に立った判断基準
- 今後も残す仕組み
これを書くことで、振り返りが失敗対策だけで終わらなくなります。
まとめ
振り返りは、反省会ではありません。
起きたことを事実として整理し、
外部要因と自分たちで変えられることを分け、
次に取る行動へ変えるための作業です。
失敗には、次に同じことを起こさないためのヒントがあります。
うまくいったことには、次も再現するためのヒントがあります。
大事なのは、良かった・悪かったで終わらせないことです。
事実を見る。
要因を分ける。
対策に落とす。
続けることを決める。
その積み重ねが、プロジェクトを少しずつ良くしていくための土台になります。