プロジェクト完了チェックリスト

英語名 Project Closure Checklist
読み方 プロジェクト クロージャー チェックリスト
難易度
所要時間 1〜3日
提唱者 PMBOKの終結プロセス群
#プロジェクト完了 #ナレッジ管理 #振り返り
目次

ひとことで言うと
#

プロジェクト終了時に行うべき作業を**「成果物の確認」「契約・会計の締め」「教訓の記録」「チームの解散」の4領域で体系化した**チェックリスト。「終わったはずなのに残務が出てくる」「同じ失敗を次のPJで繰り返す」を防ぐ。

押さえておきたい用語
#

押さえておきたい用語
成果物受領（Acceptance）
クライアントやスポンサーが成果物を正式に受け入れたことを文書で確認する手続き。
教訓（Lessons Learned）
プロジェクトで得られた成功・失敗の経験を将来のPJに活かすために記録したもの。
残務処理（Punch List）
主要な成果物は完成しているが未完了の小さな作業や修正が残っている一覧を指す。
アーカイブ
プロジェクトの全文書・データを将来の参照に備えて整理・保管する作業である。

プロジェクト完了チェックリストの全体像
#

4領域の完了処理
1. 成果物の確認□ 全成果物の検収完了□ 残務リスト（Punch List）の消化□ 受領書への署名□ 保証期間・サポート範囲の合意2. 契約・会計の締め□ 最終請求書の発行・支払い□ 外注・ベンダー契約の終了確認□ 予算の最終精算□ ライセンス・サブスクの解約3. 教訓の記録□ 振り返り会議の実施□ 教訓シートの作成・登録□ 実績データの記録（工数・コスト）□ ナレッジDBへの登録4. チームの解散□ メンバーの次アサイン確認□ アクセス権限の回収□ 共有ドライブのアーカイブ□ メンバーへの感謝・評価完了処理の漏れは「終わったはずのPJ」からの手戻りコストを生む
プロジェクト完了処理の進行フロー
1
残務の洗い出し
Punch Listを作成し、未完了項目を全て列挙
→
2
検収・精算
成果物の受領確認と契約・予算の最終締め
→
3
振り返り・教訓
チーム全員で成功・失敗を振り返り記録
→
★
アーカイブ・解散
文書を整理・保管し、メンバーを正式にリリース

こんな悩みに効く
#

  • プロジェクトが「なんとなく終わった」状態で、残務が半年後に出てくる
  • 同じ種類のプロジェクトで同じ失敗を繰り返している
  • 終了後もメンバーが「旧PJの問い合わせ対応」に時間を取られている

基本の使い方
#

完了2週間前にチェックリストを配布する

プロジェクト終了予定日の2週間前にチェックリストを全メンバーに共有し、担当を割り振る。

  • 成果物の確認: PM＋クライアント窓口
  • 契約・会計の締め: PM＋経理
  • 教訓の記録: PM＋チームリーダー
  • チームの解散: PM＋部門マネージャー

各項目に期限を設定し、毎日のスタンドアップで進捗を確認する。

振り返り会議を実施し教訓を記録する

チーム全員が参加する振り返り会議（60〜90分）を実施する。

  • Keep（続けたいこと）: 上手くいったプラクティスは何か
  • Problem（問題だったこと）: 苦労した点、繰り返したくないこと
  • Try（次に試したいこと）: 改善アイデア

教訓は「事実 → 原因 → 対策」のフォーマットで記録し、社内のナレッジDBに登録する。記録しただけで終わらせず、次のPJのキックオフで参照するルールを設ける。

アーカイブとリソースリリースを完了する

プロジェクトの全文書・データを整理し、所定の場所に保管する。

  • 共有ドライブのフォルダ構成を整理し、READMEを書く
  • 開発環境・ステージング環境のアクセス権限を回収
  • PJ専用のSlackチャンネルやJIRAボードをアーカイブ
  • メンバーの次アサインを部門マネージャーと確認し、正式にリリース
  • PMからメンバーへの感謝メッセージ（口頭またはメール）を送る

具体例
#

例1：Web制作会社が納品後の手戻りをゼロにする

状況: 年間50件のWeb制作案件を手がける会社。納品後に「ここが動かない」「このページが抜けている」と言われるケースが 年12件（24%）。PMが個人の記憶に頼って完了処理しており、チェック漏れが原因。

標準チェックリストの導入

  • 全50項目のチェックリストをNotionテンプレート化
  • 各案件の完了時にPMがテンプレートを展開し、1項目ずつ消化
  • 特に効果が大きかった項目：「全ページのクロスブラウザ動作確認」「CMSの管理者アカウント引き渡し」「ドメイン・SSL更新のリマインダー設定」
指標導入前導入1年後
納品後の手戻り件数年12件年2件
完了処理の平均所要時間5時間（属人的）3時間（標準化）
クライアント満足度3.8/5.04.5/5.0
例2：製造業の大型PJで教訓DBが次のPJを救う

状況: 工場増設PJ（予算5億円・18か月）が完了。PMBOKに沿ったクロージングを実施し、教訓を50項目記録した。

教訓が次のPJで活きた事例

  • 前回の教訓：「空調設備の発注リードタイムが想定の2倍（6か月）かかり、工期が1か月延伸した」
  • 次のPJのキックオフで教訓DBを参照 → 空調発注をPJ開始直後に前倒し
  • 結果：次のPJでは工期遅延ゼロで完了

教訓DBへの登録率を 100% にするため、「教訓が未登録のPJは完了承認しない」ルールを導入。2年間で 120件 の教訓が蓄積され、類似PJの見積もり精度が 平均15% 向上した。

例3：スタートアップが解散プロセスでセキュリティリスクを防ぐ

状況: 50名のスタートアップ。外部委託で進めたアプリ開発PJが完了したが、委託先のエンジニア5名のGitHub・AWS・Slackアクセス権限がそのまま残っている。退職者のアクセス権限も放置されていたことが監査で発覚。

チェックリストにセキュリティ項目を追加

  • GitHub Organization からの委託先メンバー削除
  • AWS IAMユーザーの無効化
  • Slack ゲストアカウントの削除
  • 開発用APIキーのローテーション
  • 委託先との秘密保持契約（NDA）の終了確認

チェックリスト導入後、PJ完了時のアクセス権限の回収漏れは 0件 に。「以前はPJが終わってもSlackにログインできたが、今はちゃんと整理されるようになった」と委託先からもポジティブな反応があった。

やりがちな失敗パターン
#

  1. 振り返り会議をスキップする — 「忙しいから」と省略すると、教訓が蓄積されず同じ失敗を繰り返す。完了処理の中で最も価値の高いステップ
  2. チェックリストが長すぎて形骸化する — 100項目を超えると誰も真面目にチェックしない。PJの種類に応じて30〜50項目に絞り込む
  3. アクセス権限の回収を忘れる — 退職者や外部委託先のアクセスが残ったままになると、セキュリティインシデントのリスクが高まる
  4. 完了の正式な承認を取らない — 「口頭でOKをもらった」は証拠にならない。受領書やメールでの正式承認を必ず取得する

まとめ
#

プロジェクト完了チェックリストは「きれいに終わる」ための仕組みだ。成果物・契約・教訓・チームの4領域を漏れなく処理することで、終了後の手戻りを防ぎ、教訓を次のPJに引き継ぐ。特に振り返りの記録とアクセス権限の回収は見落とされやすいが、組織にとって長期的に最も価値が大きい項目になる。

↑ 目次に戻る