📌

KPTのTryを仕組みに変え、同じ失敗を繰り返さないための振り返り運用

に公開

はじめに

私たちのチームで取り組んでいたKPTによる振り返りについて紹介します。

KPTは、Keep(良かったこと)、Problem(課題)、Try(次に試すこと)を整理する振り返り手法です。

この取り組みの目的は、次の3つでした。

  • プロジェクトで起きた反省を次のプロジェクトに活かすため
  • 同じ失敗を繰り返さないため
  • プロセスやチーム運営を継続的に改善するため

ただKPTを回すだけではなく「Tryを必ず仕組みに変える」という運用にこだわっていたので、その実践を中心に書いていきます。

運用方法

参加者

  • 技術顧問がファシリテーターを担当
  • プロジェクトメンバー全員が参加

実施タイミング

  • プロジェクトの終了ごと

利用ツール

  • Miro

オンラインホワイトボードのMiro上で、付箋を貼りながら振り返りを進めていました。

Miroでの進め方

流れは次のとおりです。

1. タイムライン(約5分)

いきなりKeepとProblemを書き始めるのではなく、まずプロジェクト全体を思い出す時間を設けます。

  • 横軸:プロジェクト開始〜終了
  • 縦軸:ポジティブ / ネガティブ

各メンバーは、次のような出来事を付箋に1枚ずつ書いて貼っていきます。

  • 「このタイミングでこんな出来事があった」
  • 「ここが良かった」
  • 「ここで問題が起きた」

この工程を挟むことで、全員の記憶を揃えてから本題に入れるのがポイントです。

タイムライン
タイムライン

2. Keep

良かったことを書き出します。

3. Problem

良くなかったことを書き出します。

Keep & Problem
Keep & Problem

4. Try

KeepとProblemの内容を見ながら、次に取り組むことを書き出します。

  • 次回どう改善するか
  • 何を仕組みにするか

Try
Try

5. Final Try

多くのTryが出てきます。ただ、一度にすべて進めるのは難しいです。そこでTryのあとに Final Try というフェーズを設け、本当に取り組むものを絞り込んでいました。

まず、出てきたTryに対して 一人三票 で投票し、票が多く集まったものから優先的に取り組みます。

投票で選ばれたTryは、次の点をその場で決めて実行に移していました。

  • 誰がやるか(担当者)
  • どこまでやるか

そして決まったTryは実行して終わりではなく、毎週1回、進捗を確認する場を設けていました。

各Tryについて、次の状態を確認します。

  • 終わったか
  • まだ終わっていないか
  • 詰まっていることはないか

止まっているものはフォローする、という形で着実に前に進めていました。やりっぱなしにしないための重要な仕組みです。

Final Try
Final Try

Tryを「仕組み」に落とし込む

今回の取り組みで一番特徴的なのは、KPTそのものではなく Tryを必ず仕組みに変えていたこと です。

Tryを単なる反省や「次は頑張る」で終わらせず、具体的な仕組みに落とし込んでいました。例えば次のような形です。

  • 仕様書を作るAI Skillを作成
  • StorybookとChromaticを開発テンプレートに入れる
  • デザインチェックリストの作成
  • ペアプロをやる

例えば「プロジェクト開始時に認識をそろえる時間が足りなかった」というProblemがあれば、次のプロジェクトではキックオフ時の確認項目としてチェックリストに追加します。「議事録に決定事項が残らず、あとから確認しづらかった」というProblemであれば、議事録テンプレートに決定事項を書く欄を追加します。

こうすることで、次の状態を作ることを目指していました。

次のプロジェクトでは同じ失敗を起こさない状態

反省を組織の資産に変換していく、という点が他のチームにも参考になる実践的な知見だと感じています。

難しかったこと

技術的・運用的な改善は仕組みに落とし込みやすかった一方で、次のような内容は扱いにくさがありました。

  • 考え方
  • マインド
  • チームとして大切にしたい価値観

これらはチェックリストやテンプレートに落とし込みづらく、運用として定着させる難しさがありました。

Notionに「Yoshinaniのマインド」のようなページを作り、チームで大切にしたい判断基準をまとめる運用を試しました。

おわりに

当時を振り返って、今ならこんなことを試してみたいと考えています。

  • KPT以外の振り返り手法
  • プロジェクト終了時だけでなく途中でも実施する
  • 振り返りをより短いサイクルで行う

KPT自体はよく知られた振り返り手法ですが、今回の取り組みで効果を感じたのは「Tryを必ずガイドラインやチェックリスト、テンプレート、運用ルールといった仕組みに変換していたこと」でした。

振り返りをやりっぱなしにせず組織の資産に変えていく運用は、チームの規模や手法を問わず参考になるはずです。

GitHubで編集を提案
YOSHINANI

Discussion