KPTの問題点

テーマ:
ふりかえりツールとしてKPTは広く使われるようになりました。わたしもKPTを使ったワークショップを前川さんとSPES2007で やったこともありました。

KPTの良さは「次にやること」を挙げていくことだと、自分では思っています。プロセス改善のモデルのPDCAにおけるActionに相当することのプラクティスとしてはとても有効です。

しかし、今日社内で議論した中でKPTにもまだ弱点がある、という話が出てきました。

KPTによって新たなチャレンジとしてのプラクティスを挙げても、実際にはフェードアウトしてしまったりすることがある。それはなぜだろうか?

次にやることを考えるときに「なぜそれをやらなければいけないのか」ということが、KPTの上には書かれないということが1つの要因になっているのではないでしょうか。

KeepやProblemで挙がる、チームで起こったことやそれに対するメンバーの感情。そこからTryを導いているのですが、そこに「なぜ」があるはずなのに、KPTにはそれを書くスペースが用意されていないのです。

おそらく、KPTを効果的に活用している現場では、この「なぜ」もどこかに記入するという、独自の方法を使っているのかもしれません。紹介されているプラクティスはあくまでモデルであって、それを自分たちの使いやすいように、より効果的に工夫することが必要です。

弊社でもそうで、いろいろTryを挙げていっても、どうもそれが効果的に見えないケースが多い。そこにはメンバーが「本質を理解する」という部分がない、もしくはそのようなディスカッションは含まれていても、見える形で残さないと印象に残らないのかもしれません。

そこで、まだ名前は考えてないのですが、NewKPTが提案されました。


How to make a smiling face ~笑顔の作り方~
この利用方法は以下の通りです。プロジェクト終了時のふりかえりを例にしたいと思います。

1)プロジェクトの活動を通して、自分が感じたことを「自分の感情」エリアに挙げる。これは良いことも悪いことも一緒に。
2)プロジェクトの中で起きた事実を挙げる。例えば「仕様の誤理解で手戻りが発生した」とか「見積よりも思ったより早くタスクが終了した」など。
3)先に挙げた感情や事実について「何がそうさせたか?」を挙げます。すべての事実にはその原因があり、それを探ることで、本当の解決策を考える手助けをします。

簡単に手順を説明しましたが、これを挙げていくうちにも新しいアイデアが出てきました。
ここの「何がそうさせたか?」という問いは、トヨタ式で使われる「なぜなぜ分析」にとても近いものです。なので、この項目も3段階ぐらいやってみてはどうか、というアイデア。

また、従来のKPTを踏襲すると、やはり「次にどうするか」を挙げると思います。しかし弊社はそこをチームのふりかえりでやらなくていいのではないか、という結論になりました。

その理由は「自分で考えるエンジニアを育てたい」という会社の方針によります。

エンジニアにとって大切なことは、自ら考えチャレンジすること。そこに自らの工夫を持ち込むこと。
その場を提供するために、あえて結論を出すことルールにせず、各自で考えてもらうことをルールにします。

もちろん、やり方を決めようということがチームの決定であれば問題ありません。それはふりかえりを自分たちのルールで実施するという「エンジニアの工夫」であると解釈します。


ふりかえりのツールはKPTに限らず、まだまだあります。前回の記事でも紹介したこの本に、様々な方法とその効果が紹介されています。

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き/Esther Derby
¥2,520
Amazon.co.jp
これらを参考にして、自分たちの状況や目的に適ったふりかえり方法を模索することをお勧めします。楽しいですよ。

あたらしいこの方法に名前がついたら、またご紹介しますね。

AD

コメント(2)