ブログ

ryuzeeによるブログ記事。不定期更新

直近開催のScrum Alliance認定スクラムマスター研修のご案内

なぜスプリントレトロスペクティブでKPTをお勧めしないのか

みなさんこんにちは。@ryuzeeです。

KPT(Keep, Problem, Try)はシンプルで使いやすいフレームワークとして知られていますが、スクラムのスプリントレトロスペクティブで繰り返し(毎回のように)利用することはお勧めしません。

なお、KPT自体が有効でないと言っているわけではありません。スプリントレトロスペクティブで繰り返し利用することに対する問題提起です。 たとえば何らかの大きな取り組みの最後に行ったり、プロダクトゴールを達成したあとや四半期ごとに長めの時間をとって全体を見たりするときには有効なこともあります。 また、ずっと改善を繰り返してきて非常に練度や能力が高くなっているチームの場合も有効かもしれません。

スプリントレトロスペクティブでKPTをお勧めしない理由の1つは、スクラムの価値基準の1つである「集中」にそぐわない点です。 リーン思考の説明でも「ムダを省き、本質に集中する」という記述があります。

スクラムでは、ゴールや本当に重要なことに集中します。この価値基準をスプリントレトロスペクティブでも日々の仕事のなかでも実践しなければいけません。 つまり、スプリントレトロスペクティブの結果を受けて改善するときは、本当に役立つアクションアイテムに「集中」することが重要です。 多数の(やってもやらなくても大して変わらないような)小さなアクションアイテムを選ぶのではなく、少数であってもインパクトの大きいアクションアイテムに集中します。 効果的な改善には時間とエネルギーが必要です。スクラムチーム全体のエネルギーを分散させずに少数の重要なアクションアイテムに集中することで、その労力の結果が最大限に発揮できます(逆に言うと、たくさんのアクションアイテムを出し、それを個人ごとにアサインするというのは、どれも中途半端に終わる可能性があり、インパクトも少ないやり方だということになります)。 これについてはスクラムガイドでも、「スクラムチームは、自分たちの効果を改善するために最も役立つ変更を特定する。最も影響の大きな改善は、できるだけ早く対処する」と明示されています。

一方で、KPTはその構造上、多数のアイデアやアイテムを抽出することになります。 前述のように、多数のアクションアイテムにそのまま取り組むと効果が限定的になりますし、アクションアイテム(Try)の数を制限した場合は、多くのアイデアが放置されるか、議論だけで終わってしまいます。 議論自体に意味がないわけではありませんが、多くの項目を議論するとそれぞれにかけられる時間は限られてしまい、深掘りも不足して、中途半端になります。 結果的に多数のアイデアやアイテムを出して内容を共有する過程自体が無駄になりやすく、参加者に「そもそもそんなに多くのアイテムを出す必要があるのか?」という疑問を抱かせてしまいます。 ずっとKPTを続けていると、同じ内容が何度も登場します。 ずっと解決されないまま同じ内容を出てくると、諦めのような感覚も醸成してしまいます。その結果、スプリントレトロスペクティブでの発言が減ったり、雰囲気が暗くなったりしてしまい、スクラムチームに悪影響を及ぼします。

繰り返しになりますが、改善の本質を見失わないためには、多くのアイテムを出すのではなく、最初から少数の大きな改善点に絞るほうが効果的です。 そのほうが、効果の有無を判断するのも圧倒的に楽です。

アジャイルマニフェストの背後にある12の原則(Principles behind the Agile Manifesto)には「Simplicity–the art of maximizing the amount of work not done–is essential.」という記述があります。これは「シンプルさ(やらずに済ませる仕事の量を最大にする)が本質である」という意味です(なお、アジャイルマニフェストの日本語訳は間違っています)。この点からも効果が小さいアクションアイテムに多数取り組むのはお勧めできません。

以上を踏まえてアドバイスです。

  • 本当に重要なアクションアイテムに集中して取り組もう
  • スプリントレトロスペクティブで毎回のようにKPTを使うのが本当に効果的か考えよう
  • チームの状況や課題にあわせて別のやり方も試してみよう。別にフレームワークを使わなくても構わない
  • どうしてもKPTを使いたいなら、最初に対象とする問題領域を絞ってみよう
  • スクラムマスターが毎回「では5分でKeepとProblemを書いてください」みたいなことを言うマシーンになっていたら、スクラムチームのメンバーは疑問を投げかけよう

関連リンク

関連FAQ

それでは。

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください(初回相談無料)
前の記事 スケーリングにおけるチーム構造の変遷
次の記事 【資料公開】スプリントレトロスペクティブ Deep Dive

プロダクト開発で、こんな課題を感じていませんか?

  • 何を作るべきか、順位の決め方が定まらない
  • プロダクトの方向性をチームで共有できていない
  • 開発組織の体制や役割がうまく機能していない
  • 開発プロセスが形骸化し、目的を見失っている
  • アジャイルを導入したが、組織に定着しない

プロダクトマネジメント、組織構造、開発プロセスの課題について、組織全体の視点から支援します。

お問い合わせ(初回相談無料)

契約を前提にした相談でなくて構いません。相談に際して事前の整理や準備は不要です。

Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方
ダイナミックリチーミング 第2版
Tidy First?
脳に収まるコードの書き方
プロダクトマネージャーのしごと 第2版
エンジニアリングマネージャーのしごと
チームトポロジー
スクラム実践者が知るべき97のこと
プロダクトマネジメント
SCRUM BOOT CAMP THE BOOK
みんなでアジャイル
レガシーコードからの脱却
Effective DevOps
変革の軌跡
ジョイ・インク
アジャイルコーチの道具箱
カンバン仕事術
Software in 30 Days
How to Change the World