【KPT】プロジェクトにおける振り返りの方法とその効果

だっとまん

2026年6月30日 12:42

ごあいさつ

こんにちは。だっとまんです。

今回は、疎かにされがちですが
プロジェクトにおける振り返りの方法とその効果
についてのお話です。

本内容は、スクラム開発におけるレトロスペクティブではなく、プロジェクトにおける「振り返り」について書いてます。システム開発だけにとどまらず、営業や企画、はたまた社内行事など、プロジェクトであれば何でもよいです。

健康になるよ

これは、「プロジェクトが」健康になる、というお話。
健康なプロジェクトって、ざっくり言うとこうです。

何がうまくいっているか分かっている
何が詰まっているか隠れていない
課題が個人攻撃ではなく、仕組みの問題として扱われている
次に何を変えるか決まっている
同じ失敗を何度も繰り返さない

KPTはこの状態を作るのに向いています。

モテるようになるよ

プロジェクトが健康になり、うまく回りだすと
”あいつのいるプロジェクト、いつもうまくいってんなぁ”
こう思われます。すると、

”つぎはうちのプロジェクトに入って！”
”この案件のPMやって！”

と、いろいろご依頼が来るようになります。
そういう意味でモテます。

モテると選択肢が増えるので、
「あ、見えてる地雷。」
みたいなプロジェクトに呼ばれそうなときは

「ごめん、あっちのプロジェクトちゃんと付き合うことにしたの。てへ。」

DVの匂いとか、束縛強そうなプロジェクトは振りましょう。

そもそも、振り返りってなんでやるの？

過去を振り返って未来に生かす、教訓を生かすのが目的。
ここでいう教訓は「失敗したこと」「困ったこと」だけではありません。
「これ良かったね」も教訓として生かしましょう。

ああすればもっとよかったのではないか
これはやりやすいから続けていこう、快適
とかを共有することで、みんなの経験を財産として生かしていくことを目的とします。

かえるさんの失敗を教訓に。
振り返らないと、「また同じとこで怪我したの？」と・・・追い打ちをかけられることがある。

KPTのやりかた

既にご存じの方も多いかと思いますので釈迦に説法ですが、
（余談：コンサルって「釈迦に説法」って言いたがる人が多いよね。謎。）

KPTとは？

K：Keep
続けたいこと。うまくいったこと。
P：Problem
困ったこと。うまくいかなかったこと。モヤモヤしたこと。
T：Try
次に試すこと。改善アクション。

この3つについてみんなで話しましょう。というものです。

用意するもの

集まってやる場合、リモートの場合、ツールを使う、等いろいろなやり方があります。

ホワイトボードと3色のポストイット、ペン　★おすすめ
Keepは青、Problemは赤、Tryは黄色、みたいにポストイットの色は決めておきましょう。
Trello　https://trello.com/ja
Miro　https://miro.com/ja/

などなど、検索したらいろいろ出てきますので、ご自身のチームに合わせて決めましょう。

進め方

まず、全員で「Keep」「Problem」を考えます。考える時間は5分～10分くらい。
ポストイットを使う場合は手元に書き出しておきます。
ツールを使う場合は、その場で書き込んでいって構いません。
書いた「Keep」を1人ずつ話していきます。
ポストイットを使う場合は、このときにホワイトボードに貼りながら話します。すでに出た内容、重複する内容があっても構いません。全員、書いた内容を話します。
次に「Problem」についても同様に話していきます。
全員が話し終わったところで、KeepとProblemのグルーピングをおこないます。
ここでは、似た内容をまとめながら、
「これはルールがなかったのが原因っぽいね」
「ここは意思決定の遅さがボトルネックだったね」
という感じで、原因を少し整理します。
「これ、地味だけど効いてたね」
みたいに、よかった動きもちゃんと拾います。
「Try」を決めます。みんなで取り組む改善アクションです。
ここで大事なのは、全部を解決しようとしないことです。
Problemが10個出ても、Tryは2〜3個で十分です。
課題管理ツールでチケット化しておくのがおすすめです。
※課題管理してない場合・・・即「Problem」として認識してください。
Tryの主担当を決めます。主担当だけがやるわけではなく、改善アクションの旗振りくらいのイメージでいましょう。Tryはチーム全員で行います。
次回、Tryの状況をみんなで確認します。

どんな効果があるの？

個々のメンバーが普段何となく思っている意見を聞くことができる
- 声の大きい人や積極的な人の意見のみが通りがちですが、普段発言が少ない人からも意見を聞きます。もしかしたら普段何か発言しづらい環境なのかもしれませんし。
- 「みんなに言うほどのことでもないけど、こうしたらいいのになぁ・・・」みたいなことを発見できるかもしれません。実は言うほどのことだった、ってこともあるかもしれませんし。
個々のメンバーが普段何となく思っている良いこと、悪いことを可視化できる。
- Keep、Problemの重複OKなので、「実は同じこと思ってた！」と、じつはチームの多くが思っていたことを可視化できますし、「その観点はなかった！」「若手は（ベテランは）そう思っているのか」みたいな発見もあります。
チームとして「取り組むこと」がはっきりする。
- KeepやProblemが重複するもの＝みんなが思っているよいこと、わるいことなので取り組みやすいですね。
- 新しい観点で「それは大事！」「それはいいね！」となったものはその場でみんなで共有、取り組みを決めることができます。
チームとして「取り組んだ結果」を振り返ることで、方向が正しかったのかがわかる。定期的に方向修正もできる。
- 「あ、前回のProblem、今回ちょっと改善したね」
  「このTryは効果あったからKeepに移そう」
  こうやって、TryがKeepに変わっていくと、プロジェクトがちゃんと健康になっていきます。
- 「これはやってみたけど微妙だったね」
  変化がないようであれば、アプローチがよくなかったよね、取り組み方を工夫する必要があるよね、ということが分かります。取り組み方を工夫することで方向修正ができます。

注意事項

全員参加

全員がKeep、Problemを挙げる　内容がかぶっていてもよい
持ち時間は一律とし、しゃべる人としゃべらない人に偏りが出ないようにする
- 持ち時間を超えてしゃべる人が出てきたら、持ち時間を超えた時点で打ち切ります

「問題」vs「全員」

「〇〇さんの品質が・・・」「XXさんの指示が・・・」のような人vs人の構造ではなく、「問題」vs「全員」で考える
なぜその問題が起こったか？我々はどう立ち向かえばよかったか？どうすべきか？仕組みを考える

時間を決めて実施する

振り返りの時間はだらだら長くしない。30分～1時間くらいがよいです
振り返りの時間内で収まらない議論は別途時間をとって行う

会議ではなく習慣にする

1回やって終わりではなく、定期的に実施する。定期的に実施することでことでチームが成長していく
振り返りの期間を一定以上空けず、プロジェクト終了 or 前回の振り返りから一定期間　のどちらかで必ず実施する（月一くらいが妥当ですかね。）

失敗する振り返りのパターン

絶対やっちゃダメなパターンです。
こういう振り返りをしているプロジェクトはままありますが、例外なく雰囲気悪くなってパフォーマンス落ちます。

全員参加できない、参加者が少ない
- 全員参加が鉄則です。特に、参加できない人がPMとかリーダークラスの場合、自分で「無責任です」「マネジメントできません」と宣言しているようなものです。
ずっと話し続ける　／　何も意見を出さない人がいる
- たとえ見た目上成果が出せている人であっても黄色信号、チームから外すことをお勧めします。「あいつの意見ばっかり」「別になにも意見無くていいんだ」という空気の製造元となり、近いうちにチームを壊します。
自慢話
- よそでやれ。こういう人も振り返りの趣旨を理解できていないのでメンバーとして黄色信号です。
人の攻撃
- 最悪です。即振り返りを中断してください。やらないほうがましです。振り返りの趣旨を再度説明して、それでもだめならエスカレーションしてください。あなたがPMなのであれば、人を攻撃する人は即切ってよいです。
  「〇〇さんの品質が・・・」「XXさんの指示が・・・」のような人vs人の構造ではなく、「問題」vs「全員」で考えます。

まとめ

みんなでKPTをつかった振り返りをして、健康でモテるぞー！
ということで、本日はここまででございます。
PMとして
”プロジェクトでやってみてよかったシリーズ”
はちょいちょい書いていこうかと思います。

お知らせ

AI/DX/システム開発まわりで、
「ベンダーの提案が妥当かわからない」
「AIチャットボットを入れたいが進め方が不安」
「要件定義の前に壁打ちしたい」
というみなさま向けに、30分のスポット相談を始めます。

アクセンチュア、Yahoo! JAPAN、AWS、トヨタグループなどでDX・クラウド移行・要件定義・PM/POをやってきた経験から、発注側の立場で論点整理します。

初回のみ30分5,000円で受けます。
希望される方はDMくださいませ。