事象変換がカギ｜GB→KPT法で正しくプロジェクトを振り返ろう

皆さんは業務の振り返りでKPTを行った事はありますか？振り返りの手法としてポピュラーではありますが、形骸化し、何も生まれない/次に活かせない場になることがよくあります。
KPTについて調べても一般的なフレーム説明しかなく、どんなプロセスでアウトプットすれば良いか、実践イメージも湧きづらいです。

実はKPTのフレームに事象を当てはめるだけでは良い考察は生まれません。事象からKeep,Problemを抽出する「事象変換」が必要なのです。「GB→KPT法」と勝手に呼んでいるのですが、事象変換による正しいKPTの方法をご紹介します。

KPTをやる目的とは

改めておさらいすると、KPTとは、Keep/Problem/Tryの略で、プロジェクト遂行の振り返りを行うフレームワークです。

• Keep：プロジェクト成果に繋がった、続けるべきこと
• Problem：プロジェクトの成果に影響する、改善すべきこと
• Try：Keepの継続、Problemの解決に向けたアクションプラン

KPTの目的は事象から維持、課題項目を特定し、次に繋がるアクションプランを出すことです。
客観的にプロジェクトと向き合い、KPをうまく抽出、内省を持って、次のプロジェクトへ活かします。

長期プロジェクトの場合は1ヶ月ごと、マイルストーンごとなど、一区切りをもって行うことで効果的に次のアクションへ活かせます。

よくあるKPTの失敗ケース

と言ったKPTの概要でしたが、そのまま試してみようと思い取り組むと、大体のケースで失敗｜良い内省ができず何にも活かせない状態となってしまいます。
正しいKPTの方法を知る前に、代表的な失敗を知ることでどんな場にするべきか明確にイメージしましょう。

Keep / Problem の内容が感想文

Keep / Problem に書かれた内容が広がらず、ある種“感想文”で終わってしまうケースです。具体的なこの様な感じ。

【ディスカッションにおけるKPT】

• Keep
  • チーム全員で話し合いを行い、仕様を決めることができた
  • 正直に意見を言い合い議論しながら決めることができた
  • 議論の際に、的確にファシリテートして、意見を収束させられた
• Problem
  • 意見をまとまってないままその場で発言して、だらだら話してしまった
  • 根拠なく主観で物事を話してしまった
  • 発言者に偏りが出てしまった

ここから話を広げられず「じゃあだらだら話さないように気をつけよう」の様な、何の改善にもつながらない案になってしまいます。

人に対して攻撃的で非建設的

この時点であまり良いチームではないですが…他責思考で良い議論が出来ないケースです。

【ディスカッションにおけるKPT】

• Problem
  • Aさんのファシリテートがグダついて、時間を押してしまった
  • Bさんがディスカッションに参加しなく、無駄な時間を過ごしていた

この課題をもらっても良い気分にはならないですよね。感情で会話することで、良いTryには繋がりません。

ふわっとしたTryで次につながらない

プロジェクトとして当たり前だったり、粒度として粗過ぎたり、Tryできる内容ではあるけど、気持ち的な側面が強く、アクションとして成立しないケースです。

【ディスカッションにおけるKPT】

• Try
  • かならず議論に参加する
  • 各自が発言できるように気をつける
  • ファシリテーターは話を均等に降る

確かにそうなんですが、とても表層的で本質課題の解決はできません。

---

これら失敗例に共通するのは「事象を変換できていない」ことです。挙がった事象一つずつは扱って良いですが、事象からそれがなぜ起こるのか、どうすれば良いのか、Keep / Problem に変換できてないのです。
変換できないと、論点がズレたり事象の本質にたどり着けず、良い考察を出せません。

この様な失敗を起こさないために有効なのが「GB→KPT法」です。具体的な方法についてここから紹介します。

正しくKPTを行う｜GB→KPT法

GB→KPT法（Good / Bad→Keep / Problem / Try）ですが、簡単に言えば、まずGood / Bad の事象を出し、粒度を揃えた上でKeep / Problem へ変換するKPT手法です。
具体的なプロセスについてご紹介します。

今回は前述の「ディスカッション後のKPT」を題材に、具体的なアウトプットも載せていきます。

前準備：フレームの作成

GB→KPT法ですが、ホワイトボード&付箋やディスカッションツールの利用がおすすめです。
セブンデックスではFigjamが標準ツールですので、Figjamを使ってフレームを用意します。以下のようなフレーム作成がおすすめです。

Good / Bad で事象を洗い出す

まずはじめにGood / Bad を洗い出します。ここではプロジェクトを進める上で起きた良かった / 良くなかった事象を書き出します。書く事象の粒度ですが、結果からプロセスまで、起きたことを一通り記載して大丈夫です。人に対するBadについても、攻撃的な書き方に注意すれば、一つの事象として挙げましょう。
細かな事象になると忘れてしまうこともあるので、日々事象が起こる度に書き留めて置くこともおすすめです。

前述の事象をGood / Badに書き出したのがこちら。

Good / Bad に対して「だから？」「なぜ？」を当てて、結果とプロセスで分割する・粒度を揃える

発散した事象は粒度がバラバラの状態のため、プロセス-結果の関連性で整理します。粒度が異なる事象に対しては、「だからどうなったのか」「何が理由で起きたのか」を問い直し事象分解、解像度を上げましょう。

今回の例もプロセスと結果に分割、事象に関連性を持たせました。

Good / Bad 事象からKeep / Problem を抽出する

Good / Bad によって事象を洗い出しましたが、ここからKeep / Problem を抽出します。抽出のコツとして、「なぜそれが起きたのか」を考え根本の要因を探ります。

優先度やそもそも要因特定するほどでもない事象に関しては、抽出の対象外として扱ってももんだいありません。

今回の例だと、ゴール達成に向けたシミュレーション、その場のコミュニケーション、論点整理など、準備と実行は良かった一方で、ゴール達成までのタイムマネジメントの観点が漏れていることがわかりました。
発言者の偏りはファシリテートで解決できる一方で、この場の目的がディスカッションであることから、発言者側の改善が優先事項であり、Problemに落とす優先度ではないと判断しました。

簡潔なTryに落とし込む

最後に出てきたKeep / Problemから、Tryに落とし込みます。KPTを行う際、ProblemのTryに目を向けがちですが、Keepからより良くするためのアクションを出すことも大切です。
また、Keep / Problem から共通のTryが出ることもあります。構造化を意識しながらTryを出してみましょう。

今回はディスカッションを例にしたため、簡単なTryになりましたが、実プロジェクトでは「◯月◯日までに、△を改善する」と具体的なTryも出てきます。

まとめ

事象から要因を抽出するGB→KPT法について紹介しました。この方法を使うことでより良いアクションに繋げられます。今のプロジェクトでも即実践できるので、ぜひ試してみてください。