今月の振り返りでも、先月と同じ「共有不足」「確認不足」が並ぶ。最後は「次は気をつけよう」で終わり、次の仕事でも同じ問題が起きる。会議を開いているのに変わらないと、参加する側も話す意味を感じにくくなります。
振り返りを次の仕事へつなげるには、反省の言葉を、実際の業務で試せる変更に直します。「誰が悪かったか」ではなく、「次のどの場面で、誰が、何を変え、何を見て判断するか」まで決めることが必要です。
この記事は、振り返りの後に改善が動かないチーム向けです。失敗後の落ち込みや負担の立て直しは、未達・失敗の後に上司が変える条件で扱っています。ここでは、会議に出た改善案を実行し、次回に検証するところまでを掘り下げます。
前回決めたことが動いたかを、最初に確認する
毎回、新しい問題から話し始めると、過去の改善案が置き去りになります。冒頭で前回の記録を開き、「試した」「試せなかった」「試す場面がなかった」に分けてください。成果が出たかを問う前に、実行する機会と条件があったかを確認します。
試せなかった場合も、担当者の意識の問題とすぐには決めません。時間を確保できなかったのか、必要な権限がなかったのか、担当者が決まっていなかったのかで、今回直すことは変わります。新しい改善を追加する前に、前回の一件を続けるか、変えるか、やめるかを決めましょう。
スクラムガイド2020も、振り返りで役立つ変更を特定し、重要な改善へ早く対処する考え方を示しています。本記事は、その趣旨を参考にした一般の職場向けの実務提案で、スクラムの導入手順そのものではありません。スクラムガイド2020「スプリントレトロスペクティブ」
「共有不足」を、起きた場面の説明へ戻す
「確認不足」「連携不足」は問題の分類には使えても、それだけでは仕事を変えられません。どの情報を、誰が、いつ必要としていたのか。その時点で何が分かっていたのかまで戻します。
たとえば「営業からの共有が遅かった」なら、「仕様変更が確定した日」「制作担当が知った日」「変更前の仕様で進めた作業」を確認します。顧客からの連絡と社内の判断を混ぜず、記録で確かめられる事実と、本人の記憶・推測を分けて残します。
うまく進んだ案件も一緒に見ると、残したい条件を探せます。ただし、成功したからその手順が正解だったとは限りません。たまたま案件が簡単だった、特定の人が時間外に補ったなどの違いがないかも確認します。
犯人探しへ傾いたときの戻し方
「結局、誰が伝えなかったの？」と話が偏ったら、行動の確認は残しながら、次の設計へ戻します。以下は架空の進行例です。
「連絡がなかった事実は確認します。そのうえで、当時は何を連絡する約束だったのかも見たいです。今回は、仕様が変わったことと、納期が動くことのどちらを共有するルールでしたか」
これは個人の責任を消すための言い換えではありません。守るべき手順を認識したうえで実行しなかった問題と、手順や権限が曖昧だった問題を区別するための確認です。個別の評価や指導が必要なら別の面談で扱い、チーム全員の前で反省を言わせることを改善策にしないようにします。
安全上の問題、不正、ハラスメントなどは、この振り返りだけで処理せず、社内の正式な報告・対応手順へつなげます。通常の業務改善と、調査や保護が必要な案件を混同しないことが大切です。
改善案を「次の一件で試せる行動」に書き換える
原因を一つに断定できなくても、確かめたい仮説を決めて小さく試すことはできます。「共有先が曖昧だから連絡が遅れるのではないか」と考えたなら、次の同種案件で共有先を明示し、実際にどこで止まったかを見る、という形です。
| 反省のままの表現 | 試せる形への変更例 |
|---|---|
| 情報共有を徹底する | 仕様変更を受けた担当者が、その日の業務終了までに変更点と影響する工程を案件欄へ記載し、次工程の担当者へ通知する |
| もっと早く相談する | 必要情報が合意した確認日までにそろわなければ、担当者が不足項目と期限への影響を上司へ伝える |
| 二重チェックを強化する | 今回抜けた項目を確認欄に追加し、提出前に担当者と確認者が同じ版を見た記録を残す |
これらは架空の例です。すべての案件へ同じ期限や確認回数を当てはめるものではありません。安全や契約に関わる対応は既存の基準を守り、必要な承認を得て変更します。チェックを増やす場合は、何の失敗を防ぐのかと、その分どの作業を減らせるかも確認してください。
改善を三つ決めるより、一つを予定へ入れる
会議では多くの案が出ても、実行する人の時間は増えません。まず、影響が大きく、自分たちの権限で変えられ、近いうちに試す機会があるものを選びます。他部署の協力が必要な案は、その部署への相談を次の行動として切り分けます。
実行担当は「全員」ではなく、開始を確認する人を決めます。関係者の協力が必要なら、担当者一人に任せず、誰が何を支援するかも残します。権限の所在が曖昧な場合は、担当と決定者を分ける役割表で確認できます。
議事録には、感想より試行条件を残す
発言の全文を記録するより、次の仕事で迷わず動ける情報を残します。次の表は、仕様変更の共有で手戻りが起きたチームの架空の記入例です。
| 項目 | 記入例 |
|---|---|
| 確かめたいこと | 変更点と影響工程が一か所に書かれていれば、制作前に認識のずれを見つけられるか |
| 試す対象 | 来週開始する二つの標準案件。例外の多い大型案件は別途判断する |
| 行動と担当 | 案件担当者が変更欄を更新し、制作担当者が着手前に確認。上司が開始時の運用を確認する |
| 確保する時間 | 週次会議の経緯説明を短縮し、その時間を着手前の確認へ振り向ける |
| 見る材料 | 変更欄、確認した時点、不足情報、変更連絡にかかった手間 |
| 判断する日 | 二案件の着手後、次の振り返りで継続・修正・終了を決める |
記録には「試行中」と書き、いきなり全社ルールにしないようにします。対象外の案件で必要な確認を省いてよいわけではありません。記録の置き場と閲覧者も決め、顧客情報や個人の相談が不要に広がらないようにしてください。
次回は、実行したかと役立ったかを分けて判断する
チェック欄を埋めたことは実行の確認にはなりますが、手戻りが減った証拠にはなりません。まず予定どおり使えたか、次に必要な情報が届いたか、その結果として仕事がどう変わったかを見ます。
試した件数が少ないときは、「効果があった」と確定せず、今回分かったことと残る不明点を分けます。二件とも問題がなかったとしても、もともと変更が起きない案件だったなら、共有方法の良し悪しは十分に確かめられていません。
- 続ける：使える場面があり、手間に見合う助けになった。次に確認する場面を決める。
- 直す：狙いは合っているが、記入項目や通知先が使いにくい。変える点を絞る。
- やめる：すでに別の手順で足りている、重複作業が増えるなど、続ける理由が薄い。
- 保留する：対象の仕事が発生しなかった。次に試す機会と担当を確認する。
やめた改善を「失敗」として隠す必要はありません。合わない方法が分かったことも、次の選択の材料です。ただし「忙しかった」で毎回保留するなら、上司が実行時間や優先順位を変えられていない可能性を確認します。
振り返りの手法を増やす前に、前回の一件を進める
KPTなどの枠組みを使っても、「気をつける」が並ぶだけなら、用紙を変えるより行動を具体化する必要があります。逆に、課題を出すところで対話が止まるなら、会議の目的や発言を遮る進行を見直します。議論を整理する方法は、結論が出ない会議の進め方が参考になります。
進行や任せ方を学び直したい場合は、管理職の悩み別に選ぶ本で、今つまずいている場面に合う一冊を選ぶ方法を紹介しています。新しい手法を増やすためではなく、次回の振り返りで変えることを一つ決めるために使ってください。
次の振り返りでは、前回の議事録から一つだけ選び、「これは次のどの仕事で、何を変える約束だったか」と確認してみましょう。答えが出なければ、まずその一件を試せる形に直すところから始められます。
