この記事で分かること
- 完了した課題の中から、振り返る対象を絞る方法
- 遅れや差し戻しの原因を、次の改善につなげる考え方
- 次の案件でも使える手順や資料、見直すルールの残し方
案件を完了しても、すぐ次の仕事へ移るだけでは、同じ確認漏れや手戻りを次の案件でも繰り返しやすくなります。一方、すべての課題を読み直す長い反省会は負担が大きく、続きません。
完了後の振り返りで大切なのは、記録を網羅することではありません。次の案件でも役立つ課題だけを選び、次回変えることを一つ決めることです。
完了しただけでは次の案件は楽にならない
案件中は目の前の期限を守ることが優先されるため、「なぜ差し戻されたか」「どの資料が役立ったか」を整理する余裕がありません。案件が終わった直後に振り返らなければ、判断の理由や困った場面を忘れていきます。
振り返りをしないと、次の案件でも次のような状況が起こります。
- 完了条件が曖昧なまま課題を登録する
- 同じ確認漏れによる修正が発生する
- クライアントからの返答待ちを予定へ入れていない
- 前回作った確認手順や資料を探し直す
- 使われなかった入力項目や会議をそのまま続ける
- 遅れの原因を「忙しかった」で終わらせる
振り返りは、過去の評価ではなく、次回の準備として行います。
プロジェクトをアーカイブする前に振り返る
振り返りは、納品や公開が終わり、関係者が経緯を覚えているうちに行います。Tasselに振り返り専用の画面がある前提にはせず、プロジェクトをアーカイブする前に、課題一覧、課題詳細、コメント、添付ファイル、マイルストーンを確認します。
完了直後であれば、コメントだけでは分からない判断の背景も担当者へ確認できます。時間がたってから全課題を調べ直すより、案件終了時に短い時間を設ける方が負担を抑えられます。
振り返りの日時と参加者を大きな会議として設定する必要はありません。小規模な案件なら、終了時に15分から30分程度、遅れや差し戻しなど、振り返る理由がある課題だけを見る方法でも十分です。
振り返る課題を絞る
問題なく完了したすべての課題を、一件ずつ読み直す必要はありません。まず課題一覧から、次の対象を選びます。
- 期限を過ぎた課題
- 差し戻しや修正が繰り返された課題
- 担当者の変更や引き継ぎがあった課題
- 外部からの返答を長く待った課題
- 完了条件の捉え方が人によって異なった課題
- 次の案件でも繰り返す可能性がある課題
- 予定より大幅に早く、または想定より少ない手間で完了できた課題
課題一覧から、遅れ・差し戻し・引き継ぎなど、次の案件へ残したい課題を選びます。
完了課題だけでなく、途中で不要になった課題も対象になります。不要になった理由が分かれば、次回は最初から作らずに済む場合があります。
想定より早く進んだ課題からは、再利用できる手順や、見積もりを短縮できた理由を確認します。問題だけでなく、次回も続けたい進め方を見つけることも振り返りの目的です。
予定と実際の違いを見る
振り返る課題を選んだら、最初の予定と実際の進み方の違いを確認します。
予定時間と実績時間を入力している場合は、その差を一つの判断材料にできます。ただし、時間の差だけで良し悪しを決めません。確認回数、待ち時間、途中で増えた作業も合わせて見ます。
確認する内容は次のとおりです。
- 想定していた作業と、実際に必要になった作業
- 最初の担当者と、実際に対応した担当者
- 予定時間と実績時間
- 当初の完了条件と、最終的に確認した内容
- 作業中に追加された確認や修正
期限を変更した場合、現在の期限だけを見ても当初予定との差は分かりません。Tasselが過去の期限を振り返り用に自動保存・比較する前提にはせず、日程を変えた理由や判断をコメントから確認します。次回の振り返りでも確認したい変更は、今後コメントへ残す運用にします。
遅れや差し戻しの原因を分ける
遅れた課題を見つけても、「担当者が遅かった」で終わらせると改善につながりません。仕事が止まった地点と、その時点で不足していたものを確認します。
原因は、たとえば次のように分けられます。
- 情報不足：原稿、仕様、対象範囲がそろっていなかった
- 完了条件の曖昧さ：どこまで確認すれば終わりか決まっていなかった
- 担当の集中：同じ担当者へ期限の近い課題が重なっていた
- 確認待ち：社内確認やクライアント確認の担当・期限が決まっていなかった
- 外部返答待ち：次回確認日や、返答がない場合の行動がなかった
- 課題の大きさ：異なる担当者や期限の作業が一件に混ざっていた
- 見積もりとの差：確認や差し戻しに必要な時間を含めていなかった
一つの課題に複数の原因がある場合もあります。誰の責任かを決めるのではなく、次回はどの情報や判断を早く用意すれば止まりにくいかを考えます。
繰り返し発生した修正を確認する
同じ種類の差し戻しが複数の課題で起きている場合は、個別のミスではなく、最初の確認方法に原因がある可能性があります。
Web制作なら、次のような修正を確認します。
- 支給原稿とデザイン上の文章が一致していない
- スマートフォン表示の確認が最後になった
- リンク先やフォーム通知先の確認が漏れた
- 公開対象外のページまで変更した
- クライアント確認前に実装を進め、手戻りが発生した
繰り返し発生した内容は、次回の完了条件、課題の詳細、確認手順のいずれかへ追加します。一度だけ起きた例外のために、すべての課題へ新しい入力項目を増やす必要はありません。
再利用できる資料と手順を残す
完了課題のコメントや添付ファイルには、次の案件でも使える情報が残っていることがあります。
- 公開前の確認項目
- フォーム送信テストの手順
- 原稿や画像を受け取るときの確認事項
- クライアント確認を依頼するときの文面
- 担当者変更時の引き継ぎ項目
- よく起きる差し戻しへの確認方法
課題詳細のコメントや添付ファイルから、次の案件でも使える手順や資料を確認します。
Tasselが資料を別のプロジェクトへ自動転用する前提にはしません。再利用する資料は、必要に応じてチームの共有場所へ整理し、次の案件から参照できるようにします。
クライアント名、連絡先、未公開情報、認証情報など、案件固有または機密性のある内容はそのまま転用しません。再利用する前に不要な情報を除き、誰が更新する資料かも決めます。
不要だった入力や確認ルールを外す
振り返りでは、足りなかったものだけでなく、使われなかったものも確認します。
- 入力したが、誰も判断に使わなかった項目
- 同じ内容を複数の場所へ記録していたルール
- 毎日確認する必要がなかった項目
- 読み上げるだけで判断につながらなかった進捗確認
- 細かく分けすぎて、更新されなかった課題
次の案件でも使う理由を説明できないものは、共通ルールから外す候補です。必要な案件だけで使う方法へ変えることもできます。
ルールを増やすだけでなく、不要なものを減らすと、次の案件を軽く始められます。
次の案件で変えることを一つ決める
振り返りで多くの問題が見つかっても、一度にすべて変えようとすると運用が定着しません。次の案件で効果を確認したい変更を一つ選びます。
たとえば、次のように具体化します。
- 課題を登録するとき、詳細へ完了条件を一文で書く
- 外部へ確認を送った日に、次回確認日をコメントへ残す
- デザイン作成とデザイン確認を、担当者が異なる場合は別課題にする
- 公開前確認をマイルストーンの期限より前に終える
- 期限未設定の課題を週初めに確認する
- 使われなかったカテゴリを次の案件では作らない
「連携を改善する」「早めに対応する」のような抽象的な目標ではなく、誰が、いつ、何を変えるかが分かる形にします。
選ばなかった改善案をすべて管理対象として残す必要はありません。影響が大きく、次の案件で試せるものを優先します。
プロジェクト終了時の短い振り返りルール
振り返りは、次の流れで短く行います。
- プロジェクトをアーカイブする前に行う
- 課題一覧から、遅れ・差し戻し・引き継ぎ・返答待ちがあった課題を選ぶ
- コメント、添付ファイル、必要に応じて予定時間・実績時間を確認する
- 予定と異なった理由を、情報・担当・確認・課題の大きさなどに分ける
- 次回も使える手順や資料を共有場所へ整理する
- 不要だった入力や確認を外す
- 次の案件で変えることを一つ決める
振り返り結果を長い報告書にする必要はありません。次の案件を始めるときに確認できる場所へ、「続けること」「やめること」「次回変えること」を短く残します。
案件開始時に決める内容は、Web制作案件を始めるときに決めておきたいタスク管理ルールで紹介しています。管理ルール自体が重くなっている場合は、小規模チームでタスク管理のルールを増やしすぎない方法も参考にしてください。
まとめ
完了後の振り返りでは、すべての課題を読み直さず、遅れ、差し戻し、引き継ぎ、返答待ち、次回も繰り返す作業があった課題へ対象を絞ります。予定と実際の違いを見て、原因を情報不足、確認待ち、担当集中、完了条件の曖昧さなどに分けます。
再利用できる手順や資料は、案件固有情報や機密情報を除いて共有場所へ整理します。同時に、使われなかった入力項目や確認ルールを外します。
最後に、次の案件で変えることを一つだけ、具体的な行動として決めます。短い振り返りを次の案件の開始準備につなげることで、同じ手戻りを減らし、続けやすい運用へ整えられます。