以前、書いたKPT法を実際に1人やプロジェクトの「フリカエリ」で使ってみて感じたことを書きます。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
KPT法の優れている点は以下の3つと思います。
1つ目：サッとできる。
紙とエンピツがあればすぐにその場でできます。
2つ目：見える化できる。
付箋紙等を使えば「見える化」されることで、改善される感がより実感できます。
3つ目：ブレストしやすい。
手軽に行えるので前準備も特に必要なく、みんなでやりやすく、良いブレーンストーミングができる可能性が高くなります。
KPTの難しい点
逆に「これはKPT法では難しい」と思ったこともありました。
KPT法では「悪かった点(Problem)」に対し「改善点(Try)」を行いますが、このTryが抽象度が高いぼやけた内容だと「なんとなく」な内容になり、そのアクションリストも曖昧なものになります。
つまり「Problem」に対する表面的な「Try」でしかなく、『真因』まで分析できていないからです。
製造業の現場に多い「なぜを5回繰り返す」「なぜなぜ分析」など、考えに考え抜き、その真因を導き出すのが「根本的な改善」というものです。
ただ、(KPT法に比べ)時間がかかり、また、「なぜ？なぜ？？」と突き詰めるのはパワーも必要なのでなかなかそこまで踏み込めないこともあります。
話を戻すと「Problem」に対する表面的な「Try」を立ててみたところで、その「Try」は的外れかもしれません。
この手の改善プロセスは、割とすぐに目に見える効果が出ないとしんどくなり、必須でも無い故に「やっぱり無駄なので、止めようよ」となりがちです。
そのためにも、小さな成功体験で良いので、それを体験する時を導入する時の最初の目標にすることもあります。
「Keep」も同様で「なぜそれが良かったのか？/良くできたのか？」が分からず、「なぜかな知らないけど偶然出来た」レベルでは、再現性の低い事象となります。
その結果、習慣として定着せず、安定した高いパフォーマンスを出せなくなります。
最初からヘビーウェイトなプロセスで深掘りするのもしんどいものですし、そもそも全ての「Problem」に対して必要があるか分かりません。そしてもちろんそんな時間もありません。
ですので、どれを重点的に深掘りするか「見える化」するためにKPT法を使い、そこから重点的な項目に深掘りの技法を使うのが私にとってはしっくり来る改善のパターンだと感じました。
コメント