「特にありません」で終わる振り返りの正体
スプリントやフェーズの終わりに振り返り会議を開いたが、メンバーから出てくるのは「特にありません」「順調だったと思います」という言葉ばかり——PLとしてこの場面に遭遇した経験はないだろうか。私自身、初めてKPTを使った振り返りを開催したとき、Keep（良かったこと）は3件、Problem（問題点）は1件、Try（改善策）は0件で、15分で会議が終わった。形式的には振り返りを「やった」が、何も改善につながらなかった。
振り返りが形骸化する原因は、多くの場合ファシリテーションの設計にある。「さあ、KPTを書いてください」と言うだけでは本音は出ない。メンバーが本音を話すには、「話しても大丈夫」という安全な場と、「話しやすくなる」仕掛けの両方が必要だ。
本記事では、振り返り会議で本音を引き出すための場づくり・フレームワークの選び方・具体的な進行手法を紹介する。サンプルはIT開発プロジェクト（5〜10人）のスプリント振り返りを想定しているが、考え方は業種・規模を問わず応用できる。少人数（3〜4人）のチームでは簡略化し、大規模プロジェクトではチーム単位に分割して実施するとよい。
振り返りの前提：心理的安全性を高める場づくり
振り返りで本音が出ない最大の理由は、「問題を指摘すると自分が損をする」とメンバーが感じていることだ。「遅延の原因を指摘したら、自分が責められるのではないか」「改善案を出したら、自分がやらされるのではないか」——こうした不安があるかぎり、振り返りは当たり障りのない内容に終始する。心理的安全性は一朝一夕には構築できず、チームの日常的な相互作用の中で蓄積されるものだ。ただし、振り返り会議の「場」における安全性を高めるために、PLが毎回行うべき行動がある。
PLが振り返りの冒頭で行うべきことは、以下の3つだ。
- 目的を宣言する：「この振り返りは、誰かを責めるためではなく、チームとして次をより良くするための場です」と明言する。毎回言う。1回言えば伝わると思いがちだが、毎回宣言することでルールが定着する
- PLが先に自分の失敗を開示する：「今回のスプリントでは、私のスケジュール調整が遅れて皆さんに迷惑をかけた部分がありました」のように、PLから弱みを見せる。PLが完璧を装うと、メンバーも完璧を装う
- 匿名の意見収集手段を用意する：口頭での発言が難しい場合に備え、付箋・チャット・匿名フォームなど「名前を出さずに意見を出せる手段」を必ず用意する
特に2つ目が重要だ。PLが自分の問題を先に出すことで、「この場では問題を出しても大丈夫なのだ」という空気ができる。逆に、PLが何も出さないまま「さあ皆さん、問題を出してください」と求めると、メンバーは「自分だけが損をする」と感じる。ただし、開示する失敗の選び方にはさじ加減がある。チーム全体に深刻な影響を及ぼした失敗を突然開示すると、メンバーが不安になる。「小さめの、自分でリカバリ済みの失敗」を選ぶのがコツだ。
また、正社員と協力会社（BP・SES等）が混在するチームでは、協力会社のメンバーが「問題を指摘すると契約更新に影響するのでは」と感じやすい。PLは「契約形態に関係なく、この場ではフラットに意見を出してほしい」と明示した上で、協力会社メンバーの意見を意識的に拾い上げる必要がある。
なお、上位者（PM・部長クラス）が振り返りに同席すると、メンバーは発言を控える傾向が強まる。可能であれば、振り返りはチームメンバーとPLだけで行い、上位者には結果をサマリーで共有する形が望ましい。上位者の同席が避けられない場合は、以下の工夫で影響を軽減する。事前に上位者と「オブザーバーとして聞く役割」を合意しておく、上位者の発言順を最後にする、上位者自身にもチェックインで自分の課題を開示してもらう、そして匿名での意見収集を必ず併用する。
フレームワークの選び方：KPTだけが正解ではない
振り返りのフレームワークとして最も知られているのはKPT（Keep / Problem / Try）だが、これが常に最善とは限らない。チームの状態やフェーズに応じて使い分けることで、振り返りの質が上がる。
フレームワーク1：KPT（Keep / Problem / Try）
構造：Keep（続けたいこと）→ Problem（問題点）→ Try（改善策）
向いている場面：チームが安定期に入り、問題の特定と改善のサイクルを回したいとき
注意点：ProblemがKeepやTryに比べて出にくい傾向がある。特にチーム結成初期は「問題」を指摘する心理的ハードルが高い
フレームワーク2：YWT（やったこと / わかったこと / 次にやること）
構造：Y（やったこと）→ W（わかったこと）→ T（次にやること）
向いている場面：チーム結成初期、メンバーが振り返りに慣れていないとき
利点：「問題」という否定的なラベルを使わないため、心理的ハードルが低い。「わかったこと」の中に自然と問題点が含まれる
フレームワーク3：Fun / Done / Learn
構造：Fun（楽しかったこと）/ Done（達成したこと）/ Learn（学んだこと）の3つの円のベン図に付箋を貼る
向いている場面：チームの士気が低下しているとき、長期プロジェクトの中間地点
利点：ポジティブな振り返りから始まるため、疲弊したチームでも発言が出やすい。「Fun かつ Done」「Learn かつ Fun」など領域の重なりから対話が生まれる
限界：問題の特定や原因分析には向かない。チームの士気回復が目的の場合に限定して使い、構造的な問題（リソース不足・過剰な残業等）が疑われるときはKPTと組み合わせる
サンプル：フレームワークの使い分け判断
- チーム結成1〜2回目 → YWT（心理的ハードルが低い）
- 安定期・改善サイクルを回したい → KPT（問題と改善策の紐付けが明確）
- チームの士気が低い・マンネリ化している → Fun / Done / Learn（ポジティブ起点）
- 同じフレームワークが3回以上続いて形骸化の兆候 → 別のフレームワークに切り替える
フレームワークは手段であって目的ではない。「KPTをやること」がゴールになると形骸化する。チームの状態を観察し、「今のチームにはどのフレームワークが合っているか」をPLが毎回判断する姿勢が重要だ。なお、ウォーターフォール型のプロジェクトではスプリント単位の振り返りがないが、フェーズ終了時やマイルストーン到達時に同様の振り返りを行える。間隔が長い場合は記憶の鮮度が落ちるため、「気づいたことをその都度メモに残し、振り返り時に持ち寄る」運用を組み合わせるとよい。
本音を引き出す5つの仕掛け
フレームワークを選んだ後、具体的にどう進行すれば本音が出るのか。以下の5つの仕掛けは、現場で繰り返し使えるものだ。
仕掛け1：書いてから話す（サイレントライティング）
振り返りの最初に、口頭でいきなり意見を求めない。まず3〜5分の沈黙の時間を設け、各自が付箋やチャットに自分の意見を書く。書いてから共有する。
なぜ有効か：口頭で即座に意見を求めると、最初に発言した人の意見にアンカリング（引きずられる）されやすい。書くことで全員が独立して考えをまとめ、多様な意見が出る。また、口頭で話すのが苦手なメンバーも、書くことなら参加できる。
仕掛け2：チェックインで場を温める
第2回で紹介した「今スプリントを天気で表すと」のチェックインが、振り返りの冒頭で機能する。直接「問題は何でしたか」と聞くと防衛的になりがちだが、天気というメタファーを介すことで、個人の感情を安全に表出できる。「雨」と答えた人の背景を振り返り本体で掘り下げることで、自然と課題が浮かび上がる。
仕掛け3：「人」ではなく「プロセス」に焦点を当てる
振り返りが「犯人捜し」になると、誰も本音を話さなくなる。PLは議論の焦点を常に「プロセス（やり方・仕組み）」に向ける。
言い換えの例：
- 「田中さんのレビューが遅かった」→「レビューのプロセスにボトルネックがあった。どう改善できるか」
- 「佐藤さんが仕様を誤解した」→「仕様の伝達方法に抜け漏れがあった。ドキュメントの書き方を変えるべきか」
「誰が悪かったか」ではなく「仕組みのどこに穴があったか」を問う。個人の能力や態度を変えるのは難しいが、プロセスは変えられる。この原則を守ることで、メンバーは「指摘しても個人攻撃にならない」と安心して発言できる。
仕掛け4：Tryは「小さく・具体的に・担当者付き」で
振り返りで最も形骸化しやすいのがTry（改善策）だ。「コミュニケーションを増やす」「ドキュメントを充実させる」のような曖昧なTryは、翌スプリントで実行されない。
Tryの良い例と悪い例：
- 悪い例：「コミュニケーションを増やす」→ 誰が何をするか不明。翌週には忘れられる
- 良い例：「毎朝のスタンドアップで、前日の作業で困ったことを1つ共有する枠を追加する。担当：PL。来週月曜から開始」
Tryは1回の振り返りで2〜3個に絞る。10個のTryを出して1個も実行しないより、2個出して2個とも実行するほうが改善は進む。
仕掛け5：前回のTryの振り返りから始める
振り返り会議の冒頭で、前回のTryがどうなったかを確認する。「前回決めた改善策を実行しましたか。効果はありましたか」と問いかけることで、振り返りが「やりっぱなし」にならない。第6回で紹介した進捗会議のアクション追跡と同じ原則だ。
Tryを実行しても効果がなかった場合は、「やめる」判断も重要だ。効果のないTryを惰性で続けると、「振り返りで決めたことは意味がない」という学習が生まれてしまう。また、チーム内で完結できないTry（予算が必要、他チームの協力が必要、上位組織の承認が必要等）が出た場合は、PLがステークホルダーに持ち帰り、次回までに実行可否を確認する。チーム内で完結できるTryを優先して選ぶことで、「振り返りで決めたことが翌週には動いている」という成功体験をチームに積ませることが大切だ。
なお、振り返りのファシリテーターは必ずしもPLが務める必要はない。PLはプロジェクトの成果に直接の利害があるため、無意識に防衛的になるテーマもある。チームが成熟してきたら、ファシリテーター役を持ち回りにすることも検討するとよい。PLが当事者として議論に参加したいテーマがあるときは、別のメンバーにファシリテーションを委ねることで、PLも一参加者として本音を出しやすくなる。
サンプル：振り返り会議のアジェンダ（60分）
振り返り会議 アジェンダ（60分・KPTの場合）
ゴール：今スプリントの学びを共有し、次スプリントで実行する改善策を2〜3個決める
① チェックイン・前回Tryの確認【共有】5分
→ 天気チェックイン＋前回Tryの実行状況確認
② サイレントライティング【個人作業】5分
→ 各自がKeep / Problem / Tryを付箋に書き出す
③ 共有・グルーピング【共有】15分
→ 付箋をボードに貼り出し、似たものをグルーピング。PLが読み上げて補足を促す
④ 掘り下げ議論【相談】20分
→ 重要なProblemを2〜3個選び、原因と対策を議論。「人」ではなく「プロセス」に焦点
⑤ Try決定・担当者アサイン【決定】10分
→ 具体的なTryを2〜3個決め、担当者と開始時期を確定
⑥ クロージング 5分
→ 「今日の振り返り自体のフィードバック」を一言ずつ
オンラインで実施する場合は、付箋の代わりにMiro・FigJam・Googleスプレッドシートなどを使い、サイレントライティングの結果をリアルタイムで全員が見える形にする。ツールは何でもよいが、「書いてから話す」の順番を守ることが重要だ。
経験談：振り返りが機能し始めた転機
失敗談：PLが解決策を出しすぎて逆効果になった
7人体制のプロジェクトで、KPTによる振り返りを導入した。Problemが出るたびに私がその場で「こうしましょう」と解決策を提示していた。最初はメンバーから「PLが対応してくれるので助かる」と好評だった。しかし3回目あたりから、メンバーが自分でTryを考えなくなった。Problemを出せば「PLが解決してくれる」という構造ができ上がり、チームとしての改善力が育たなかった。
この失敗から学んだのは、PLの役割は「解決策を出す人」ではなく「解決策をチームから引き出す人」だということだ。Problemが出たら、まず「このProblemに対して、どんなTryが考えられますか」とチームに問いかける。PLが答えを持っていても、まずメンバーに考えてもらう。PLの答えは最後の手段だ。
成功談：フレームワークを変えたら発言が増えた
別のプロジェクト（8人・4スプリント目）で、KPTの振り返りが3回続いてマンネリ化していた。毎回同じようなKeepとProblemが出て、Tryも「前回と同じ」という状態だった。そこでフレームワークをYWTに切り替えたところ、雰囲気が変わった。
「わかったこと」という問いは、「問題」と違って否定的なニュアンスがない。あるメンバーが「テストを後回しにすると手戻りが倍になると分かった」と書いた。KPTなら「テストが遅れた」というProblemになるところを、YWTでは「学び」として前向きに語れた。そこから「テストファーストを次のスプリントで試す」という具体的なTryが自然に生まれた。フレームワークを変えただけで、同じ事実が異なる角度から語られるようになった。
ただし、YWTにも限界はある。チームが成熟してくると、「わかったこと」が浅い気づきに留まり、根本的な問題の特定に至らないケースが出てくる。その段階になったらKPTに戻す、あるいは別のフレームワーク（時系列で出来事を振り返るタイムライン振り返り、Liked / Learned / Lacked / Longed for の4観点で振り返る4Ls など）を試す。フレームワークの選択自体を振り返りの対象にするのも有効だ。
振り返りの形骸化を防ぐチェックリスト
以下の兆候が出たら、振り返りが形骸化している
- 毎回同じKeep / Problemが出ている → Tryが実行されていない可能性がある
- Tryが抽象的で担当者がいない → 「誰が・いつ・何を」が不足している
- 15分で終わる → メンバーが本音を出していない可能性がある
- 特定の人しか発言しない → サイレントライティングやラウンドロビンを導入する
- メンバーが「またか」という表情をしている → フレームワークを変える時期
まとめ：振り返りは「場の設計」が9割
振り返り会議で本音を引き出すために、PLが押さえるべきポイントは以下の通りだ。
- 心理的安全性を高める場をつくる（目的宣言・PL自身の開示・匿名手段の用意）
- フレームワークをチームの状態に合わせて選ぶ（KPT・YWT・Fun/Done/Learn）
- 5つの仕掛けで本音を引き出す（サイレントライティング・チェックイン・プロセス焦点・Try具体化・前回Try確認）
- Tryは2〜3個に絞り、担当者と開始時期をセットで決める
- 形骸化の兆候を察知し、フレームワークや進め方を変える
振り返りは、フレームワークの種類よりも「場の設計」で成否が決まる。次の振り返りでは、冒頭にPL自身の失敗を1つ開示するところから始めてみてほしい。
次回（第8回）は、オンライン会議特有のファシリテーションの落とし穴と対策について取り上げる。
