KPTは「チームの力で問題を見つけるふるまい」の養成ギブスです。 ふるまいに慣ていない間は違和感があります。
たとえば次のような問題が起きます。
トライ狙いすぎ問題
KPTの「改善活動」の面に強く期待しすぎて生じる問題です。 無意識に、KPTの成功指標を「TRYの数」にします。
TRYを出すことに意識をとらわれると、慣れている「個人で問題を見つけて解決する」方法を取ることがあります。一つのKPTの場に集まって、参加者がそれぞれ別々に問題を発見して解決します*1。
すると、途中のプロセスが無駄に見えると思います。特にKeepに意味を感じないのではないでしょうか？アイスブレイクの一緒だと思ってはいませんか？たとえばKPTの参加者にKeepを出していない人が居ても問題ないと思っていませんか？あるいは、時間短縮のため事前にKeepやProblemを用意していませんか？
KPTをK→P→Tの順に進めることには意味があります。この意味を知るためにKPTを逆順に見て行きましょう。
良いTRYには良いProblemが必要
良いProblemが出せれば、TRYは自然に出ます。問題解決の第一歩は問題発見です。 TRYが出ない、あるいは何度かKPTをやると出なくなってくるのは、良くないProblemを並べているからです。 良くないProblemとはどんなProblemでしょうか？
解決方法がわかっているProblemは良くない
解決方法がわかっているProblemは良くないProblemです。 たとえば「自動テストが導入されていない」は良くないProblemです。
良くないというのは「正しく認識できていない」という意味です。 本当に「自動テストが導入されていない」がProblemならば、導入するというTRYになるはずです。というか、KPTをするまでもなく、業務上のタスクとして導入しているはずです。 導入していないなら、何か理由があるはずです。 それがProblemです。
て、いうと「チームメンバーが・・・」とか「うちの会社では・・・」とか言い出すんですけど、そうじゃないです。 もうこの時点で、良いProblemじゃないんです*2。 これをどんなに掘っても問題は見つかりません。TRYは生まれません。
「解決方法がわかっているProblem」から問題が発見されることはありません。 Keepからやり直しましょう。
KPTでは「チームの力で問題を発見したい」です。 解決方法がわからないProblemの方が良いProblemです。
全員が知っているProblemは良くない
全員が知っているProblemは良くないProblemです。
全員が知っているのに解決していない問題は、重要でない問題です。 例えば「社内システムがSSOに対応していないので、ログインに手間が掛かる」みたいなのは大抵チームで取り組む価値がない重要でない問題です*3。
KPTでは「チームの力で問題を発見したい」です。 全員が知らない、一部のメンバーが気がついてるProblemの方が良いProblemです。 もし、１人しか気がついていないとしたら、とても良いProblemです。
良いProblemを出すのは難しい
良いProblemを出すのは難しいです。
解決方法がわからないProblemの場合
「解決方法がわからないProblem」を挙げると、リーダーの機嫌が悪くなることがあります。 リーダーが「チームの問題はリーダーが解決するもの」と、思い込んでいるためです。 責任感の強いリーダーほど、この傾向が強いです。 「問題を抱えているチームのリーダーは無能である」とか「自分のチーム運営に、チームメンバーが不満を感じている」などと思っているはずです。
リーダーの機嫌が悪くなると、メンバーは空気を読みます。「解決方法がわかっているProblem」を挙げるようになります。 あるいは、一見解決できなさそうなProblemを挙げておいて、「実はこういう手段があるんですよ・・・」と、リーダーの機嫌を使って自分の提案が通るように、チームを誘導します。
リーダーがポーカーフェイスをすればいいのか？というと、そうでもありません。 ポーカーフェイスは完璧ではありません。ポーカーフェイスから漏れる感情を読み取る人間が偉くなります。 KPT外の場でリーダーの気にしてる問題を知ろうとしてくるかもしれません。忖度ですね。
簡単な解決方法は、KPTに参加している全員がKeepを挙げることです。詳しくは後述します。
一部のメンバーだけが気がついているProblemの場合
自分しか気がついていないProblemを挙げるのは意外と難しいです。 Problemに気がついたとして、それがチームのProblemなのかわかりません。
もしも自分しか気がついていないProblemだった場合、説明が大変です。 がんばって自分なり説明した結果、上手く伝わらなかったら、 明後日のことを言う変な人になってしまうかもしれません。 恥ずかしくないですか？
こういうとき、人間の脳はいくらでも言い訳が思いつきます。
- みんなが知っていて当然で、自分だけが知らない情報があるだけ、後になればわかる
- 気のせい、見間違い
- 極レアケースで滅多に問題にならない
どんだけ言い訳を並べても、本当にProblemである可能性はなくなりません。 チームのProblemか確かめるには、KPTの場でProblemとして挙げてみるしかありません。
簡単な解決方法は、KPTに参加している全員がKeepを挙げることです。
良いProblem出すには全員がKeepを挙げる必要がある
KPTを良くするための簡単な方法があります。 「全員がKeepを挙げる」です。
仕事に取り組んでいるときの緊張した心理状態では、大抵のProblemが深刻な問題に見えます。 そのため、解決できそうにないProblemを出すこと出されることに、大きな抵抗を感じます。
悪いことを言う前に、良いことを言うと、この抵抗感が消滅します。 なぜか全然わからないんですが、経験則的にマジです*4。 同時に「明後日のことを言ってしまうかも」問題も深刻でないものにしてくれます。 「解決方法がわからないProblem」「一部のメンバーだけが気がついているProblem」どちらを挙げる場合にも効果的な魔法です。
私は、Keepは挙げることが重要で、Keepの内容はあまり重要でないと思っています。 どんな内容でも良いことを口にするだけで、なぜか問題を深刻に感じなくなる効果があります。
例えば、つぎのものでも大丈夫です。
- 天気が良い
- 給与が振り込まれた
- おいしいご飯屋さんをみつけた
- 楽しみしているゲームが発売された
自分がやった結果でなくても良いです。 チームで取り組んでいる内容でなくても良いです。 単にKPTの場で、脳が「現状は最悪ではない」と認識すれば十分です。
何よりも大事なのは、KPTに参加している全員がKeepを挙げることです。 誰か一人でも最悪の気分の人がいると「解決方法がわからないProblem」を挙げられなくなります。 その人は「自分だけが気がついているProblem」を挙げてくれないでしょう。
Keepが挙げにくい状況
Keepが挙げにくい状況があります。 例えば、次のような場合です。
- KPTに、チーム外の偉い人が参加する
- 事前にKeepを考えてくる
こういうとき人間は、かっこいいKeepを挙げたくなります。 「チームで取り組んでいる素晴らしい施策」を挙げたくなります。 こういうKeepの候補は少ないです。 また、前の人が出したKeepと同じでは格好がつきません。 そして、先に格好いいKeepを思いついた人だけがKeepを挙げ、残りの人は「Keepはありません」になります。
また、こういう格好いいKeepを挙げるKPTでは、KPTに急に参加した偉い人は格好いいKeepを挙げられないので「チームの普段の細かい取り組みはよくわからないから」とKeepを挙げるのをサボります。
これはとても良くないです。 偉い人が「現状は最悪ではない」モードでない場で、問題は発見されません。 時間の無駄です*5。
Keepが効かない状況
- 事前にProblemを考えてくる
Problemを考えているとき、参加者全員が「現状は最悪ではない」モードに入っているかわかりません。 事前にProblemを考えてしまうと、良いProblemは出てきません。
ただし、KPT以外の時間でProblemを考えることには意味はあります。 考えたProblemはKPTを待たずにチームに共有しましょう。 KPTの開催日を待つ意味がありません。 共有が遅くなると、チームは損をします。
もし、KPT以外にProblemをチーム内で相談する場がないとしたら、それはそれで別の問題です。 KPTに大きすぎる役割を与えているように思えます。
まとめ
KPTでは「チームの力で問題を発見したい」です。 「良いProblemを挙げられる場を作れるか」の勝負です。 「こんなこと言っても良いのかな？」というProblemが挙げられる会になったら成功です。 良いProblemさえ挙げられればTRYは自然に出てきます。
そのために
- 全員がKeepを挙げる
- Keepの内容はくだらないことほど良い。特に偉い人ほど
*1:KPTがチームとしてのふるまいを学習する場ではなくなっています。業務と別にサブプロジェクトがあって、KPTがその進捗会議になっているイメージです。
*2:もっというと、これはたぶんKPTを使って「自動テストの導入」に誘導しようとしています。個人の問題を他のメンバーに押しつけているだけで、チームで解決するムーブになっていません。「自動テストは我々の開発の役に立つだろうか？」という問いをすっ飛ばして、個人の意見をいきなり結論として押しつけています。
*3:社内システムを改善するチームだとしたら、重要な問題です。が、その場合はKPTで扱うような問題ではなく。業務上のタスクになっているはずです。
*4:アンカリングの一種なんですかね？理由を知っている人がいたら教えてください。
