プログラマの思索

XP祭り関西2014で「KPTによるプロセス改善～あなたはPDCAを回したことがありますか？」を講演する予定ですが、一部の資料が余ってしまったので、プレ資料として公開します。

【参考】
XP祭り関西2014 ~やってみよう！XP~ - 日本XPユーザーグループ関西 | Doorkeeper

XP祭り関西2014 - XPJUG関西wiki

XPやScrumなどのアジャイル開発をやった経験がある人なら、KPTと言えばすぐに分かるだろう。
そして、ふりかえりも実際に経験したこともあるだろう。

僕も、プロジェクトファシリテーションの流れから、KPTとふりかえりを実際に試してみた経験がある。
その経験から、PDCAサイクルとはこういうプロセスなのだな、という感覚がつかめたように思う。

そして、周囲のプロジェクトリーダーや部課長などを見ていると、この人はPDCAサイクルを回した経験が無いんだな、と思う時もあった。
そんな人は、チームを動かしたり、もっと大きな組織を動かしたという経験がないのだろうな、と思う。

作業を指示したからといって、人は動くわけではない。
エンジニアのように、技術の専門家に対して、部課長が上から指示を出して、それでシステムが完成するわけではない。

また、そんな人に限って、計画をきちんと作ったとしても、その計画を現場に当てはめて、微調整しながらコントロールしたことがない。
無理やり、チームや組織に当てはめようとするから、現場の人はサボタージュしたり、服従背面の行動をとったりする。

そんな現場では、いわゆる継続的な改善というプロセスが存在しない。
だから、いつまで経っても、チームも組織も成長しない。
同じような失敗を何度も繰り返す。

「これだけ! KPT」にも書かれているが、PDCAサイクルを回すのは至難の業だ。
1ヶ月や3ヶ月という長いスパンでPDCAサイクルを回すのは、たとえ少人数のチームでも、結構難しい。
PDCAサイクルを回した経験がないプロジェクトリーダーや課長が上に立っていたら、もっと最悪だ。
毎日がデスマーチ。

KPTの良さは、PDCAサイクルを自然に回す仕組みが整っていること。
プログラマ上がりで、マネジメントの経験が短い人でも、KPTでチームを回すことは可能だし、簡単にできるのがいい。

但し、KPTには結構コツがある。
そのコツをKPTのアンチパターンとしてまとめみた。

詳細を聞きたい場合、XP祭り関西2014 - XPJUG関西wikiにぜひ聞きに来てくだい。