振り返りとKPT

ストーリー

「スプリントが終わったら、何をする？」

渡辺マネージャーが聞いた。

「次のスプリントの計画ですか？」

「その前に、今回のスプリントを振り返る。振り返りなしに次に進むのは、テストなしにリリースするのと同じだ。同じ失敗を繰り返さない。良かったことは続ける。 KPTという手法を使おう」

振り返りの重要性

なぜ振り返るのか

振り返りなし:
  Sprint 1: 問題A発生 → 応急処置で対応
  Sprint 2: 問題A再発 → また応急処置
  Sprint 3: 問題A + 問題B発生 → さらに忙しく
  Sprint 4: 問題A + B + C → チームが疲弊
  → 同じ問題が繰り返され、チームの速度が低下

振り返りあり:
  Sprint 1: 問題A発生 → 振り返りで根本原因を特定
  Sprint 2: 問題Aの対策を実施 → 問題A解消
  Sprint 3: 新しい問題Bが発生 → 振り返りで対策
  Sprint 4: 問題A, B解消。チームの速度が向上
  → 継続的に改善され、チームが成長

KPT法

KPTは、振り返りの最も基本的なフレームワークです。

KPTの3要素

要素	意味	質問
Keep	良かったこと。続けたいこと	「何がうまくいったか？」
Problem	問題だったこと。困ったこと	「何がうまくいかなかったか？」
Try	次に試したいこと。改善策	「次のスプリントで何を試すか？」

KPTの進め方

1. 準備（5分）
   - ホワイトボードかMiroボードを準備
   - K, P, T の3エリアを作る

2. 個人ワーク（10分）
   - 各自が付箋にK, P, Tを書き出す（1枚1項目）
   - 最低各カテゴリ2枚以上

3. 共有（15分）
   - 1人ずつ付箋を貼りながら説明
   - 似ている項目はグルーピング

4. 議論（15分）
   - Problemから優先順位をつけて議論
   - 具体的なTry（改善アクション）を決める

5. アクション決定（5分）
   - Tryから次のスプリントで実行する項目を3つ以内に絞る
   - 担当者を決める

KPTの実例

あるスプリントのKPT

┌────────────────────────────────────────────┐
│ Keep（良かったこと）                         │
├────────────────────────────────────────────┤
│ ・PRレビューSLAが機能している（24h以内達成率90%） │
│ ・デイリースタンドアップが15分以内に収まった     │
│ ・鈴木さんが自力でバグ修正できるようになった     │
│ ・ドキュメントの整備が進んだ                   │
├────────────────────────────────────────────┤
│ Problem（問題だったこと）                     │
├────────────────────────────────────────────┤
│ ・見積もりが甘く、3タスクが未完了              │
│ ・水曜の障害対応で半日失われた                 │
│ ・テスト環境が不安定で作業が中断された          │
│ ・リモートの佐藤さんへの情報共有が不十分        │
├────────────────────────────────────────────┤
│ Try（次に試すこと）                           │
├────────────────────────────────────────────┤
│ ・見積もりに1.3倍の補正係数をかける [あなた]    │
│ ・テスト環境の安定化タスクをスプリントに入れる [田中] │
│ ・#decisions チャンネルへの投稿を徹底する [全員] │
└────────────────────────────────────────────┘

良い振り返りのポイント

1. 心理的安全性を確保する

振り返りの冒頭で宣言:

  「振り返りの目的はチームの改善であり、
   個人を責めることではありません。
   率直な意見を歓迎します。
   発言は外に持ち出しません」

2. 事実ベースで話す

NG: 「田中さんのコードの品質が悪い」（主観・攻撃的）
OK: 「今回のスプリントでバグが5件発生しました。
     テストカバレッジが低い部分に集中しています」（事実ベース）

3. Tryは具体的なアクションにする

悪いTry	良いTry
「コミュニケーションを改善する」	「毎朝Slackに今日の予定を投稿する」
「テストをもっと書く」	「新規コードのカバレッジ80%をCIで必須にする」
「見積もりを正確にする」	「見積もりに1.3倍の補正係数をかける」

4. Tryは3つまでに絞る

多すぎるTry → 全て中途半端に
3つに絞る → 確実に実行して効果を測定

次のスプリントのTry:
  1. 見積もりに1.3倍補正 [あなた]
  2. テスト環境安定化 [田中]
  3. #decisions投稿の徹底 [全員]

他の振り返り手法

Start / Stop / Continue

要素	質問
Start	新しく始めるべきことは？
Stop	やめるべきことは？
Continue	続けるべきことは？

4Ls（Liked, Learned, Lacked, Longed for）

要素	質問
Liked	気に入ったことは？
Learned	学んだことは？
Lacked	足りなかったことは？
Longed for	欲しかったことは？

タイムラインレトロスペクティブ

スプリントの出来事を時系列に並べ、感情の変化を可視化する手法です。

         感情
  嬉しい  │      ★          ★
          │   ★     ★
  普通   │  ★        ★  ★
          │               ★
  辛い   │                    ★ ← 障害発生
          └──────────────────→ 日
          月  火  水  木  金

振り返りの定着

振り返りの頻度

レベル	頻度	対象
個人	毎日	日報の「学んだこと」セクション
スプリント	2週間ごと	チーム全体でKPT
プロジェクト	プロジェクト完了時	プロジェクト全体の学び
四半期	3ヶ月ごと	チームの働き方全体

Tryの追跡

前回のTryが実行されたかを、次の振り返りの冒頭で確認します。

前回のTry確認:
  1. 見積もりに1.3倍補正 → ✓ 実施。精度が向上
  2. テスト環境安定化 → ✓ Docker化で安定
  3. #decisions投稿の徹底 → △ 6割実施。引き続き継続

まとめ

ポイント	内容
KPTの目的	チームの継続的な改善
K（Keep）	良かったこと、続けること
P（Problem）	問題だったこと、困ったこと
T（Try）	具体的な改善アクション（3つまで）
心理的安全性	個人を責めず、事実ベースで議論
追跡	前回のTryの実施状況を確認

チェックリスト

KPTの進め方を説明できる
具体的なTry（改善アクション）を設定できる
心理的安全性を確保した振り返りの進め方を知っている
振り返りの頻度と対象レベルを理解した

次のステップへ

次は演習です。ここまで学んだプロジェクト計画、リスク管理、ステークホルダー管理、振り返りの技術を使って、困難なプロジェクトシミュレーションに挑戦しましょう。

推定読了時間: 30分