「これだけ! KPT」の感想

天野勝さんが出版された本「これだけ! KPT」がとても良かったのでメモ。
ラフなメモ書き。

KPTの基本と、その活用法 from ESM SEC

【1】天野さんの体験談
・チームの分裂を回避するためにKPTを実施
　　KPTを実施してみたら、実はチーム内では対立していなかった

・KPTのデジャブ
　　以前の会社で、完了報告書にベストプラクティスを教訓として残す作業があった
　　　何が嬉しい？
　　繰り返し型開発でKPTを実施したら、自然にプロセス改善された
　　　Keep＝ベストプラクティス、教訓
　　　Problem＝問題
　　　Try＝対応策

【2】KPTの使い方

・学びを整理するKPT
　　教訓を残す

・現状打破のためのKPT
　　行動を促す
　　　より良くするため
　　　問題を取り除くため

・カイゼンのKPT
　　継続的改善のため
　　Problem→Try→Keep
　　　問題解決
　　Try→Keep
　　　新しいことに挑戦する
　　Keep→Try→Keep
　　　良かったことをもっと良くする

【3】PDCAサイクルを回せない管理職が多い

・理由：PDCAを回した経験がない
　　　　プロセス改善の経験がない

→PDCAを回すには練習が必要
　　1週間単位がやりやすい
　　　3か月～1年のサイクルは長すぎる
　　　回すだけでも大変

・理由：有益な情報がないので、Planを立てられない

→CheckとActionから始める
　　PDCAではなく、CAPDにする
　　現状：Keep、Problem
　　課題：Try
　　そこから対応策を計画にする

【4】KPTのやり方

・10分KPT
・30分KPT
・60分KPT
・120分KPT

【5】KPTの注意点

・意見の取捨選択
　影響度 * 発生頻度のマトリクスで、優先順位付けする

・KPTと相性の良いフレームワークがある。
　KPTで問題を深堀するための観点として使う。
　　7つのムダ
　　5S
　　4P
　　3C
　　SWOT

【6】KPTのアンチパターン

・わがままTry
　状況：TryはKeepになるが、Problemが残ったまま

・計画先行
　状況：Tryが多すぎる。KeepやProblemが少ない。前回のTryが評価されていない。

・言ったもの負け
　状況：Tryは少数意見のみ。Tryを言い出せる雰囲気がない。チームの成熟度が低い。

・救われないProblem
　状況：Problemが多すぎ。問題の深堀だけで、行動(Try)につながらない。

【7】KPTの仕組み

・チームの成長プロセスは、タックマンモデルに従う
　　形成→混乱→統一→機能
　　チーム間の対立は、チームが一体化するために必要な作業
　　　雨降って地固まる

Educate.co.jp | タックマンモデル

・KPTと相性の良いテクニック
　ファシリテーション
　見える化
　　タスクボード、バーンダウンチャート
　改善活動

【8】感想

プログラマからリーダーになると、チームとしてのアウトプットが要求される。
リーダー個人の能力が優れていても、チーム全体で進捗が進み、成果物を出せなければ、リーダーとしての管理能力がない。
それは、一つのマネジメントスキル。

いきなり技術者がマネジメント能力を身に着けるのは難しいと思う。
しかし、KPTによるプロセス改善から、チームを回す能力を身に着ける方法は結構有効だと思う。

アジャイル開発やスクラムで言われるサーバントリーダーシップは、リーダーが万能で指示命令型ではなく、メンバーを信頼し、メンバーが最大限の能力を発揮できるように、自律化を促す。
そのためには、メンバーに目標と対応方法とモチベーションを渡すのが必要。
KPTにはそのテクニックが十分に埋め込まれていると思う。

なお、P.169にKPTの指標(KPI、メトリクス)の一覧がある。これはすごく便利そう！
ぜひ使ってみたい。