今までなんとなく、「ふりかえりはやったほうがいいよね」という前提で色んな現場を回ってきたが、改めてふりかえりってどうやるのが効果的なんだろう？と考えるべき機会にあったのでメモ的なものとして考えを書き出してみる。
そもそもなぜふりかえりをやるべきか
これは、書籍「エクストリームプログラミング（第二版)」 の フィードバック の項の内容が当てはまりそう。ちょっと長いが引用。
最初に決まった方向性が、長期間そのまま有効であることはない。それは、ソフトウェア開発の詳細であっても、システムの要件であっても、システムのアーキテクチャであっても同じだ。経験する前に方向性を決めてしまうと、すぐにダメになってしまう。変化は避けられないものであり、変化がフィードバックを必要にするのである。
彼は「最初から正しくやる方が簡単ですよね？」と言った。もちろんそうだ。ただし、以下の３つの場合は例外である。
- 「正しく」やる方法がわからない場合。これまでになかった新しい問題を解決するときは、うまくいきそうな解決案が複数考えられたり、そもそも明確な解決策が存在しなかったりする。
- 今日は正しかったとしても、明日は間違っている可能性がある場合。コントロールや予測ができる範囲を超えた変化が発生すると、昨日の決定はあっさり無効になってしまう。
- 全てを「正しく」やろうとして、時間がかかりすぎる場合。解決策が完成する前に環境が変わると、その解決策は無効になってしまう
一時的な完成に期待するよりも、常に改善を続けていこう。
何もかもが決まっているウォーターフォールのような開発であれば、ふりかえりは必要ない。作ったものが仕様を満たしているかが全てだ。
逆に、システムの完成形が見えない状態で開発を続ける場合は、チームの現在位置が目指すべき方向とあっているか常に軌道修正し続ける必要がある。この時、今自分たちは何をしてきてどういう成果を得たのか？を確認するためにふりかえりを行う必要があると言える。
ふりかえりでは何に注目すべきか
ここでもまずはエクストリームプログラミングの「ふりかえり」から引用する
優れたチームは単に仕事をしているだけではない。どうやって仕事をしているのか、なぜ仕事をしているのかを考えている。なぜ成功したのか、なぜ失敗したのかを分析している。自分たちのミスを隠そうとはしない。それを明らかにして、そこから学ぼうとするのである。偶然に優秀になれる人などいないのだ。
「どうやって」、「なぜ」 に注目することでどんな効果が得られるだろうか。自分としては以下があると思っている。
- 単純に結果の差分をみることよりも、継続的な改善につながる可能性が高くなる
- 理由を明らかにすることで、問題の本質に気づくことができる
例えば、あるシステムでのエラーハンドリングに間違いがあった場合、担当者がその箇所の修正をして終わりでなく、他に似たような実装がないかチェックし、事前に穴を埋めるべきではないか？といった議論をチームでできた方がいい。
また、ある機能のリリースが遅れてしまったという場合に、ふりかえりで理由を明らかにしていくと、そもそもスケジュールの組み方に問題があるのではないか？といった議論に発展させていける可能性がある。
が、特に工夫もせずKPTを実施すると下記のような状況に陥りがちだ。
- そもそも重要な課題が掘り出されず表面的な発言に終始する
- 議論がうまく発展せず、「つらい」という愚痴だけを言う場になってしまう
これをうまくやっていくための作戦として、 理想と現実にどのようなギャップがあるかを考える というのが有効ではないだろうか？ 例えば、
- 問題: タスクの進捗が遅れている
- 理想1: そのタスクは本当にやるべきか
- 理想2: タスクを進める人を増やす(ペアプロ) できた方が良さそう
KPTや1on1で課題出しをすると、問題だけが単に噴出する。それはそれで必要だが (何も出てこないのが一番良くない) 、課題を言った後で、「じゃあ理想はどうあるべき？」 「そこに近づくために何ができる？」 と考えるのが良さそう。
過去を「ふりかえり」、未来へ「むきなおる」 行為を同時に行うこと。
この「むきなおる」ためには、自分たちがどこに向かっていくべきか？をわかっていなければならない(完璧なものでなくとも).
この時に必要なのがチームとしてのマニフェストやリーンキャンバス、ミッションビジョンバリューやゴールデンサークルといったものなのかなと思うが、これがどういった観点を元に作られているか？も重要だ。
トップダウンで決められたものなのか、チームメンバーが話しあって決めたのか、それらは定期的に見直されているのか、どのような理論・思想・論文等を元に作られているのか....
この辺はまた改めてまとめたい。