この記事はリクルートライフスタイル Advent Calendar 2016の20日目の記事です。
グルメ開発チームでAP基盤・KAIZEN推進をやっている齋藤です。
今回は改善のためのフレームワークである「KPT」の、ベタープラクティスについてまとめてみたいと思います。
ちなみに敢えて「ベストプラクティス」ではなく「ベタープラクティス」としているのは
以前一緒に仕事していた人が「まだまだ改善の余地があるからベストじゃなくてベター」という趣旨の話をしていて
それに大いに共感して以来、この表現を勝手に使わせていただいています。
KPT(Keep/Proglem/Try)のキモ
自分がKPTのファシリテートをする場合の重要ポイントが3つあります。
- 期待値調整
- Tryの方向性を狭めない
- とにかく意見を出しやすい雰囲気を作る
の3つです。
それぞれちょっと深掘りしてみたいと思います。
期待値調整
「KPTを始めよう」となった時、何を期待しますか？
当然今よりもっといい状態に改善されていって、目に見えた成果が出ることが期待されますよね。
ただ冷静に考えた時に、そんな簡単に何かが変わるわけはないですよね。
「銀の弾丸はない」という言葉ももはや今更改めて言う必要が無いほどに当たり前の言葉になってます。
KPTを始めても何も変わらないです。
改善の意識がチーム内に根付くまでは、無駄に時間を消費しているようにすら感じることもあると思います。
増えないKeep、一向に解決されないProblem、出すだけ出して実行に移されないTry…
でも改善ってそういうものです。日々の積み重ねです。
体重を測るだけじゃ痩せないけれど、まずは測らないことにはどれくらい頑張らなくてはいけないのか分からないように、
どんな問題点を抱えているのかが見えるようになること、
今のやり方のままでは新しい取り組みをやるような余裕すらないこと、
試したことの方向性がイマイチフィットしないこと、
それが分かることがまずは最初の一歩となり、それを積み重ねることで少しずつ変化が出てくるものです。
ただし目に見えた成果が出ないものを続けるのは、誰にとってもキツイものです。
なので一番最初に期待値をちゃんと調整しておくことを忘れない。
思ったように改善が進まないからと言って、チームやメンバーを責めても何も得しないです。
まずは自分たちが今どういう状態なのかを知る。
これが最初のTryでちょうどいいと思います。
Tryの方向性を狭めない
「トライしよう！」と言われると、なんとなく新しいことをやらなくてはいけないような気になりませんか？
英語から日本語に脳内変換する際にそういうフィルタが掛かってしまうのかもしれませんが
本質的にはTryとはあくまで「何かを試すこと」です。
何かを試そうと思った時、それは必ずしも「何かをやる」で無くてもいいはずです。
今やっている何かを「やらない」というのも新たな試みです。
往々にして、そもそも新しいことをやってる余裕なんてないチームのほうが圧倒的に多いはずです。
そこに何かを足すなんて全く現実味がない。
まずはいらないもの削るところから始めてみて、それで生まれた時間を使って
新しい要素を足していけばいいと思います。
とにかく意見を出しやすい雰囲気を作る
KPTとは、過去の失敗を嘆くのではなく、未来の話をするポジティブな場であった方がいいです。
改善って過去を否定するためのものではなくて、今よりもっといい未来があると信じるからこそやるものですよね。
なのでその場の空気も基本的にはポジティブなものであったほうがいいです。
いくつか私がやった雰囲気作りのための試みをご紹介です。
- みんなで食べるためのお菓子を用意しておく
- お茶会のような気持ちで気軽にトークを出来るように
- 部屋の電気はとにかく消さない
- PCの投影には注意！暗い部屋で明るい気分を持つのは難しい
- Keepをとにかく出す。「思いつかない」はナシ
- ポジティブなことを先に共有して、雰囲気を和らげるため
- ハードルを下げるために「続けたいこと」ではなく「良かったこと」のGoodという枠を設ける
- 付箋を貼るときは一箇所に集まる
- 少人数（3～4人）のときは、いっそ壁に貼らずテーブルの上でやったり
- ある程度人数がいたら壁の前に集まってワイワイやるのが理想
- リーダー的立ち位置の人は腕組まない。威圧感を出さない
- 個人的なKeep, Problem, Tryも許容する
- 「チームとして」という括りをつけると意見が出にくくなる
- この辺はメンバーの経験値次第なところにも左右される
改めて書いてみると、そんなに特別なことはやってはいないですが
（お菓子とかはモロにアジャイルサムライで紹介されてますしね…）
どれも効果はあったな、と思います。
その他の心がけ
他にも意識しておくと円滑にすすめることが出来る要素がいっぱいあります。
例としていくつか上げてみます。
タイムキーパーは必ず置く
ホットなProblemがあると時間が長引きがちです。
Tryに行く前に時間が終わってしまった…！とならないよう、時間管理はきちんとしましょう。
あまりに長引きそうならKPTの中ではなくて、専用の枠を取るべきだと思います。
むやみに前回の内容を引き継がない
時間が解決してくれること、時間とともにマッチしなくなること、当然あります。
「前回のProblem」が今も問題かどうか、語る時間は勿体無いです。
本当に問題なのであれば、今回もまたProblemとして上がってくるはず。
前回考えた未着手のTryが、今もまだ有効な手立てなのかは改めて考えないとわからないはず。
改めて考える時間があるなら、その分今を語る方に時間もパワーも回したほうがプラスです！
Tryを実行した結果の共有くらいはあってもいいかもしれませんね。
ブレストの基本には従う
KPTだなんだと言っても要はブレストです。
- 他人の意見を否定しない
- 質より量
- 実現可否は一旦無視
- 便乗もOK
この辺はKPTだからといって変えることもなく、当たり前のようにやったほうがいいです。
KとPとT、三位一体。仲間はずれにしないこと
ProblemとTryだけ、とかだとただ苦しい時間が続くことになりますし、雰囲気も重いです。
そんな状態ではいいアイディアも出てこなくなります。
逆にKeepとProblemだけになってしまい、Try話す時間がなくなってしまうと
これの目的は何だったっけ…？ということになりがちです。
KとPとT、優劣はないです。
どれもきちんと消化するように心がけると良いと思います。
Tryを考える時にむやみにProblemに紐付けようとしない
Problemに対してTryを出す、ということをよくやりがちですが
必ずしも効果的でない可能性があります。
Problemが本当に細かい原因まで分解できている場合は効果的ですが
大体がそこまでブレイクダウン出来ているわけではないと思います。
根本原因が曖昧なままで直接的にTryを考えると
部分最適化になってトータルでの改善に繋がらなかったり、
最終的に「ちゃんとやろう」みたいなよく分からない試みをすることになりがちです。
もちろんProblemごとに考えることが全て悪というわけではなく、
それに限定せず幅広く考えたほうが、多角的に見ることが出来て良いだろうというものです。
思考停止はよくないということですね。
定期的に開催する
長期のプロジェクトが終わったら1回！みたいなやり方だと
大体そのあとチーム再編成とかが起こったりするので、チームとしてのTryをやる時間がありません。
また、数ヶ月分を振り返ると、それはそれは膨大な意見がでてくることになります。
基本的には1週間～2週間ごとに開催するようにしましょう。
1週間だと何も変わっていない、ということが起こりやすくなり、
2週間ごとだと1週目に起こった出来事が忘れられがちなので、
このあたりはチーム状況を見て判断するのがベターです。
定期的にやることで、改善するということが日常になります。
特別なイベントにしないことが改善の第一歩です。
応用編
KPTという考え方は、とてもシンプルなのでいくらでも応用ができます。
個人の1日の振り返りや週次の振り返りに使ってもいいでしょう。
基本的なやり方は何ら変わりないです。
ただどうしても個人でやるとただの反省会になってしまいがちです。
チームでやる時以上に「よかった探し」を意識するといいと思います。
また、自分なりに出してみたKPTの結果を第3者に見てもらって
客観的な意見をもらったりするのも効果的です。
最後に
今が理想的な状況でないのであれば、どこかに改善の余地はあるはず。
その方法の1つとしてのKPT、これももちろん常に正解や理想形が明確にあるわけではなく
TPOによっても何が効果的か変わりますし、当然改善の余地は常にあります。
いろいろと書きましたが、要は1～2週に1回くらい
みんなでワイワイと自分たちを客観視する時間を取ったっていいじゃないか、と。
チームの状況を今より良くするためのものなので、やり方に正解はないです。
振り返りという観点からしたら、別にKPTである必要すらありません。
ただ、ちょっとした心がけでいい雰囲気は作れる、ということもまた然りだと思います。
主にKPTがうまく行かない…という方の参考になれば幸いです！
技術的な話からはちょっと外れてしまいましたが
ここまでが結構技術に振り切った感じで来ていたので、ここらで箸休めということで笑