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

エンジニア的なネタを毎週書くブログ

東京でWebサービスの開発をしています 【英語版やってみました】http://taichiw-e.hatenablog.com/

チームのKPTをちょっとだけ深堀すること

ふりかえりの手法としてKPTはメジャーな方法の一つだと思います。

私がチームでふりかえりする際に、ファシリテータとして少しだけ気を使っている事があります。

KやPは少しだけ掘り下げる

メンバーに意見を挙げてもらうときに、「うすい」意見が出ることが、どうしてもあります。

  • XXが予定通りリースできてよかった
  • YYが難しかった

これだとあまり話が広がらないため、このような意見が出たときは、出してくれた人に問いかけるようにしています。

 

「予定通りリリース亅なら、

「それができた要因ってなんですか?」「どんなところを頑張りました?」

 

「難しい」なら、「どうしてそう感じました?」「何が難しさの原因でした? スキル不足か、知識不足か、周りのせいか…」

 

と、単なる事象の共有だけでなく、その背景にある理由を挙げてもらえるようにします。

挙げてもらったものが、またまた単なる事象の共有の場合もありますので、その際はさらに「その原因は?」ときくようにしています。(いわゆる『ツメている』状況にならない程度に。ここの見極めが難しい)

 

KとPはスコープを広めに

毎回ではないのですがKPTを始める際の枕詞がありまして、

「このスプリントで良かった(or あんまり良くなかった)ことを挙げてください。『自分のこと、チームのこと、プロダクトのこと、環境のこと、何でもいいです』」と言っています。

特に、最後の環境の要因で問題が発生している場合を個人的には重視しています。当人はどうにもならないと思っていても、意外と他の人が聞いたらどうにかなるケースもあり、とりあえず挙げてもらうことが大事だと思っています。

例えば、

PCのスペックが低すぎるとその人は感じているけど変えられないと思っていた。→実は申請すればもっとハイスペックなマシンが使える

的な。

(どうにもならないことも多いので、その際は共感だけして終了です… が、その思いをみんなで共有できる事にも意義はあると思います。)

 

Pを挙げるときにTを考えない

Pを考える際、いきなり解決方法を出してしまうケース多いですよね。

「三回遅刻しました。次から目覚し時計を増やします。」

それで解決できるならいいのですが、何か問題が発生している場合、本人が思いついたTryでは解決できないので問題になっているケースが多いのではないでしょうか。

まず、「遅刻した」と言うのはただの事象なので、先程挙げたとおり、根本的な理由を見つけたいところです。

  • 本人が単に夜更かしして遊んでいたのか
  • 仕事量が多すぎて毎日帰宅が遅いのか
  • 何か心配事があってよく眠れていないのか
  • そもそも遅刻って問題なの?うちフレックス制じゃなかったっけ?

いきなりTryに行ってしまうと、このようにProblemを掘り下げることが難しくなります。

そのため、KやPとを考える時間と、Tを考える時間は分けたほうがいいと思います。