個人的KPTアンチパターンのまとめ

おーき

開発チームや社内コミュニティでふりかえりを主催することが多くなってきて、様々なふりかえり手法を試してきました。

・KPT
・YWT
・Fun!Done!Learn!
・Timeline
・ワールドカフェ

※それぞれの手法についての説明などは、先人が詳しく書いてくださっていますから、そちらにお任せしたいと思います。

この中でも僕が最も多く経験してきたKPTについて、実際の経験から学んだアンチパターンを集めてみました。個人的な経験を基にしていますので、

・ゲーム業界（主にコンソール）
・ディレクター、プランナー、プログラマー、デザイナー、サウンド、PMが参加
・KPTの開催目的は「チームの開発プロセスをより良くする」
・1～4週間毎に、定期的に開催

これらを前提にしているところがあります。他のチームではあてはまらないものもあるかもしれませんが、読まれた方の受け取り方にお任せしようと思います。

「問題v.s.私たち」の構図を作れていない

KPTは、ワークの中でProblem（チームにとっての問題）を取り上げるが故にファシリテーションがなかなか難しいものです。この時に大事なのが、「問題v.s.私たち」の構図。

この構図が明確でないと、「これを言ったらあの人は『自分が悪く言われてる』と思うのではないか」という不安が生まれるなど、「人対人の対立とまではいかないまでも、議題に挙げるべき問題が避けられてしまい、本来得られるはずだった学びが失われてしまう」ということが起こりえます。

不安に支配されず、問題を問題と言える組織文化（≒心理的安全性）はそう簡単に根付くものではありませんが、「問題v.s.私たち」であることや、ノーム・カースの最優先条項をKPTを始める前に読み上げるなど、ちょっとした工夫で良くなることもあります。チームに合わせて、試してみると良いでしょう。

Keepが出ない

経験則ですが、Keepの項目が挙がってこないKPTは重苦しくなりがちです。KPTを続けたいという気持ちを阻害する要因になります。

また、開発が長期間に及ぶと「Keepのネタ切れ」状態になることも。でも、過去に出た項目でも構わないと思いますし、過去のKeepがKeepされていることをKeepとする、というやり方もあります。

問題ばかりに目を向けず、自分たちの良いところを見つけていきましょう。

KeepからTryにつなげられていない

「Problemを改善しようとしてTryを考える」というのはとても自然な流れです。この自然さのお陰か、長くKPTを続けているといつしかProblemが話題の中心になっていって、KeepからTryにつなげることを忘れがちです。

そうなるとKeepの形骸化が進んで、Keepが挙げられなくなってしまうことにも繋がります。

このアンチパターンに陥らないための方法を一般化するのは難しいですが、僕はファシリテーターとして「KeepをKeepするためにどんな試みが必要なのか」という視点を忘れないように、と心がけています。

Problemの主語がでかい

開発チームとしてのKPTをやっているのに、Problemに「うちの会社のミッション、おかしくない？」とか、「ゲーム開発っていうのはこうあるべきだ」とか、場に見合わない主語のでかいものが挙げられたら要注意です。

もちろん、意見としては正しいのかもしれませんし、せっかく意見を出してくれたのにその話題に触れないのは悪い気がしてしまうかもしれませんが…KPTの目的が「開発プロセスをよくしていくこと」であり、そこからから逸脱するのであれば、それは別の場で議論すべきです。ファシリテーターとしては、話題が広がりすぎる前にすぐ引き戻したほうが良いでしょう。

Problemの主語が小さい

逆に、主語が小さ過ぎるケースも注意が必要です。プログラマ以外も参加する場なのにコーディング規約の話を持ち出してしまうとか、デザイナしか使っていないペンタブの調子が悪い、とか。もちろん問題ではあるんですが、プログラマの中で閉じる問題ならプログラマの間で問題が起きた時に話し合えばいいし、他の職種でも同様です。

これだけ見ると、「場に適した議題を挙げよう」で終わる話でもあるのですが…なぜ注意が必要なのかというと、このケースはチームがうまくいっていない兆候である場合があるのです。

こうした小さい問題は、本来なら当事者間で十分解決できるものが多いです。それができていないのは、

・「KPTがあるから」と問題を先送りにする考え方が浸透してしまっている
・当事者が行動できない理由がファシリテーターの知らないところに潜んでいる

などのケースも考えられます。こうした状況が続くようなら、1on1などを通じて当事者に直接話を聞くなども視野に入れていくのが良いでしょう。

無理やりKeep/Problemに分類しようとする

「KPTでふりかえろう」と伝えると、人は自然に「Keep」「Problem」に分類できるものを探そうとしてしまうものです。そうすると起きがちなのが、「Problemっていうほどのものでもないんですけれど…」「どこに入れるべきか分からないんですが、とりあえずここに入れちゃいました。」というように、分類できないものを分類しようとしてしまうこと。さらに、分類できないことを理由に意見を出さなくなってしまう場合も。

僕の場合は、そういうものはKPTの枠からは外れた場所（O：思ったこと、とか）を用意しておくことで解消を試みます。とりあえずそこに置いておいて、話し合いの中で掘り下げていくという形。気軽に書ける分、意見出しのハードルも低くなる効果があります。

みんなで掘り下げを手伝ってあげることで、本人もうまく扱えていなかった問題が見えてきたりするようです。掘り下げた後に、必要に応じてTryを出すなどしていけばいいと思います。

Problem/Tryの緊急度や重要度を判断できない

緊急でも重要でもないProblem/Tryに対して、参加者全員の貴重な時間を使うことはやめましょう。僕がチェックしている問いは以下のようなものです。

・それは本当に対処する価値のあるProblemなのか
・Tryによって得られるものは、チームにとって本当に効果があるのか

挙げられた項目全てに真正面から向き合う

これは前の項目と似ていますが、触れておきます。

留意しておかないといけないのは、「自分の意見が読まれない」という事実が、その人の自己効力感が下がる要因にもなりかねないということ。ある程度のバランス感覚が必要ですし、1on1など他のケアが必要になるケースもあるかもしれません。

それでも、KPTの効果を高めるためには、向き合うべき問題に時間を割く、ということが重要だと思います。「パレートの法則」を意識しましょう。

Tryを達成可能なところに落とし込んでいない

チームでTryを決めたは良いものの、「何をすればいいんだっけ？」となるようでは意味がありません。達成可能な（可能ならSMARTな）Tryを意識するのがいいでしょう。

どうしても達成可能なTryをうまく作れない場合は、KPTAによって行動計画まで作るワークにするのも一つの手です。KPTAについては下記スライドがとても分かりやすいので紹介させていただきます。

Tryの進捗がわからない

Tryの進捗が見えないと、なあなあのままになってしまいがちです。さらに「どうせちゃんと達成されないなら、Tryなんて出すだけ無駄じゃないか」と参加者に思われてしまう、という事態もありえます。

タスク化可能なものはバックログに入れたり、そうでないものは定量化したて、定期的に確認します。（定性的なTryの場合は、例えばファイブフィンガーを使って定量化します）

取り組むTryが多すぎる

KPTの中で挙げられるTryには、

・前回のKPTの場で出たが達成できず持ち越しになったTry
・今回新しく出たTry

の２つがあります。KPTを繰り返し開催していくと、前者の繰り越しTryがなかなか消化されず、Tryの数が膨れ上がってしまうことがあります。こうした状況は

・「べき思考」を生みやすい環境になってしまうなど、開発者の精神的な負担が大きくなる
・プロセスのカイゼンばかりに目がいって肝心のプロダクトのカイゼンに割く余裕がなくなる

ということにも繋がりかねません。定期的にTryを棚卸して、チームが一度に取り組むTryの数を適正に保ちましょう。

他のふりかえり手法を検討していない

全てうまくKPTというのはなかなか難しいものです。そういう時、いろいろとやり方を工夫したりするのも大切なのですが…時には、KPTという枠組みから外れて、他のふりかえり手法を検討することも大切です。

KPTが合うチーム、合わないチームがいます。KPTに固執せず、「このチームがふりかえりの後にどうなっていてほしいか」をまず考えて、そこからふりかえり手法を検討していきましょう。

他の手法を探すとき、びばさんのふりかえりチートシートがとても便利で僕も活用させていただいています。参考にどうぞ。

※なお、技術書典7で頒布される「ふりかえり読本 実践編」では最新のふりかえりチートシートがついてくるそうです。要チェック！

おわりに

KPTによるふりかえりの場は、チームの成長のヒントが多く潜んでいると感じます。これには、議論の内容それ自体はもちろん、メタ的に場を俯瞰して見たときの状態も含まれます。

今回アンチパターンにまとめてみたような、場の変化・傾向を素早く察知して、成長のためのアクションを的確に行えることが、ふりかえりのファシリテーターに求められていると考えています。KPTが上手くいかないチームがあるなら、まずは場を俯瞰して見る、ということをやってみるのもいいかもしれませんね。

この記事が気に入ったらサポートをしてみませんか？