地方エンジニアの学習日記

興味ある技術の雑なメモだったりを書いてくブログ。たまに日記とガジェット紹介。

【ポエム】KPTについてにツラツラと書いていく

新年一発目のポエム。KPTってなんでやってるんだっけという話題が年末くらいに出てそれについてそういえばなんでだっけとなったので考えをまとめてみる。ちなみにこんな本を読んだので割と感化されたりした。

KPTスクラム

スクラムイベントの振り返りを行う上で便利なフレームワークだから」というのがざっくりした答えかなと思っていた。スクラムにはスプリントレトロスペクティブという振り返りをするイベントがスプリントの終わりにある。このやり方は自分たちも取り入れていてる。ふりかえりの機会を設け、「進め方に課題はないか」「もっとよいやり方がないか」をチェックして改善できそうなら改善案を話あっていたりする。スクラムガイドにはスプリントレトロスペクティブの⽬的は、品質と効果を⾼める⽅法を計画することである。と定義されている。スプリント内で行ったプロセスを振り返り、議論、共有することで次スプリントの品質や効果を高めることとなる。これをやる上でKeep、Problem、Tryを出して話し合うことで実現している。

感じた課題

毎スプリントごとに振り返りをやっているとこなれてきてしまいそのうち何も出てこなくなったりする。KPTのうちPが大量にあると問題だらけの状況となり「Problemが少ないならよいじゃないか!」となってしまいそうである。スプリントごとに30分時間を取っていたとして15分くらいで終わる。そうすれば溜まっていた仕事に着手する時間が増えたり短期的に見れば「問題も起きていなくて」「仕事も進む」という良い状態と見えそうである。一方で長期的に見るとどうだろうか?スプリントタスクをいい感じにこなせていればうまく回っているのでProblemは出にくくなるかも知れない。例えば「タスクAを期限内に完了することができた」ときの振り返りでKeepに「チームで協力して進めることができた」みたいなのが出たとする。似たようなタスクBを今度やるとしたら同じような進め方をすれば恐らく同じく期限内に終えることができる。

あとはKeepがでなくても課題はありそうでなぜうまくできたかを正しく言語化できないなら再現性が無いのでもしかしたら奇跡的に何かが噛み合ってタスクを完了させることができただけかも知れない。言語化と再現性は大切。

Problemが出ないと

「Pが出ない=改善活動ができていないサイン」ではないかなと思う。前述したタスクBは同じやり方をすれば出来るのが分かっている。このときの振り返りでもっとよりうまく出来ることが出てこないこと自体がPではないだろうかと思う。成長するためのチャレンジをしたいのであればこのPは常に出し続けるのがよさそうに思う。出来ることをできるようにやっているだけになってしまってはいけない。

振り返りの理想

スクラムガイドで挙げられているスプリントレトロスペクティブの⽬的は、品質と効果を⾼める⽅法を計画することである。をスプリントごとに実施出来る状態ではないだろうか。スプリントごとによかったこと(Keep)を言語化し再現性を高めつつ、タスクを進める上でよりよくするには(Problem)を考え実行に移す(Try)ことで加速的に成長できそうに思えた。

15分でさっと終わらせて仕事を進めるのではなく30分、60分という時間を投資してでも加速的成長できる環境を整えるほうを取っていきたい。毎週5%成長すれば結構な複利になる。これがKPT投資だ(?)

終わりに

KPTの本がとてもよかった。仕事を想像しながら書いていたが途中から家のことでもこうしていくと良いのではないかと思い始めた。それは楽しいのかを考えるとちょっとわからないw

参考

qiita.com