進捗80%からが長い——「完了」の定義と残作業の見える化

＜目次＞

「あと少し」が永遠に続く、プロジェクトの不思議
なぜ「残り20%」はこんなに重いのか
1. 見えていない作業が後半に集中する構造
2. 「完了」の定義があいまいだと、報告も実態もズレる
「完了」を定義する実践的アプローチ
1. DoD（Definition of Done）をタスク単位で作る
2. 残作業の「見える化」はリスト化から始まる
残作業を「工数と日数」に変換して初めて管理できる
「80%」を報告されたときにPMが聞くべき一つの質問
1. 進捗遅延・炎上プロジェクトを立て直したい方へ

「あと少し」が永遠に続く、プロジェクトの不思議

プロジェクト現場でよく耳にする言葉がある。「今、80%くらいまで来ています」。だが、その80%という報告が出てから、プロジェクトが本当に完了するまでに、計画の2倍も3倍も時間がかかってしまうケースは珍しくない。

これは「90%シンドローム」とも呼ばれる現象だ。進捗は90%のまま週を越え、月を越え、気づけばデッドラインを突破している。なぜこうなるのか。原因は単純なサボりではない。「完了」が定義されていないまま、進捗を数字で語っているからだ。

なぜ「残り20%」はこんなに重いのか

見えていない作業が後半に集中する構造

あるシステム開発プロジェクトでの話だ。開発フェーズが「80%完了」と報告された翌週、PMが各担当者に「残っている作業を全部リストアップしてほしい」と依頼した。返ってきたリストには、単体テストの修正、データ移行の確認、環境構築の残作業、ドキュメント整備、ユーザー受け入れテストの準備など、70件以上のタスクが並んでいた。

担当者は決してさぼっていたわけではない。ただ、「完成に向けた最後の詰め」に必要な作業を、当初の計画に織り込んでいなかっただけだ。主要機能の実装が終わった時点を「80%」と感覚的に定義し、残りの見えにくい作業を見落としていた。これは構造的な問題だ。

「完了」の定義があいまいだと、報告も実態もズレる

PMBOKの観点から言えば、タスクや成果物には明確な「完了基準（Done Criteria）」が必要だ。しかし現場では、「ほぼできた」「あとは細かい調整だけ」という感覚的な完了判定が横行している。この感覚と実態のギャップが、後半の失速を生む。

特に落とし穴になりやすいのは以下の三つだ。

「動く」と「使える」の混同：機能は動いているが、エラーハンドリングや境界値処理が未完了
「作った」と「確認した」の混同：成果物は存在するが、レビューや承認が終わっていない
「伝えた」と「受け渡した」の混同：引き継ぎや教育が完了していない状態での「完了」宣言

「完了」を定義する実践的アプローチ

DoD（Definition of Done）をタスク単位で作る

アジャイル開発の現場では「Definition of Done（DoD）」という概念が浸透しているが、これはウォーターフォール型プロジェクトにも応用できる。要は、「このタスクが完了した、とみなせる状態を事前に言語化する」ということだ。

たとえば「設計書の作成」というタスクのDoDはこうなる。

設計書が所定のフォルダに格納されている
レビューが実施され、指摘事項がすべて反映されている
レビュアーの承認サインがある
関連するWBSのステータスが「完了」に更新されている

このようにチェックリスト形式で定義しておくと、「感覚の完了」を「事実の完了」に置き換えられる。最初は面倒に感じるが、後半の混乱を防ぐ効果は絶大だ。

残作業の「見える化」はリスト化から始まる

「完了まであと何があるか」を把握するには、残作業を網羅的にリストアップするところから始める。このとき重要なのは、「やるべき作業」ではなく「完了に必要な作業」を問いかけることだ。

具体的には、以下の観点で洗い出すと抜け漏れを防ぎやすい。

成果物の観点：作成すべきドキュメント、承認が必要な資料、納品物のリスト
確認・検証の観点：テスト、レビュー、ユーザー確認、動作検証
引き渡しの観点：環境移行、操作説明、マニュアル整備、運用への引き継ぎ
管理・クローズの観点：課題の解消確認、変更管理の締結、ライセンスや契約の整理

この四つの観点で洗い出すと、「あとは機能を仕上げるだけ」と思っていたプロジェクトが、実は「まだ30件以上の作業がある」という現実に気づくことが多い。

残作業を「工数と日数」に変換して初めて管理できる

残作業のリストが出そろったら、次は各タスクに担当者・所要工数・完了予定日を紐づける。これをしないと、リストは「作業の羅列」に終わり、スケジュールに接続できない。

あるインフラ移行プロジェクトでは、終盤に「残タスクの工数合計」を集計したところ、残期間のキャパシティを40時間以上オーバーしていることが判明した。PMはここで初めてリソースの追加投入と、一部タスクのスコープ外し交渉に動けた。遅延は免れなかったが、ゼロ日でも早く対処したことで、最小限の被害に抑えられた。

残作業の見える化は、対処を早めるための情報武装だ。後半になるほど、見える化の精度と速度がプロジェクトの結末を左右する。