ふりかえりの呪い - 室長のひとりごち

別にKPTをすると呪われるわけではない。ふりかえり＝KPTになっていることがある種の呪縛なのだ。

ふりかえりをするのは、何かしらの目的があるはずだ。この目的を意識してふりかえりの手法を選択する。

例を挙げると以下のような手法がある。年齢層が高かったり、IOS9001をやっている組織が知っていそうな順に並べてある。

PDCA
なぜなぜ分析
KPT
YWT

PDCAは言わずと知れた手法だ。ISOにはマネジメントシステムとして取り入れられている。plan do check actionのループを続ける。ポイントは、actionからplanへ繋げることころだが、checkで止まってしまうかactionからplanに繋がらないままで放置されるケースが多い。

なぜなぜはトヨタで知られている手法だ。不具合が起きたら、なぜ（起きたか原因を探るために原因を探る質問）を5回繰り返す。このなぜの質問を3回続けると大体のエンジニアは怒り出すか、黙ってしまう。怒り出すエンジニアは、バグが出たら直せば良いと思っている傾向があるので不具合を起こした真因に自力で辿り着くことは出来ない。

KPTはケプトと呼ぶ。けーぴーてぃーではない。大事なのはTのTryだが、もっと大事なことは次に繋げる、ということだ。プロジェクトの完了後にKPTをやっても意味がない。やるなら、プロジェクト期間中に繰り返し行う必要がある。

YWTは、やったこと、わかったこと、次やることで、全体的なトーンとして後ろ向きの言葉を使っていないところが好感が持てるのではないか。

運用する際のポイントは、見える文字にしてから話す、だ。口頭で話し出すとモヤっとし始めて、そのうち一番辛かったことの原因を作ったエンジニアに対する個人攻撃になってしまう。これが気をつけないと自然とそうなってしまう。

慣れの問題もあるので、だから、プロジェクト開始後にルーチンとしてふりかえりを導入することを強く勧める。「金曜16時からはふりかえり」とするのだ。これはアプリ開発に限定しない。インフラのプロジェクトでも、とても効果的だ（実証済み）。

以下、 KPTで検索したら出てきた参考書籍。