プロジェクトの終わらせ方

プロジェクトは、始めるより終わらせるほうが難しいことがあります。

システムは動いている。主要な機能も出来ている。それなのにいつまでも終わったことにならず、メンバーが少しずつ抜けていく。そういう終わり方をした案件は、誰にとっても後味が悪く残ります。

■ 「終わり」を決めていないから終わらない

終わらないプロジェクトに共通しているのは、完了条件が曖昧なことです。

「安定」「問題がない」「慣れる」は、人によって基準が違います。誰が見ても同じ判断になる形で書き直します。

これは本来、計画の段階でやることです。すでに終盤に来てしまっている場合は、いまからでも関係者と合意し直します。

■ 残件は「行き先」まで決める

完了時点で、残っている課題や要望が必ずあります。リストを作るだけでは終わりません。1件ずつ行き先を決めます。

とくに「やらない」を明確に決めることが大事です。決めずに放置すると、数か月後に「あれはやってもらえるはずだった」という話になります。

「やらない」と決めたものは、誰が決めたかまで記録に残します。これがないと、後で誰も引き受けられません。

■ 運用への引き渡しは、受け取り側の合意が要る

作った側が「引き継ぎ資料を置きました」で終わらせると、運用側は受け取ったつもりがありません。そして問い合わせは、開発メンバー個人に来続けます。

引き渡すものを明確にします。

そのうえで、運用側に内容を確認してもらい、受け取りを書面で合意します。形式は簡単な受領確認で十分ですが、「受け取った」という記録が残ることに意味があります。

■ 問い合わせ窓口を切り替える

引き渡しが形だけになる典型は、問い合わせが今までどおり開発メンバーに来続けることです。

切り替えには、宣言と経過措置の両方が必要です。

• 利用者に対して、「今後の問い合わせ先は◯◯です」と明確に伝える

• 一定期間（1か月程度）は、運用側からの質問を開発側が受ける

• その期間が過ぎたら、開発側への直接連絡は止める

経過措置なしで完全に切ると運用が回りません。逆に期限を切らないと、いつまでも切り替わりません。

■ 記録を残す

次のプロジェクトのために残すものは、次の3つです。

• 実績：計画と実際の工数・期間の差。どの工程で、どれだけずれたか

• 教訓：うまくいったこと、うまくいかなかったこと、次にどうするか

• 成果物の置き場所：設計書・議事録・課題管理表を、どこに保管したか

教訓は、反省文にしません。「次に同じ状況になったらどうするか」という形で書くと、読んだ人が使えます。

実績の記録は地味ですが、次の見積りの根拠になります。ここを残しているかどうかで、組織としての見積り精度が変わります。

■ 解散日を決めて、伝える

最後に、チームをいつ解散するかを決めます。

• メンバーが次の案件にいつから移れるか

• 解散後、質問が出たときは誰に連絡すればよいか

• 成果物の管理は誰が引き継ぐか

解散日を決めずにいると、メンバーは中途半端な状態で次の案件と掛け持ちになり、どちらも進まなくなります。

■ 終わったことを、関係者に伝える

意外と抜けるのが、これです。

完了したことを、関係者に正式に伝えます。内容は次の4点で足ります。

• プロジェクトが完了したこと

• 何が出来たか（簡潔に）

• 今後の問い合わせ先

• 協力してもらった人への謝意

終わりを宣言しないと、関係者の中では「まだ続いている」状態が残ります。

■ まとめ

終わらせることも、PMの仕事です。やることは次の4つです。

• 完了条件を、判断できる形にする

• 残件の行き先を、1件ずつ決める

• 運用への引き渡しを、書面で合意する

• 記録を残して、解散日を伝える

いま終盤にある案件があれば、「何ができたら完了か」が誰の目にも同じに見える形で書かれているかを確認してみてください。