読者です 読者をやめる 読者になる 読者になる

KPT法のまとめ

会社のユニットMTGでは、1週間の振り返りのためにKPT法を利用している。

でも、もしかしたらルール曖昧なままじゃない?
もっと、カイゼンした方が良いね。

ってことになった。

さすがに、その状態から闇雲に議論するのは、時間コストとしても想起される結論も危険と判断。
調べてみることにした。

調べてみた

経験からの学習は、今週からコーチングに来ていただいている方に質問をして、
自分たちでは一般論を調べてみる。

本も一冊買いたかったが、とりあえずネットで。
欲しかった本はコレ。

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き


会社にあるかな?読みたい。


以下、徒然に

KPTとは?

行ってきた仕事や活動を振り返る際に、「継続」「問題点」「挑戦」の3つの視点で整理するフレームワークのこと。

具体的には

  • K = KEEP = 「今後も続けること」
  • P = PROBLEM = 「問題なので、やめること」
  • T = TRY = 「Pをやめるために行うこと/今後、試してみたいこと」

つまり、仕事や活動を振り返り、その場限りのものにしておかない、ということだ。
常にカイゼンをかけていくためのフレームワークである。
PDCAとも似ているが、KPTは振り返り、という作業に特化している。

必要なモノ

ホワイトボードで行うとき。(推奨)

  • ホワイトボード
  • マーカー

ホワイトボードが使えないとき。(スペースが限られているなどのとき)

  • なるべく大きな紙(B紙など)
  • 付箋(大きめのサイズ)
  • ペン

必要なモノはとてもシンプルだ。そう、KPTはとてもシンプルでやりやすいものだ。

どうやるの?

KPTの時には、以下のような図を使うことが多い。(Themeはあってもなくても良い)
f:id:sugilog:20091024113833p:image:w400,h300

まずはホワイトボードに、ざっくりとKPTを書くスペースを作ろう。
参加者全員に、ホワイトボードの前に立ってもらおう。

説明のために例として、ワークショップの1回目を行った、という状況を想像してみよう。
使うモノは、ホワイトボード。
リーダー + 参加者数名 というようなチームだ。

テーマの設定

f:id:sugilog:20091024113834p:image:w400,h300

「何のための振り返り?」という目的をはっきりしないと、KPTが進まない。
みんなの共通認識として目的を持つために、リーダーが書き出してしまうと良い。

ここから先は、参加者ベースで進んでいく。
参加者がホワイトボードに直接KPTを書き込んでいく。

リーダーは、何を書く時間か(K or P or T)を示し、書き込みを促すようにする。

KEEPの洗い出し:良かったことを次回以降に残す。

f:id:sugilog:20091024113835p:image:w400,h300

良かったことは、次回以降でも実践するために書き出しておこう。
いくつでも、どんな簡単なことでも良い。

書き出すことができたら、なぜ良かったのか?なぜできたのか?ということを、簡単に考えよう。
これを行わないと、再現性をもったKEEPにならず、KEEPしにくい。
ただし、KEEPに時間を使いすぎるのは良くない。

PROBLEMの洗い出し:問題があったことをみんなで共有する。

f:id:sugilog:20091024170913p:image:w400,h300

問題があったことは、放置しておくと、取り返しのつかないことになる。
個人レベルではもちろん、チームで問題を放置すると、チーム全員の時間をムダにする。

問題を書き出すときには、原因が何で=>その結果どんな悪いことが起きるというようにして書くと良い。
それが本当に問題なのか?それともただ問題みたいに感じたけどそうでもなかったのか?
参加者全員で確認することができるからだ。

注意点は、PROBLEMはアクションではない。何が悪い、ということを書く場だ。
○○をしなければいけなかった。はPROBLEMではない。

TRYの洗い出し:PROBLEMのないTRYはない。

f:id:sugilog:20091024171245p:image:w400,h300

問題は書き出しただけでは意味がない。
問題を解決するために、何をしなければならないのか、ということを書きだそう。

PROBLEMのないTRYはない、という考え方の元でTRYを洗い出す。
つまり、PROBLEM一つ一つに対して、TRYを考えるのだ。

そのときに、PROBLEMから線を引っ張ってTRYを書いていくと、ぱっと見たときに何のためのTRYなのか?ということがわかるだろう。

基本は、PROBLEM => TRYと言う流れだ。
しかし、TRYがPROBLEMのないTRYが出てしまうこともあるだろう。(PROBLEMのときにしっかりと振り返るべきではあるが、、、)
そのときには、TRYは何のためにあるのか?逆算的にPROBLEMを考えてみても良いだろう。

TRYのコミットを全て決める:責任を分配して全員に参加している意識を持たせる。

f:id:sugilog:20091024172633p:image:w400,h300

TRYは書き出したままでは中途半端だ。
だれがそのTRYに対しての責任を持つのか?これを決めなければいけない。

このときのコミットはあくまで、責任をもって完了されることを確認する、ということを意味する。
つまりコミットされた人自身が作業者とならなくても良い。しかし、そのTRYはコミットされた人によって完了確認されなければならない。

書き出すときは、TRYのよこに、(○○)みたいにして、添えておくと良いだろう。
また、やる必要がないTRYを発見したならば、それはやらないことを決めるべきだ。
何から何まで、全てできるわけではない。

できるだけ全員にコミットが行き渡ると良いだろう。参加しているコトへの意識がうまれるからだ。
逆に一人の人に集中してしまうと、完了確認自体が大変になってしまう。

KPTの確認:どんなことを話し合い、TRYにコミットしている人はだれか?

最後のプロセスだ。ここまでKPTをやると、かなり時間が掛かるだろう。
簡単に確認作業をして、KPTを意義のあるものにしよう。

  • KEEPを確認:残したいモノを確認=>名前をつけても面白い。親しみも湧く。
  • P+T+コミットを確認:何のため(PROBLEM)のTRYで、誰がやるのか、をみんなで共有。チケットを発行しても良いだろう。

クロージング:最後のシメは大切に。

リーダーが参加者への感謝と共にシメよう。最後は拍手で!!

まとめ

徒然に書いてきた。流れをまとめよう。

  1. 準備:ホワイトボードの用意、参加者に集まってもらう
  2. テーマの確認:何のための振り返り?を共有
  3. KEEPの洗い出し:残したいモノを書き出す。できたらなぜできたのかも。
  4. PROBLEMの洗い出し:問題点を書き出す。それがあるとどう悪いのか?を意識。
  5. TRYの洗い出し:基本はPROBLEMのないTRYはない。
  6. TRYのコミット:誰がTRYに対して責任をもつのかを確認。全てのTRYを無理に行う必要はない。
  7. KPTの確認:振り返りの作業全体をみんなで確認。
  8. クロージング:最後は感謝と拍手で!!

ここでは触れなかったが、前回のTRYの実施確認を最初にやってもいいだろう。
コミットもだれ?だけでなく、いつまで、ということを決めても良いだろう。

KPTはいい。

KPTは楽しく振り返りの作業をすることのできるフレームワークだ。
アジャイルレトロスペクティブ、ではKPTを含めた振り返り作業がたくさん紹介されていると言うことだが、KPTもアジャイル開発の一つの要素といえるのだろう。

アジャイルは、クリストファーアレグザンダーの考えである、「無名の質」を大事にしている。
それは、そこにいる人の何か良い、という感覚的な気持ちよさを大事にしている、ということだ。

仕事や活動は、気持ちよくできた方がよい。もちろん、それは目的ではない。
しかし気持ちよくできる仕事や活動は、長期的な生産性や効率性という面でも大事だと思っている。
KPTを通して、「無名の質」を育んでほしい。