プロジェクトの振り返りを行う際に KPT というフレームワークを使われる方も多いのではないかと思います。このフレームワーク自体はよくできていると思うのですが、その良さを十分に引き出せていないケースが少なくないように感じます。最初に KPT の Keep, Problem を(場合によっては Try も) 書き出すことから始めることも少なくありませんが、最初から Keep, Problem, Try について埋めていかないほうが良いと思っています。

以下の理由からです。

• Keep や Problem という名前に制限されて出てこない事項がある
• 分析が不十分になりがち

このような理由から、最初は単に Good, Bad を出し、それに対して分析を行うというアプローチが良いと考えます。Good, Bad は事実ベースで洗い出し、意見や仮説は分析フェーズで出します。例えば「〜した方が良かった」など、事実ではなく意見を Bad に出さないようにしなければいけません。分析は事実に基づいて行うべきだからです。

Good, Bad を洗い出し終わると、次に Good の中から Keep を抽出し、必要に応じて Keep するためにはどうすればよいか、更に良くするためにはどうすればよいかということを考えます。場合によってはなぜ良かったのか、上手くいったのかを分析することも有効かもしれません。

Bad についてはなぜなぜ分析などを使って分析を行い Problem を抽出します。問題分析ではすべての Bad について問題分析する必要はありません。そのようなことをしていると時間が足りませんので、問題分析が必要そうなものに絞って分析を行うことが重要です。また、問題分析をしていると、ついつい目的を忘れそうになることもあるのでその点にも注意が必要です。あくまでも目的は問題分析ではなく改善です。

最後に Try です。抽出した Keep や Problem をもとに考えます。Problem に対する Try はよくあるのですが、Keep に対する Try、または Keep や Problem に関係のない Try があっても良いと思います。

観点も重要です。私の周りだけかもしれませんが、とかくプロジェクトの進め方・プロセスにフォーカスされがちな気がします。ナレッジ共有・管理の観点からも、設計や実装など技術的な観点も意識して出していった方が良いと思います。

今回はエンジニアが振り返りの際によく使っている KPT について思っていることを書いてみました。こうしたほうが良いよ、うちではこうしている、など意見がありましたら是非教えてください。