仕事やプロジェクトを進めていると、「同じ失敗を何度も繰り返している」「うまくいったことが次に活かされていない」「会議では反省するが、具体的な改善につながらない」と感じることがあります。
プロジェクトでは、計画を立てて実行するだけでは十分ではありません。実行した結果を振り返り、何がうまくいったのか、何がうまくいかなかったのか、次に何を変えるのかを整理することが重要です。
そこで役立つのが、レトロスペクティブです。
レトロスペクティブは、仕事やプロジェクトの進め方を振り返り、次の改善につなげるためのフレームワークです。Scrumやアジャイルでよく使われる言葉ですが、考え方自体は、IT開発だけでなく、社内研修、営業活動、業務改善、イベント運営、資料作成、チーム運営など幅広い仕事に応用できます。
日本語では「振り返り」と表現されることが多いですが、単なる反省会とは違います。レトロスペクティブでは、誰かを責めるのではなく、チームの仕事の進め方をより良くするために、事実、学び、改善アクションを整理します。
初心者にとっては、まず「レトロスペクティブは、次の仕事をより良くするための振り返りの型」と理解すれば十分です。
この記事でわかること
・レトロスペクティブとは何か
・レトロスペクティブは何に使うのか
・レトロスペクティブの基本的な考え方
・レトロスペクティブの使い方
・レトロスペクティブの具体例
・関連フレームワークとの違い
最初から完璧に使いこなす必要はありません。まずは「レトロスペクティブは、チームの仕事を振り返り、次の改善を決めるための型だ」とつかめれば十分です。
レトロスペクティブとは？
レトロスペクティブとは、一定期間の仕事やプロジェクトを振り返り、次に改善することを決めるためのフレームワークです。
英語のRetrospectiveには、「回顧」「振り返り」という意味があります。Scrumでは、Sprintの最後に行う振り返りの場としてSprint Retrospectiveが位置づけられています。
レトロスペクティブでは、主に次のようなことを話し合います。
・うまくいったこと
・うまくいかなかったこと
・困ったこと
・続けたいこと
・やめたいこと
・次に試したいこと
・改善すべきこと
たとえば、社内研修プロジェクトが終わった後に、「受講者募集はスムーズだった」「教材レビューに時間がかかりすぎた」「アンケート設計が遅れた」「次回はレビュー期限を前倒しする」といった内容を整理します。
初心者向けに言い換えるなら、レトロスペクティブは「仕事が終わった後に、よかった点と改善点を整理し、次にやることを決める振り返り」です。
一言でいうと、レトロスペクティブはチームの仕事の進め方を改善するためのフレームワークです。
レトロスペクティブは何に使うのか
レトロスペクティブは、チームやプロジェクトの改善に使います。
仕事では、毎回完璧に進むことはありません。スケジュールが遅れたり、確認漏れがあったり、コミュニケーション不足が起きたり、逆に非常にうまくいった工夫があったりします。
それらを振り返らずに次の仕事へ進むと、同じ失敗を繰り返したり、せっかくの成功パターンを再現できなかったりします。
レトロスペクティブは次のような目的で使われます。
・チームの仕事の進め方を改善する
・同じ失敗を繰り返さないようにする
・うまくいった工夫を次回も活かす
・メンバーの困りごとを共有する
・コミュニケーションの問題を見つける
・次に試す改善アクションを決める
・チームの学習を習慣化する
・プロジェクト終了後の知見を蓄積する
たとえば、毎回プロジェクトの終盤にレビューが集中するチームなら、レトロスペクティブで「なぜレビューが終盤に集中するのか」を振り返ります。その結果、「レビュー担当者を早めに決める」「中間レビュー日を設定する」「Definition of Doneにレビュー完了を入れる」といった改善策を決められます。
レトロスペクティブは、過去を責めるための場ではありません。次を良くするための学習の場です。
どんな人に向いているか
レトロスペクティブは、チームで仕事を進めている人に向いています。
特に、次のような人におすすめです。
・プロジェクトの振り返りを行いたい人
・チームの改善を習慣化したい人
・同じ問題が繰り返し起きている人
・アジャイルやScrumを実践している人
・会議や業務の進め方を改善したい人
・チームメンバーの困りごとを把握したい人
・プロジェクト終了後の学びを次に活かしたい人
・管理職やリーダーとしてチームの成長を支援したい人
レトロスペクティブは、開発チームだけでなく、営業チーム、マーケティングチーム、人事部門、知的財産部門、教育担当、業務改善チーム、プロジェクト事務局などにも使えます。
たとえば、社内研修を実施した後、展示会が終わった後、営業キャンペーンが終わった後、Webサイト制作が一区切りした後、月次業務が終わった後などに使えます。
「次回はもっと良くしたい」「会議で反省はするが行動につながっていない」と感じるチームには、レトロスペクティブが役立ちます。
レトロスペクティブの基本的な考え方
レトロスペクティブの基本は、チームの仕事の進め方を客観的に振り返り、次の改善アクションを決めることです。
ここで重要なのは、成果物そのものだけでなく、プロセスを振り返ることです。
たとえば、プロジェクトの成果物として研修教材が完成したとします。成果物の内容がよかったかどうかを見るだけでなく、教材作成の進め方、レビューのタイミング、役割分担、コミュニケーション、スケジュール管理などを振り返ります。
レトロスペクティブで大切な考え方は、次の通りです。
・人を責めず、プロセスを見る
・事実をもとに話す
・うまくいったことも扱う
・改善点を具体的な行動にする
・小さく試せる改善から始める
・次回に活かすことを明確にする
・全員が発言しやすい場にする
特に大切なのは、心理的安全性です。
レトロスペクティブで発言した人が責められたり、否定されたりすると、次から本音が出なくなります。そうなると、振り返りは形式だけになります。
「なぜ失敗したのか」を個人攻撃として扱うのではなく、「どの仕組みや進め方を変えれば、次はうまくいくか」と考えることが重要です。
また、改善アクションは小さく具体的にすることが大切です。「もっと早めに確認する」では曖昧です。「次回は初回レビュー日を作成開始から3日後に設定する」のように、具体的にすると行動につながります。
レトロスペクティブの使い方
手順1 振り返る対象を決める
最初に、何について振り返るのかを決めます。
レトロスペクティブは、対象が曖昧だと話が広がりすぎます。プロジェクト全体を振り返るのか、直近1週間を振り返るのか、特定のイベントを振り返るのかを明確にします。
振り返り対象の例は次の通りです。
・1つのSprint
・1か月のチーム活動
・社内研修の実施
・展示会出展
・Webサイト制作プロジェクト
・営業キャンペーン
・業務改善プロジェクト
・新商品発売準備
・定例会議の運営
・外部ベンダーとの共同作業
たとえば、社内研修を実施した後なら、「今回の研修企画から実施、アンケート回収まで」を対象にします。
対象期間や範囲を明確にすることで、参加者が具体的な出来事を思い出しやすくなります。
手順2 事実を集める
次に、振り返りの材料となる事実を集めます。
いきなり感想を話し始めると、印象に引っ張られやすくなります。まずは、何が起きたのか、どんな結果だったのかを整理します。
集める事実の例は次の通りです。
・予定と実績の差
・納期遅れの有無
・成果物の完成状況
・発生した課題
・関係者からのフィードバック
・アンケート結果
・問い合わせ件数
・レビュー指摘件数
・会議回数
・作業時間や工数
・うまくいった具体的な出来事
たとえば、研修後のレトロスペクティブなら、受講者数、満足度、理解度テストの結果、アンケートコメント、当日のトラブル、準備スケジュールなどを確認します。
事実をもとに振り返ることで、「何となく大変だった」「何となく良かった」ではなく、具体的な改善につなげやすくなります。
手順3 うまくいったことを整理する
次に、うまくいったことを整理します。
レトロスペクティブでは、問題点だけでなく、良かった点も必ず扱います。うまくいったことを見つけることで、次回も再現しやすくなるからです。
確認したい問いは次の通りです。
・今回うまくいったことは何か
・なぜうまくいったのか
・次回も続けたいことは何か
・チームとして良かった行動は何か
・関係者から評価された点は何か
・予想以上に効果があった工夫は何か
たとえば、社内研修であれば、「事前案内を早めに出したことで参加率が高かった」「演習を入れたことで理解度が上がった」「FAQを用意したことで問い合わせが減った」といった良かった点があります。
うまくいったことを言語化すると、チームの成功パターンになります。
改善というと悪い点ばかりに目が向きがちですが、良い点を継続することも重要な改善です。
手順4 改善したいことを整理する
次に、改善したいことを整理します。
ここでは、問題、困りごと、手戻り、遅れ、認識ズレなどを扱います。
ただし、個人を責める言い方は避けます。「Aさんが遅かった」ではなく、「レビュー担当が1人に集中し、確認が遅れた」のように、仕組みやプロセスとして捉えます。
確認したい問いは次の通りです。
・何がうまくいかなかったか
・どこで作業が止まったか
・何が手戻りの原因になったか
・情報共有は十分だったか
・役割分担は明確だったか
・スケジュールに無理はなかったか
・次回避けたいことは何か
たとえば、Webサイト制作であれば、「原稿確認が遅れた」「デザイン修正の判断者が曖昧だった」「公開前チェックリストがなかった」「スマートフォン表示確認が後回しになった」といった改善点が出るかもしれません。
改善点は、できるだけ具体的に書き出します。曖昧なままだと、次のアクションにつながりません。
手順5 次に試すアクションを決める
最後に、次に試す改善アクションを決めます。
レトロスペクティブで最も重要なのは、話し合いで終わらせないことです。改善点を出しただけでは、次の仕事は変わりません。
改善アクションは、具体的で実行可能なものにします。
悪い例は、次のようなものです。
・もっと早く動く
・しっかり確認する
・情報共有を強化する
・全員で気をつける
これらは方向性としては正しいですが、行動が曖昧です。
良い例は、次のようなものです。
・次回は初回レビュー日を作成開始から3営業日後に設定する
・公開前チェックリストを作成し、担当者が確認してからレビューに出す
・毎週金曜にKanbanボードを見ながら詰まりを確認する
・研修資料のDefinition of Doneを作成する
・外部ベンダーとの定例会議で未解決課題をRAIDログに記録する
改善アクションは、多すぎない方がよいです。たくさん決めても実行されなければ意味がありません。まずは1〜3個に絞り、次回実際に試すことが大切です。
レトロスペクティブの具体例
例 社内研修を実施した場合
社内研修を実施した後に、レトロスペクティブを行う例を考えてみます。
まず、事実を整理します。
・受講者は80名だった
・受講後アンケートの満足度は平均4.2点だった
・理解度テストの平均点は75点だった
・教材レビューが予定より3日遅れた
・当日の質疑応答が予定時間を超えた
・受講案内メールへの問い合わせが多かった
次に、うまくいったことを整理します。
・事前案内を早めに出したため参加率が高かった
・実務例を入れたことで受講者の反応が良かった
・確認テストにより理解度を把握できた
・講師と運営担当の役割分担が明確だった
次に、改善したいことを整理します。
・教材レビューが遅れ、最終修正が直前になった
・受講案内に必要情報が不足していた
・質疑応答の時間が不足した
・アンケート設問がやや抽象的だった
最後に、次回アクションを決めます。
・教材レビュー日は実施日の2週間前に固定する
・受講案内メールにFAQを追加する
・質疑応答を最後ではなく途中にも入れる
・アンケートに「実務で使えそうな場面」を聞く設問を追加する
このようにレトロスペクティブを行うと、単なる反省ではなく、次回の研修改善につながります。
別の例 Webサイト改善プロジェクトの場合
Webサイト改善プロジェクトの後に、レトロスペクティブを行う例です。
まず、事実を整理します。
・トップページの改修は予定通り完了した
・問い合わせフォームの改善は1週間遅れた
・スマートフォン表示の不具合が公開直前に見つかった
・関係部署レビューで修正依頼が多かった
・公開後の問い合わせ数は前月比で増加した
うまくいったことは、次のようなものです。
・CTAの改善により問い合わせボタンのクリック率が上がった
・アクセス解析を見ながら改善箇所を決められた
・関係者への進捗共有は週1回できていた
・公開後の効果測定をすぐに始められた
改善したいことは、次のようなものです。
・公開前チェックリストがなく、表示確認が後手に回った
・レビュー依頼時に確認観点が明確でなかった
・フォーム改善の仕様が途中で変わった
・スマートフォン表示確認の担当者が決まっていなかった
次回アクションは、次のように設定できます。
・公開前チェックリストを作成する
・レビュー依頼時に確認観点を3つに絞って伝える
・フォーム仕様は作業開始前にProduct Ownerが承認する
・スマートフォン表示確認をDefinition of Doneに追加する
このように、レトロスペクティブはプロジェクトの実行結果を次の改善に変えるために使えます。
具体例でわかるポイント
レトロスペクティブの具体例からわかるポイントは、次の通りです。
・事実をもとに振り返ると改善点が明確になる
・うまくいったことも次回に活かす
・問題点は個人ではなくプロセスとして捉える
・改善アクションは具体的にする
・アクションは少数に絞ると実行しやすい
・振り返りを習慣化するとチームの学習が進む
レトロスペクティブは、失敗を責める場ではありません。チームが継続的に良くなるための仕組みです。
レトロスペクティブを使うメリット
レトロスペクティブを使う最大のメリットは、経験を次の改善につなげられることです。
仕事では、毎回さまざまな学びがあります。しかし、忙しいと振り返る時間が取れず、次の仕事でも同じ問題が起きてしまいます。
レトロスペクティブを使うメリットは次の通りです。
・同じ失敗を繰り返しにくくなる
・うまくいった工夫を再現しやすくなる
・チームの課題を早めに見つけられる
・メンバーの困りごとを共有できる
・具体的な改善アクションを決められる
・チームの学習が進む
・コミュニケーションが改善される
・業務改善が継続しやすくなる
・プロジェクト終了後の知見を蓄積できる
特に実務で大きいのは、改善を習慣化できることです。
一度大きな反省会を開くだけでは、仕事の進め方はなかなか変わりません。短い周期で振り返り、小さな改善を繰り返すことで、チームの働き方が少しずつ良くなります。
また、レトロスペクティブはチームの心理的安全性を高めるきっかけにもなります。困っていることや改善したいことを話せる場があると、問題が大きくなる前に共有しやすくなります。
レトロスペクティブを使うときの注意点
レトロスペクティブは有効ですが、運用を間違えると単なる反省会や愚痴の場になってしまいます。
よくある失敗例は次の通りです。
・個人を責める場になってしまう
・愚痴だけで終わる
・改善アクションが決まらない
・アクションが抽象的すぎる
・毎回同じ話をしている
・参加者が本音を言えない
・上司の意見だけで結論が決まる
・良かったことを扱わない
・決めたアクションを次回確認しない
・会議を開くこと自体が目的になる
特に注意したいのは、改善アクションを決めた後のフォローです。
レトロスペクティブで「次回は早めにレビューする」と決めても、次回本当に実行されたか確認しなければ、改善は定着しません。次のレトロスペクティブでは、前回決めたアクションが実行されたかを確認することが大切です。
また、レトロスペクティブでは、発言しやすい雰囲気を作ることが重要です。上司やリーダーがすぐに否定したり、犯人探しを始めたりすると、メンバーは本音を言わなくなります。
「何が悪かったか」ではなく、「次にどうすれば良くなるか」に焦点を当てることが重要です。
関連フレームワークとの違い
レトロスペクティブと似た場面で使われるフレームワークはいくつかあります。それぞれの違いを理解しておくと、振り返りや改善活動で使い分けしやすくなります。
Scrumとの違い
Scrumは、Product Backlog、Sprint、Sprint Review、Retrospectiveなどを使って、短いサイクルで成果物を作るフレームワークです。
レトロスペクティブは、Scrumの中でチームの進め方を振り返るイベントとして使われます。
Scrumが全体の進行フレームワークだとすれば、レトロスペクティブはその中で「次のSprintをより良くするための振り返り」です。
Scrumは仕事の進め方全体、レトロスペクティブは改善のための振り返りに強いフレームワークです。
Sprint Reviewとの違い
Sprint Reviewは、Sprintで作った成果物を関係者に見せ、フィードバックを得る場です。
一方、レトロスペクティブは、チームの仕事の進め方を振り返る場です。
つまり、Sprint Reviewは「作ったもの」を確認する場、レトロスペクティブは「作り方や進め方」を改善する場です。
たとえば、Webページを作った場合、Sprint Reviewではページの内容や使いやすさを確認します。レトロスペクティブでは、作成プロセス、レビュー手順、チーム内連携を振り返ります。
KPTとの違い
KPTは、Keep、Problem、Tryの3つで振り返るフレームワークです。
Keepは続けたいこと、Problemは問題だったこと、Tryは次に試すことです。
レトロスペクティブは振り返り全般を指す広い考え方であり、KPTはその中で使える具体的な手法の一つです。
初心者がレトロスペクティブを始める場合、KPTを使うと分かりやすく進められます。
PDCAとの違い
PDCAは、Plan、Do、Check、Actionの流れで業務改善を進めるフレームワークです。
レトロスペクティブは、PDCAでいうCheckとActionに近い役割を持ちます。実行した結果を振り返り、次の改善アクションを決めるからです。
ただし、レトロスペクティブは特にチームの対話や仕事の進め方の改善に重点があります。
PDCAは改善サイクル全体、レトロスペクティブは振り返りと次の改善アクションに強いフレームワークです。
RAIDログとの違い
RAIDログは、リスク、前提、課題、依存関係を管理するためのフレームワークです。
レトロスペクティブは、一定期間の仕事を振り返り、改善点を見つけるために使います。
たとえば、レトロスペクティブで「外部ベンダーからの回答待ちが多かった」と分かった場合、次回プロジェクトではそれをRAIDログの依存関係やリスクとして管理できます。
RAIDログは進行中の管理、レトロスペクティブは振り返りと学習に向いています。
レトロスペクティブはどんな場面で使うと効果的か
レトロスペクティブは、チームで仕事を進め、次回改善したい場面で効果を発揮します。
逆に、単発で終わり、同じような仕事が繰り返されない場合は、本格的なレトロスペクティブを行う必要は少ないかもしれません。ただし、大きな学びがある場合は、短時間でも振り返る価値があります。
レトロスペクティブが効果的な場面は次の通りです。
・ScrumのSprint終了時
・プロジェクト終了後
・社内研修の実施後
・展示会やイベント後
・営業キャンペーン後
・Webサイト制作や公開後
・業務改善施策の実施後
・月次業務の終了後
・チーム定例の見直し
・外部ベンダーとの共同作業後
・新商品発売準備の節目
・問い合わせ対応業務の改善
特に、「同じ問題が繰り返される」「改善点が分かっているのに実行されない」「チーム内の認識ズレが多い」という場合、レトロスペクティブを定期的に行う効果が大きくなります。
また、良かった点を言語化することで、チームの成功パターンを共有できます。振り返りは、失敗を探すだけではなく、強みを再現するためにも使えます。
まとめ
レトロスペクティブは、仕事やプロジェクトを振り返り、次の改善アクションを決めるためのフレームワークです。
単なる反省会ではなく、うまくいったこと、困ったこと、改善したいことを整理し、次に何を変えるかを具体的に決める場です。Scrumやアジャイルでよく使われますが、社内研修、営業活動、Web制作、業務改善、イベント運営など、幅広い仕事に応用できます。
レトロスペクティブで重要なのは、人を責めず、プロセスを改善することです。事実をもとに振り返り、次に試す小さなアクションを決めることで、チームの仕事の進め方は少しずつ良くなります。
ただし、振り返りだけで終わると意味がありません。決めた改善アクションを次回実行し、その結果をまた振り返ることで、継続的な改善につながります。
まずは、直近の仕事について「うまくいったこと」「改善したいこと」「次に試すこと」をそれぞれ3つずつ書き出してみましょう。
次に読みたい関連記事
まず全体像を見たい方へ
仕事で使えるフレームワーク一覧｜初心者向けに意味・種類・使い方をわかりやすく解説
あわせて読みたい関連記事
Scrumとは？初心者向けに意味・使い方・具体例をやさしく解説
Definition of Doneとは？初心者向けに意味・使い方・具体例をやさしく解説
PDCAとは？初心者向けに意味・使い方・具体例をやさしく解説
目的別にまとめて読みたい方へ
プロジェクト管理で使えるフレームワークまとめ｜初心者向けに種類・使い分け・活用例を解説
