この記事はグロースアンドコミュニケーションズ Advent Calendar 2017 の10日目の記事です。
こんにちはsadaです、
今回は振り返りの手法の一つである「KPT」で心がけていたことを書かせていただきます。
私が経験していたKPTでの振り返りの流れは以下になっております。
- チェックイン
- KEEP
- PROBLEM
- TRY
- ドット投票
それぞれのフェイズで何を心がけていたのかを順番に書いていきます。
チェックイン
チェックインは緊張をほぐしたり、発言をしやすくするためのものです。
このフェイズで私が心がけていたことは「大きな声で話す」でした。
大きな声で話すことでこのあとのフェイズで発言をするときに自然と声が大きくなり自信をもって話ができるようになります。
KEEP
振り返り当日までにKEEPを貯めるためのコツを書きます。
私が心がけていたことは、「できて当たり前の事をあえて探す」です
例として前回のTRYで「新規のSQLは必ず検証環境で性能を測りエビデンスとして残す」というTRYが上がったとします。
果たしてチームメンバーの中でどれだけの人間がこのTRYを実行するでしょうか？
私の経験では少なくとも全員では無いと思います、むしろ忘れずにやっている人のほうが偉いのです！
このようなやって当たり前とされていることをやることは評価がされにくくKEEPに上がらないことが多いです、しかし私はこのようなやって当たり前の事をやることは承認されるべき大事な行為で、
このような行為を承認することでチームメンバーのモチベーションが高まると考えています。
PROBLEM
ここで私が心がけていたことは、「誰かがPROBLEMとして上げそうなことでも素直にだす」です。
PROBLEMを書くときにいつも「今回の障害はあの人が担当だから自分は出さなくて良いや」、
「インターフェイスの変更はみんな被害被ったしみんな書くだろう」などと考えたりして、
課題に感じていることでも書かないことがありました。
しかしある重大な障害が発生したときのスプリントの振り返りのとき、このような
「誰かが書くから自分は出さなくていい(=他のPROBLEMを出したほうが良い)」
という考え方が誤りであった事を思い知りました。
振り返りのときその重大な障害をPROBLEMで上げたのは二人だけでした、
もちろん重大な出来事なので振り返りでは全員が当事者意識をもって問題解決に努めていましたが、その振り返りが終わったあと障害対応を担当していた人がポツリと
「PROBLEMがあがらなかったからみんなあまり大事だと思っていないんですかね」
とつぶやいたのを聞きました。
私はそれまで同一のPROBLEMが多く上がることを、深く掘り下げられていない状態だと認識していましたが、その日以来認識を改め、同一のPROBLEMが多く上がることを、課題に感じている人が多い状態であると素直に認識するようにしました。
TRY
ここで私が心がけていたことは「個人攻撃にならないように気をつける」です。
PROBLEMに対して「なぜ？どうして？」を突き詰めていくと
「（個人名）さんが作業ブランチ間違えたから」
「（個人名）さんが仕様変更の連絡に気が付かなかったから」
などの個人攻撃の暗黒面に落ちがちです。
気持ちはすごくわかるのですが、まったくなんの発展も無いので個人攻撃はやめましょう。
ドット投票
ここで私が心がけていたことは「一番に投票すること」です。
投票という行為で最も避けたいことは投じた票が「死票」となることです、そしてそれは多くの人が避けようとすることであり行動原理となります。
なのでドット投票のときに一番に投票すると、同じ課題感を持っている人で死票を投じたくない人の票が自分の投票した意見に対して集まるようになるためイニシアチブがとれます。
ちょっと小狡い方法ですが、どうしても賛同を得たい意見があるときにオススメです。
最後に
なぜこの記事を書こうと思ったのか、それは私自身が振り返りに初めて参加してからしばらくはなんとなく参加しているだけで、
無為な時間を過ごしていたため、そのような経験をしている人の役に少しでも立てばいいと思ってのことです。
振り返りはチームとしての機能を高めるためのものですので、メンバーとして積極的に参加することで、振り返りを有意義なものとしチームとしてのパフォーマンスをガンガン上げていきましょう！！
