はじめに
プロジェクトの立ち上げや計画については多くの手法や資料がありますが、「プロジェクトをどう終わらせるか」については、意外なほど語られることが少ないものです。本番稼働を迎えたあと、なんとなくプロジェクトチームが解散し、気づけばベンダーとの契約も終わっていた——という終わり方をしているプロジェクトは珍しくありません。
しかし、クロージングをきちんと行わないと、後から「検収が終わっていない成果物があった」「ベンダーに預けたデータがそのまま残っていた」「誰が運用を担当するのか曖昧だった」といった問題が表面化します。プロジェクトの「終わりの定義」を決めておくでは、完了基準を事前に定義しておく重要性を整理しました。今回はその続きとして、実際にクロージングの段階で発注側が何をやるべきかを、具体的なタスクとして整理します。
プロジェクトクロージングとは何か
プロジェクトクロージングとは、プロジェクトを正式に終了させるための一連の活動のことです。PMBOKなどのプロジェクトマネジメントの体系でも、終結のプロセスとして位置づけられています。具体的には、次のような活動が含まれます。
- 成果物が完成し、受け入れられたことの確認
- 契約上の義務の完了と、支払い・精算
- 運用体制への移管
- 記録の整理と保管
- 振り返りと教訓の共有
- 体制の解散とリソースの解放
これらは、どれもベンダーだけで完結するものではありません。むしろ、最終的な判断と承認を行うのは発注側です。ベンダーは「納品しました」と言えば一区切りつきますが、発注側は「受け取ったものを、この先も使い続けられる状態にする」ところまで責任を持つ必要があります。
発注側がやるべきクロージングの6つのタスク
タスク1：成果物の最終確認と検収
まず、契約上の成果物がすべて納品され、検収が完了しているかを確認します。プロジェクト終盤は本番稼働への対応に追われ、ドキュメント類の検収が後回しになっていることがよくあります。
- 契約書・仕様書に記載された成果物の一覧を作り、1つずつ納品状況を確認する
- プログラムだけでなく、設計書・運用手順書・テスト結果報告書なども対象に含める
- 「暫定版」のまま納品されているドキュメントが最終版に更新されているかを確認する
検収基準を曖昧にすると起きることで触れたとおり、検収は契約上の大きな節目です。検収後に見つかった不具合は、契約不適合責任の範囲で対応を求めることになるため、検収日と、その時点で把握していた未解決事項の扱いを記録として残しておくことが重要です。
タスク2：残課題の扱いを決める
本番稼働時点で、すべての課題が解決していることはまずありません。課題管理表に残っている未解決課題について、1件ずつ扱いを決めます。
- プロジェクト内で解決する：クロージングまでに対応を完了させる
- 運用保守に引き継ぐ：保守契約の範囲で対応してもらう。誰が、いつまでに対応するかを明記する
- 次期プロジェクト・改善案件に回す：機能追加などは別案件として予算化を検討する
- 対応しない：影響が小さく、運用でカバーできるものは、その判断と理由を記録して閉じる
ここで曖昧なまま残した課題は、プロジェクトチームの解散とともに「誰も覚えていない課題」になります。すべての未解決課題に「行き先」を決めることが、クロージングの最も重要な作業の一つです。
タスク3：運用保守体制への移管
システムを使い続けるためには、プロジェクトチームから運用保守体制への正式な移管が必要です。
- 運用保守の担当部門と担当者が決まっているか
- 運用手順書・障害対応手順が整備され、担当者が理解しているか
- 保守ベンダーとの契約が開始されているか（開発ベンダーと保守ベンダーが異なる場合は特に注意）
- 問い合わせ窓口が利用部門に周知されているか
保守・運用フェーズで揉めるベンダーとの関係で触れたように、保守の範囲が曖昧なまま運用に入ると、トラブルの原因になります。移管の段階で、保守契約の範囲と、プロジェクトで対応すべきものの境界を明確にしておいてください。
タスク4：契約・費用の精算
ベンダーとの契約を正式に完了させ、費用を精算します。
- 最終の支払いが契約どおりの条件（検収後の支払いなど）で行われているか
- 追加費用や変更契約が、すべて正式な手続きを経ているか
- 予算の執行実績を集計し、当初予算との差分とその理由を整理する
予算の実績は、コスト管理の基本で触れた「追うべき数字」の最終結果でもあります。社内の予算管理上も、プロジェクト予算を締めて運用予算に切り替えるタイミングを明確にしておく必要があります。
タスク5：データ・アカウント・情報資産の整理
見落とされがちですが、セキュリティの観点から非常に重要なのがこのタスクです。
- ベンダーに提供したデータ（テストデータ、移行用データ、本番データのコピーなど）の返却または削除を依頼し、完了報告を受ける
- プロジェクト用に発行したアカウント（ベンダー要員のVPN、各種システムの管理者権限など）を棚卸しし、不要なものを停止する
- プロジェクトで使った共有フォルダ・チャットツールのアクセス権を見直す
NDA（秘密保持契約）で発注側が注意すべきポイントで触れたように、契約終了時のデータの返却・破棄は契約書に定めておくべき事項ですが、定めていても発注側から依頼しなければ実行されないことがあります。プロジェクトが終わった後に、委託先に残っていたデータから情報が漏えいするという事例は、実際に起きています。「契約が終わった＝データも消えた」とは考えず、完了報告まで確認してください。
タスク6：記録の保管と振り返り
最後に、プロジェクトの記録を整理して保管し、振り返りを行います。
- 計画書、議事録、各種管理表、成果物を、後から参照できる場所に整理して保管する
- 主要な意思決定とその理由を、一覧として残す
- 振り返りを実施し、教訓を次のプロジェクトに引き継ぐ
振り返りの進め方は、基幹刷新プロジェクトの振り返り（ポストモーテム）のやり方で詳しく整理しています。クロージングの段階で振り返りの日程まで確保しておかないと、メンバーが次の業務に移ってしまい、実施できなくなることが多いので注意してください。
クロージングを確実に進めるための工夫
クロージングを「フェーズ」として計画に入れる
クロージングが疎かになる最大の原因は、計画上にクロージングの期間と工数が確保されていないことです。本番稼働をプロジェクトの最終マイルストーンにするのではなく、稼働後に数週間〜1か月程度の「クロージングフェーズ」を計画段階から設けておくことをお勧めします。
クロージングのチェックリストを作る
上記の6つのタスクをチェックリストにし、それぞれに担当者と期限を設定します。最終的に、プロジェクトオーナーがチェックリストの完了を確認して、プロジェクトの終了を正式に承認する、という流れにしておくと、終わり方が曖昧になりません。ゲートレビュー（フェーズ移行判定）の設計と同じ考え方で、「終了判定」を一つのゲートとして扱うイメージです。
関係者に「終わった」ことを伝える
意外と忘れられがちなのが、プロジェクトの終了を関係者に正式に伝えることです。経営層、利用部門、ベンダーに対して、プロジェクトが終了したこと、今後の問い合わせ先が運用保守体制に変わったことを明確に伝えておかないと、いつまでもプロジェクトメンバーに問い合わせが来続けます。
まとめ
プロジェクトクロージングは、本番稼働で自然に訪れるものではなく、発注側が意図して進める必要がある活動です。成果物の検収、残課題の行き先の決定、運用保守体制への移管、契約・費用の精算、データやアカウントの整理、記録の保管と振り返りという6つのタスクを、計画段階からクロージングフェーズとして確保し、チェックリストで管理することで、「なんとなく終わったプロジェクト」を防ぐことができます。
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント