プロジェクト実務
プロジェクトが終わっても教訓が残らないとき:レッスンズラーンド記録チェックリストと引き継ぎテンプレート
レッスンズラーンド記録チェックリスト
教訓(レッスンズラーンド)は、プロジェクトが終わってから思い出して書くものではない。起きた時点でこの項目を埋める記録シートを先に用意しておけば、終結のタイミングでまとめて作文する作業自体がなくなる。
レッスンズラーンド記録シートに書く項目
| 項目 | 記入すること | 運用上の要点 |
|---|---|---|
| Lesson ID | 通し番号 | 後から検索・参照できるよう一意の番号を振る |
| カテゴリ | スコープ・スケジュール・コスト・品質・リスク・ステークホルダー・調達のいずれか | 分野を絞ると、次のプロジェクトで同じ分野の担当者が検索しやすくなる |
| 事実の記述 | 何が起きたかを、原因・事象・影響の3点に分けて書く | 「うまくいかなかった」とだけ書いても次に使えない。原因と結果を分けて書く |
| 影響度 | プロジェクト目標(コスト・納期・品質)への影響 | 金額や日数で書けるものは数値で書く。感覚的な評価だけで終わらせない |
| 推奨アクション | 次に同じ状況が起きたとき、何を変えるか | 「注意する」は推奨アクションにならない。担当・判断基準・手順のいずれかを具体的に変える案を書く |
| 記録者・記録日 | 誰が、いつ書いたか | 経験が新しいうちに書いた記録ほど価値が高い。終結時にまとめて書くと細部が落ちる |
| ステータス | ドラフト/レビュー済み/組織のリポジトリへ提出済み | 「提出済み」にならない記録は、次のプロジェクトのPMの目に触れない |
振り返り会議の進め方:6ステップ
記録シートの項目を担当者1人で埋めても、チーム全員の記憶は拾いきれない。レトロスペクティブの技法を会議形式で使い、チームから引き出す。
振り返り会議(レッスンズラーンド会議)の6ステップ
- STEP1準備する目的と成果物を決め、参加者を選ぶ。事前アンケートで、各自の気づきを匿名で下書きさせておくと当日の発言が出やすくなる。
- STEP2各自が黙って書き出す「うまくいったこと」「うまくいかなかったこと」を、発言ではなくまず各自が黙って書く。声の大きい参加者の意見に全体が引っ張られるのを防ぐ。
- STEP3グループ化する出た意見をトピック別にまとめる。似た指摘が複数人から出たトピックほど、組織的な課題である可能性が高い。
- STEP4匿名で投票する深掘りするトピックの優先順位を、匿名投票で決める。限られた時間ですべてのトピックを討議できないため、ここで絞り込む。
- STEP5優先度の高いトピックから討議する「なぜ」を繰り返し、表面的な事象ではなく根本原因まで掘り下げる。全員が発言できるよう時間を区切る。
- STEP6アクションに変換するトピックごとに、担当者と期限を持つ具体的なアクションアイテムに変換する。「次は気をつける」で終わらせない。
引き継ぎドキュメントのテンプレート:何を渡すか
引き継ぎで最も多い誤りは、文書を渡すことと知識を移すことを同じ扱いにすることである。コードやマニュアルは「システムがどう動くはずか」を説明できても、「運用担当者が実際に何を知っておくべきか」までは説明できない。文書に加えて、次の担当者と顔を合わせる知識移転セッションを最低1回は設定する。
引き継ぎドキュメントに書く項目
| 区分 | 記載する内容 | 引き継ぎ時の要点 |
|---|---|---|
| プロジェクト概要 | 目的・スコープ・契約形態・完了状況 | 次の担当者が初見で全体像をつかめる分量で書く |
| ステークホルダー一覧 | 関係者の役割と連絡先 | 引き継ぎ直前に在籍・連絡先を確認してから渡す。古い連絡先は緊急時に使えない |
| 成果物ステータス | 成果物ごとの完成度と検収状況 | 「完了」「一部保留」を成果物単位で明示する |
| 未解決タスク | 保留中の承認・残作業・変更要求の一覧 | ここを空欄のまま渡すと、次の担当者が「終わった」と誤認する |
| 財務サマリー | 予算対実績・承認済み変更・未精算の金額 | 契約・支払いの後始末が残ったまま引き継がれる事故を防ぐ |
| 重要文書の所在 | 契約書・議事録・検収記録・運用マニュアルの保管場所 | 文書そのものではなく「どこにあるか」が引き継ぎでは重要になる |
| リスク登録簿の引き継ぎ | 残存リスクと、監視中のトリガー | 対応済みで終わっていないリスクを明示的に渡す |
| 教訓の要約 | レッスンズラーンド記録シートから拾った、次の担当者がすぐ使える推奨アクション | 記録シート全件ではなく、次の担当者の意思決定に関わるものに絞って抜粋する |
なぜ教訓は残らないのか
レッスンズラーンドという言葉自体は、ほとんどのプロジェクトで知られている。それでも組織に蓄積されないのは、仕組みの作り方に共通の欠陥があるからである。
第一に、記録のタイミングが終結時の1回だけになっていることである。プロジェクトが終わる頃には、途中で起きた細かい判断の経緯は忘れられている。残るのは結果の印象だけで、「スケジュールが厳しかった」のような抽象的な記述しか出てこない。
第二に、推奨アクションが具体性を欠くことである。「次は気をつける」「もっと早く着手する」は、担当・判断基準・手順のどれも変えていない。同じ状況になったとき、また同じ選択をしてしまう。
第三に、オーナーが個人名で指定されないことである。「チーム全体の学び」として記録すると、誰もその教訓を次のプロジェクトに持ち込む責任を負わない。
第四に、組織のリポジトリに提出されないことである。担当者の手元のファイルに残ったままでは、次のプロジェクトのPMがその教訓に出会う機会自体がない。
第五に、率直な発言を妨げる文化である。失敗を報告した人が責められる環境では、記録される内容は無難な表現に丸められ、実際に再発防止へつながる具体的な事実は出てこなくなる。
レッスンズラーンドと引き継ぎは、終結プロセスの一部でもある
教訓の記録と引き継ぎは、プロジェクトが終わる段階でまとめて発生する作業ではない。PMBOK®ガイドが示す枠組みでも、終結(クロージング)はプロジェクトの管理活動を区分する5つの区分の最後にあたり、教訓の整理と、成果物・権限を次の担当者へ移す作業がここに含まれる。第8版で整理された7つのパフォーマンス領域を含む標準の全体構造は、PMBOK®第8版の7つのパフォーマンス領域を、実際の作業に落とすにまとめている。
契約そのものの終結手続き(検収・未決済請求の解消・クローズアウトパッケージの作成)は、ベンダー選定で揉めないために:契約タイプの選び方から契約終結までの実務チェックリストの契約終結チェックリストで扱っている。本記事が扱うのは、契約の後始末ではなく、プロジェクト全体として何を学び、何を次の担当者に渡すかという、終結のもう一方の軸である。
いつ記録するか:終結時ではなく、随時
レッスンズラーンド登録簿は、プロジェクトの終わりに作る文書ではなく、プロジェクト全体を通じて随時更新される活動文書である。大きなマイルストーンの直後、フェーズの切り替わり、重大な課題が解決した直後、あるいは効果的なやり方が見つかった時点で、その都度1行を書き足す運用が実際に機能する形である。終結時にまとめて書こうとすると、経験が新鮮なうちに捉えられる具体性が失われる。
この随時記録という発想は、アジャイル開発のスプリントレトロスペクティブと同じ構造を持つ。スクラムガイドは、レトロスペクティブの目的を「品質と有効性を向上させる方法を計画すること」と定め、1か月のスプリントに対して最大3時間という時間枠で、スプリントごとに固定して実施すると規定している。スクラム運用実務ガイドで扱ったとおり、終結時の1回だけに頼らず、区切りごとに振り返りを固定の時間枠で回す設計は、この随時記録と同じ発想である。ウォーターフォール型のプロジェクトであっても、マイルストーンやフェーズゲートのたびに同じ発想で振り返りの枠を固定しておくと、終結時の作業が大幅に減る。
記録の中身も、他の実務手順とつながっている。対応済みのリスクと、対応したが残った残存リスクは、リスク管理の実務手順で作成したリスク登録簿から、そのままレッスンズラーンド記録シートのカテゴリ「リスク」に転記できる。リスク登録簿とレッスンズラーンド記録シートを別の作業として一から始める必要はない。
引き継ぎでよくある5つの失敗
レッスンズラーンドの記録と引き継ぎのそれぞれで、同じ失敗が繰り返されている。
終結・引き継ぎで繰り返される5つの失敗
| 失敗 | 何が起きるか | 対応 |
|---|---|---|
| 教訓を終結の1回だけでまとめようとする | 途中の判断の経緯を忘れ、「次は気をつける」という抽象的な記述しか出てこない | マイルストーンやフェーズの切り替わりのたびに記録シートへ1行足す運用に変える |
| 引き継ぎドキュメントを渡すだけで終わる | 書いた本人の暗黙知が伝わらず、次の担当者が同じ質問を繰り返す | ウォークスルー形式の知識移転セッションを最低1回は設定する |
| ステークホルダー一覧の連絡先が古いまま渡される | 緊急時に連絡が取れない、あるいは退職済みの担当者が窓口のまま残る | 引き継ぎの直前に全件の在籍・連絡先を確認してから渡す |
| 教訓が個人の手元ファイルに残り、組織のリポジトリに提出されない | 次のプロジェクトのPMが同じ教訓に出会わないまま、同じ失敗を繰り返す | 記録シートのステータスを「提出済み」まで追跡し、未提出のまま放置しない |
| 未解決タスクと財務の未精算が引き継ぎ文書に書かれない | 「完了」と誤認したまま、契約・予算の後始末が放置される | 未解決タスクと財務サマリーを引き継ぎ文書の必須項目として固定する |
出典・参考
公開情報および各機関の一次情報をもとに、PMアンカー編集部が作成・更新しています。事実関係は出典を明記し、内容は定期的に見直しています。