見出し画像

ふりかえりアンチパターン「とりあえずKPT」

dora_e_m


ふりかえりを知るものでKPTを知らぬものはない

ふりかえりの代表的なプラクティスは?と問えば、多くの人が「KPT」と答えるのではないでしょうか。「プロジェクトファシリテーション実践編ふりかえりガイド」でも代表的なフレームワークとして紹介されてますし、私がふりかえりという概念に初めて触れた10年前は「ふりかえり＝KPT」くらいの印象を持っていました。

KPTとは、ふりかえりに適した思考フレームワークです。改善したい対象に対して、Keep(続けること)、Problem(不満点)、Try(試すこと)と順に考えを進めることで、改善のループを実現します。ふりかえり会を行なう場合に最もよく用いられるフレームワークです。

プロジェクトファシリテーション 実践編 ふりかえりガイド
http://objectclub.jp/download/files/pf/RetrospectiveMeetingGuide.pdf

近年では「ふりかえりガイドブック」などKPT以外のプラクティスに触れられる良書も多く、以前ほど「ふりかえり＝KPT」という印象はありませんが、それでも現場でKPTを実施しているというところは多いのではないでしょうか。

それだけ普及しているKPT、普及しているだけあって扱いやすく効果を生みやすい手法ではあるのですが、一方でアンチパターンに陥りやすい側面もあります。本稿ではその点にふれ、うまくKPTを使えるシーン、アンチパターンに陥らないための処方箋について考察します。

ふりかえり=KPTなチーム

Cheers!!

ふりかえりファシリテーションの依頼

ふりかえりについての相談を受けることが多々あります。つい先日も、普段からふりかえりをやっているというチームからファシリテーション依頼があり参加してきました。自分たちではうまくいっているという手応えはあるものの、客観的にみてどうなのか知りたい。また、メンバー全員が当事者としてふりかえりに参加したい。という二つの狙いがあったようです。

そのチームは少人数、メンバー間の関係は良好。ふりかえりはコンスタントに開催している。手法は毎回、KPTを使っているということでした。ファシリテーションを任せるとのことだったので他の手法の採用も考えたのですが、毎回使っている手法でどのようにふりかえりを行っているかを観察することでチームとしての改善点が明らかになるだろうという予測から、KPTで実施することにしました。

堅実でKPTに習熟したチーム

すげーちゃんとしてる

ファシリテーションをし始めて感じたのが、そのチームがとても「しっかりしている」ということでした。ファシリテーターが「Keepを出してください」といえばKeepが、「Problemを出してください」といえばProblemがたくさん出てくる。タイムボックスもきっちり守るし、どのメンバーも積極的に発言している。また、KPTでKeepやProblemを出す前にタイムラインをつかってふりかえり対象期間にあったことを思い出す時間を明示的に設けている。わざわざ僕たちにファシリテーション頼まなくてもいいんじゃない?という練度でした。

が、よく観察してみると気になることがいくつかありました。

  • タイムラインの時点で、事実だけ洗い出すのではなく事実に対しての評価が混在して洗い出されていた

  • Keepは続けるべきものとして、Problemは改善するべきものとして扱われている

    • なぜそれがKeepなのか、そのKeepが生まれたのは何故か。Problemの背景にあるのはなにか。そういった深堀りがない状態でTryを考えてしまう

例えば、「会議が多く開発時間がとれない日がある」というProblemに対し、即座に「会議を他の日にも分散させる」というTryが出ていました。なぜ会議が多いのか?開発時間がとれない日が予測可能な状態で出現しているのは問題なのか?そういった視点に立つことなく表面の課題を解決する方法を模索している点は課題だと感じました。

上記の問題についてはファシリテーション時に問いを投げかけることで背後にある課題を深堀りすることができました。ですが、上記問い以外でもおおむね「出ている課題を直接的に解決するTry」が出る傾向にありました。どうしてこういった傾向が生まれるのか、考察してみました。

KPTがアンチパターンとなるとき

Keep, Problem, Tryというアンカリング

けっこういい感じのチームなのに、なんで課題の深堀りができないんだろうというのを疑問に感じていました。ですが、真剣にフレームワークと向き合う生真面目なチームが「KPT」と向き合ったとき、Keep, Problem, Try「しか」話してはいけない、と思ってしまうのは無理からぬことなのかもしれません。Keepを共有したら、次はProblem。それが終わったらTry。そういうプロセスを遵守しすぎるがあまり、「え、なんでそれがProblemなの?」といったメタ的な問いにつながらないのでしょう。

これは「課題を深堀りしたい」という観点では課題でありつつも、表面化する課題がたくさんあるような状況では有効な手法になりえます。

制約事項が生む「小さな成功体験」

baby stepに向いているKPT

ボードに貼られた付箋以上の話に発展しづらいがゆえにタイムボックスを守りやすいこと。
問いが深くなりすぎないゆえに「いますぐにできて、目に見える効果が出る」アクションが出てきやすいこと。

チームが初めてふりかえりに取り組む段階では、明らかに解決するべき課題が山積していることが少なくありません。であるがゆえに「きっちりと時間をまもって」、「表出している課題を直接的に解決する」KPTという手法はふりかえりのアーリーステージでは十分に機能するのです。

やがて訪れる停滞

最初の頃は簡単なのに後半にいくほど難易度が急上昇する

シンプルな課題が解決されていくと、残るのは当然ながら複雑な問題になっていきます。ある課題を解決する施策が他の問題を引き起こしてしまう。表層の課題を解決するのではなく、システム全体で俯瞰して考えなければいけない段階に突入していきます。

このときにKeep, Problem, Tryを言葉どおりなぞるふりかえりは、チームの真の課題にたどり着きチームを前進させる力を失ってしまいます。

いや、KPTだとできない、というわけではありません。KPTのフレームワークを活用しながらメタ的に俯瞰するプロセスを追加する、5 whysと連結するなどKPTを使っていても深い問いに到達する方法はあります。けれども「ふりかえりといえばKPTだよね」というマインドセットであれば「KPTに何か足そう」という発想にはたどり着きにくく、KPTしか手段を知らずKPTのみを使い続けることはアンチパターンとなってしまうのです。

なぜふりかえるか考え、KPT以外の手段を持つ

その道具、その用途にあってる?

いわずもがなですが、KPTという手法が悪いわけではありません。ネジにトンカチを、釘にレンチを使うような目的と手法のアンマッチがよくないのです。KPTという手法が人口に膾炙していること、「なぜふりかえりを実施するか」を考える機会がないこと。そういった状況が「とりあえずKPT」を生み出し、停滞を生み出し、「ふりかえりがうまくいっていない」「ふりかえりって意味ないよね」を引き起こすのです。

じゃあどうするか?というと、以下の3点に尽きるのではないでしょうか。

  1. ふりかえりをする際になんのためにふりかえるのかハッキリさせる

  2. 自分たちのステージを理解する（課題が表出している段階か、表面上は課題がないように見える状態か）

  3. 様々な目的、ステージに適したふりかえり手法をたくさんストックしておく

3については、無料で参照できるふりかえりカタログあたりをおさえておくとよいでしょう。

結局のところ、銀の弾丸はありません。KPTだってそう。ふりかえりの手法でもっともポピュラーなものではあるものの、あらゆるシーンで有効なものではありません。ある場面でのベストプラクティスが別の場面ではアンチパターンになる、それを常に念頭に置きながら今の自分たちに必要な方法を選び取っていきましょう。

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