筋のよいTryを導くProblemの書き方

こんにちは、天野勝です。

KPT／KPTAフレームワークを使ってふりかえりをするときに、筋の良いTryを導き出しやすくするProblemの書き方があります。不満や不安と感じている困り事を書くことです。

このブログでは、好ましいProblemの書き方について紹介します。

KPT／KPTAとは？

KPT／KPTAとは、ふりかえりで用いられるフレームワークです。

KPTAは、アリスター・コーバーン氏が書籍『アジャイルソフトウェア開発』で紹介している「Keep、Problem、Try」(KPT)を拡張して、Actionを追加したものです。

各観点は、以下の通りです。

• Keep：続けること

• Problem：不満・不安なこと

• Try：試したいこと

• Action：行動すること

「KPTAのTryとActionの違い」にて紹介しているとおり、ふりかえりの結果、何かしらの実行可能な具体的な行動が生み出されることが重要です。

多くのTryはProblemを元に生み出されますので、筋よいProblemを記載できれば、有効なTryを導きやすくなります。

Problemは改善案ではない

好ましくないProblem

Problemに「～していない」「～すべきだった」という記述を見かけます。

例えば「事前準備を早く始めるべきだった。」というProblemです。このようなProblemだと、Tryを「事前準備を早く始める」としがちです。ProblemがTryの裏返しとなっているのです。

事前準備を早く始めることで、何が改善されるのかもわかりにくいです。

「ProblemとTryがセットになっている方が好ましい」「対策案のない問題を挙げるな」と考えもありますが、私の考える「ふりかえり」では、各人が感じていることや考えていることを共有することが大切と考えています。

「～すべきだった」といつ、自身の行動に対してのProblemが挙げている場合は、安全安心なチームとして成熟していない可能性が高いです。

強いプレッシャーがかかっていたり、個人に対する期待強すぎる場合など、チームに対して自身が充分に貢献ができていないと感じていてるときに、このような懺悔のようなProblemが増えてきます。

この後紹介する、好ましいProblemの書き方ではありませんが、このようなProblemもアラームとして拾い上げ、改善の対象としてもよいでしょう。

Problemには不満や不安などの困りごとの事象を書く

好ましいProblem

Problemには、不満や不安などの困りごとの事象を書きます。

改善案が思いつかなくてもよいですので、本人が感じていることをそのまま記載します。

また、困りごとを誘発している原因と思われることがあれば、それも合わせて記載してもよいでしょう。必須ではありません。

「事前準備を早く始めるべきだった」というProblemであれば、「事前準備が遅く、他のチームメンバーが会議の準備にバタついた。」の様に記述します。

「他のチームメンバーが会議の準備にバタついた」が困りごとの事象です。

Tryには、この困りごとの事象に対する改善案を挙げます。あくまでもチームでの改善案なので、自身が実行するかどうかはさておき、自由な発想でTryを挙げましょう。

良いアイデアが浮かべば、それを具体的にどのように実行するかを考えます。

考えすぎてProblemが挙がらないのはダメ

筋のよいTryを導きやすくするProblemの書き方を紹介しました。

このようなことに留意しすぎると、頭に思い浮かぶものがあっても、手が動かず文字にすることができないという、一番避けるべき事態に陥ることもあります。

チームでのふりかえりでは、各人が感じていることを共有することが大切ですのでは、まずは文字にして共有してみてください。そうすれば、他のメンバーからフィードバックがもらえるでしょう。

ご参考

「アジャイル開発の現場から #2 リモートふりかえり」

https://agile-douga.tv/products/practices-of-an-agile-team-remote-retrospective

「KPTとKPTAはどう使い分ける？」

https://agile-douga.tv/products/kpta-2

チームが成長し続けられるふりかえり支援ツール。

https://kpta.agile.esm.co.jp/