「ふりかえり」というロストロギアを使おう
ここ最近、ウォーターフォールのプロジェクトでも「ふりかえり」をやっていることを見かけることが増えたような気がします。あるケースでは他のプロジェクトでやっていたことを見て自分のプロジェクトでもやってみようというプロジェクトマネージャ自身が取り入れていたりと、なかなか良い傾向だなぁと。続けられるかどうか、が鍵ですが。でもまだ、プロジェクトの終わりに「ふりかえり」をやろう、なんですよね。
時間軸でいうと、プロジェクトの終わりにふりかえりをするパターン。
ふりかえりをするプロジェクトが終わってしまうと、プロジェクトは有期限性のものだからそのプロジェクトは解散するんですよね。システム開発プロジェクトが終わって維持管理が始まるかもしれませんが、プロジェクトとしては別物です。スコープも違うしメンバも違し、バジェットも違うんだから。
なので、システム開発の最後でふりかえりをしても、次のタイミングのtryは維持管理のプロジェクトに引き継がれてもやる人が違うんだったら、ふりかえることの有用性は疑問です。だって、ふりかえりって繰り返し作業を行う人たちのための改善ですから。
振り返りをしたメンバたちは解散すれば元の職場に戻りますから、ふりかえりで出てきたtryをやるかどうかはその人に委ねられちゃうし、tryをやろうと思っても次のプロジェクトで実践できる環境かどうかはわからないですし。
そうすると、ふりかえり自体にやることの意味がわからなくなってしまうんですね。
なので、是非実行して欲しいのは、1週間くらいのサイクルのふりかえりです。毎週ふりかえりをするのがおすすめ。
繰り返しふりかえりをすることはメンバが振り返りをすることに対して慣れができることのメリットがあるのですよ。プロジェクトの完了時にふりかえりをするとどうも会議形式になってしまうし、反省会になってしまう。日本人ぽいですが、ちょっといやですね。
なぜ嫌かというと会議形式にした途端、時間は長くなるし、建前が出てきたりするから。また、効果がどうとか管理のための管理が増えたりとかとか。そんなためにふりかえりをするんじゃないんだから!!
あとですね、時間は15分と決めましょう。それ以上はやらない。終わらなくてもいいから。でね、来週もやるよ、と予告しておく。繰り返すので次第に慣れますから。
ふりかえりの本質は、継続するチームで「思ったようにできなかったところを変えてみよう」というものです。だから、チームとしての活動が続かないとふりかえりをしたところで、変えようがないんですよ。だから、プロジェクトの完了時にやるのではなくて、1週間に1度とかにしてみようと言うのです。
サイクルを短くすることで、できる変更は少なくなります。だって、1週間の間に改善を3つも4つも変更できないですよ、現実的に。もともとの計画している活動があるんですから。それを棚に上げて改善活動をしていたら、予定していたアウトプットが得られないですもの。
あと、短いサイクルでやることにすると、1週間の中で長い会議じみたことをやっていられなくなるですね。だって、作業しないとアウトプットでななくなって本末転倒になっちゃうんですから。
で、ですね、プロジェクトの中で繰り返してふりかえりをするのって、チームの成熟度を上げていくためにやるんですけれど、薄々気づかれていましたか。
図にするとこんなイメージ。ふりかえりをして何か1つでいいから変えてみることにして、実際に変えることで次のスプリントとか工程とか1週間に変化が起きる。だって、1つやることややり方を変えたんですから、その変えたことから学習が生じるわけです。
変えてみたら期待どおりだったとか、上手くいかなかったとか。上手くいかないということを経験で知ることも1つ成熟度が上がります。それは失敗するやり方なんだ、と。
このふりかえりって、KPT(ケプト)とか言ったりしますが、実は、品質管理のPDCAのサイクルなんですよね。何言っているかと思いましたか。えっとですね、品質管理も工程の最後だけで評価していたら品質管理にならないんですね。短いサイクルで繰り返すふりかえりと同じように、短いサイクルで品質状況を測定して、課題の中から品質に至っていない原因に対して対処する活動そのものなんですから。
さらに言えば、こうした品質管理の活動の概念は2000年にはすでにウォーターフォールのシステム開発方法論の基礎となるプロジェクトマネジメントの管理要求で実施されていることなんですよね。そのプロジェクトマネジメントの品質管理の中のPDCAの改善の部分を取り出すと、あら、「ふりかえり」になっちゃう。
で、それをチームの改善、とラベルを貼ることで新規性が出る、と。まだまだ過去の遺産の中からロストロギアが見つけられるかもしれないなーと思うのでした。まる