プロジェクト遅延の原因7つとリカバリ手順｜予兆検知と進捗管理の実践策

「ベンダーからは『少し遅れていますがリカバリ可能です』と報告を受けている。でも数字の裏付けはなく、気づけばマイルストーンが2つ後ろにずれていた」——発注側のPMや情シスの管理職の方なら、似た状況に心当たりがあるはずです。先に結論を言うと、プロジェクトの遅延は突然起きません。遅延には必ず原因があり、目に見える遅れとして表面化する前から予兆が出ています。さらに言えば、遅延そのものは「症状」であって、真因はスコープ定義や計画の立て方といった別の場所にあることがほとんどです。この記事では、僕が金融系SIerのシンプレクスでPMを務め、独立後は発注側の支援にも回ってきた経験から、遅延の原因7つ、予兆を掴む定量的な進捗管理、ファストトラッキング／クラッシングの使い分け、ステークホルダーへの報告と再発防止までを一気に整理します。

遅延対策の第一歩は、リカバリ手法の選択ではなく原因の切り分けです。ここを飛ばして「とりあえず増員」に走ると、だいたい傷口が広がる。遅延の原因は、僕の整理ではおおむね次の7つに集約できます。前半5つは計画起因、後半2つは実行・体制起因です。

原因1. スコープ定義が真の課題とズレている

一番根深く、一番見落とされる原因です。炎上しかけたプロジェクトに入ると、メンバー全員が「スケジュール遅延」を問題だと思っている。でも現場を見ていくと、遅延は症状であって、本当の問題はスコープの定義がクライアントの真の課題とズレていることだった——現場でそう見抜く瞬間があります。作っているものが課題とズレていれば、レビューのたびに指摘が入り、手戻りが無限に発生します。進捗管理をどれだけ厳密にやっても、走っている方向が違うのだから遅れは止まらない。

原因2. 「やることの全量」がスケジュールに載っていない

WBSで洗い出した作業と、スケジュール上のアクティビティが一致していないケースです。載っていなかった作業は消えてくれません。必ず後から割り込んできて、計画外の工数としてスケジュールを圧迫します。地味な原因ですが、遅延の発生源としては非常に多い。

原因3. 見積もりが甘く、バッファがない

すべてが予定通りに進むことは、経験的に非常に稀です。僕は計画を徹底的に立てて勝ち切るスタイルのPMですが、それでも予期せぬ遅延や追加要望は必ず出る。バッファゼロの計画は、たった1つの躓きで全体が連鎖的に倒れる構造になっています。

原因4. リソースの掛け持ちと稼働率の過大評価

特定のエンジニアが複数タスクを掛け持ちしている計画は要注意です。マルチタスクは基本的に生産性を下げるので、単純な足し算で稼働を積むと必ず破綻する。エース級メンバーの稼働率100%を前提にした計画も同じです。

原因5. クリティカルパスが把握されていない

どのタスクの遅れが全体の致命傷になり、どの遅れは吸収できるのか。この区別がないまま全タスクを同じ温度で管理していると、本当に守るべき経路への手当てが遅れます。詳しくはリカバリ手順のところで説明します。

原因6. 進捗報告が定性的で、遅延の発見が遅れる

「概ね順調です」「対応中です」という言葉ベースの報告だけで進捗を把握している状態です。遅延そのものより、遅延に気づくのが遅れることが被害を大きくする。次の章で掘り下げます。

原因7. 発注側の意思決定・確認が滞留する

耳の痛い話も書きます。仕様の確定待ち、成果物レビューの放置、社内承認プロセスの長さ——発注側の意思決定の遅れがクリティカルパスに乗っているプロジェクトは、実は珍しくありません。プロジェクトの失敗原因は発注側にも受注側にもある、というのが両側を経験した僕の結論です。ベンダーの尻を叩く前に、自社がボールを何日持っているかを数えてみてください。

原因の次は検知の話です。遅延対策として一番費用対効果が高いのは、リカバリの技術を磨くことではなく、遅れを早く掴む仕組みを作ることだと僕は考えています。

「大体オンスケです」を鵜呑みにしない

YouTubeのPM講座でスケジュールマネジメントを解説した際、進捗確認について僕はこう話しました。

format_quote

担当者に「今このタスク、オンスケ？遅延？」と聞いたときに、「やや遅延だけどリカバリーできます」とか「大体オンスケです」とか、こういった定性的な報告が上がってくることが非常に多いと思うんですが、こういった報告を鵜呑みにしていていいことってないんですよね。

報告する側に悪意があるとは限りません。むしろ問題は、悪意がなくても実態とズレるという点にあります。

format_quote

担当者も、遅れてるってなかなか報告するのはストレスがかかるから、ぶっちゃけやや隠蔽チックな感じで、本当は遅れてるのに遅れてるって言ってくれない人もいたりしますし、担当者に悪気がなくて本当にオンスケだとは思ってるんだけども実は遅延してるケースとか、いろんなケースがあるので、定量的に把握していくってことが非常に重要になります。

発注側の立場なら、ベンダーの週次報告が「順調」「概ね順調」という言葉だけで構成されていないかを確認してください。数字のない進捗報告は、進捗報告ではなく感想です。

EVMで「出来高」を測る

定量把握の代表的な手法がEVM（アーンドバリューマネジメント）です。仕組みはシンプルで、2つの数字を比べます。

EVがPVを下回っていれば、担当者が何と言おうと遅延です。逆に上回っていれば前倒し。ポイントは「完了したタスクの見積もり工数」だけを出来高に数えることで、「80%くらい終わっています」という自己申告の進捗率を排除できる点にあります。導入のハードルは高くありません。WBSと見積もりさえあれば、スプレッドシートでも運用できます。

毎朝の「予兆チェック」を定型業務に組み込む

数字と合わせて、僕が金融系プロジェクトのPM時代に実際にやっていたのが、毎朝の予兆チェックの定型業務化です。チェックしていたのは次の3点でした。

• 課題管理表で、3日以上ステータスが変わっていないタスクはないか
• テストの消化率と障害検出率が、予定線から乖離していないか
• メンバーの「大丈夫です」の頻度が増えていないか

更新が止まっているタスクは「進んでいない」のではなく、「状況を把握する余裕すらない」ことのサインです。そして進捗していないタスクは、報告には上がってきません。だから、組織として見つけに行く構造が必要なんです。個人の注意力に頼った瞬間、この仕組みは崩れます。なお、進捗会議そのものが報告の読み上げ大会になって形骸化している場合、それ自体が予兆を埋もれさせる元凶になります。会議体の再設計という別の手術が必要になるため本記事では扱いませんが、形骸化した進捗会議の立て直し方は別記事で詳しく解説しています。

スケジュールマネジメントの全体像とEVMの考え方について、動画で詳しく知りたい方は、以下もあわせてご覧ください。

「【PM講座#5/12】定量的に進捗管理できていますか？【プロジェクトマネジメントの教室】」

遅延が確定したら、次はリカバリです。なお、すでに複数工程が崩壊して本格的な炎上に至っているプロジェクトの立て直しは別の技術体系になるので、ここでは「遅れはじめた段階」での打ち手に絞ります。リカバリで間に合わず炎上まで進んでしまった場合の火消しの手順は、別記事で解説しています。

Step1. 遅延を数字で確定する

まず「どのタスクが、何日、なぜ遅れているのか」を定量で確定します。前章のEVMや消化率のデータがあれば、ここは一瞬で終わる。逆にこれがないと、リカバリ計画自体が「たぶんこれくらい遅れている」という曖昧な前提の上に組まれることになります。

Step2. クリティカルパスへの影響を判定する

次に、その遅れがプロジェクト全体の納期に直結するかを判定します。判定基準はクリティカルパス——依存関係でつながったタスクの経路のうち、所要期間の合計が最も長い経路です。

format_quote

このクリティカルパスが遅延すると、ここが一番期間が長くなる経路なので、ここが遅れてしまうとプロジェクト全体の遅延に即直結する。

逆に言えば、クリティカルパス外の遅れは、一定の範囲なら全体納期に影響しません。すべての遅延に同じ強度で反応する必要はなく、パス上の遅延に手当てを集中させるのが正しい優先順位です。

Step3. リカバリ手法を選ぶ——3つのレバー

リカバリの選択肢は、突き詰めると3つしかありません。

使い分けの考え方はこうです。まずコスト増を伴わないファストトラッキングを検討する。ただし、本来順番にやるべき作業を重ねるので手戻りリスクは上がります。次にクラッシング。ここで見極めるべきは「人を足せば本当に早くなる作業か」です。引き継ぎに時間を食う属人的な作業に増員をかけると、かえって遅くなることすらあります。発注側としては、ベンダーから増員提案を受けたときに「追加要員は何の作業を、いつから独力で担えるのか」を確認してください。

そして3つ目のスコープ調整。これは敗北宣言のように扱われがちですが、僕はむしろ最有力の選択肢になり得ると思っています。原因1で書いた通り、遅延の真因がスコープ定義のズレにあるなら、ズレた部分を削ることは後退ではなく軌道修正です。全機能を予定通り作って課題を解決できないより、コア機能に絞って課題を解決できるほうがプロジェクトとしては成功でしょう。

リカバリ案が固まったら、ステークホルダーへの報告と合意形成です。ここの巧拙で、同じ遅延でもプロジェクトの空気がまったく変わります。

報告は「事実・影響・選択肢・依頼」の4点セットで

遅延報告の型は次の順番が鉄則です。

1. 事実: どのタスクが何日遅延しているか（定量で）
2. 影響: クリティカルパスと最終納期、事業側の期限にどう波及するか
3. 選択肢: リカバリ案が複数あり、それぞれ何を犠牲にするか
4. 依頼: 誰に、何を、いつまでに決めてほしいか

「遅れています、頑張ります」は報告ではありません。判断材料の提示です。発注側の立場なら、ベンダーにこの4点セットを最初から要求してください。逆に経営層へ上げるときも同じ型が使えます。

責めると、遅延は「隠れる」

もう1つ重要なのが、遅延報告への反応の仕方です。報告者を詰めると、次から遅延は報告されなくなります。報告されなくなった遅延は消えたわけではなく、水面下で育って、テスト工程やリリース直前に爆発する。遅延の第一報は早いほど打ち手が多く安く済むのだから、早く報告した人が損をする力学だけは絶対に作ってはいけません。だからこそ前章の定量管理が効きます。EVMの数字が遅延を示すなら、それは誰かの失点報告ではなく計測結果です。人ではなく数字が遅延を告げる仕組みにしておくと、報告の心理的コストが劇的に下がります。

合意したら、ベースラインを引き直す

リスケジュールが合意されたら、必ずスケジュールベースライン（進捗判定の基準線）を更新し、チーム全体に周知します。これを怠ると「どの版のスケジュールが正なのか誰も分からない」状態になり、以後の遅延判定が不可能になります。リスケを重ねるほど雑になりがちな作業ですが、基準線が曖昧なプロジェクトは、遅延の検知機能そのものを失っていることと同じです。

目の前の遅延を収めたら、最後は再発防止です。ここで手を抜くと、数カ月後に同じ記事をまた検索することになります。

計画に時間をかけることを恐れない

僕の持論ですが、プロジェクトの成功で一番重要なのは、徹底した計画がきちんとできているかどうか、それだけです。システム開発の成功率は3割と言われるほど世の中のプロジェクトは燃えていますが、3億円以下くらいの規模なら、やること・やらないことを全部洗い出して計画に落とし切れば、大コケすることはあんまりない。計画にはコストがかかります。それでも、問題を事前に潰すコストは事後対処の3分の1から5分の1で済みます。前始末は後始末より圧倒的に安い。遅延リカバリに払った工数と神経を思い出せば、計画フェーズへの投資は高くないはずです。

バッファを「設計」として組み込む

再発防止の具体策の1つ目はバッファ設計です。動画でも話した通り、僕はどれだけ計画を立て切っても、バッファは必ず積みます。

format_quote

ある程度のプロジェクトになると、必ず予期せぬ遅延ですとか予期せぬ追加要望ですとか、そういった予期しないリスクが顕在化してくるので、バッファーを設けて必ずリスクに備えておいた方がいいです。

目安として、一般的にはスケジュール全体の3%程度と言われます。365日のプロジェクトなら約10日。リスクが高いと判断するならもっと厚く。ポイントは、バッファを「余った時間」ではなく「リスク対応のための予算」として明示的に計画へ組み込むことです。隠しバッファは各担当の見積もりを膨らませるだけで、全体最適には使えません。

予兆検知を個人技にしない

2つ目は、本記事で紹介した予兆チェックとEVMを、特定の誰かのスキルではなくプロジェクトの定型業務として組み込むことです。優秀なPMが「なんとなく気づく」体制は、そのPMが抜けた瞬間に終わります。毎朝のチェック項目、週次のEVM更新、遅延報告の4点セット——これらをルール化して、誰がPMでも同じ検知力が出る状態にする。リスク管理プロセス全体の組み立て方はそれだけで1本の記事になるテーマなので、ここでは深入りしませんが、遅延要因を事前に潰すリスク管理の組み立て方は別記事にまとめています。

• 遅延は症状。真因はスコープ定義のズレ・計画の甘さ・体制の無理にあり、発注側の意思決定の停滞も原因になる
• 定性的な報告を鵜呑みにせず、EVMと毎朝の予兆チェックで遅れを数字で掴む
• リカバリはクリティカルパスへの影響判定が先。ファストトラッキング／クラッシング／スコープ調整を代償込みで比較する
• 遅延報告は「事実・影響・選択肢・依頼」の4点セット。合意後は必ずベースラインを引き直す
• 再発防止は計画を立て切ること。バッファを設計に組み込み、予兆検知を定型業務化する

いま遅延に直面している方にとって、一番苦しいのは遅れそのものより「どこまで悪いのか正確に分からない」ことだと思います。だとすれば、最初にやるべきは増員の稟議ではなく、遅延を数字で見える化することです。現在地さえ正確に掴めれば、リカバリの選択肢は思っているより残っています。

---

遅延が常態化したプロジェクトを、仕組みから立て直したい方へ

「ベンダーの『リカバリ可能です』を検証する材料が社内にない」「遅延報告のたびに増員を打診されるが、妥当性を判断できない」「そもそも進捗を定量で把握する仕組みがない」——こうした状態は、担当者の頑張りではなく、進捗管理の構造を変えないと抜け出せません。

クリエイティブテックスタジオでは、EVMをはじめとする定量的な進捗管理の導入から、遅延プロジェクトの原因分析・リカバリ計画の策定まで、発注側に立ったPMO支援を行っています。受注側PMと発注側支援の両方を経験しているからこそ、ベンダーの報告のどこを検証すべきかが分かります。支援内容の詳細はPMO支援サービスをご覧ください。

まずは現状のスケジュールと進捗報告の資料を見せていただくだけでも、遅延の構造はある程度診断できます。外部支援を入れるべき状態か、社内の運用改善で足りるのか、他社のサービスが適していればその旨も含めて率直にお伝えしますので、無料相談からお気軽にご連絡ください。