プロジェクトの振り返りシート｜次に活かす書き方

プロジェクトが終わったあと、振り返りシートを作るように言われたものの、何を書けばよいのか分からず手が止まっている人は多いはずです。 プロジェクト振り返りシートは、反省文を書くための紙ではなく、次のプロジェクトで同じ失敗を繰り返さず、うまくいったやり方を再現するための記録です。 この記事では、シートに入れる項目、そのまま使える記入例、KPTやYWTなどのフレームワークの選び方、振り返り会の進め方、決めた改善策を実行まで追う方法までを順に説明します。 シートそのものはExcelやGoogleスプレッドシートで作れますが、決まった改善策を担当と期限付きで追いかけるなら、Pinateca のようなタスク管理の道具に移す方法もあります。

プロジェクトの振り返りシートが求められる背景

振り返りが重視されるようになった理由の1つは、仕事の進め方そのものが変わったことです。 以前は、半年や1年かけて作り切ってから納品する進め方が主流でした。 現在は、1〜4週間ほどの短い区切りで作っては確かめる進め方が広がり、区切りごとに「次はどう進めるか」を決め直す場面が増えています。

ソフトウェア開発の進め方を示したアジャイル宣言にも、振り返りを定期的に行うことが原則の1つとして書かれています。

チームがもっと効率を高めることができるかを定期的に振り返り、 それに基づいて自分たちのやり方を最適に調整します。 出典: agilemanifesto.org

もう1つの理由は、チームの形が変わったことです。 社員だけでなく、業務委託のエンジニアやデザイナー、在宅のメンバーが加わるプロジェクトが当たり前になりました。 同じ部屋で働いていれば、終わったあとの雑談で「あそこは危なかったね」と共有できましたが、離れて働くメンバーとはそうはいきません。 口頭の反省会だけでは、話した内容が記録に残らず、次のプロジェクトのメンバーに引き継がれないのです。

振り返りシートは、こうした「話したけれど残らなかった学び」を文字にして残すための道具です。 次のプロジェクトの立ち上げのときに、前回のシートを開いて「見積もりが甘くなりやすいのはどの工程か」「確認に時間がかかったのは誰とのやり取りか」を確かめるだけで、計画の精度は大きく変わります。 逆に言えば、書いたあとに誰も読み返さないシートは、作る手間だけがかかって効果が出ません。 この記事では、読み返される前提でのシートの作り方を説明します。

振り返りシートに入れる基本の項目

振り返りシートの項目は、会社やチームによって呼び方が違いますが、中身はおおむね次の7つに整理できます。 最初からすべてを細かく埋める必要はありませんが、この7つが揃っていれば、あとから読んだ人が状況を理解できます。

項目	書く内容	書くときの目安
基本情報	プロジェクト名、期間、メンバー、目的	1〜3行。後から検索できる名前にする
目標と結果	最初に決めた目標と、実際の結果	数字で比べられる形にする
良かったこと	続けたいやり方、うまくいった判断	理由も一緒に書く
問題だったこと	遅れ、手戻り、認識のずれ	人ではなく出来事として書く
原因	問題が起きた理由	1つの問題に1〜3個
次に試すこと	改善策、新しく始めること	動詞で終わる形にする
担当と期限	次に試すことを誰がいつまでに行うか	担当は1人、期限は日付で

この中で、多くのシートで抜けやすいのが「目標と結果」と「担当と期限」です。 目標と結果が書かれていないと、良かったことと問題だったことが感想の言い合いになり、何が成功で何が失敗なのかの基準がぶれます。 たとえば「納期に間に合った」は良かったことに見えますが、最初の計画より作業時間が40%多くかかっていたなら、見積もりの面では問題があったことになります。

担当と期限が抜けると、改善策は「次は気をつける」という決意表明で終わります。 振り返り会で「確認の手順を決めよう」と話がまとまっても、誰がいつまでに手順を書くのかが決まっていなければ、次のプロジェクトが始まるころには忘れられています。 次に試すことの欄には、必ず担当者の名前と日付を書く欄を並べておきましょう。

項目の数は、チームの規模で調整します。 3人ほどの小さなプロジェクトなら、良かったこと、問題だったこと、次に試すことの3つだけでも十分に機能します。 10人を超えるプロジェクトや、社外の関係者が多いプロジェクトでは、工程ごと、または関係者ごとに欄を分けると、話が混ざらずに済みます。

そのまま使える振り返りシートの記入例

項目だけ見ても書き方のイメージがわきにくいので、ある会社のWebサイトのリニューアルを例に、記入例を示します。 社員2人と、業務委託のデザイナー1人、エンジニア1人の4人で進めたプロジェクトという想定です。

基本情報

• プロジェクト名：コーポレートサイトのリニューアル
• 期間：2026年6月1日から8月29日まで（13週間）
• メンバー：企画担当（社員）、営業担当（社員）、デザイナー（業務委託）、エンジニア（業務委託）
• 目的：問い合わせフォームまでの導線を短くし、問い合わせ件数を伸ばす

目標と結果

• 公開日：目標8月22日、結果8月29日（1週間の遅れ）
• 作業時間：見積もり320時間、実績410時間
• 公開後1か月の問い合わせ件数：目標は前年同月の1.3倍、結果は1.4倍

良かったこと

• 最初の2週間で、営業担当に過去の問い合わせ内容を聞き取ったことで、トップページの構成がすぐに固まった
• デザインの確認を毎週金曜日の30分に決めたことで、確認待ちの時間が短くなった

問題だったこと

• 原稿の提出が予定より2週間遅れ、エンジニアの作業が後ろに詰まった
• スマートフォンでの表示の確認を公開直前に行い、修正が集中した

原因

• 原稿を書く人と期限を、プロジェクトの最初に決めていなかった
• 表示の確認を誰が行うのかが、工程表に入っていなかった

次に試すこと／担当と期限

• 原稿の担当と提出日を、立ち上げの会議で工程表に書き込む（企画担当、次のプロジェクトの初回会議まで）
• スマートフォンでの確認を、デザインの確認会に毎回含める（デザイナー、次回の確認会から）
• 原稿のひな形を作り、営業担当が書きやすくする（営業担当、9月30日まで）

この例で大切なのは、問題だったことを「原稿担当が遅れた」と人の責任として書いていない点です。 「原稿の担当と期限を決めていなかった」という仕組みの問題として書くことで、次に試すことが具体的な手順の変更になります。 人を責める書き方をすると、次の振り返りから本音が出なくなり、シートに書かれる内容が当たり障りのないものになっていきます。

飲食店の新メニューの開発でも、同じ考え方が使えます。 試作から販売開始まで1か月の予定が2か月かかったなら、「シェフが遅かった」ではなく「仕入れ先の試供品が届く日を最初に確かめていなかった」と書きます。 こう書けば、次の開発では最初の週に仕入れ先へ連絡する手順を加えるだけで、同じ遅れを防げます。

フレームワークの選び方とそれぞれの特徴

振り返りシートの枠組みには、いくつかの定番のフレームワークがあります。 どれが正しいというものではなく、プロジェクトの規模や、振り返りに使える時間で選びます。

KPT（ケプト）

Keep（続けること）、Problem（問題）、Try（次に試すこと）の3つの欄で振り返る方法です。 欄が少なく、初めて振り返りをするチームでも書き方に迷いません。 Problemに書いたことに対して、Tryで改善策を書く流れが分かりやすく、短い区切りで何度も振り返る進め方に向いています。 一方で、問題の原因を深く掘る欄がないため、大きな失敗の振り返りには物足りないことがあります。

YWT（ワイダブリューティー）

やったこと、わかったこと、次にやることの3つの欄で振り返る方法です。 日本で生まれたフレームワークで、成り立ちについては次のように説明されています。

YWTは、日本能率協会コンサルティング（JMAC）によって開発された、振り返りに使用されるフレームワークです。このフレームワークは、「Y：やったこと」「W：わかったこと」「T：次にやること」という3つの要素から構成されています。 出典: teams.qiita.com

KPTと違い、良し悪しを判断する前に「やったこと」を事実として並べるので、成功も失敗もない淡々としたプロジェクトでも書きやすいのが特徴です。 新人や、プロジェクトに初めて参加したメンバーの学びを残すのにも向いています。

4L

Liked（良かったこと）、Learned（学んだこと）、Lacked（足りなかったこと）、Longed for（あればよかったもの）の4つの欄で振り返る方法です。 「あればよかったもの」の欄があるので、道具や人手、予算など、プロジェクトの外側にあった不足を書き出しやすくなります。 次のプロジェクトの予算や体制を決める前の振り返りに向いています。

タイムライン

プロジェクトの期間を横に並べ、時期ごとに起きた出来事と、そのときのメンバーの気持ちの浮き沈みを書き込む方法です。 数か月以上の長いプロジェクトでは、最初のころの出来事を誰も覚えていないことがよくあります。 時系列で並べ直すことで、「問題の始まりは3か月目の仕様変更だった」といった、つながりが見えてきます。

Fun Done Learn（ファン・ダン・ラーン）

楽しかったこと、やり遂げたこと、学んだことの3つの観点で振り返る方法です。 3つの円を重ねた図を描き、出来事がどの観点に当てはまるかで、円の中の位置を決めて書き込んでいきます。 「楽しかった」という気持ちの面を正面から扱うので、メンバーの意欲が下がっているチームや、厳しいプロジェクトを乗り越えたあとの振り返りに向いています。 改善策を決める欄がないため、最後にKPTのTryの欄だけを加えて、次に試すことを決めておくと実務に結びつきます。

選び方の目安

• 2週間程度の短い区切りを何度も振り返る：KPT
• 新人の学びや、淡々と進んだプロジェクトを記録する：YWT
• 次の予算や体制を決める前に振り返る：4L
• 3か月以上の長いプロジェクトや、大きな失敗を振り返る：タイムラインで出来事を並べてからKPT

迷ったら、まずKPTで始めるのが無難です。 欄が少ないぶん記入の負担が小さく、振り返り自体を習慣にしやすいからです。 慣れてきたら、Problemの欄の横に「原因」の列を加えるなど、チームに合わせて形を変えていきます。

振り返り会の進め方のステップ

振り返りシートは1人で書くこともできますが、チームのプロジェクトなら、全員で集まる振り返り会を開いてから仕上げるのが効果的です。 1時間の会を想定した進め方を、5つのステップで説明します。

1. 事前の記入（会の2〜3日前まで）：各メンバーがシートの良かったこと、問題だったことの欄に、思いつくことを書き込んでおく
2. 目的と結果の確認（10分）：司会がプロジェクトの目標と結果を読み上げ、判断の基準をそろえる
3. 出来事の共有（20分）：書き込まれた内容を1人ずつ説明し、似た内容をまとめる
4. 原因と次に試すことの話し合い（20分）：問題だったことの中から、次のプロジェクトに影響が大きいものを2〜3個選び、原因と改善策を決める
5. 担当と期限の決定（10分）：次に試すことごとに担当者と期限を決め、シートに書き込んで終える

ポイントは、事前の記入を必ずお願いすることです。 会の場でいきなり「何か問題はありましたか」と聞くと、声の大きい人の意見だけが出て、静かなメンバーの気づきが埋もれます。 事前に書いてもらえば、全員の意見が同じ重さでシートに並びます。

ステップ4で、問題を2〜3個に絞るのも大切です。 問題だったことが10個出たからといって、10個すべてに改善策を決めると、次のプロジェクトで手が回らず、結局どれも実行されません。 影響の大きさと、改善のしやすさの2つで並べ、上位のものから取り組みます。 残りの問題はシートに記録として残しておき、次の振り返りで同じものがまた出てきたら優先度を上げる、という扱いにします。

在宅のメンバーが多いチームでは、オンライン会議と共有のシートを組み合わせます。 全員が同じシートを開いた状態で会を始め、司会が画面を共有しながら書き込んでいけば、離れていても同じ記録を見ながら話せます。

振り返りシートを書くときのコツと失敗しやすいポイント

振り返りシートは、書き方を少し変えるだけで、次に活かせる度合いが大きく変わります。 ここでは、よくある失敗と、その直し方を整理します。

事実と感想を分けて書く

「デザインの確認が大変だった」は感想です。 「デザインの確認が1回あたり平均3日かかり、全部で5回行った」は事実です。 事実で書くと、何を改善すべきかが自然に見えてきます。 確認に3日かかっていたのなら、確認の担当者を1人に決める、確認の曜日を固定するといった改善策が出しやすくなります。

次に試すことは動詞で終える

「コミュニケーションの改善」は目標であって、行動ではありません。 「毎週月曜日の朝に、進み具合を10分で共有する」のように、誰が見ても何をするのかが分かる動詞で終えます。 動詞で書けない改善策は、まだ考えが足りていない合図です。

良かったことも必ず書く

問題ばかりを書くと、振り返りが反省会になり、参加する人の気持ちが重くなります。 良かったことを書くのは、気持ちを明るくするためだけではありません。 うまくいった理由を言葉にしておかないと、次のプロジェクトで同じやり方を再現できないからです。 「たまたまうまくいった」で済ませず、「最初の週に関係者全員と顔を合わせたので、その後の質問がしやすかった」のように理由まで書きます。

プロジェクトが終わってすぐに書く

振り返りは、記憶が新しいうちに行うほど正確になります。 公開や納品から1〜2週間以内に振り返り会を開くのが目安です。 間が空くと、細かい出来事を忘れ、印象に残った大きな出来事だけで判断することになります。 長いプロジェクトでは、終わってからまとめて振り返るのではなく、1か月ごとなど区切りを決めて中間の振り返りを入れると、最後の振り返りの負担も軽くなります。

読み返す場面を決めておく

もっとも多い失敗は、書いたシートが誰にも読まれないことです。 これを防ぐには、読み返す場面を先に決めておきます。 たとえば「新しいプロジェクトの初回の会議では、似たプロジェクトの振り返りシートを最初の10分で読む」とルールにすれば、シートは自然に活用されます。 シートのファイル名に、プロジェクトの種類と年月を入れておくと、あとから探しやすくなります。

無料で使える振り返りシートのテンプレートの作り方

振り返りシートのテンプレートは、有料の道具を使わなくても、手元のソフトで十分に作れます。 ここでは、よく使われる3つの形を紹介します。

ExcelやGoogleスプレッドシートで作る

もっとも手軽なのは、表計算ソフトで1行に1項目を書く形です。 列は「区分（良かったこと／問題だったこと／次に試すこと）」「内容」「原因」「担当」「期限」「状況」の6つにします。 区分の列はプルダウンで選べるようにしておくと、表記がそろい、あとから区分ごとに絞り込めます。 Googleスプレッドシートなら、複数のメンバーが同時に書き込めるので、振り返り会の事前記入にも使えます。

プロジェクトごとにシートのタブを分け、1つのファイルに積み重ねていくと、過去の振り返りを横に並べて比べられます。 同じ問題が何度も出てきていれば、それはチームの仕組みに根本の原因がある合図です。

文書作成ソフトで作る

WordやGoogleドキュメントで、見出しごとに欄を作る形です。 記入例で示したような、文章で経緯を説明する書き方に向いています。 社外の関係者に振り返りの結果を共有するときや、報告書として提出するときは、こちらの形のほうが読みやすくなります。

紙やホワイトボードで作る

同じ場所に集まって振り返る場合は、ホワイトボードを3つか4つの区画に分け、付せんに書いて貼っていく方法もよく使われます。 付せんを動かしながら似た内容をまとめられるので、話し合いが進めやすいのが利点です。 ただし、終わったら必ず写真を撮るか、表計算ソフトに書き写して残しておきます。 紙のままだと、次のプロジェクトで探し出すことができません。

どの形を選ぶ場合も、テンプレートの最初の欄にプロジェクトの目標と結果を書く欄を設けることをおすすめします。 判断の基準が先に書かれていれば、その下に続く良かったことと問題だったことの欄が、自然に目標に照らした内容になります。

成功と失敗を判断する目標の決め方

振り返りシートの質は、プロジェクトの最初に決めた目標の質で決まります。 目標があいまいなまま始まったプロジェクトは、終わったあとに何を基準に良し悪しを判断すればよいのかが分からず、振り返りが感想の交換で終わってしまいます。 振り返りを意味のあるものにするには、立ち上げの段階で、あとから比べられる目標を決めておく必要があります。

目標は、次の3つの種類に分けて考えると決めやすくなります。

• 期日の目標：公開日、納品日、各工程の締切
• 量と費用の目標：作業時間、予算、作る画面やページの数
• 成果の目標：問い合わせの件数、売上、利用者の数、作業時間の削減

期日と量と費用の目標は、プロジェクトの進め方がうまくいったかを測るものです。 成果の目標は、プロジェクトをやった意味があったかを測るものです。 この2つは別のものとして扱います。 期日に遅れても成果の目標を大きく上回ったプロジェクトもあれば、期日どおりに終わったのに成果が出なかったプロジェクトもあります。 両方を並べて書くことで、「進め方は直す必要があるが、方向は正しかった」といった判断ができるようになります。

成果の目標は、プロジェクトが終わってすぐには結果が出ないことがあります。 Webサイトのリニューアルなら、公開から1か月や3か月たたないと問い合わせ件数の変化は分かりません。 その場合は、振り返りを2回に分けます。 終わった直後に進め方の振り返りを行い、成果が出そろったころに成果の振り返りを短く行う、という形です。 2回目の振り返りの日付を、1回目のシートの最後に書いておけば忘れずに済みます。

目標を決めるときは、数字で書けるものは数字で書きます。 「使いやすいサイトにする」ではなく「問い合わせフォームまでのクリック数を4回から2回にする」と書けば、終わったあとに達成できたかどうかが誰の目にも明らかになります。 数字で書けない目標でも、「営業担当が説明に使える資料になっているか、営業担当2人に確かめてもらう」のように、判断する人と方法を決めておけば、振り返りの基準になります。

振り返り会を気まずい場にしない司会の役割

振り返り会でもっとも難しいのは、参加者が本音を話せる雰囲気を作ることです。 特に、遅れや失敗があったプロジェクトでは、誰かが責められるのではないかと身構えて、口が重くなりがちです。 この雰囲気を作るのが、司会の役割です。

司会は、プロジェクトのリーダーとは別の人が務めるのが理想です。 リーダーが司会をすると、どうしても自分の判断を弁護する方向に話が流れやすく、メンバーも上司の前で問題を指摘しにくくなります。 小さなチームで別の人を立てられない場合は、会のたびに司会を交代する方法もあります。

司会が会の最初に伝えておきたいのは、次の3つです。

1. この会の目的は、次のプロジェクトをうまく進めることで、誰かの責任を問うことではない
2. 問題は人ではなく、出来事や仕組みとして話す
3. 話された内容はシートに残すが、評価の材料には使わない

3つ目は特に大切です。 振り返りの内容が人事評価に使われると分かれば、誰も正直に失敗を書かなくなります。 評価と振り返りは切り離すことを、会のたびに言葉にして伝えます。

話し合いの途中で、特定の人への批判が出てきたときは、司会が「その出来事が起きた仕組みはどこにあったか」と問い直します。 「担当者が確認を忘れた」という発言なら、「確認の手順が工程表に入っていたか」と聞き直すことで、話が人から仕組みに戻ります。 また、発言の少ないメンバーには、事前に書いてもらった内容を司会が読み上げて、補足をお願いする形にすると、話しやすくなります。

決めた改善策を担当と期限まで追う方法

振り返りシートを作っても、次に試すことが実行されなければ意味がありません。 実行まで追う方法は、チームの人数で選びます。

1人か2人のプロジェクトなら、振り返りシートの「状況」の列に「未着手」「進行中」「完了」を書き込んで、週に1回見直すだけで十分です。 次のプロジェクトの計画を立てるときに、状況が「完了」になっていない改善策がないかを確かめる手順を入れておけば、抜けを防げます。

人数が増えると、表計算ソフトだけでは追いにくくなります。 誰がどの改善策を担当しているのか、期限が近いものはどれか、もう終わったのかを確かめるために、毎回シートを開いて探すことになるからです。 担当者に「あの件どうなりましたか」と確かめる連絡も、メールやチャットで別に行うことになり、やり取りが散らばります。

複数人で担当と期限と進み具合を共有したい場合は、振り返りで決まった次に試すことを、タスク管理の道具にカードとして移す方法があります。 その選択肢の1つが Pinateca です。 公式サイトによると、Pinatecaはカンバンボード、ガントチャート、カレンダー、リストなど8種類のボードとチャットを備えたタスク管理の道具で、5人までのチームならフリープランで全種類のボードを使えます。 次に試すことを1枚ずつカードにして担当者と期限を設定し、カンバンボードで「未着手」「進行中」「完了」の列に分けておけば、進み具合が1画面で見渡せます。 カードにはカスタムフィールドとして優先度などの項目を自由に追加でき、カード単位のコメントで担当者とのやり取りもカードに残せます。 社外のゲストを招待できるので、業務委託のメンバーにも同じボードを見てもらえます。 フリープランはメンバー5人まで、ボード10個までで、それを超える場合のスタンダードプランは1人あたり月額500円（税抜、年払いなら月額400円）です。 振り返りの文書そのものを作る機能ではないため、シートは表計算ソフトや文書作成ソフトで作り、決まった行動の管理に使う形になります。 Pinatecaは、@SOHOを運営する株式会社ライフスケープが開発・提供しています。

どの道具を使う場合も、改善策を移すときに、振り返りシートのどの行から来たものかが分かるようにしておくと、あとから経緯をたどれます。 カードの説明欄に、振り返りのプロジェクト名と日付を書いておくだけで十分です。

業務委託のメンバーが加わるプロジェクトの振り返り

業務委託のエンジニアやデザイナーが加わるプロジェクトでは、振り返りに外部のメンバーを呼ぶかどうかで迷うことがあります。 結論から言えば、可能な範囲で参加してもらうほうが、振り返りの質は上がります。 手戻りや確認待ちの原因は、発注側と受注側の間のやり取りにあることが多く、片方だけで振り返っても原因の半分しか見えないからです。

ただし、業務委託のメンバーに振り返り会への参加を求める場合は、その時間を作業として扱うのか、契約の範囲に含まれるのかを先に確かめておきます。 契約で決めていない作業を当然のように頼むと、相手の負担になり、関係がぎくしゃくします。 参加が難しい場合は、事前の記入だけをお願いし、会の結果をシートで共有する形でも、外部の視点を取り込めます。

在宅ワークとフリーランスの仲介を2004年から続けてきた運営者の立場から見ると、長く関係が続く発注者と受注者には、終わったあとに短くても振り返りの時間を持っているという共通点があります。 「今回はここで確認に時間がかかったので、次は最初に決めましょう」という一言が交わされているだけで、2回目以降の仕事は目に見えて進みやすくなります。 仲介の手数料がかからない直接のやり取りでは、こうした振り返りの会話も当事者どうしで気軽に交わせるため、同じ相手と仕事を重ねるほど進め方が洗練されていきます。

受注する側のフリーランスにとっても、振り返りシートは自分の仕事の進め方を見直す材料になります。 見積もりと実績の時間を毎回記録しておけば、自分がどの工程で時間を読み違えやすいのかが分かり、次の見積もりの精度が上がります。 これは単価の交渉の根拠にもなります。

職種ごとの振り返りの観点

振り返りシートの基本の形は同じでも、職種によって見るべき観点は少しずつ違います。 自分の仕事に近いものを、シートの項目に加えてみてください。

アプリやシステムの開発では、見積もりと実績の時間の差、仕様の変更の回数、不具合が見つかった工程を記録しておくと、次の計画に活かせます。 開発の仕事の種類や進め方は、アプリケーション開発のお仕事で、受託開発から保守までの仕事の形とあわせて紹介しています。

デザインの仕事では、確認の回数と、確認ごとの修正の量を記録するのが有効です。 修正が多かった回の原因が、最初の要望の聞き取り不足なのか、途中の方針の変更なのかを分けて書くと、次のヒアリングの質問が具体的になります。 デザイナーの仕事の相場はデザイナーの年収・単価相場で、雇用と業務委託それぞれの水準を確かめられます。

AIを業務に取り入れる支援の仕事では、導入前後で作業時間がどれだけ変わったかを、振り返りシートの目標と結果の欄に書くことが求められます。 数字で効果を示せれば、次の提案の説得力が増します。 こうした仕事の内容はAIコンサル・業務活用支援のお仕事で整理しています。

経営の改善を支援する立場で、顧客の会社のプロジェクトの振り返りに関わることもあります。 中小企業の経営課題を診断し助言する国家資格については、中小企業診断士のページで、試験の内容と資格を活かせる仕事を紹介しています。 振り返りの進め方を身につけておくと、顧客のプロジェクトの改善を手伝う場面でも、そのまま使えます。

よくある質問

Q. プロジェクト振り返りシートは、いつ書くのがよいですか？

公開や納品から1〜2週間以内に書くのが目安です。記憶が新しいうちに書くほど、細かい出来事まで正確に残せます。3か月を超える長いプロジェクトでは、終わってからまとめて書くのではなく、1か月ごとなど区切りを決めて中間の振り返りを入れると、最後の振り返りの負担も軽くなり、途中で進め方を直すこともできます。

Q. KPTとYWTはどちらを使えばよいですか？

短い区切りで何度も振り返るならKPT、新人の学びや淡々と進んだプロジェクトを記録するならYWTが向いています。KPTは問題と改善策の流れが分かりやすく、YWTは良し悪しを判断する前に事実を並べるので書き始めやすいのが特徴です。迷ったら、欄が少なく習慣にしやすいKPTから始め、チームに合わせて列を加えていく方法がおすすめです。

Q. 振り返りで出た問題が多すぎる場合はどうすればよいですか？

すべてに改善策を決めず、影響の大きさと改善のしやすさで並べて、上位の2〜3個に絞ります。多くの改善策を一度に決めると、次のプロジェクトで手が回らず、どれも実行されないまま終わりがちです。選ばなかった問題もシートに記録として残しておき、次の振り返りで同じ問題が再び出てきたら優先度を上げる、という扱いにすると抜けを防げます。

Q. 振り返りシートのテンプレートは無料で作れますか？

作れます。ExcelやGoogleスプレッドシートで「区分」「内容」「原因」「担当」「期限」「状況」の6列を用意すれば、それだけで実用的なシートになります。区分の列をプルダウンにすると表記がそろい、絞り込みもしやすくなります。プロジェクトごとにタブを分けて1つのファイルに積み重ねると、過去の振り返りを並べて比べられ、繰り返し起きている問題にも気づけます。