DoorKeeper
https://changeit.doorkeeper.jp/events/43036
場所は神田の永和システムマネジメントさんです。
参加者は30人くらいでしょうか。お馴染みの顔もちらほらと。
ちょうど今週、スクラムマスターとしてプロジェクトに参加する話があって、復習にちょうど良い機会ということで参加しました。
以前、天野さんのKPTの話は横浜道場で聞いたことがありました↓
『横浜道場 特別編 「見せて貰おうか、KPTの性能とやらを・・・。」～KPTの基本と、その活用法～』に参加しました
http://makopi23.blog.fc2.com/blog-entry-117.html
もう２年半くらい前になるんですね～。読み返して、よい復習になりました～
あ、まだ本買ってない・・・・
↓はよく参考にさせてもらってます。
プロジェクトファシリテーション 実践編 ふりかえりガイド
http://objectclub.jp/download/files/pf/RetrospectiveMeetingGuide.pdf
以下、自分の復習のためのメモ。
講演
ふりかえりをステップアップ from ESM SEC
この日の講演資料は公開するご予定はないとのことですが、↑とほぼ同じとのことでした。
KPTA.club
「テーマ」欄
- みんなで、こーゆう方向だよね、とか話したほうがやりやすいので、KPTに「テーマ」欄を追加することが多い。
- 改善活動の一貫でKPTをやる人は、「テーマ」欄を追加している人がおおい。
- KPTが形骸化する場合は、Keepに着目して、もっと良くするにはどうすればいいか、という観点で考えてみるのも良い。
KPTの基本ステップ
- K/P/Tの枠の繋がりに、意見を導き出す仕掛けがはいっている。
(1) Keep
- ここから上げる。続けたいこと、良いこと。
(2) Problem
- Keepの後にProblemを出していくが、これはネガティブなイメージになりがち。
- なので、ProblemよりKeepから書いた方がいいかも。
- いきなり、「問題ない？」と聞くと引かれちゃう。アイスブレークも兼ねてProbolemよりKeepから先に考えるのお勧め。
(3) Try
- 「Keepに対して、それをより良くするTry」より「Problemを改善するTry」のほうが多い。
- なので、Problemから先に書くとTryが出やすい。人間は、意見が出ると安心する。
- ProblemからTryへの意見は出やすいので、そこで時間を使い過ぎがちになる。
- 元々、KeepからTryへの意見は出にくいため、ProblemからTryの方で時間を使い過ぎると、考える時間が無くなる。
- なので、Keep → Tryを先にやった後、Problem → Tryの順に実施するよう、KPT本を変更した。
- たくさんアイデアを出しておいて、そこから選ぶ。
- 対策を出した人が自分でやれ、となると、Try出しを言い澱んでしまう。
- なので、とりえあずTryを出す。その後、試すことを選ぶ。
- やってみたあとに見直すことも大事。
- Tryでうまくいったことが次のKeepになる。
ふりかえり
- 過去の学びを、未来に活かす行為のこと。
- 「振り返り」と漢字で書くと堅苦しいし、後ろ向きなイメージがするので、「ふりかえり」とひらがなで表現してる。
- そういうイメージ大事。
ふりかえり会
- やるきっかけを作るために、定期的にやる。
- チームでやると時間制約とかあるので、毎週水曜にやる、とか定期的にやる。
- プロジェクトが終わってから、ではなく、週１とかでやると良い。
- 深く話たい場合は、臨時でプロジェクトの中でやったりする。
- 時間を開けすぎると、思い出すだけで大変なので、定期的にやる。
ふりかえり会のタイムテーブル
- 「じっくりバージョン」は、６人くらいでやるとこのくらいかな。
- 「ざっくりバージョン」はKeep, Problem, Tryを同時に出す。
- チームの習熟度に応じてタイムテーブルを使い分ける。
演習
「自己紹介」をふりかえりのテーマに、机ごとにKPTAをやってみました。
１人が自己紹介をして、残りの人がその人に対するKPTを付箋に書いて、その人のKPTの各欄に貼ります。
それを順に繰り返して、全員が終わったらふりかえり、Tryを意識して再度１周やる、といった感じです。
実際やってみて、いろんな気付きが得られました。
そういや先日の"第3回CodeIQ感謝祭「春のエンジニアまつり」 "で、澤円さんが言ってましたね。
「プレゼンを上達させるには、自分のプレゼンを録画してもらって見てみるのが良い」と。
自己紹介も同じこと言えるんじゃないでしょか。
質疑応答／コメントその他
- 時間を考慮して、深掘りの優先順位やどこまで掘り下げるかを決める。
- グラウンドルールを決める。
- ファシリテーター役でも自分で深掘りをリードしてみみて、やりすぎたと思ったら、「俺、やりすぎた？」とメンバーに聞いてみればいいんじゃないか。
- Problemを頻度と影響度で分類してみる。
- チームがKPTに習熟してくると、難しい問題ばかりProblemに残って、KPTに時間がかかりすぎる。
- その場合は別で関係者が集まって議論する場を設けるのが良いのでは。
- KPTで意見が出ない場合は、「１人最低３０個上げてみて」と言って、しょぼい案でも出しやすくする雰囲気にすると良い。
感想
良い復習になりました。過去のKPTのブログとか読み返したりとかも。
KPTはシンプルで良いですね。
天野さん、関係者の方々、ありがとーございました。
- 関連記事
-
- 「要求の変化とマイクロサービスアーキテクチャ」に参加しました
- 「最強のカイゼンフレームワーク "KPT" by KPTの神 天野勝による」に参加しました
- 第3回CodeIQ感謝祭「春のエンジニアまつり」 に参加しました
