Tbpgr Blog

Ruby プログラマ tbpgr(てぃーびー) のブログ

KPTを使いこなすの、難しくないですか?

システム開発関連の現場ではそこそこ浸透してきている印象のあるKPTですが、
実際に取り組んでみると、

  • 問題ってどのくらいの粒度なのだろう?
  • Try と Keep の境界ってどこだろう?
  • Keep から消すタイミングっていつだろう?

など、考えるところは多いと思います。
そこで、私が考えるKPTの難しさについてまとめてみます。

KPTとは?

KPTは振り返りのためのフレームワークです。
それぞれ Keep / Problem / Try の略で、
よかったこと、うまくいかなかったこと、今後実施することをあげていきます。
基本的な話については下記の記事が詳しいです。

KPTの起源

物事には起源があります。
KPTにも当然作者がいて、そのとき困っていた問題を解決するという目的があったはずです。

で、ほどほどに時間を使って調べてみましたがわからなかったので、起源についてはわかっていないままです。

目的

これは私の推測です。間違っている可能性が大いにあります。

KPTの大きな目的は振り返りをフレームワーク化することで習慣化を始めるためのコストを下げ、
より多くの場所で振り返りが実施されることを促進することではないか、と思います。

そして実際の振り返りによる恩恵はチーム・個人の成長に尽きると思います。

チームとして以前よりよい手法を取り入れる、作り出す。
個人の問題点を改善する。

これによってより大きい成果を有無、労力をより小さくするなどの成果につながります。

KPTの難しさ

問題発見の難しさ

過去の経験や視野や知識量によって、発見できる問題の質と量が大きく変わりそうです。
自ら問題を発見し、解決する経験が少ない人が多い場合は、得意な人がそういった思考について
仲間に説明していく必要がありそうです。
それをしない場合に、問題を発見する人が一箇所に集中しそうです。
一番厳しいパターンは誰も問題発見に慣れていなくて、その事実自体に誰も気づいていないケースです。

問題解決の難しさ

Problem から Try を作り出す際に問題をどう解決するか、という解決の仮説を作る能力は人によって異なります。

例えば、誤って対症療法を選んでしまい、それが全体の構造としては長期的に負の結果を招く可能性があります。
それを成功とみなすか失敗とみなすかの基準が曖昧だと実は負債を積み上げる対症療法を選択し続ける可能性があります。
その結果として Problem が出現してきて首をかしげることになるのかもしれませんが。

逆に視点の高い人がいると、ちょっとした問題から組織の課題を発見し、例えば組織の命運を変えるレベルでの
改善提案をできることもありえそうです。

※問題解決の思考フレームワークなどを使うまでもなく、解決策が明白な場合の話は対象外です。
また、そもそも思考フレームワークが必要となるような規模のものはKPTでは扱わないという意思決定もありそうです。

優先度の概念の抜け落ち

何かをするには時間が必要です。仕事においても個人においても時間は有限です。

例えば、 Problem で発生した問題の重要度やそれを解決するのに必要な時間を加味せずに
「問題が発生したから取り組む。そして解決する。やった嬉しい!」
となった場合に、実は同じ時間を使って他の課題に取り組んだほうが好ましいかもしれません。
KPT で出てきたタスクというのはその時点では想定外のものだと思うので、既存のタスクと優先度を確認し、
その上で取り組む必要がありそうです。

まとめ

念のためですが、特にKPT批判とかではありません。
振り返りは重要で、KPTのような仕組みがあるのはとても有用だと思っています。
ただし、使いこなすには少なくとも中心人物の一人が振り返りと問題の解決に関わる周辺の知識を
多く持っている必要がありそうだな、ということを思いました。

また、ある程度KPTを利用する組織内での活用方針のルールのようなものを定める必要がありそうで、
それがないとけっこうカオスになりそうだなと思います。

ということで、KPTを使いこなすために必要な前提知識のようなものが
まとまっていると嬉しいのではないか、ということを思いました。

皆さんの組織のKPTにはどんなルールがありますか?
優先付や真因の発見はどのようにしていますか?
組織・個人として使った時間に値する成果はでていますか?

補足

個人では数年以上KPTを使っています。
組織では一時期少し同僚と3人でKPTを使っていましたが、どちらかというと個人の振り返りをそれぞれが
話しているようなものでした。
サービスに対するKPTについては数回だけしか実施したことがないので、あまり知見がありません。