プロジェクトの終結と教訓の蓄積
多くのプロジェクトは、終わるのではなく、消えていきます。稼働日を過ぎ、メンバーが一人また一人と別の案件に移り、気づけば誰も残っていない。終結の手続きを踏まないまま自然消滅する形です。
これが問題なのは、事務手続きが残るからだけではありません。そのプロジェクトで得たものが、何も次に渡らないからです。同じ規模の案件を来年また受注したとき、今回と同じ失敗を繰り返すことになります。
■ 終結でやること
大きく3つに分かれます。契約と事務を閉じること、体制を解くこと、そして知見を残すこと。最初の2つは誰かが催促してくれますが、3つ目は誰も催促しません。だから意識的に計画へ組み込む必要があります。
■ 「終わった」を宣言する
意外に効果があるのが、終了を明示することです。
いつまでも終わらないプロジェクトでは、メンバーが次の仕事に集中できません。問い合わせが来るたびに戻される状態が続き、心理的にも区切りがつきません。「◯月◯日をもって本プロジェクトは終結し、以降は運用・保守体制で対応します」と関係者に通知することで、線が引かれます。
あわせて、その後の窓口を明記します。線を引くだけで受け皿を示さないと、結局は個人に連絡が来続けます。
■ 実績値を記録する
知見を残す作業のうち、最も手軽で、最も効くのがこれです。
当初の見積り工数と、実績工数
当初の期間と、実際の期間
フェーズごとの工数配分
不具合の件数と、発見された工程の内訳
変更要求の件数と、それによる追加工数
これらは集計するだけで、次の案件の類推見積りに使えます。「前回、同規模の案件で見積りの1.3倍かかった」という事実が一行あるだけで、次の見積りの説得力が変わります。
重要なのは、差が出た理由もあわせて書くことです。数字だけ残しても、なぜそうなったかが分からなければ次に活かせません。「要件定義が2か月延びた。原因は決裁者が途中で交代したこと」といった一文が、次のプロジェクトのリスク一覧の1行目になります。
■ 振り返りの進め方
振り返り（レトロスペクティブ）は、やり方を間違えると逆効果になります。犯人探しの場になった瞬間に、誰も本当のことを言わなくなるためです。
KPTという枠組みが広く使われています。Keep（続けること）、Problem（困ったこと）、Try（次に試すこと）の3つに分けて出し合う方法です。単純ですが、Keepから始めることで場の空気が作られ、Problemを出しやすくなります。
進めるうえでの要点は3つです。
「誰が」ではなく「どういう状況だったら防げたか」を問う：個人の注意不足に帰着させると、対策が「気をつける」で終わる
解散する前にやる：メンバーが散ってからでは集まらない。稼働後の落ち着いた時期に日程を押さえておく
Tryを具体的な行動にする：「コミュニケーションを改善する」ではなく「キックオフで決裁者を必ず特定する」のように、次回そのまま実行できる形にする
■ 教訓を「読まれる場所」に置く
振り返りの最大の失敗は、議事録を作って終わることです。誰も読まない場所に置かれた教訓は、存在しないのと同じです。
現実的な工夫はいくつかあります。プロジェクト計画のテンプレートにチェック項目として組み込む。リスク一覧の初期版に、過去に顕在化したリスクをあらかじめ入れておく。キックオフの資料に「過去案件からの教訓」の一枚を入れる。
文書として残すよりも、次のプロジェクトの手順に埋め込むほうが確実に伝わります。読む努力を必要としない形にするということです。
■ メンバーへの還元を忘れない
終結は、事務作業であると同時に、人に関する作業でもあります。
関わったメンバーに、何がうまくいき、何が評価されたのかを伝えます。とくに社外のメンバーや他部門からの応援については、その人の上長に貢献を伝えると、次に協力を仰ぎやすくなります。
プロジェクトは一度きりでも、人との関係は続きます。終わり方は、次のプロジェクトの始めやすさに直結します。
■ チェックリスト
検収と受領の手続きが完了しているか
運用・保守への引き継ぎが完了しているか
終結の宣言と、以降の窓口を関係者に通知したか
見積りと実績の差、その理由を記録したか
解散前に振り返りを実施したか
Tryが具体的な行動になっているか
教訓を次の手順・テンプレートに反映したか
メンバーと、その上長に貢献を伝えたか
終結は、プロジェクトの中で最も省略されやすい工程です。納品が済めば成果は出ているため、誰も困らないように見えます。しかし、ここを省いた組織は毎回ゼロから始めることになります。終わらせ方を決めておくことは、次を楽にするための投資です。