振り返りのやり方とは？フレームワーク 8 選とテンプレート、次のアクションにつなげる方法

振り返りとは

振り返りとは、過去の一定期間における行動と結果を客観的に整理し、そこから得られた学びを次の行動に反映させるプロセスです。英語では「リフレクション (reflection)」と呼ばれ、人材育成や組織開発の文脈で広く用いられています。

対象となる期間や単位はさまざまです。1 日の終わりに行う日次の振り返り、週単位や月単位の定期的な振り返り、上期や下期の評価にあわせた半期単位の振り返り、そしてプロジェクト完了時に実施する振り返りがあります。

振り返りと反省の違い

振り返りと反省は混同されがちですが、目的が異なります。

反省は、うまくいかなかった点に焦点を当て、原因を自分の内面に求める行為です。「準備が足りなかった」「意識が低かった」といった表現に代表されるように、精神論で終わりやすく、次の行動につながりにくいという特徴があります。

一方の振り返りは、うまくいった点とうまくいかなかった点の両方を対象とし、原因を行動やプロセスに求めます。「確認の回数が足りなかったため、認識のずれが後工程で発覚した」というように、事実と構造に着目するため、具体的な改善策を導きやすくなります。

上司から振り返りを求められた際、感想文や反省文のような内容になってしまう場合、この違いを意識するだけで書ける内容が大きく変わります。

振り返りと反省会の違い

チーム単位で行う振り返りは、いわゆる反省会とも異なります。

反省会では、問題が起きた原因を特定する過程で、責任の所在を問う方向に議論が流れがちです。その結果、参加者が防御的になり、本当の課題が表に出てこなくなります。

振り返りの場では、個人の責任を追及せず、プロセスや仕組みの問題として扱います。誰が悪かったのかではなく、どの仕組みがあれば防げたのかを問うことで、率直な意見が出やすくなります。

振り返りの目的

振り返りを実施する目的は、大きく 4 つに整理できます。

業務改善につなげる 

うまくいかなかった原因を特定し、次回以降の進め方を変えることで、同じ問題の再発を防げます。個人の作業手順からチームのプロセスまで、改善の対象は幅広く存在します。

自己理解を深める 

自分がどのような場面で成果を出しやすいのか、どのような条件下でパフォーマンスが落ちるのかを把握できます。得意不得意の傾向がわかれば、仕事の進め方を自分に合わせて調整できるようになります。

人材育成を促進する 

経験から学びを引き出す力は、実務を通じた成長の土台になります。上司やメンバーとの対話を伴う振り返りは、フィードバックの質を高め、育成の機会として機能します。

目標設定の精度を上げる 

過去の実績と、その背景にある要因を把握していれば、次の目標を現実的な水準で設定できます。根拠のない努力目標ではなく、達成可能かつ挑戦的な目標を立てられるようになります。設定した目標を組織全体で追跡する方法は、Asana の目標管理機能で確認できます。

ワークマネジメントとは？チームがワークマネジメントを必要とする理由

この電子書籍では、ワークマネジメントとは何かを解説し、ビジネスにどう役立つかをご紹介します。

電子書籍をダウンロード

振り返りテンプレートと記入例

振り返りの進め方を理解しても、実際に何をどう書けばよいかで手が止まることは少なくありません。ここでは、そのまま使えるテンプレートと具体的な記入例を、利用シーン別に 3 パターン紹介します。

基本のテンプレート

まずは、どのような場面でも使える汎用的な形式です。

ポイントは、「うまくいったこと」と「うまくいかなかったこと」の両方に要因を書く欄を設けることです。結果だけを並べても学びにはなりません。なぜそうなったのかを言語化して初めて、次に再現したり回避したりできるようになります。

チームで振り返りを行う場合は、スプリントの振り返り用テンプレートを使うと、話し合ったトピックとそこから生まれた To-Do を同じ場所で管理できます。

記入例 1: 個人の週次振り返り

日常業務を対象とした、1 週間単位の振り返りの例です。

対象期間 2026 年 10 月 5 日 (月) から 10 月 9 日 (金)

取り組んだこと

• 新製品の紹介資料の作成 (初稿提出まで完了)

• 定例ミーティングの進行 (2 回)

• 顧客からの問い合わせ対応 (12 件)

• 来期予算案の数値集計

うまくいったこと 

紹介資料の初稿を予定より 1 日早く提出できた。要因は、着手前に上司へ構成案を共有し、方向性の合意を取ってから本文を書き始めたこと。以前は完成してから見せていたため、大幅な修正が発生していた。

うまくいかなかったこと

予算案の数値集計が締め切り当日までかかり、確認作業の時間を確保できなかった。要因は、必要なデータが複数の部署に分散しており、依頼と回収に想定の 2 倍の時間がかかったこと。依頼を出すタイミングが遅く、相手の都合を考慮していなかった。

わかったこと 

他部署の協力が必要な業務は、自分の作業時間ではなく、相手の回答待ち時間が全体の所要時間を左右する。着手のタイミングを前倒しすべきなのは、作業量が多い業務ではなく、関係者が多い業務である。

次にやること 

他部署への依頼が発生する業務は、締め切りから逆算して依頼期限を設定し、着手初日に依頼を出す。次回の月次集計 (11 月 5 日締め切り) では、10 月 28 日までに依頼を完了させる。

記入例 2: チームのプロジェクト完了後の振り返り

プロジェクト終了時に、チーム全体で実施する振り返りの例です。

対象プロジェクト コーポレートサイトのリニューアル (2026 年 6 月から 9 月)

取り組んだこと

• 要件定義とワイヤーフレーム作成

• デザイン制作と社内レビュー

• 実装と検証

• 公開とその後の修正対応

うまくいったこと 

デザインフェーズでの手戻りが前回のプロジェクトより大幅に減った。要因は、初回レビューの前に決裁者を含めた方向性のすり合わせを実施したこと。前回は制作完了後に決裁者から根本的な指摘が入り、2 週間の遅延が発生していた。

うまくいかなかったこと 

公開直前に表示崩れが複数見つかり、公開日を 3 日延期した。要因は、検証に使用した端末とブラウザの組み合わせが限定的で、実際のユーザー環境を網羅できていなかったこと。検証項目の一覧は作成していたが、誰がどの環境を確認するかの割り当てが曖昧だった。

わかったこと 

チェックリストの有無ではなく、各項目に担当者が割り当てられているかどうかが、抜け漏れの発生を左右する。「全員で確認する」という状態は、実質的に誰も確認していない状態になりやすい。

次にやること 

検証フェーズでは、確認項目ごとに担当者と期日を設定したタスクを作成する。次回プロジェクトのキックオフ時に、検証項目のタスク化をスケジュールへ組み込む。

記入例 3: 上期評価の振り返り

半期の評価面談に向けて、自身の実績と成長を整理する際の例です。

対象期間 2026 年 4 月から 9 月 (上期)

設定していた目標

• 担当顧客の解約率を前年同期比で 2 ポイント改善する

• 新規顧客向けのオンボーディング手順を標準化する

目標に対する結果 

解約率は前年同期比 3.1 ポイントの改善を達成。オンボーディング手順の標準化は、ドキュメント作成までは完了したが、チーム全体での運用開始には至らなかった。

うまくいったこと 

解約率の改善は、契約更新の 3 か月前に利用状況をヒアリングする運用を新設したことが要因。従来は更新月の直前に連絡していたため、課題が判明しても打ち手を講じる時間がなかった。前倒しにより、解約意向のある顧客に対して改善提案ができるようになった。

うまくいかなかったこと 

オンボーディング手順の標準化が運用まで到達しなかった。要因は、ドキュメントを作ることを目標として設定してしまい、チームへの浸透を目標に含めていなかったこと。完成した時点で達成と見なし、展開の計画を立てていなかった。

わかったこと 

成果物の作成を目標にすると、作った時点で終わってしまう。本来の目的が「チーム全体の対応品質を揃えること」であれば、目標は運用開始や利用率で設定すべきだった。目標設定の段階で、何をもって達成とするかの定義が甘かった。

次にやること 

下期の目標は、成果物ではなく状態で定義する。オンボーディング手順については、11 月末までにチームメンバー全員が 1 回以上使用している状態を目標とし、週次で利用状況を確認する。

AI でよりスマートな働き方を実現するか、取り残されるか

AI を理解するには、まず事実を知ることから始まります。トップクラスの企業がどのように AI を活用して成功を加速させているのか、最新の調査結果をご覧ください。

調査レポートを見る

振り返りの基本ステップ

フレームワークを使う場合でも使わない場合でも、振り返りは次の 5 つのステップで進めます。

ステップ 1: 対象と期間を決める

何をどの期間で振り返るのかを最初に定めます。範囲が曖昧なまま始めると、話が発散して具体性を欠いた内容になります。

「今週の業務全般」よりも「今週担当した A 案件の進め方」のように、対象を絞るほど具体的な学びが得られます。

ステップ 2: 事実を書き出す

評価や解釈を加えず、起きたことをそのまま書き出します。実施した業務、かかった時間、発生した問題、得られた結果などが対象です。

この段階で「よくなかった」「頑張った」といった評価を混ぜると、事実が歪みます。あくまで客観的な記録として書き出すことが重要です。

ステップ 3: 要因を分析する

書き出した事実について、なぜそうなったのかを掘り下げます。うまくいったことにも、うまくいかなかったことにも、必ず要因があります。

原因を個人の資質や努力量に求めると、改善策が精神論になります。行動、手順、判断のタイミング、情報の流れなど、変えられる要素に着目してください。

ステップ 4: 学びを言語化する

要因の分析から、次に活かせる形の学びを取り出します。特定の案件だけに当てはまる話ではなく、他の場面でも使える教訓の形にすることがポイントです。

「A 社への提出が遅れた」は事実であり、学びではありません。「相手の確認が必要な工程は、自分の作業時間の倍を見積もる必要がある」まで抽象化して初めて、次に使えます。

ステップ 5: 次のアクションを決める

学びを具体的な行動に変換します。ここまで到達しなければ、振り返りは実施したこと自体が目的化します。

アクションは、いつ、誰が、何をするのかが明確な形で設定してください。「意識する」「気をつける」といった表現は行動ではないため、実行されたかどうかを後から確認できません。

Asana のデモを視聴

Asana を活用することで、オペレーションチームは仕事の連携、プロセスの統一、ワークフローの自動化を 1 か所で実現できます。

デモを見る

振り返りのフレームワーク 8 選

フレームワークを使う利点は、考える順序が決まっていることで、書くべき内容に迷わなくなる点にあります。ここでは代表的な 8 種類を、それぞれの特徴と適した場面とあわせて紹介します。

1.KPT

KPT は、Keep、Problem、Try の頭文字を取ったフレームワークです。シンプルな構造で、個人でもチームでも使いやすく、振り返りの手法として広く用いられています。

Keep (継続すること)

うまくいっていること、今後も続けるべきことを挙げます。

記入例

• 着手前に構成案を共有する進め方

• 朝の 30 分を資料作成にあてる時間配分

• 週次で進捗をチームに共有する運用

Problem (問題点)

うまくいっていないこと、課題だと感じていることを挙げます。

ここで重要なのは、問題を人ではなく事象として記述することです。「A さんの確認が遅い」ではなく「確認依頼から回答までに平均 3 日かかっている」と書けば、解決すべき対象が明確になります。

記入例

• 他部署への依頼が締め切り直前になっている

• 会議の議題が事前に共有されていない

• 検証環境の準備に毎回 2 時間かかっている

Try (次に試すこと)

Problem を解消するため、また Keep をさらに強化するために、次に試す行動を挙げます。

Try は実行可能な粒度まで具体化してください。「効率化する」では行動になりません。「テンプレートを作成して次回から使用する」まで落とし込みます。

記入例

• 依頼が必要な業務は着手初日に依頼を出す

• 会議の前日までに議題をタスクのコメントで共有する

• 検証環境の構築手順をドキュメント化する

KPT の進め方

チームで実施する場合は、次の手順が基本です。

1. 各自が付箋やドキュメントに Keep を書き出す (5 分)

2. 順番に共有する (10 分)

3. 同じ要領で Problem を書き出し、共有する (15 分)

4. Problem に対する Try を全員で検討する (15 分)

5. Try のなかから、次の期間で実行するものを選び、担当者と期日を決める (10 分)

所要時間は 1 時間程度が目安です。Try をすべて実行しようとすると形骸化するため、優先度の高いものを 2 つか 3 つに絞ってください。

アジャイル開発の文脈における振り返りについては、レトロスペクティブの進め方と手法で詳しく解説しています。

2.KPTA

KPTA は、KPT に Action を加えた形で運用される派生的な進め方です。

KPT では、Try が挙がったところで終わってしまい、実際に誰が何をするのかが決まらないまま次回を迎えることがあります。KPTA はこれに対処するため、Try で出たアイデアを具体的なアクションに落とし込む工程を明示的に設けています。

項目内容Keep継続することProblem問題点Try試したいこと (アイデア)Action実行する行動 (担当者と期日つき)

Try と Action の違いは、実行の確約があるかどうかです。Try は候補であり、Action は実行が決まったものを指します。

振り返りが形式的になっていると感じる場合、KPT から KPTA への移行を検討する価値があります。

3.YWT

YWT は、やったこと、わかったこと、次にやることの頭文字を取った日本発のフレームワークです。日本能率協会コンサルティングが提唱したもので、経験からの学習を重視する構造になっています。

Y: やったこと

期間内に実施した行動を事実として書き出します。

評価を含めず、実際に何をしたのかだけを列挙する点が特徴です。ここで成否の判断を挟まないため、失敗した取り組みも等しく記録されます。

W: わかったこと

やったことから得られた学びや気づきを書き出します。

YWT の中心はこの W にあります。同じ経験をしても、そこから何を学び取るかで成長の度合いが変わるという考え方が背景にあります。

成功からも失敗からも学びを引き出すため、「うまくいったからよかった」で終わらせません。なぜうまくいったのかを言語化することで、再現性のある知見になります。

T: 次にやること

わかったことを踏まえ、次に実行する行動を決めます。

KPT と YWT の使い分け

両者は似ていますが、重心が異なります。

KPT は問題解決に向いています。課題が明確で、それを解消する打ち手を出したい場合に適しています。チームでのプロセス改善に使われることが多いのはこのためです。

YWT は学習と成長に向いています。経験から何を学んだかを言語化する構造のため、人材育成や個人のスキル向上を目的とする場面に適しています。新人の育成や、若手の定期的な振り返りで用いられます。

課題が明確で解決したい場合は KPT、経験から学びを引き出したい場合は YWT と考えると選びやすくなります。

4.PDCA サイクル

PDCA は、Plan、Do、Check、Act の 4 段階を繰り返すことで、継続的な改善を図るフレームワークです。品質管理の分野で生まれ、現在では業務改善全般に広く使われています。

Plan (計画)

目標を設定し、それを達成するための計画を立てます。

この段階で重要なのは、後の Check で検証できる形にしておくことです。数値目標や期限を含まない計画は、達成できたかどうかを判断できません。

Do (実行)

計画に沿って実行します。

実行中の記録を残すことが、次の Check の精度を左右します。何をいつ実施したか、想定と異なる点はなかったかを記録しておきます。

Check (評価)

実行の結果を、計画と照らし合わせて評価します。

目標を達成できたかどうかだけでなく、達成できた場合もできなかった場合も、その要因を分析します。この工程が形骸化すると、PDCA は単なる作業の繰り返しになります。

Act (改善)

Check の結果を踏まえ、次のサイクルに向けた改善を行います。

うまくいった方法は標準化して定着させ、うまくいかなかった方法は原因に応じて修正または中止します。ここで得た内容が、次の Plan の入力になります。

振り返りにおける PDCA の位置づけ

PDCA は振り返りそのものというより、振り返りを含む業務サイクル全体を指す枠組みです。4 段階のうち Check と Act が、振り返りに相当します。

PDCA が回らない組織では、Plan と Do で力尽き、Check が省略されるパターンが多く見られます。振り返りの時間を確保する仕組みがなければ、サイクルは完結しません。

5.経験学習モデル

経験学習モデルは、組織行動学者のデービッド・コルブが提唱した、経験から学ぶプロセスを 4 段階で示したモデルです。人材育成の分野で理論的な基盤として広く参照されています。

具体的経験

実際に業務を経験します。

内省的観察

その経験を多角的に振り返ります。何が起きたのか、自分はどう行動したのか、他者からはどう見えたのかを検討します。

抽象的概念化

振り返りの内容から、他の状況にも応用できる教訓や仮説を導き出します。概念化とも呼ばれる工程です。

ここが不足していると、経験がその場限りのものとなり、次に活かされません。「あの案件は大変だった」で終わるか、「関係者が 5 名を超える案件は、合意形成の工程を独立させる必要がある」まで到達するかの差が、成長の差になります。

能動的実験

導き出した教訓を、次の場面で実際に試します。その結果がまた具体的経験となり、サイクルが循環します。

経験学習モデルの活用場面

このモデルは、個人の振り返りシートに直接使うというよりも、振り返りの設計思想として使うと効果的です。

自社の振り返りが機能していない場合、4 段階のどこが欠けているかを点検してみてください。経験だけがあって内省がない、内省はするが概念化に至らない、概念化しても次に試さない、といった形で、どこかの段階が抜け落ちていることがほとんどです。

6.4 行日記

4 行日記は、事実、発見、教訓、宣言の 4 行で構成される、個人向けの日次振り返り手法です。

各行は 1 文で書きます。分量が限られているため、毎日続けやすいことが最大の利点です。

記入例

• 事実: 提案資料の修正依頼が 3 回続き、想定の倍の時間がかかった

• 発見: 修正依頼の内容が毎回異なり、方向性の認識が揃っていなかった

• 教訓: 作り込む前に方向性の合意を取る工程が必要である

• 宣言: 私は、着手前に認識を揃えて仕事を進める人間である

振り返りの習慣がない場合、まず 4 行日記から始めると定着しやすくなります。1 日 5 分程度で完了するため、継続の負担が小さく済みます。

7.ジョハリの窓

ジョハリの窓は、自己理解と他者からの認識のずれを整理するフレームワークです。心理学者のジョセフ・ルフトとハリー・インガムが考案し、2 人の名前を組み合わせて名づけられました。

自分が知っているかどうか、他者が知っているかどうかの 2 軸で、4 つの領域に分類します。

開放の窓

自分も他者も知っている領域です。自覚している長所や短所のうち、周囲にも認識されているものが該当します。

この領域が広いほど、コミュニケーションの齟齬が起きにくくなります。認識が一致しているため、期待と実際のずれが生じにくいためです。

盲点の窓

他者は知っているが、自分は気づいていない領域です。

無意識の口癖や、本人が短所だと思っていない癖が該当します。この領域はフィードバックによってのみ明らかになります。振り返りを自分ひとりで完結させると、盲点の窓には永久に到達できません。

秘密の窓

自分は知っているが、他者には伝えていない領域です。

苦手意識を持っている業務や、実は自信がある分野などが該当します。開示することで開放の窓に移り、周囲からの適切な支援や機会を得やすくなります。

未知の窓

自分も他者もまだ知らない領域です。未開発の可能性や、まだ発揮されていない適性が該当します。

新しい業務への挑戦や、これまでと異なる役割の経験によって、この領域が開放の窓や秘密の窓へ移っていきます。

振り返りへの活用方法

ジョハリの窓は、上司との 1 on 1 や、チームメンバー間の相互フィードバックの場で活用できます。

自己評価を書き出したうえで、他者からの評価を受け取り、両者の差分を確認します。差分が盲点の窓にあたるため、そこに最も学びが含まれています。

自己理解を目的とした振り返りでは、このフレームワークが最も直接的に機能します。

8.LAMDA

LAMDA は、リーン製品開発の文脈で用いられる問題解決と学習のフレームワークです。Look、Ask、Model、Discuss、Act の頭文字を取っています。

特徴は、Look で現地現物の確認を求める点と、Model で因果関係を可視化する点にあります。推測や伝聞ではなく、観察した事実に基づいて原因を構造化するため、複雑な問題の分析に適しています。

原因が特定しにくい技術的な課題や、製造・開発の現場における問題の分析に向いています。一方で、工程数が多く負担も大きいため、日常的な業務の振り返りには対象を選んで使うことになります。

フレームワークの選び方

8 種類を整理すると、目的別に次のように使い分けられます。

複数を併用する必要はありません。まずは 1 つを選んで運用し、機能しない部分が見えてきた時点で別のものを検討する進め方が現実的です。

振り返りを次のアクションにつなげる方法

振り返りが形骸化する最大の原因は、実施したこと自体が目的になり、出た内容が実行されないまま次回を迎えることにあります。ここでは、振り返りの成果を確実に行動へつなげるための方法を解説します。

改善策をタスクに変換する

振り返りで挙がった改善策は、議事録やホワイトボードに書かれた時点では、まだ実行されていません。担当者と期日が設定されたタスクになって初めて、実行の対象になります。

変換の際は、次の 3 点を明確にしてください。

• 誰が実行するのか (担当者)

• いつまでに実行するのか (期日)

• 何をもって完了とするのか (完了条件)

「チーム全体で意識する」という形の改善策は、担当者が不在であるため実行されません。全員に関わる内容であっても、推進する担当者を 1 名決める必要があります。

アクションプランに落とし込む

改善策が複数の工程を含む場合は、アクションプランとして分解します。

たとえば「検証手順をドキュメント化する」という改善策は、次のように分解できます。

1. 現行の検証項目を洗い出す (担当: A、期日: 10 月 15 日)

2. 項目ごとに手順を記述する (担当: A、期日: 10 月 22 日)

3. チームでレビューする (担当: B、期日: 10 月 25 日)

4. 次回プロジェクトで運用を開始する (担当: 全員、期日: 11 月 1 日)

分解せずに 1 つのタスクとして扱うと、着手のハードルが高くなり、後回しにされやすくなります。

実行状況を可視化する

決めたアクションが実行されているかどうかを、次の振り返りまでに確認できる状態にしておきます。

進捗が見える状態になっていれば、遅れている項目に早い段階で気づけます。逆に、次回の振り返りの場で初めて未着手が判明する運用では、改善のサイクルが 1 周期分遅れます。

Asana のようなワークマネジメントツールを使うと、振り返りで決めたアクションをタスクとして登録し、担当者と期日を設定したうえで、進捗をチーム全体で確認できます。スプリントの振り返り用テンプレートを使えば、ディスカッションのトピック、フィードバック、実行可能な To-Do を 1 か所で追跡できるため、振り返りで生まれたアイデアが放置されることを防げます。

次回の振り返りで実行結果を確認する

振り返りの冒頭に、前回決めたアクションの実行状況を確認する時間を設けます。

この工程があることで、決めたことは確認されるという前提がチームに共有され、実行率が上がります。確認されない運用が続くと、振り返りの場で出る意見は次第に形式的なものになります。

実行できなかった項目については、なぜできなかったのかを新たな Problem として扱います。担当者を責めるのではなく、実行を妨げた要因を特定することで、次のアクションの精度が上がります。

最新最強の仕事術を学びましょう

Asana を活用することで、オペレーションチームは目標設定の合理化、プロセスの統一、年間計画の迅速化を 1 か所で実現できます。

デモを見る

振り返りがうまくいかない原因と対策

感想で終わってしまう

「大変だった」「勉強になった」といった感想にとどまり、次の行動につながらないケースです。

原因は、事実と要因を分けて書く工程がないことにあります。テンプレートに要因を記入する欄を設け、なぜそうなったのかを必ず言語化する形式にしてください。

毎回同じ意見しか出ない

定例の振り返りで、毎回似た内容が挙がるケースです。

前回のアクションが実行されていないことが原因である場合が多く見られます。実行されていなければ状況は変わらないため、同じ問題が繰り返し挙がります。前回のアクションの実行確認を先に行ってください。

対象範囲が広すぎることも原因になります。「今月の業務全般」ではなく「今月の A 案件」のように、対象を絞ると新しい論点が出やすくなります。

発言が出ない

チームでの振り返りで、意見が出ずに沈黙が続くケースです。

過去に発言が批判につながった経験があると、参加者は発言を控えます。個人の責任を問わないというルールを明示し、進行役がそれを徹底する必要があります。率直な意見が出る土台をつくる方法は、心理的安全性を高める方法で解説しています。

また、その場で考えて発言する形式は負担が大きいため、各自が事前に書き出してから共有する形式に変えると発言量が増えます。

アクションが実行されない

振り返りでは活発に意見が出るものの、決めたことが次回までに実行されないケースです。

担当者と期日が設定されていないことが主な原因です。加えて、1 回の振り返りで挙げるアクションが多すぎる場合も、優先順位がつかず全体が滞ります。実行するアクションは 2 つか 3 つに絞ってください。

時間がかかりすぎる

振り返りに時間を取られ、負担になっているケースです。

議論が発散していることが原因です。フレームワークを導入して考える順序を固定し、各工程の時間を事前に区切ってください。KPT であれば 1 時間、4 行日記であれば 5 分と、手法によって適切な所要時間は異なります。

アジャイルな企業のための意思決定ツール

この電子書籍では、従業員がより良い意思決定を行えるようにするための方法をご紹介します。これにより、競合他社よりも効果的に方向転換し、適応し、課題に対処できるようになります。

調査レポートを見る

まとめ

振り返りは、過去の行動を整理して次の行動につなげるための取り組みであり、反省や感想とは目的も進め方も異なります。

実施にあたっては、対象と期間を決め、事実を書き出し、要因を分析し、学びを言語化し、次のアクションを決めるという 5 つのステップを踏みます。KPT、YWT、PDCA、経験学習モデル、4 行日記、ジョハリの窓など、目的に応じたフレームワークを使うことで、考える順序が定まり、書くべき内容に迷わなくなります。

ただし、フレームワークを使うこと自体が目的ではありません。振り返りで挙がった改善策が、担当者と期日の設定されたタスクとして実行されて初めて、業務改善や人材育成という成果につながります。

振り返りを継続的な改善の仕組みとして機能させるには、決めたアクションが実行されているかどうかを可視化し、次回の振り返りで確認する運用が欠かせません。

よくある質問