はじめに
プロジェクトの「完了」とは、具体的にどの状態を指すのでしょうか。本番稼働した時点なのか、並行稼働が終わった時点なのか、それとも現場での定着が確認できた時点なのか——この「終わりの定義」を明確にしないまま進めているプロジェクトは、実務の現場で意外と多く見られます。
完了基準が曖昧だと起きること
プロジェクトの完了基準が曖昧なまま進めると、次のような問題が起きます。
- プロジェクトチームの体制をいつ解散してよいのかの判断がつかず、だらだらと維持コストがかかり続ける
- 経営層やステークホルダーの間で「もう終わったはず」「まだ終わっていない」という認識のズレが生じる
- プロジェクトとしての振り返り（ポストモーテム）を実施するタイミングを逃し、結局やらずに終わってしまう
- 予算の精算・プロジェクト予算の切り替えタイミングが判断できない
基幹刷新の本当のゴールは「稼働」ではなく「定着」でも触れたとおり、「稼働」と「完了」は本来別物であるにもかかわらず、多くの現場でこの区別が曖昧なまま進んでしまいます。
「終わりの定義」に含めるべき観点
プロジェクトの完了基準は、少なくとも次の観点から具体的に定義しておくことをおすすめします。
① 成果物の観点
当初計画していた成果物が、すべて納品・検収されているか。一部の機能が未完成のまま「ひとまず稼働」という形になっていないか。
② 定着・移管の観点
新システムの運用が、プロジェクトチームから定常的な運用保守体制に正式に移管されているか。基幹刷新の本当のゴールは「稼働」ではなく「定着」で触れた定着の指標を満たしているか。
③ 契約・予算の観点
ベンダーとの契約が正式に完了し、最終的な支払いが完了しているか。プロジェクト予算が精算され、運用フェーズの予算に切り替わっているか。
④ 振り返りの観点
プロジェクトの振り返り（ポストモーテム）が実施され、得られた教訓が組織の資産として記録されているか。
完了基準は、プロジェクト開始時に合意しておく
完了基準は、プロジェクトが終盤に差し掛かってから慌てて議論するのではなく、プロジェクト開始時点（プロジェクト計画書やプロジェクト憲章の作成時）に、関係者間で合意しておくことが重要です。終盤になって完了基準を議論すると、「早く終わらせたい」という心理的なプレッシャーの中で、基準が甘く設定されてしまうリスクがあります。
「もう後戻りできない」空気に流されないために｜カットオーバー判定基準を事前に決めるで触れた考え方と同様に、プロジェクトの完了基準も、プロジェクトの熱量が高い初期段階のうちに、冷静に定めておくべき事項です。
まとめ
プロジェクトの「終わりの定義」が曖昧なまま進めると、体制の維持コスト、ステークホルダー間の認識のズレ、振り返りの機会損失といった問題が生じます。成果物・定着移管・契約予算・振り返りという4つの観点から完了基準を具体的に定義し、プロジェクト開始時点で関係者と合意しておくことが、プロジェクトをきれいに終わらせるための重要な準備です。
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント