どんな振り返り(レトロスペクティブ)をやっていくのか

企業文化 働き方 スクラム 振り返り

どんな振り返り(レトロスペクティブ)をやっていくのか
こんにちは！開発本部 SINIS for Instagram 開発チームのamkkrです。 今回は私が社内勉強会で話をした、振り返り（レトロスペクティブ）の話をテックブログでもまとめようと思います。

振り返りは機能していますか？

  • 「今週もKPTやりました」で終わっていないか
  • 出てくる意見が毎回同じになっていないか
  • Tryが実行されずに忘れられていないか

振り返りを形式的にこなすだけになっていると、チームの改善サイクルは止まってしまいます。 機能させるための仕組みがないか、改めて考えてみようと思います。

メインで取り上げること

  • レトロと呼んでる物は何なのか
  • 振り返りのFWのいくつか
  • 形骸化しないために

そもそも「振り返り(レトロスペクティブ)」とは何か

スプリントレトロスペクティブ（Sprint Retrospective）とは、「スプリント全体の現状認識の共有、課題や改善案を話し合い、次のスプリントの効率向上を行うイベント」です。

  • チームのプロセス改善: プロセス、技術、チームについて振り返る
  • 次のスプリントへの学びの反映: 議論した改善策を次のスプリントで実行する

振り返りの目的

  • チームの継続的改善: プロセス、技術、チームワークを改善し続ける
  • 同じ失敗を繰り返さない仕組み: 問題を可視化し、再発を防ぐ
  • 良い実践を定着させ、横展開する: 成功事例を共有し、チーム全体に広げる

PDCAサイクルとの関係

PDCAサイクル（PDCA cycle）とは、継続的な業務改善、目標達成の概念で、以下の4段階を繰り返して業務を継続的に改善する手法です。

  • Plan（計画）: 目標を設定し、計画を立てる
  • Do（実行）: 計画を実行する
  • Check（評価）: 実行結果を評価し、計画との差異を確認する
  • Act（改善）: 問題点を改善し、次のサイクルに活かす

振り返りは「Check」と「Act」に相当して、実行した結果を評価し、次に向けた改善策を考える場でもあります。

おまけ：OODAループ

OODAループ（OODA Loop）は、アメリカ空軍のジョン・ボイド大佐により提唱された意思決定と行動に関する理論です。

  • Observe（観察）：状況や環境を客観的に観察し、現状を正しく認識
  • Orient（状況判断）: 観察した情報を元に、取るべき行動の方向性を定める
  • Decide（意思決定）： 具体的な手段を決定する
  • Act（実行）：決定した手段の実行

より素早い状況判断と行動のサイクル: PDCAが計画ベースで1周するのに対し、OODAは状況に応じて柔軟にループを回す考え方です。

振り返りは「Orient（状況判断）」を深める場: チームで観察結果を共有し、状況を正しく理解することで、次の意思決定の質を高めるものとして定義されています。

振り返りが形骸化する理由

参考: https://note.com/dora_e_m/n/n8e640c28e823#4a5f5891-b8b7-4ff0-be5e-a59c6d4a5669

構造的な問題

  1. フレームワークへの過剰適合
    • 真剣にフレームワークと向き合う生真面目なチームが「KPT」と向き合ったとき、Keep, Problem, Try「しか」話してはいけない、と思ってしまう。Keepを共有したら、次はProblem。それが終わったらTry。そういうプロセスを遵守しすぎるがあまり、「え、なんでそれがProblemなの?」といったメタ的な問いにつながらないという状況が発生
  2. 深掘りの欠如
    • 「会議が多く開発時間がとれない日がある」というProblemに対し、即座に「会議を他の日にも分散させる」というTryが出ていた。なぜ会議が多いのか?開発時間がとれない日が予測可能な状態で出現しているのは問題なのか?そういった視点に立つことなく表面の課題を解決する方法を模索し始めてしまう
    • これにより、根本原因の分析がスキップされる
  3. 成熟度による限界
    • 「Keep」は継続を意味するため、記録するのが難しい
    • そもそも、何を続けたいかについてあまり考えない→KEEPとは..?
    • 初期：明らかな課題が多く、KPTで十分機能する
    • 後期：残るのは複雑な問題。K/P/Tの枠では扱えなくなる

振り返るためのフレームワークを紹介

KPT (Keep/Problem/Try)

概要

改めてKPT法とは、「Keep」「Problem」「Try」の3要素からなる振り返り式のフレームワークです。元々Alistair Cockburn（アリスター・コーバーン）氏が考案したとされ、アジャイルやスクラムと呼ばれるシステム開発で活用されてきました。

https://www.agile-studio.jp/post/kpt-focus-on-strengths

  • Keep（継続すること）: 上手くいった要素や評価が上がった要素など、次回以降も続けていくこと
  • Problem（問題・課題）: 上手くいかなかった要素や事故になった要素を洗い出し、次回に向けた課題とすること
  • Try（試すこと）: KeepとProblemの内容をもとに、次回行う具体的なアクションをまとめる

メリット

  • 認知度が高い: PDCA等と一緒に社会人なら知っているくらい知名度がある
  • 課題の可視化: 漠然としていた課題が明確になり、メンバー間で共通認識を持てる
  • 課題の早期発見: 短い(Keepに近い)スパンで問題を早期に発見し、迅速な対策を講じやすい

デメリット

Tryが複数出るため、何をアクションするかチームとして中途半端にせずに取り組むかが難しく、アジャイルの経験主義の柱、適応がおろそかになっていきやすい。

  • Tryを複数扱おうとした場合：全てに取り組む場合に深掘りする時間的・人的リソース不足
  • Tryを1個または制限した場合 ：（FWの性質上多く出る）改善のアイデアなどが放置されることになり、メンバーの諦めや虚無感を引き出してしまう

Starfish

概要

Starfish（スターフィッシュ）は、Patrick Kua氏によって考案されたレトロスペクティブ手法で、5つのカテゴリでチーム全体の活動を振り返ります。

ヒトデ（starfish）の形状に5つの観点を配置することからこの名前がついています。 https://www.funretrospectives.com/starfish/

  • Keep Doing（続けること）: チームがうまくやっていて、その価値を認識していること
  • More of（もっとやること）: すでに行っていて、もっと増やすことで価値が高まると考えられること
  • Less of（減らすこと）: ある程度の価値は見ているが、少し減らしたいこと
  • Stop Doing（やめること）: ビジネスに全く価値を加えていない、シンプルに停止すべき活動
  • Start Doing（始めること）: 新しいアイデアや、以前うまくいったのを見たことがあり、取り入れたいこと

starfish公式より引用

使いどころ

「完全にやめる」か「続ける」かの二択ではなく、「もっと増やす」「少し減らす」といった選択肢が明示されるため、なんとなく続いているものをスパッとやめてみるとか、チームの改善がマンネリになってきた時にマンネリ打破として。

(Small Starfish)

Starfishの軽量版で、Keep / Less / More の3象限で構成されたFWです。

  • 時間が限られているときに有効
  • Starfishの考え方を取り入れつつ、よりシンプルに実施できる

象・死んだ魚・嘔吐

概要

「Elephants, Dead Fish, and Vomit」は、Airbnbの共同創業者Joe Gebbia氏によって考案されたフレームワークです。

Elephants, dead fish & vomit

  • 象（Elephant in the room）: 誰も触れたがらない大きな問題。部屋にいる象のように、誰もが気づいているのに誰も言及しない問題のこと
  • 死んだ魚（Dead fish）: 放置しておくとまずいことになる問題
  • 嘔吐（Vomit）: 吐き出したい不満や懺悔。

Google Gemini Nano Bananaで作成した象・死んだ魚・嘔吐の図

使いどころ

チームに溜まった膿を出したいときや、心理的な障壁が高いとき。

ネガティブな意見を言っても誰も嫌な顔をしないという状況を作り、全体の心理的安全性の確保をしたいとき。

Fun/Done/Learn

概要

Fun/Done/Learnは、沖縄で開催されたScrum Coaches Retreatでアジャイルコーチたちによって考案された振り返り手法です。 ベン図を使って、スプリント中に行ったことを分類するFWです。

  • Fun（楽しかったこと）: 楽しかった活動や出来事
  • Done（完了したこと）: 達成したこと、成果を出したこと
  • Learn（学んだこと）: 新しく学んだこと、気づいたこと

3つの円が重なる部分には、複数の要素を満たす項目を配置していきます（ 楽しくて、完了して、学びもあった）。

Google Gemini Nano Bananaで作成したFun/Done/Learnの図

使いどころ

ポジティブな雰囲気を作りたいときや、チームの士気を上げたいときなど。

KPTのように課題を解決にするというよりは、良かったことや楽しんで学習できたことを共有して、個人でなくチーム全体のスキルアップとモチベーションの向上を図りたいとき。

闇鍋

概要

匿名性とランダム性を組み合わせた振り返り手法です。

テーマを1つだけ取り上げて、それに対するアクションを考えるものになります。

KPTなどの手法には以下のような性質がありました：

  • 出てきた項目のうち、どれに取り組むべきなのかを決めるのが難しい
  • 発言者の声の大きさや同調圧力の影響で、特定の意見ばかりが採用される
  • スプリントを繰り返すうちに、議論内容がマンネリ化してしまう

闇鍋は1つしか取り扱わないことで、スクラムの価値基準の1つ「集中」を実践しやすいものとなっています。 参考： 新しいふりかえりのやり方『闇鍋』 | Ryuzee.com

形骸化させないための実践ポイント

メソッドを使い分ける

  • 基本はKPTでもOK: シンプルで理解しやすく、継続しやすいし
  • 3-4回に1回は違うメソッドを試す: マンネリ化を防ぎ、新しい視点を得る
  • チームの状況に応じて選択:
    • 心理的安全性が低い → 象・死んだ魚・嘔吐
    • ポジティブな雰囲気を作りたい → Fun/Done/Learn
    • 活動量を調整したい → Starfish

状況に応じて使い分けることで、振り返りの質を保つ。

アクションの追跡

  • Tryの進捗確認を次回の冒頭で必ず行う: 前回決めたことを振り返る習慣をつける
  • できなかったものは「なぜできなかったか」を議論: 責めるのではなく、障害を取り除くことにフォーカス
  • 小さくても実行可能なアクションにする:
    • 「コミュニケーションを改善する」→ 「毎朝15分の雑談タイムを設ける」
    • 「ドキュメントを整備する」→ 「READMEに環境構築手順を追加する」

大きすぎる目標はやはり実行しづらいです。
1週間〜2週間で完了できるサイズに分解してから取りかかりましょう。

心理的安全性の醸成

  • 批判ではなく改善のための議論: 「誰が悪い」ではなく「どうすればよくなるか」
  • 失敗を責めない文化: 失敗を共有することが学びになると認識する
  • 本音を出しやすい仕組みを作る:
    • 必要に応じて匿名性のある手法を使う
    • 定期的に実施することで、溜め込まずに問題を吐き出せる

心理的安全性は一朝一夕では築けないです。
こういった場も使って、継続的な取り組みが必要になります。

まとめ

ふりかえりの目的をわすれないこと

  • 「やること」が目的ではない
  • 「チームが学び、継続的に改善し、チームの血肉にすること」が目的

振り返りは手段であり、目的はチームの成長と成果の向上です 形式に囚われず、本質を見失わないようにチームの改善をして価値提供をしていけると良いですね。

テテマーチでは、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！ herp.careers

エンジニアチームガイドはこちら！ tetemarche01.notion.site