概要
業務プロセス改善に用いられる「KPT」ですが、
結果を見ていていくつかのバッドパターンのようなものがあったので
自分への戒めを込めてまとめてみたいと思います。
1.次のKPTまでの期間が長すぎる
起こってしまう事象
リリースやプロジェクトの完了時にKPTを行うようなパターンですが、
リリースが長引いてしまったりすると前回が数カ月前！のような状態になることがあるようです。
当然ながら前回のKPTの内容など覚えておらず、今期の作業内容も思い出せない！
というような状況に陥ってしまいます。
改善策
週次、月次等KPTの間隔を短く取る。
短くしすぎるとKPT自体にコストがかかってしまうため、そのあたりは要調整です。
2.前回のTryが評価されない
起こってしまう事象
Keep/Problem/Tryを振り返る期間の内容からのみひねり出してしまい前回のTryについての評価がされない。
前期間のTryがどうだったかは、今期間の取り組みを振り返ることでわかります。
Tryを忘れてしまってはプロセス改善になりません。
改善策
KPTの開始時に前期間のTryを分析して今期間のKeepとProblemに振り分ける。
前回のTryを実際に試してみた結果をKeep/Problem/Tryに分解します。
Tryがうまくいったのであれば継続するのでKeep、
うまくいかなかったのであればそれを分析してProblem、
実施できなかったのであればTry、もしくは実施できなかった理由がProblem
として分解されます。
3.ProblemとTryに関連が無い。
起こってしまう事象
ProblemとTryを列挙することに終始してしまい、
ProblemとTryの間の関連が無い状態になってしまう。
結果として、Problemに対して対応策となるTryが無い、
もしくはTryの原因となるProblemが無い
という状況になります。
改善策
ProblemとTryに番号を振って紐づけましょう。
どのProblemからどのTryが発生したのかがわかるようにすることが重要です。
4.Keepに実績を書いてしまっている
起こってしまう事象
表題の通り。
Keepは次期以降も継続する施策なので実績は含まれません。
実績をKeepに挙げても次期以降で参考にならないので、やった気になれますが役に立ちません。
改善策
実績をあげられた原因を分析する
例えば
「いつもスケジュールが遅延するが、今回はスケジュール通りに行うことができた」
が実績としてあるのであれば、
「XXという見積もり方法を取り入れることでうまくいった」
のような原因があるはずです。(ないのであればKeepにはあげられません)
この場合、「XXを次回以降も実践する」がKeepとなります。
まとめ
KPTは基本的に起こった事象を深堀して次の期間のプロセスを改善するためのツールです。
今期間のProblemからTryを見つけ、それを次の期間でKeepするのかさらに別のTryをするのかを分析します。
Keep/Problem/Tryの間の関連がわからなくなったら大体失敗なので、
それぞれがつながっていることを意識して分析するといいと思います。