会社でプロジェクトを終えた後、効果的な振り返りを実施していますか？そのプロジェクトが上手く行った場合はそれをKeepしつつ、さらに高みを目指すため、上手く行かなかった場合はProblemが何だったのかを考え、それらを踏まえて次へ何をTryすれば良いのか、その手法をそれらの頭文字をとって、KPT法と言います。本記事では効果的なKPTの進め方についてフォーマットを用いて分かりやすく解説していきます。
KPT法とは
会社であるプロジェクトを実施し、そのプロジェクトを終えた後、「振り返り」をする事はとても重要です。これは、会社にとっても、そのプロジェクトにとってももちろん重要ですが、何より自分自身にとってとても重要な事だと思います。特にそのプロジェクトをリードしているような立場の方であればなおさらであり、そのプロジェクトを経て、何を学んだのかを、客観的に、ロジカルに振り返る事で、自分の成長につなげる事で出来ます。
例えば、うまく行ったプロジェクトであれば、なぜ上手く行ったのかを振り返り、それをKeep（継続）し次のプロジェクトでも活かす。逆に上手く行かなかったプロジェクトでは、何がProblem(問題）だったのかを、皆で出し合い、問題の見える化を実施する。このように、KeepとProblemを踏まえて、次のプロジェクトでTry(挑戦)する事を決め、よりよいプロジェクト、製品、自分自身へ成長していく。
これがKPT法です。
このような手法はいくつかありますが、総じて言える事は、このようなフレームワークを使う事で、皆の頭が整理され、議論が発散しない。また、結果を見える化していく事で、相乗効果で意見が出やすいというメリットがあります。
是非こういったフレームワークを活用し、組織力の向上や、自分自身の成長の為に活用していきましょう。
実施するタイミングはプロジェクトが終わった後や、アジャイル開発をしているチーム等はスクラム毎に実施する事で、PDCAサイクルがスムーズに回るかと思います。
プロジェクトの進め方やアジャイル開発に関しては下記の記事を参照頂ければ幸いです。
参考：今更聞けない、アジャイル開発のスクラムの進め方と各プロセスの説明
参考：ものづくりエンジニアの仕事内容と製品が出来るまでのプロセスを公開します
KPT法のフォーマットと手順
それでは具体的にKPT法の進め方を説明していきます。メンバーはそのプロジェクトに直接関わったメンバーに絞った方がよく、また、あまり人数が多いと意見が出しにくくなる為、人数が多い場合は10人くらいのチームに分け、それぞれのチームで振り返りを実施し、最後まとめる。という形をとった方が良いです。
また、実施する中で一番気を付ける事は、「意見を出しにくい空気」になってしまう事です。ここもリーダーやファシリテーターの役目であり、意見ができるだけ自由に出せるような空気が作れるように、チーム編成の工夫や、それが難しい場合は、ポストイットを配布して全員に事前に書いてもらう、事前に意見をまとめておいてもらい、全員から発言してもらう等の工夫が必要です。
いずれにしても、ブレーンストーミングの基本である、「他人の意見は否定しない」は徹底して、少しでも多くの皆の生の声を書き出す事に終始した方が良いと思います。
ただし、プレーンストーミングと違うのは、意見が出れば良いという物でもなく、Tryへつなげ、改善につなげる事を目的としておりますので、ちょっとしたルールは必要です。最後のトピックでそのコツについて説明していきたいと思います。
■フォーマット
フォーマットは有名ですが、下の図の通りです。K、P、Tの意味はそれぞれ次の通り、それを白板に書いても良いですし、PC上に書いても良いですし、自由です。
・Keep：今後も継続する事（良かった事）
・Problem：今後改善すべきこと（悪かった事）
・Try：次に挑戦する事
■Keep（今後も継続する事：良かった事）を記載
K,P,Tの順ですが、Keep、もしくはProblemから記載していく必要がありますが、お勧めとしては、Keepからまとめて行った方が良いと思います。理由はプロジェクトを通してよかった事なので、ポジティブな内容が多く、場の雰囲気が良くなるからです。
初めからProblemに行きがち、かつ、Problemの方が多く意見が出るのですが、始めにそこに議論が集中すると、良かった事が出にくくなってしまう為、繰り返しになりますが、お勧めはKeepをまずは洗い出しまとめる事をお勧めします。
■Problem（今後改善すべき事：悪かった事）
これは、たぶん放っておいても、沢山意見が出ると思います。ポイントとしては他人を非難するような意見を出さないように、うまくファシリテートする事です。それさえ守れば、Problemは必ず日本人の場合は沢山出てくると思います。
■Try（次に挑戦する事）
Tryは、上記洗い出した、KeepとProblemの内容を見ながら、次のプロジェクトや次のスクラムで実施する事をまとめていきます。多くがProblemを改善する方向としてのTryを書きがちにりますが、それだけでなく、Keep（良かった部分）をさらに良くするためのTry。また、良かった事を次のプロジェクトでもそのまま実行する。という観点でのTryも忘れずに記載するようにしましょう。
また、これらのKeepやProblemからのTryだけでなく、これらの意見を踏まえた、第三のアイデアをうまく出せれば、このKPTは成功だと思います。
そして、そこでTryした内容に対し、次のプロジェクトで試した後、再度KeepとProblemを出し、継続、改善、新たなアイデアを出しまた次へ挑戦する。そのサイクルをぐるぐる回す事で、組織も強くなり、なにより自分自身が強い存在になれると思います。イメージは下の図のような感じです。
KPT法の本質
これまで説明して来たKPT法ですが、実際に経験のある方の中には、Keep,Problemと意見は沢山でたけれども、バラバラな意見の為、まとめるのに途方にくれ、皆の意見を尊重しすぎて、結局何も効果的なアクションに結び付ける事が出来なかった。Tryを書いたものの、自分たちの努力で出来る物ではなく、結局実行できないかったという方もいるのではないでしょうか？
KPTで意見を出してもらう事は重要です。意見そのものが無ければアクションはうまれません。ただ、すべての意見を尊重すべきかというとそうではありません。KPT法の本質は、意見を沢山出す事ではなく、効果的なTryを１つでも多く導き出す事です。
その為には、出て来た意見を取捨選択しなければいけません。それを全員集めた場でそのまま実施出来ればよいですが、難しい場合も多く、一度意見を出してもらった後は、更に人数を絞り、リーダー格のメンバーで、それぞれの意見の本質を整理する事が良いと思っています。
つまり、出してもらった意見は、すべてをKeepする必要があるは限らなく、すべてがProblemであるとも限らず、出て来たTryはすべて実行すべき内容であるとは限らない。すべてを実行しようとすると、逆にやる事が増えてしまうだけの場合もあります。
そこで、出た意見を「採用するか、採用しないか」を整理する必要があります。整理のポイントは下記。
- 主観的意見か、客観的意見かを分ける（個人の思い込みの意見ではないかどうかを見極める）
- 自責の内容か他責の内容かを分かる（自分たちの力で動かせる物か、そうでないのかを分けける）
簡単にいうと、個人的な思いの意見、共通認識でなない物は除外し、
①共通認識の課題
②自責による内容
にフォーカスし、Tryをまとめていく事です。そこをうまくまとめ、メンバーへも共通認識として共有し、次プロジェクトにつなげていく、そんな活動ができればKPTを用いた振り返りとしては成功ではないかと思います。
アジャイル開発の記事もありますので、よろしかったらご覧ください。
参考：今更聞けない、アジャイル開発のスクラムの進め方と各プロセスの説明
記事が気に入って頂けたら、クリックして頂けると嬉しいです。
コメント