【初級編】振り返り（KPT）での改善がなかなか進まない人への処方箋
アジャイルだろうとウォーターフォールだろうと
システム開発においては定期的な振り返り改善のサイクルを回すというのが
常套手段になりつつある（と信じてる）今日この頃。
＃ここでは振り返りとしてKPTをメインで考える
- Keepがなかなか出てこない
- 逆にProblemがやたら出る
- Try出すものの、どれをやるか決めてる時間がない
- どのTryをやるか決まっても、実際はタスクに追われて時間がない
- 結果問題点ばかりが出てきて改善が進まない
みたいな問題はきっとどこにでも出てくるはず。
こういった問題に対してどう対処していくべきか？
自分なりの考えをまとめておく。
Keepが出ない・Problemが出すぎる問題
「継続した方がいいこと」という考え方だと
「そもそも新たに取り組んだTryがないとKeepも出てこない」
ということで、TryができていないとKeepが出にくくなったりする。
Keepを最初に語る理由の1つに
「まずは良かったことを語ることで雰囲気をよくする」
というものがある。
なのでまずは「継続」という観点を外し、
「良かったこと」をあげるというのが一つの案にはなると思う。
KeepにプラスしてGoodやLikeをあげる方式。
最後まとめる時に「継続するもの」はそこからピックアップすればいい。
Keepがたくさん出て来れば、相対的にProblemの多さは気にならないのでは。
そもそもProblemが出てくるというのはいいことだと思う。
改善の第一歩は、自分たちの現状に課題があるということを認識することなので
そこに課題感がなければ始まらない。
どのTryをやるか決まらない
どのTryをやるか決まらない、というよりは
「これはみんなが意識しよう」
みたいなTryばかりになって、最終的に見てみると
「全部やる」
ということになっていたりする。
こうなってしまうとただスローガンを掲げただけになってしまい
全く進まないということになってしまう。
改善は1日にしてならず。
どれもやろうと欲張るのはうまくいかない可能性が高い。
1つ1つは割とすぐにやれることだとしても
それが積み重なるとそう簡単な話ではない。
すぐやれることだとしても1〜2個に絞るのがベターだと思う。
また、「みんなで意識しよう」系のTryだとしても
必ず推進担当を立てること。
意識できていなそうな時に注意喚起をする役割がいないと
ほぼ間違いなく、と言っていいほど形骸化してしまう。
まとめると
- 「やるTry」の上限数を決めてしまう
- 推進担当を必ず立てる。「みんなでやる」は悪手
の2点がポイントになる。
Tryをやる時間がない
Keepで雰囲気がよくなり、Problemで自分たちの活動を見つめ直して
実施するTryも決まり、さぁ改善だ！
となっても結局日々のタスクに追われてしまい
Tryが一向に進んでいかない、というのはとてもよくある話だと思う。
ここに対する打ち手はそんなに多くはない。
至ってシンプルなものにはなってしまうが
- 「何かをやる」Try ではなく、「何かをやめる」Tryを優先的に採用する
- 日々のタスクの中にTryも明確に入れてしまう
→チケットやカンバンに入れてしまえばそれもタスクの1つに - 20%ルール的なものを導入して改善活動の時間にあてる
くらいしか今のところ思いついていない。
1つ目の施策が一番効果的だとは思っていて、
基本的に納期に追われるエンジニアには時間がない。
なので時間を作ることが大事になる。
自分たちのプロセスを見える化して、やらなくてもいいことを見つけてみたり
打ち合わせを減らしてみたり、掛け持ちをやめて1つの作業に専念できるようにしたり。
まずはとにかくメンバーの負担を減らす。
ただしいくら負担を減らしても、パーキンソンの法則とかもあるように
結局空いた時間目一杯までタスクが膨らむ、とかが起こる。
なので余裕をもたせた上で、その余裕が埋め尽くされる前に
奪ってしまうのがいいと思う。
貯金と同じで「残った分を貯金」では貯まらない。
使ってしまう前にとっておく。それが20％ルール的な考え方になる。
おわりに
さもこれでうまく行っているかのように書いてしまったが
今自分はちょうどチーム開発からはちょっと離れてしまっているので
実際にこれが実践できているわけではない。
ただ、いろいろとこの手の相談を受けることは多くて
その時に言ってることを改めて形にしてみた。
改善習慣をチームに根付かせるためには、
意志を持って推進する人が必ず必要になるので、
まずはそこが第一歩なのではないかと思う。
