プロジェクトの振り返りの進め方｜良かった点と次に直す点のまとめ方

2026年2月18日

＠SOHO編集部

この記事のポイント

✓プロジェクトの振り返りの進め方を
✓次の行動の決め方まで手順で説明します
✓Start・Stop・Continueなどの手法の使い分け

プロジェクトが終わったあと、「振り返りの会をやろう」と決めたものの、何から話せばよいのか分からず、反省の言葉が並ぶだけで終わってしまった、という経験はないでしょうか。振り返りがうまくいかない原因の多くは、話す中身ではなく、進め方にあります。目的を決めずに集まる、出来事を思い出す前に意見を出し合う、改善の案を決めても誰がいつやるのかを決めない、といった進め方では、次のプロジェクトで同じ失敗が繰り返されます。

この記事では、プロジェクトの振り返りの進め方を、目的の決め方、準備、当日の流れ、出来事の年表づくり、原因の掘り下げ、次の行動の決め方まで、順番に説明します。KPT、YWT、Start・Stop・Continueといった代表的な手法の使い分けと、誰もが本音を話しやすい場の作り方も整理します。決めた改善を次のプロジェクトで本当に実行するための記録の残し方として、議論と作業を同じ場所で追いかけられるPinatecaのような道具を使う方法にも触れます。

プロジェクトの振り返りとは何か

プロジェクトの振り返りとは、終わったプロジェクトや、区切りまで進んだプロジェクトについて、何がうまくいき、何がうまくいかなかったのかを関係者で確かめ、次に生かす改善を決める話し合いのことです。英語では「レトロスペクティブ」と呼ばれ、ソフトウェアの開発の現場から広まりましたが、イベントの運営、Webサイトの制作、営業の企画など、チームで進めるあらゆる仕事で使われています。

ソフトウェアの開発の進め方の1つであるスクラムの考え方をまとめた「スクラムガイド」では、振り返りにあたるスプリントレトロスペクティブについて、次のように説明しています。

スプリントレトロスペクティブの目的は、品質と効果を高める方法を計画することである。スクラムチームは、個人、相互作用、プロセス、ツール、完成の定義に関して、今回のスプリントがどのように進んだかを検査する。出典: scrumguides.org

スプリントとは、スクラムで使う、1か月以内の決まった長さの作業の区切りのことです。同じガイドでは、チームは自分たちの効果を改善するために最も役立つ変更を見つけ、影響の大きな改善はできるだけ早く取り組む、とも書かれています。振り返りの中心は、反省ではなく「次にどう変えるか」を決めることだと分かります。

振り返りと反省会の違い

振り返りと反省会は似ているようで、目的が違います。反省会は、うまくいかなかったことの原因と責任を確かめる場になりがちです。振り返りは、うまくいったことも、うまくいかなかったことも同じように取り上げ、次のプロジェクトで続けることと、変えることを決める場です。

比べる点	反省会	振り返り
見るもの	主に失敗	成功と失敗の両方
問いかけ	誰が悪かったのか	何が起きて、なぜそうなったのか
ゴール	謝罪と再発の防止の約束	次に試す具体的な行動
場の空気	緊張しやすい	率直に話しやすい

振り返りの場で個人を責める空気ができると、参加する人は失敗を隠すようになり、本当の原因が見えなくなります。「人ではなく、仕組みと進め方を見る」という前提を最初に共有しておくことが、振り返りを成功させるいちばんの近道です。

振り返りを行う時期

振り返りは、プロジェクトが終わったときだけに行うものではありません。行う時期によって、得られるものが変わります。

プロジェクトの終わりに行う

プロジェクトがすべて終わったときに行う振り返りは、最初から最後までの全体を見渡せるのが利点です。計画の立て方、関係者との調整、予算と期間の見積もりなど、プロジェクト全体に関わる学びを次のプロジェクトに持ち越せます。

ただし、期間の長いプロジェクトでは、最初のころの出来事を思い出すのが難しくなります。終わりからあまり時間を空けず、記憶が新しいうちに行うのが基本です。

区切りごとに行う

数か月にわたるプロジェクトなら、設計が終わったとき、最初の公開が終わったとき、といった区切りごとに短い振り返りを行う方法もあります。区切りごとに振り返ると、見つかった改善をそのプロジェクトの後半ですぐに試せます。スクラムでは、スプリントごとに振り返りを行い、1か月のスプリントなら振り返りは最大3時間、スプリントが短ければ時間も短くするのが一般的だとされています。

大きな問題が起きた直後に行う

納期に大きく遅れた、品質の問題で顧客に迷惑をかけた、といった大きな問題が起きたときは、プロジェクトの途中でも、その問題に絞った振り返りを行います。問題が落ち着いてから、関係者の記憶が新しいうちに行うのがポイントです。

振り返りの準備

振り返りの成否は、当日よりも準備で決まります。準備しておきたいことを整理します。

目的を1文で決める

最初に、この振り返りで何を得たいのかを1文で決めます。「次のWebサイトの制作で、確認の待ち時間を減らす方法を見つける」「新しく入ったメンバーが早く慣れる進め方を考える」のように、具体的であるほど、話し合いが散らばりません。目的は、振り返りの案内と一緒に参加者に伝えておきます。

参加者と進行役を決める

参加者は、プロジェクトに関わった人を中心に、多すぎない人数に絞ります。人数が多い場合は、小さなグループに分けて話し合い、最後に全体で共有する形にします。

進行役（ファシリテーター）は、話し合いの流れを整え、全員が話せるように気を配る役です。プロジェクトの責任者が進行役を兼ねると、ほかの人が意見を言いにくくなることがあるので、できればプロジェクトに深く関わっていない人に頼みます。

材料を集めておく

当日に一から思い出そうとすると、時間がかかるうえに、声の大きい人の記憶に話が引っ張られます。事前に、次のような材料を集めておきます。

最初の計画と、実際の日程の比較
作業の一覧と、それぞれの担当と終わった日
途中で起きた問題と、その対応の記録
関係者や顧客からの意見
予算の計画と、実際にかかった費用

作業の管理のツールやチャットに記録が残っていれば、それをそのまま材料にできます。

参加者に事前に書いてもらう

当日の前に、参加者に「良かったこと」「困ったこと」「次に試したいこと」を、それぞれ3つほど書いてきてもらうと、当日の話し合いの時間を大きく短くできます。事前に書いてもらうと、話すのが苦手な人の意見も拾いやすくなります。

振り返りの当日の流れ

当日は、次の6つの段階で進めると、話し合いが散らばらずに結論までたどり着けます。

段階	やること	時間の目安の割合
1. 場を整える	目的と決まりを確かめる	全体の1割
2. 出来事を思い出す	時系列の年表を作る	全体の2割
3. 気づきを出す	良かった点と困った点を書き出す	全体の2割
4. 原因を掘り下げる	似た気づきをまとめ、なぜ起きたかを考える	全体の2割
5. 次の行動を決める	試すことを選び、担当と期限を決める	全体の2割
6. 締めくくる	決めたことを確かめ、感謝を伝える	全体の1割

段階1：場を整える

最初に、振り返りの目的と、話し合いの決まりを確かめます。決まりの例は、「人を責めず、出来事と仕組みを見る」「どの意見も否定しない」「話した内容は、この場の改善のためだけに使う」の3つです。進行役が最初にこの決まりを読み上げるだけで、場の空気が和らぎます。

段階2：出来事を思い出す

次に、プロジェクトの始まりから終わりまでの出来事を、時系列で並べた年表を作ります。準備で集めた材料をもとに、「設計の確定」「顧客の確認」「仕様の変更」「公開」といった出来事を、日付の順に並べていきます。

年表を先に作るのは、全員が同じ事実を前提に話すためです。記憶だけで話し合うと、「あの遅れは確認が遅かったからだ」「いや、仕様が変わったからだ」と、人によって覚えていることが食い違います。事実を先に並べておけば、意見の違いは、事実の解釈の違いとして落ち着いて話し合えます。

振り返りの進め方を紹介した記事でも、年表を作る段階に時間がかかることが説明されています。

前提として上記振り返りの型を全員で順々に行うと、膨大な時間が必要になります。長期間になればなるほど、時系列年表の作成（＝思い出し）に時間がかかってしまうからです。出典: note.com

時間を短くするには、年表のたたき台を進行役が事前に作っておき、当日は参加者が足りない出来事を書き加える形にします。

段階3：気づきを出す

年表を見ながら、参加者それぞれが、良かった点と困った点を付箋やオンラインのホワイトボードに書き出します。1枚の付箋に1つの気づきを書くのが決まりです。書き出す時間を5分から10分ほど決めて、全員が黙って書く時間を作ると、声の大きい人の意見に引っ張られずに済みます。

書き出したら、1人ずつ、自分の付箋を年表の該当する場所に貼りながら、短く説明します。この段階では、ほかの人の意見に反論せず、出し切ることを優先します。

段階4：原因を掘り下げる

気づきが出そろったら、似た内容の付箋をまとめて、グループに分けます。「顧客の確認に時間がかかった」「確認の依頼の仕方が人によって違った」「確認の期限を決めていなかった」は、「確認の進め方」という1つのグループになります。

グループができたら、それぞれについて「なぜそうなったのか」を掘り下げます。よく使われるのが、「なぜ」を何度か繰り返す方法です。

顧客の確認に時間がかかった
なぜ：確認の依頼に、何をいつまでに見てほしいかが書いていなかった
なぜ：確認の依頼の決まった書き方がなかった
なぜ：プロジェクトの始めに、確認の進め方を決めていなかった

このように掘り下げると、「顧客が遅い」という表面の問題が、「始めに確認の進め方を決めていない」という、自分たちで変えられる原因にたどり着きます。原因は、個人の注意力ではなく、仕組みや進め方の中に見つけるようにします。

良かった点も同じように掘り下げます。「なぜうまくいったのか」が分かれば、次のプロジェクトでも意識して同じことを繰り返せます。

段階5：次の行動を決める

原因が見えたら、次のプロジェクトで試す行動を決めます。ここでの決まりは、次の3つです。

行動は2つか3つに絞る
「気をつける」ではなく、具体的な行動にする
それぞれに担当と期限を決める

「確認を早めにもらうよう気をつける」では、何をすればよいのかが分かりません。「確認の依頼のひな形を作り、何をいつまでに見てほしいかを必ず書く。担当は佐藤さん、次のプロジェクトの始めまでに」のように、誰が見ても実行できたかどうかを判断できる形にします。

改善の案がたくさん出た場合は、効果の大きさと、実行の手間の2つの軸で並べて、効果が大きく手間の少ないものから選びます。

段階6：締めくくる

最後に、決めた行動と担当と期限を全員で読み上げて確かめます。プロジェクトを一緒に進めた仲間への感謝を伝えて終わると、次のプロジェクトにも前向きな気持ちで入れます。振り返りの進め方そのものについて、「良かった点」「次に変えたい点」を短く聞いておくと、次の振り返りの改善にもつながります。

振り返りの代表的な手法

振り返りで気づきを出すときには、決まった問いかけの型を使うと進めやすくなります。代表的な手法と、向いている場面を整理します。

KPT（ケプト）

KPTは、Keep（続けること）、Problem（問題）、Try（試すこと）の3つの枠に分けて気づきを書き出す手法です。日本の職場で広く使われていて、3つの枠を書くだけで始められる手軽さが特徴です。

Keep：うまくいったので、次も続けること
Problem：うまくいかなかったこと、困ったこと
Try：次に試すこと（KeepとProblemをもとに考える）

KPTは、定期的に繰り返す振り返りに向いています。前回のTryを、次の振り返りでKeepかProblemとして確かめる、という形で、改善が続いているかを追いかけられます。

YWT

YWTは、やったこと（Y）、分かったこと（W）、次にやること（T）の頭文字を取った、日本で生まれた手法です。出来事を順に書き出してから学びを引き出す流れなので、個人の振り返りや、新しく入ったメンバーの学びの整理にも向いています。

Start・Stop・Continue

Start・Stop・Continueは、新しく始めること、やめること、続けることの3つに分けて考える手法です。「やめること」を正面から問いかけるのが特徴で、作業が増えすぎて忙しくなっているチームに向いています。改善というと何かを加えることばかりを考えがちですが、要らない会議や確認をやめることも、立派な改善です。

4L

4Lは、Liked（良かったこと）、Learned（学んだこと）、Lacked（足りなかったこと）、Longed for（欲しかったこと）の4つの問いで振り返る手法です。気持ちの面も含めて幅広く気づきを出せるので、長いプロジェクトの終わりの振り返りに向いています。

手法の選び方

手法	向いている場面
KPT	定期的に短く行う振り返り、初めての振り返り
YWT	個人の振り返り、学びの整理
Start・Stop・Continue	作業が増えすぎたチーム、進め方を大きく変えたいとき
4L	長いプロジェクトの終わり、気持ちの面も含めて振り返りたいとき

どの手法も、前の節で説明した「年表で事実をそろえる」「原因を掘り下げる」「具体的な行動を決める」という流れの中で使うものです。手法を変えるだけで振り返りが良くなるわけではないので、まずはKPTのような簡単な手法で流れに慣れ、慣れてきたら目的に合わせて手法を替えてみます。

小さな例で見る振り返りの流れ

ここまでの流れを、Webサイトの制作のプロジェクトを例に、KPTを使って追いかけてみます。期間は2か月、メンバーはディレクター、デザイナー、エンジニア、ライターの4人で、公開が予定より1週間遅れたとします。

まず年表を作ると、「構成の確定」「デザインの1回目の提出」「顧客の確認」「デザインの修正」「コーディング」「原稿の差し替え」「公開」という出来事が並びました。年表を見ると、顧客の確認に予定の倍の日数がかかり、そのあとに原稿の差し替えが2回入っていることが分かりました。

次に、KPTで気づきを書き出します。

Keep：毎週の短い打ち合わせで、作業の状況を全員が把握できていた
Keep：デザインとコーディングを並行して進め、時間を取り戻せた
Problem：顧客の確認に時間がかかった
Problem：原稿が後から差し替わり、コーディングをやり直した

Problemを掘り下げると、確認の依頼に期限と見てほしい点が書いておらず、原稿の締切もプロジェクトの始めに決めていなかったことが原因として浮かびました。そこで、Tryとして次の2つを決めました。

Try：確認の依頼のひな形を作り、期限と見てほしい点を必ず書く（担当：ディレクター、次のプロジェクトの始めまで）
Try：原稿の締切を、デザインの1回目の提出より前に設定する（担当：ディレクター、次の計画づくりのとき）

このように、事実を並べてから原因を掘り下げると、「顧客が遅い」「原稿が遅い」という表面の不満が、自分たちで変えられる行動に置き換わります。

誰もが本音を話せる場の作り方

振り返りで本当の原因にたどり着くには、参加者が失敗や困ったことを率直に話せる必要があります。そうした場を作るための工夫を整理します。

責任を問う場にしない

前の節でも触れたとおり、振り返りは誰かを責める場ではありません。進行役は、「誰がやったのか」という問いかけが出たら、「何が起きて、なぜそうなったのか」という問いかけに言い換えます。プロジェクトの責任者が、自分の判断で困らせたことを先に話すと、ほかの人も話しやすくなります。

書く時間と話す時間を分ける

話すのが得意な人と苦手な人が混ざると、話し合いは得意な人の意見で埋まりがちです。全員が黙って付箋に書く時間を先に作り、そのあとで1人ずつ説明する形にすると、全員の意見が同じ重さで並びます。

オンラインで行うときの工夫

オンラインで振り返りを行う場合は、全員が同時に書き込めるホワイトボードや共同で編集できる文書を使います。カメラをつけるかどうかは参加者に任せ、書き込みと声の両方で参加できるようにします。画面越しだと発言のきっかけがつかみにくいので、進行役が順番に名前を呼んで意見を聞くと、話しやすくなります。

決めた改善を次に生かす

振り返りでいちばん多い失敗は、改善の行動を決めたのに、次のプロジェクトで誰も覚えていない、というものです。決めたことを実行につなげるための工夫を整理します。

記録を残す場所を決める

振り返りの記録は、年表、気づき、原因、決めた行動を1つの文書にまとめ、次のプロジェクトのメンバーも見られる場所に保存します。プロジェクトごとにばらばらの場所に保存すると、次のプロジェクトの始まりに過去の学びを探せません。

決めた行動を作業として登録する

決めた行動は、話し合いの記録に書くだけでなく、ほかの作業と同じように、担当と期限を付けて作業の一覧に登録します。そうすることで、日々の作業の中で行動が目に入り、期限が近づけば気づけます。

次のプロジェクトの始めに読み返す

次のプロジェクトを始めるときに、前回の振り返りの記録を全員で読み返す時間を取ります。前回決めた行動が、今回の計画に入っているかを確かめるだけでも、同じ失敗の繰り返しはかなり減ります。

議論と作業を同じ場所で追いかける

振り返りの記録と、決めた行動の作業が別々の場所にあると、「なぜこの行動を決めたのか」が分からなくなりがちです。議論の流れと作業を同じ場所で追いかけたい場合の選択肢の1つが、Pinatecaです。

公式の使い方ガイドによると、Pinatecaのディスカッションのボードは、決めごとや確認事項を1件1スレッドで進めるボードで、話した流れがそのまま記録として残るので、「なぜそう決めたか」を後から辿れます。グリッドのボードでは、縦と横の軸を自分で決めてカードを並べられ、「効果×手間」で優先順位を決める使い方ができると紹介されています。振り返りで出た改善の案をカードにしてグリッドのボードに並べ、効果が大きく手間の少ないものを選び、選んだものをカンバンのボードに移して担当と期限を付ける、という流れで使えます。カードには担当と締切を付けられ、ワークスペースごとのチャットやカードごとのコメントもあります。

料金は、5人までのチームならボード10個まで無料で、6人目または11個目のボードからはスタンダードプラン（1人あたり月額500円・税抜、年払いなら1人あたり月額400円）になると案内されています。

Pinatecaは、@SOHOを運営する株式会社ライフスケープが開発・提供しています。

振り返りの記録のひな形

振り返りの記録は、毎回同じ形で残しておくと、過去のプロジェクトと比べやすくなります。記録に入れておきたい項目を、ひな形として示します。

プロジェクトの名前と期間、参加者
振り返りの目的（1文）
計画と実績の比較（日程、予算、作業の量）
出来事の年表（主な出来事を日付の順に）
良かった点と、その理由
困った点と、掘り下げた原因
次に試す行動（行動の中身、担当、期限）
前回の振り返りで決めた行動の結果
振り返りの進め方そのものへの意見

8つ目の「前回の行動の結果」は、特に大切な項目です。前回決めたことが実行されたのか、実行して効果があったのかを毎回書いておくと、改善が積み重なっているかどうかが一目で分かります。記録は長く書きすぎず、次のプロジェクトのメンバーが10分ほどで読める分量にとどめます。

少人数のチームや、1人で働く人の振り返り

振り返りは、大きなチームだけのものではありません。2人から3人の小さなチームや、1人で仕事を受けるフリーランスにも役立ちます。

少人数のチームの場合

少人数のチームでは、進行役を立てるほどの規模ではないことが多いので、順番に進行役を回す形にします。年表のたたき台を作る、気づきを書き出す、行動を決める、という流れは同じです。人数が少ない分、30分ほどの短い時間でも十分に行えます。プロジェクトの終わりだけでなく、月に1回など決まった日に行う習慣にすると、小さな改善を積み重ねやすくなります。

1人で働く人の場合

1人で仕事を受けるフリーランスは、案件が終わるたびに、自分だけで短い振り返りを行うと、次の案件の進め方が少しずつ良くなります。使いやすいのは、YWTの形です。この案件でやったこと、分かったこと、次にやることを、それぞれ3行ほど書き残します。

たとえば、「見積もりより作業の時間が2割多くかかった」という事実が出てきたら、なぜ多くかかったのかを掘り下げます。「修正の回数を最初に決めていなかった」と分かれば、次の見積もりでは修正の回数を書き添える、という行動につながります。1人の振り返りでも、事実、原因、行動の順で考えることが大切です。

顧客や外部の協力者を交えた振り返り

顧客や外部の協力者と一緒にプロジェクトを進めた場合は、相手を交えた振り返りを行うと、自分たちだけでは見えない改善が見つかります。

相手を交える場合は、時間を短くし、話す内容を絞ります。「次も一緒に仕事をするとしたら、何を変えるとやりやすくなるか」という1つの問いかけに絞ると、相手も答えやすくなります。社内の課題や、相手に聞かせる必要のない話は、相手を交えない振り返りで別に扱います。

相手からの意見は、その場で言い訳をせずに、まずは書き留めます。意見への対応は、社内で話し合ったうえで、後日まとめて伝えるようにすると、相手も率直に話してくれるようになります。

振り返りでよくある失敗と対処

振り返りを続けていると、決まった失敗に出合います。よくある失敗と対処を整理します。

毎回同じ問題が出てくる

振り返りのたびに同じ問題が出てくる場合は、決めた行動が実行されていないか、行動が原因に届いていないかのどちらかです。前回の行動が実行されたかを確かめ、実行されていなければ、なぜ実行できなかったのかを掘り下げます。実行したのに問題が続くなら、原因の掘り下げが浅かった可能性があります。

良かった点が出てこない

困ったことばかりが出て、良かった点が出てこない場合は、場の空気が反省会に寄っています。最初に良かった点だけを書く時間を作る、進行役が年表の中のうまくいった出来事を指さして問いかける、といった工夫で、良かった点にも目を向けます。

時間が足りなくなる

話し合いが盛り上がって、次の行動を決める前に時間切れになることもよくあります。段階ごとの時間を最初に決めて、進行役が時間を知らせながら進めます。原因の掘り下げは、すべてのグループで行おうとせず、目的に関係の深いグループに絞ります。

参加者が振り返りに飽きてしまう

毎回同じ手法、同じ流れで振り返りを続けていると、参加者が慣れてしまい、決まりきった意見しか出なくなることがあります。そうしたときは、手法をKPTからStart・Stop・Continueに替える、進行役を交代する、振り返りの目的を「今回は打ち合わせの進め方だけを見る」のように狭くする、といった変化を加えると、新しい気づきが出やすくなります。

振り返りを進める力が生きる在宅の仕事

プロジェクトの振り返りを進め、改善を形にする力は、在宅の仕事でもそのまま評価されます。

業務の進め方の見直しを外部の専門家に頼みたい会社は多く、振り返りの進行役を務めたり、改善の案をまとめたりする仕事があります。生成AIを含めた業務の改善を手伝う仕事の内容は、AIコンサル・業務活用支援のお仕事で紹介しています。ソフトウェアの開発の現場では、振り返りは日常の一部です。開発の仕事の内容は、アプリケーション開発のお仕事で確かめられます。

長く見てきた立場から見た、振り返りを続けるチームの共通点

@SOHOは2004年から在宅ワークとフリーランスの仲介を続けてきました。その中で見えてきたのは、外部のフリーランスと長く良い関係を続けている発注の側のチームほど、プロジェクトの終わりに、外部のメンバーも交えて短い振り返りを行っているという傾向です。

外部のフリーランスは、社内の人が当たり前だと思っている進め方の無駄に気づきやすい立場にいます。振り返りの場で「確認の依頼がまとめて届くと助かる」「仕様の変更は理由と一緒に伝えてもらえると対応しやすい」といった声を拾えるチームは、次のプロジェクトでの手戻りが減り、同じフリーランスに続けて頼める関係を築いています。

発注する人と受ける人が直接やり取りできる形なら、こうした振り返りも、間に人を挟まずに率直に行えます。仲介の手数料が乗らない手数料0%のやり取りであれば、発注する側は同じ予算で振り返りの時間まで含めた依頼をしやすく、受ける側の手取りも厚くなります。デザインの仕事のように確認と修正の行き来が多い分野の相場は、デザイナーの年収・単価相場でも確かめられます。

よくある質問

Q. プロジェクトの振り返りはどのくらいの時間で行えばよいですか？

プロジェクトの長さと参加者の人数で変わります。スクラムガイドでは、1か月の区切りの振り返りは最大3時間で、区切りが短ければ時間も短くするのが一般的とされています。長いプロジェクトの終わりに行う場合は、年表のたたき台を事前に作り、参加者に気づきを書いてきてもらうと、当日の時間を短くできます。

Q. KPTとYWTはどう使い分ければよいですか？

KPTは、続けること、問題、試すことの3つに分けて書き出す手法で、チームで定期的に行う振り返りに向いています。YWTは、やったこと、分かったこと、次にやることの順で考える手法で、個人の振り返りや学びの整理に向いています。どちらも、事実をそろえてから原因を掘り下げ、具体的な行動を決める流れの中で使います。