現在のプロジェクトでは定期的に振り返りを実施しており、
チーム改善に大きな効果を感じています。
実践して良かった取り組みを、具体例を交えてまとめておこうと思います。
KPTとは
プロジェクトを進めていく上では、
- よかった取り組みで今後も続けておきたいもの(Keep)
- 問題点としてあがってきていること(Problem)
- 改善して取り組みたいもの(Try)
などが出てくると思います。これらの頭文字を取ってKPTと呼ばれています。
どれも大事ですが、改善を進める上で中心になるのはやはりProblemとTryになるかと思います。
ただし、Keepを疎かにすると「問題ばかり話す後ろ向きな会議」になってしまうため、
バランスよく取り上げることが継続のコツです。
効果的な実施方法
洗い出しについて
リモートワークではExcelやMiro、Google Jamboardなどのデジタルツールが主流になりやすいですが、
対面で実施できる場合はホワイトボードに付箋を貼り出した方が情報が一覧化できてよいかと思います。
ホワイトボードのメリット
- 全員が同時に全体を見渡せる
- 付箋の移動や分類がその場でできる
- グルーピングや投票などの作業がスムーズ
- 物理的な「場」があることで議論が活発になる
デジタルツールのメリット
- 記録が残り、過去の振り返りとの比較が容易
- リモートメンバーも平等に参加できる
- 写真を撮る手間がない
- テンプレートを使い回せる
数値化について
振り返りをする上で賛否両論あるかもしれませんが、各人の作業消化状況を数値化しておくと
客観的な議論ができるようになります。
完全に数値化できないものも多いのですが、以下のような指標を追跡することで
チームの状況が可視化されます。
数値化の例
- タスクの完了数と残数
- 見積もり工数と実績工数の差異
- バグの発生件数と修正件数
- コードレビューのコメント数と修正回数
これらを記録しておくことで、
- 各人がどれくらいタスクを消化しているのか
- どこがボトルネックになっているのか
- 見積もりが難しいタスクは何か
- どの工程で時間がかかっているのか
などがわかるようになります。
実例: タスク消化率の可視化
以前のプロジェクトで、明らかに作業進捗が遅いメンバーがいました。
本人は「難しいタスクばかり担当している」と主張していましたが、
数値を見ると、実は簡単なタスクでも時間がかかっていることが判明しました。
このように数値を根拠に議論することで、感情的にならず建設的な改善策を話し合えます。
また、逆に「地味だけど重要な作業」を多く担当しているメンバーの貢献も可視化でき、
適切な評価につながります。
注意点
数値化はあくまで改善のための手段であり、メンバーを監視したり
数字だけで評価するためのものではありません。
数値の背景にある「なぜ」を理解することが重要です。
実施期間について
KPTを実施する期間ですが、プロジェクトの性質にもよりますが、
個人的には2ヶ月程度がベストではないかと考えています。
2週間サイクルの場合（短すぎる）
以前、スクラムに倣って2週間ごとに振り返りをやっていたことがありますが、
- 問題点があまり変化しない
- 前回のTryが効果を発揮しているか判断できない
- 同じ問題が何度も挙がる
といった課題がありました。
ただし、アジャイル開発のスプリント振り返りなど、
開発上のスポット的な問題（例: 今週のデプロイで発生したトラブル、直近のコードレビューの問題点など）
を扱う場合は、2週間程度でも効果的だと思います。
半年〜1年サイクルの場合（長すぎる）
逆に半年や1年だと、
- 改善の機会を逃してしまう
- 問題が深刻化してから気づく
- プロジェクトフェーズが変わってしまい、Tryが活かせない
- メンバーの異動でコンテキストが失われる
といった問題がありました。
実際に「良いTryが出たのに、次の振り返りまでに状況が変わってしまって実施できなかった」
という経験もあります。
2ヶ月サイクルが適している理由
- 新しい取り組みの効果を実感できる十分な期間
- 問題の変化や傾向が見えてくる
- 月次報告などの他の定例イベントと組み合わせやすい
- プロジェクトフェーズが大きく変わる前に軌道修正できる
もちろん、プロジェクトの進行速度や問題の深刻度によって柔軟に調整すべきですが、
まず始める際の目安として2ヶ月をお勧めします。
各項目の具体的な進め方
Keepについて
Keepは「今までやってよかったことを書き出して継続する」シンプルな項目ですが、
実は以下のような重要な効果があります。
Keepの効果
- 無意識の良習慣の再認識: 「当たり前」と思ってやっていたことが、実は重要だったと気づく
- メンバーへの感謝の表明: 「〇〇さんの迅速なレビューが助かっている」など、具体的な貢献を認識
- ポジティブな雰囲気作り: 問題ばかり話すと暗くなるため、良いことから始めると建設的な議論ができる
- 新メンバーへの文化伝達: チームの良い習慣を明文化することで、新しいメンバーにも共有しやすい
Keepの具体例
- 毎朝15分のスタンドアップミーティングで、進捗と障害を共有できている
- レビュー依頼から24時間以内にフィードバックをもらえる文化ができている
- 困ったときに気軽に相談できる雰囲気がある
- ドキュメントがしっかり整備されていて、新メンバーもキャッチアップしやすい
- 定期的なペアプログラミングで、知識共有とコード品質向上ができている
小さなことでも良いので、行動を評価することが重要です。
特に「誰かが頑張っていたこと」を取り上げると、チームの士気も上がります。
Problemについて
Problemはプロジェクト内の問題の洗い出しです。
ここで重要なのは、個人を責めるのではなく、構造的な問題を発見するという姿勢です。
良いProblemの出し方
- 「〇〇さんがレビューしてくれない」ではなく「レビュー待ち時間が長い」
- 「〇〇さんのコードが読みにくい」ではなく「コーディング規約が不明確」
- 「〇〇さんが情報を共有しない」ではなく「情報共有の場が不足している」
このように、個人ではなくプロセスや仕組みに焦点を当てることで、
建設的な改善議論ができます。
Problemの分類
私のチームでは、問題を以下のようなカテゴリに分類しています。
- プロセス: ワークフローや手順の問題
- コミュニケーション: 情報共有や意思疎通の問題
- 技術: ツールや環境、技術的負債の問題
- スコープ: 要件や仕様の不明確さの問題
- リソース: 人員や時間、予算の問題
分類することで、どの領域に問題が集中しているかが見えてきます。
Problemの具体例
- テスト環境が不安定で、開発効率が落ちている
- 要件の変更が頻繁で、手戻りが多い
- ドキュメントの更新が追いつかず、古い情報が混在している
- 特定の技術に詳しい人が1人しかおらず、ボトルネックになっている
- レビューのフィードバックが抽象的で、何を修正すべきか分からないことがある
Tryについて
Tryは改善案を実行に移す最重要項目です。
ただし、出てきた改善案を全て実施することは現実的ではありません。
優先順位付けの方法
私のチームでは、以下の3軸で評価して優先順位をつけています。
| 項目 | 評価基準 |
|---|---|
| 実行難易度 | 高・中・低（低い方が優先） |
| 必要コスト | 時間・人員・金銭コスト |
| 期待効果 | 高・中・低（高い方が優先） |
例えば、
- 「定期的なミーティングの時間を30分短縮する」→ 難易度:低、コスト:低、効果:中
- 「新しいCI/CDツールを導入する」→ 難易度:高、コスト:高、効果:高
- 「週1回のランチミーティングを実施する」→ 難易度:低、コスト:低、効果:中
といった具合です。
最初は「難易度が低く、効果が見える改善」から始めることをお勧めします。
小さな成功体験を積むことで、チームに「振り返りは意味がある」という実感が生まれ、
継続のモチベーションになります。
Tryの具体例とその効果
| Try | 背景となるProblem | 実施後の効果 |
|---|---|---|
| 毎週金曜日の午後を「ドキュメント整備タイム」にする | ドキュメントが古く、新メンバーが混乱 | オンボーディング時間が2週間→1週間に短縮 |
| コードレビューのチェックリストを作成 | レビューの観点がバラバラ | レビュー品質が向上し、バグ発見率が20%向上 |
| 週1回の「困りごと相談会」を30分設定 | 質問しづらい雰囲気 | 小さな問題の早期解決、メンター文化の醸成 |
| スラックに「感謝チャンネル」を作る | 貢献が見えにくい | チームの雰囲気が改善、モチベーション向上 |
Tryのフォローアップ
重要なのは、決めたTryを必ず次回の振り返りで評価することです。
- 実行できたか？できなかった場合、何が障害だったか？
- 実行した結果、期待した効果はあったか？
- 継続すべきか、やめるべきか、改善すべきか？
このサイクルを回すことで、チームの改善文化が根付いていきます。
振り返りを成功させるコツ
心理的安全性の確保
振り返りでは率直な意見を出すことが重要ですが、そのためには心理的安全性が必要です。
- ファシリテーターは中立的な立場を保つ
- 批判ではなく改善を目的とした建設的な議論を心がける
- 発言を遮らない、否定から入らない
- 全員が発言できるように、声の大きい人だけが話し続けないよう調整する
記録と振り返りの振り返り
- 毎回の振り返り内容を記録し、過去との比較ができるようにする
- 「同じ問題が繰り返し出ていないか」をチェックする
- 決めたTryの実施状況を追跡する
- 半年に1度は「振り返り自体」を振り返り、やり方を改善する
まとめ
KPTは単純なフレームワークですが、継続的に実施することで
チームの文化として定着し、大きな改善効果が生まれます。
重要なのは、
- 定期的に実施する（2ヶ月程度がおすすめ）
- 全員が参加する（心理的安全性を確保）
- 具体的な行動に落とし込む（Tryを明確に）
- 次回必ず振り返る（PDCAを回す）
だと思います。