プロジェクトの振り返り：質問、進行例、テンプレート

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

振り返りは、チームが一定期間の経験を見直し、次に何を変えるか決める会議です。プロジェクト、工程、繰り返しの作業サイクルのあとに行えます。協力の仕方、手順、条件を取り上げ、責任追及はしません。

進捗会議では完了や遅れを扱います。振り返りでは、なぜそのように進んだか、次にどんな小さな一手が役立つかを考えます。困り事を並べるだけで終えず、確かめられる結果を決めます。

経営側に報告書を弁明する場にしないでください。率直に答えると不利益があると思えば、役立つ情報が出ないことがあります。進行役は目的と話し合いのルールを先に説明します。

チームで準備する方法

「うまくいかないこと全部」ではなく「研修ウェビナーの準備と公開」などと範囲を区切ります。その作業に関わり、異なる立場から説明できる人を招きます。

何がいつ起き、どう影響し、何が役に立ったか、具体例を一人一つ用意してもらいます。事前にメモを集め、会議で考える時間を数分取れば、発言の多い一人の意見だけで始まるのを避けられます。

事実の確認に使える計画、タスクの履歴、承認済みの版、やり取りを用意します。記録がないことと行動がなかったことは別です。コメントが保存されていなくても、誰かが何もしなかったとは言えません。

振り返りの進行と質問

以下は少人数チーム向けの配分例です。必要に応じて調整し、複雑な話題は別の会議に分けます。

誰がいつも失敗するかという口論になったら、具体例に戻します。「まともな資料が来たことがない」ではなく「今回は何が足りず、いつ気付きましたか」と聞きます。

一度に全部解決しようとせず、仕事に影響し、手を打てる問題を選びます。他の課題は別に記録し、忘れたり担当のいない約束になったりしないようにします。

不満から検証可能な変更へ

チームがウェビナーを準備していました。開始前日に、承認した修正の一部が資料に入っていないと分かりました。振り返りで「また直前に全部やり直した」と声が上がりました。不満だけでは解決策は見えません。

参加者は資料を開いて経緯を確認しました。指摘は二つのチャットで届き、一部は直したものの、状態の一覧はありませんでした。一つの一覧があれば、最終承認前に漏れを発見できると考えました。

次の研修ウェビナーで試します。担当のマリーナが準備前に一覧を作ります。各指摘には「採用」「対応中」「確認済み」または不採用の理由を記入します。前日に編集担当者が一覧と最終資料を照合します。

次の振り返りで、承認されたのに漏れた修正があるか、一覧は管理しやすかったかを見ます。漏れが再発したら、ツールのせいと決めつけず、不明瞭な指示や直前の変更なども調べます。

振り返り結果のテンプレート

プロジェクトと期間：
参加者：
役立ったことと残すこと：

選んだ問題：
観察と具体例：
考えられる原因：
まだ分からないこと：

試す実験：
担当者：
準備の期限：
進捗の記録場所：
結果を確認する基準：
結果を話し合う時期：
確認後の判断：[続ける／変える／やめる]

次に話すその他の課題：

まとめを参加者に送り、誤りがあれば修正できるようにします。欠席者の判断が必要なら、その依存関係を記録します。本人の了承なしに担当にしたり、約束したことにしたりしないでください。

• 話し合いの範囲が明確。
• 事実と推測を分けた。
• 残したいことが決まった。
• 実行できる変更を選んだ。
• 担当者が引き受けた。
• 結果を確認する時期を決めた。