「クラッシング」で遅延を回復するためにプロマネが注意すべきこと

クラッシングはスケジュール遅延対策の最終手段

プロジェクトマネジメントで直面しやすい問題の一つがスケジュールの遅れです。社内のみで完結するプロジェクトならまだしも、ステークホルダーが絡むようなプロジェクトではスケジュールの遅れは致命的です。

ガントチャートを共有してスケジュールを管理している場合、遅延対策としては以下の2つが一般的です。

• ファストトラキング
• クラッシング

今回は、遅延対策の中でもコストを使って対応するクラッシングについて紹介します。

クラッシングとは？

クラッシング（Crashing）とは、新規にコストを追加してプロジェクトの完了時間を短縮する方法を指します。主なコストとしては以下のようなものです。

• 人員の追加（プロジェクトメンバー対応）
• 外注化（外部人員の利用）
• ソフトやハードなどの技術導入

クラッシングでは、基本的に人的・金銭的なコストが新たにかかることになります。クラッシングは単純な方法に見えますが、プロジェクト進行中の追加コストの申請はかなりハードルが高いことは経験者ならば分かるでしょう。

「プロジェクト発足時に織り込み済みじゃないのか？」と言われるのは目に見えていますが、スケジュールが遅れている以上は対策を講じるしかありません。

クラッシングを行う際に必要なこと

クラッシングによるプロジェクト遅延対策例をシンプルに説明すると以下のようになります。

• 人が足りないから人を追加する
• もっと作業を円滑に進めるシステムを導入する

ただ、これらのコストが掛かる対策を、プロジェクト統括者やステークホルダーに簡単に了承されることはありません。本当にクラッシングを行うことでスケジュールを早めることができるか証拠（エビデンス）が必要です。

クラッシングの内容を数値化する

そもそもスケジュールに遅れが出ているのは、プロジェクトキックオフ時の見積もりが甘かったことが大きな要因です。（わかります！元々無謀なプロジェクトであることもあります。）

プロジェクトでは不測の事態が起こることもありますが、それまでのタスク実施内容から、正確にクラッシングによる効果を数値化しなければいけません。

• 人が足りない：1工数の実績はどれほどか？
• ソフトの処理が遅い：現状のシステムの演算時間は？

など、現在までの進捗実績をまず明確にして、クラッシング後の改善予測値を示さなければなりません。

遅延しているタスクの内容によっては、単純に人を増やせば遅延解決できるとは限りません。そのため、多くの場合はクラッシングと同時にファストトラッキングも必要となります。

クラッシングを検討する際には必ず会議を開く

クラッシングが必要になる場合は、必ずプロジェクト関係者を集めて会議を開きましょう。関係者全体にプロジェクトの現状と同時に改善策を提示し、了解を得る必要があります。

ステークホルダーが絡むような場合は、事前に社内関係者のみで会議を行いましょう。ほぼ確実に怒られる（泣）ので、事前に根回しは必要です。プロジェクトを完遂させるのが目的であることを忘れずに。

クラッシングのデメリット

クラッシングは、当然ながらリスクがあります。「ブルックの法則」では、クラッシングはスケジュール遅延対策としては現実的ではないとさえ言われています。

代表的なクラッシングのデメリットは以下の通りです。

クラッシング最大の問題はコストアップ

クラッシングの最大の問題はコストアップです。プロジェクトは決済が降りるまでに厳しくコストチェックされますが、最終的にコストが増えるということは当然ながら大きなリスクです。

また、クラッシングによって必ずしもスケジュールが改善するとは限りません。そうなると、コストダメージに絶望するプロジェクトリーダーも多いでしょう。

人的コスト増が逆に遅延を生むこともある

クラッシングの中でも、人的リソースを増やすことは遅延リスク増大の原因にもなり得ます。新規参入者のプロジェクト理解度やそもそもの技術力の問題、また人間関係という計算できない潜在リスクもあります。

社内での限られた人員でのクラッシングの場合は、他のプロジェクトに影響を与えることもあります。外注化の場合には、直接的な資金面のコストもかかるため、定期的なチェックと管理が重要となります。

クラッシングを行う前にチェックすること

クラッシングはプロジェクトコストに直接影響します。だからこそ、スケジュール遅延がクラッシングで対策可能かを事前に検証する必要があります。

クラッシングを検討する際には、以下のようなポイントについて事前に確認しましょう。

【1】遅延しているタスクはクリティカルパス上か？

もっとも重要なことは、遅延しているタスクが「クリティカルタスクなのか？」という点です。プロジェクトリーダー経験者なら問題ないでしょうが、ここを明確にしないと話になりません。

クリティカルパス上にないタスクにコストを掛けることは、プロジェクト進行上ではほぼ許されません。

【2】クラッシングを行うあてはあるのか？

いざクラッシングを行おうにも、実際にスケジュール遅延を解消できるような「人的・物的」なリソースがないと意味がありません。

クラッシングのリスクでも紹介したように、人的コストはとくに重要です。提案する前に、確実にリソースの確かさを調べましょう。

【3】クラッシングが効力を発揮する時間を見積もっているか？

クラッシングを始めるとしても、新規メンバーにはプロジェクトの理解をしてもらう必要がありますし、新規システムなどは理解・導入までの時間が必要です。

クラッシングの効果だけに目を向けるのではなく、それによって新たに発生するタスクについても、リスクを含めて事前に見積もる必要があるのです。

【4】ファストトラッキングでの対応が不可能な理由を明確にする

スケジュールが遅延している時、多くの人は「ファストトラッキング」を検討します。それは既存のリソースだけで（一応）対応が可能だからです。

そのため、クラッシングによってコストかけないとスケジュールの遅延対策ができないことを説明する必要があります。

まとめ：クラッシングのポイント

クラッシングについて説明してきましたがいかがだったでしょうか。クラッシングのポイントは以下の通りです。

• クリティカルパス上のタスクに適用することが前提
• クラッシングはタスク期間の短縮に人的・物的コストの負担が増える
• クラッシングの有効性を数値で示す必要がある
• ファストトラッキングで対処できない理由を明確にする

プロジェクト自体のスケールや難易度によるとはいえ、プロジェクトが当初の予定通りに完遂するのは稀です。不測の事態などを事前にリスクマネジメントで検証する必要もありますが、それにも限界があります。

ただ、プロジェクトはとにかく進捗管理が重要です。プロジェクトの残り時間が少ない時に、クラッシングが必要になるほどの遅延が発生すると最悪です。

対策は早めに打たなければしんどくなります。そのためにもプロジェクトリーダーは進捗管理を徹底しましょう。舵取りがもっとも重要な業務であることを忘れてはいけません。