KPTとは
チームメンバ全員を集めた振り返りの作業です。
１週間〜4週間に１回行います。自分のところでは変化も大きく、改善スピードをあげたいため１週間に１回行っています。
KPTはアジャイル開発の中でもいちばん重要なプラクティスだと私は考えています。
なぜなら改善活動の問題をチームメンバ全員から吸い上げるための重要な機会だからです。
- K(Keep)
- よかったこと
- いい出来事
- P (Problem)
- 問題、課題
- 障害になっていること
- 認識を合わせたいこと
- T (Try)
- やること、やりたいと思ってること
- 技術的チャレンジなど
の３つをポストイットに記述して上げます。
なんとなくにならないKPTは
Problemには何らかの対処や共通認識が絶対に必要です。
いくつもProblemが出てくると、重要だけど大変な問題を適当に決めて、そのKPTの会が終わってしまうことがあります。
これは絶対に駄目です。
Problemは上がったモノに対して全て何らかの対処があるかを議事録した方が良いと思います。
次に問題に対する対処の追い方です。
KPTにTODOを加えたKPTTやActionを加えたKPTAと呼ばれる方法もあります。
ここで重要なのはProblemに対して、Actionを起こすべきことを決めた段階で、必ず１人をアサインします。
複数をアサインしたときも必ず主担当を決めます。そうしなければ、問題が見えただけで安心してしまい、なんのアクションも起こされないからです。
次に、このActionの内容は次回のKPTで必ず進捗を確認します。もし、何も動きが見られない場合、さらに次のKPTの確認事項として残し続けます。
それが活動として動き出した段階でOKとなり、リストから消します。
逆にProblemに対する対処行動が取れないときにはActionに上げてはいけません。
絶対やることのみをActionにしてください。
Problemに対して全てをActionする必要はありません。何らかの共通認識を確認し、現在は打つ手がないということもあります。それらは意識を合わせる、課題の情報をシェアするということが重要なのです。
Actionに絶対の責任を感じるような仕組みでKPT進めるようになりましょう
まとめ
KPTはウォーターフォールの開発であっても是非取り入れて貰いたいプラクティスです。
定例進捗を説明するだけではなく、問題点を吸い上げる重要な機会になり、開発スピードを向上し、あとにリスクを積み残さない作業になると思います！