KPTをやることが目的となってるから業務改善しないのだ

f:id:hrmch-ioii:20180822222552j:plain

@nabeemichi です。

プロダクトをつくるときや業務改善を行うためにKPT(keep/problem/try)を一定のサイクル(2週間に1回程度)で行って、 業務改善をおこなうことがしばしばあります。

KPTってそもそもなんのためにやるのかといいますと、結局はPDCAサイクルを回すためにやるわけです。

つまりは、業務の非効率なところを改善していくためにやるわけです。

KPTとは

keep/problem/tryの略で、ある一定期間での振り返りを行う手法のこと。

keepは続けていきたいこと。

problemは問題点

tryは問題点に対する改善策

をそれぞれ書き出して、振り返って次の期間で業務改善を行うこと。

KPTのミーティングをやることが目的となっている

KPTは問題点を洗い出したり、改善策を考えたりするのでなんか改善された気になるのかもしれませんが、

KPTをやっただけで、その後特に何もしないケースがある。これじゃあ業務改善しない。

みんなで1時間程度時間を使っってやったにもかかわらず、

Tryをやってがんばりましょう!で終わってる

のだ。

一定期間過ぎて次のKPTでやることが

前回のTryやりましたか?→よかった。これで改善できましたね

で終わってる。

は?って感じですね。

何を持って改善されたのでしょうか?

実行したTryはそもそも効果が出ていたのでしょうか?

それとも効果が出なくて何か問題が起きたのでしょうか?

これでは完全にKPTの会を開催することが目的となっていて、そもそもの業務改善が全くおこなわれてないじゃないですか!

なんならKPTの会の時間の1時間が無駄に消費されて、実務を実行する時間が1時間削られて、業務悪化してるではありませんか。

この現象に気づかないマネージャーは…正直やばいと思うのですよ。

だって、無駄な業務作ってるだけじゃないですか。無駄にKPTの会に参加するという業務。自分の実務時間を奪われて…

KPTを取り入れ始めたころはいいのですよ。

最初からうまくできることなんてないのですが、この状態を3ヶ月や半年やってると、何やってんですか?とつっこみたくなるわけです。

Tryを振り返ってKPTの制度を高めましょう。

振り返りを行うためのフレームワークですから、Tryが効果あったのかを振り返りなさい。

Tryをやった結果、何がどうなったのかを振り返って、TryしたことをKeepにするのかProblemにするのかを考えるのです。

要は、Tryをしっかり分析して次のTryへつなげましょう。

効果がなかったなら、効果のなかった原因をProblemから探しましょう。

効果があったなら、他のProblemへの横展開も考えてみてTryにしましょう。

こうやってどんどんTryの制度を上げていくことが業務改善につながるのだよ。

KPTをやっただけでは何も改善しません。