• Home
• コーポレートブログ
• 開発を初めてKPT法で振り返ってみて感じたこと

杠です。早く暖かくなってほしいところですが、まだ春は先のようですね。

さて、今回はKPTの振り返りについて書かせていただきます。ブログでも何回か登場しているKPTですが

• K(Keep)は良かったこと、続けていきたいこと
• P(Problem)は悪かったこと、改善すべきこと
• T(Try)は次にやりたいこと、試したいこと

を出して振り返りを行う方法です。

きっかけ

昨年の12月頃から出退勤管理システムの開発に取り組んでいます。新しく開発を始めるにあたりKPTを用いて振り返りを行うということに決まりました。社内の中でもKPTで振り返りを行っていますが、一つの目的（開発）に対して数人でKPTを行うのは私にとって初めての経験でした。

実際にやってみて

ボートを使って金曜日の11時からを予定して行っています。最初の方は、社内のKPTのProblemで何回か話題が出てくるほど忘れることが多く、まだ数えるほどしか行っていません。

社内で行う振り返りとは違い、同じ目的をもったメンバーと振り返りを行うと、具体的な内容のKeepやProblemが出しすいなと感じました。同じ目標に向けて取り組んでいる分、共感できる部分やこうしたらいいんじゃないかというTryも出しやすいのかなという発見もありました。

実際に前回の振り返りではつまづいたところを共有したことがKeep(Good)、 私があげた分からない部分が分からないという曖昧なProblemから 一人一人がモヤモヤしたことを張り出すスペース(ハテナリスト) をボードに作ることになりました。さらに、 チームでやってみたいことを張り出すスペース(やりたいことリスト) も新たに生まれました。

メンバーは出退勤管理システムだけだなく別のプロジェクトがあったりと、ひとりひとりが同じ時間をとって開発に取り組んでいるわけではありませんが、振り返りで１週間でそれぞれできたこと・できなかったこと・悩んだことを出し合い、個々の状況を共有できるようになりました。また個々の状況を知ることで、今後の開発に向けてどのように取り組んでいくべきか明確になりました。

コミュニケーションを取る時間は限られますが週に一回でも振り返りを行い、それぞれよかったまずかったと思っていることが共有する機会を設けることが大切だなと感じました。

自分の課題

昨年にKPTのセミナーに参加させていただき、基本的な部分は押さえているつもりですが思うようにKPTを回せていないなと感じることがあります。KeepやProblemに対してのTryが実際に行動に移せるようなものになっていなかったり、行動に移せるまで時間がかかるものを出してしまいがちです。最終的にはTryのままいつまでも残っているということにならないように見極める力も必要だと感じました。

まずは色々なTryを出してみて、実際に行うTryを選択するときに「実際にすぐに行動に移せることなのか」、「もっと具体化できないか」などを意識して振り返りを行なっていきたいです。振り返りを行なっただけで満足せずに、小さなTryでもそれを実行して得る達成感も大切にしていきたいです。個人でもKPTで振り返りを行って、振り返りの質を少しでも上げていけたらなと思います。