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

2017年12月26日

PMBOKでは、スケジュール遅延の対策として、いくつかの手段が提示されています。

その中でも「クラッシング」と「ファストトラッキング」は有名ですね。実際のプロジェクトマネジメントでも、違う言葉かもしれませんが、同じような手法を用いていることと思います。

管理人も同じような手法でプロジェクトマネジメントをしていますが、感じている注意点などを書いていきます。

クラッシングについて

クラッシングの説明

PMBOKガイドから少しだけ引用します。

資源を追加することにより、コストの増大を最小限に抑えスケジュールの所用期間を短縮する技法

簡単にいうと、人員を増強して、一気に片付けるやり方です。

人員の増強だけではありません。残業をしてもらうなど、作業時間を増やすやり方です。

当然ですが、人が動けば工数がかかりますので、クラッシングを採用すると、一般的に高コストになってしまいます。

高コストにはなりますが、期間内で終了できるので、ファストトラッキングよりは低リスクではないかと思います。

クラッシングのイメージ

クラッシングのイメージ

上段が通常の作業順序です。下段がクラッシングをした時のイメージです。

アクティビティAは作業遅延を起こしているとします。もともとの期間を変更することなく、資源を追加投入することでリカバリーする想定です。

この例では、人的資源を追加した例です。

ファストトラッキングについて

ファストトラッキングの説明

PMBOKガイドから少しだけ引用します。

通常は順番に実施されるアクティビティやフェーズを並行して遂行するスケジュール短縮技法

簡単に言うと、五月雨スケジュールにしてしまうことです。最初から五月雨スケジュールなのは、ファストトラッキングとは言いません。

スケジュール遅延した際に、簡単にファストトラッキングを採用してしまうと、最初から「並行で作業できたのでは?」と疑われます。

スケジュール作成時には、どうやっても「並行で作業ができないスケジュール」を、「無理やり」・「やむなく」・「危険だが」並行作業化するというのがファストトラッキングです。

ファストトラッキングのイメージ

ファスト・トラッキングのイメージ

上段が通常の作業順序です。下段がファストトラッキングをした時のイメージです。

アクティビティAは作業遅延を起こしているとします。

もともとの人的資源を変更することなく、アクティビティA完了後に作業開始するアクティビティBを、アクティビティAの完了を待たずに作業開始させます。

アクティビティAは作業遅延している想定なので、もともとの期間を延長しています。しかし、最終的なアクティビティBの作業完了時期を変更しては、ファストトラッキングの意味はありませんので注意してください。

実務で使う上での注意点

どちらも諸刃の剣です。コントロール不能になる可能性があるので、できる限り使わないようにしてください。

しかし、厳しい制約条件の中で使わざるをえない場合は、注意が必要です。

なぜ適用しなければならないかの原因を探る

さまざまな制約のために、クラッシングやファストトラッキングを適用しなければならない場合があります。その場合「なぜ適用しなければならないか」の理由を十分に突き詰めておいてください。

理由なくして適用することはありえません。理由があるはずです。その理由がわからずに闇雲に適用しては、効果が上がらない可能性があります。

管理人の実例

実際あった例です。ファストトラッキングがうまくいかなかったケースです。

そのプロジェクトは製造工程が遅れ始めていました。あるサブシステム(Xサブシステムと呼びます)が極端に遅れ始めたのです。

リカバリ案を検討していく上で、後工程である結合テストを、Xサブシステム以外で開始する案を採用しました。

しかし、Xサブシステムで作成するべき機能がないため、他サブシステムでは、スタブ・ドライバを作成してテストを行いました。そのため、他サブシステムは良好なテスト結果でした。

しかし、Xサブシステムが完了したので、再度結合テストを開始しました。当然、Xサブシステムが絡む箇所はすべて再テストです。

それは想定通りですが、都合よいテストをしていた他サブシステムは、再テスト結果が思わしくなく、修正が多発しました。

この場合は、クラッシングを採用して、結合テスト開始前までにXサブシステムを仕上げておくほうが、結果としてはよかったと感じました。

プロジェクトマネージャは「何が最適で、一番効率よくリカバリできるか?」を考えなければなりません。次のような内容です。

  • スケジュールが遅れた理由が何であるか?
  • 使える資源は何があるか?
  • 工期短縮技法を行うことによるリスクは何があるか?

すべて洗い出すことで、他の方法も浮かび上がるかもしれません。

管理人はどちらが得意か?

どちらも得意・不得意はないと思っていますが、管理人はファストトラッキングで痛い目にあっているので、クラッシングを最初に考えるようにしています。

そもそも、プロジェクトマネージャはこうなる前に、手を打たなければなりません。

スケジュール遅延の予兆を感じ取り、小さいクラッシング(少しだけ残業してもらうなど)で済むレベルにしておくことが重要です。

五月雨スケジュールは、最初からできるのであれば、そのように組み込んでおくことが重要です。途中から後工程を五月雨にし始めると、全体の同期を取るタイミングを図るのが難しくなります。

先程の例では、結合テストの目的のひとつは、サブシステム間を結合してテストするということです。

その目的を逸脱した工期短縮技法を用いてスケジュール構成を組むことは、後から問題が出る可能性が高いので注意が必要です。

どちらかを採用したら次はない

スケジュール遅延対策を打つ場合、たいていプロジェクトマネージャの権限だけでは決定できません。

先ほど記載したような、小さいクラッシング程度ならばよいのですが、ベースラインの変更を伴うような場合、各ステークホルダーの判断が必要です。

そこで、承認をもらえるだけの理由や材料をそろえておかないと、承認会議はプロジェクトマネージャを責めるための会議となってしまいます。

そうならないよう、十分に原因と、選定理由を準備しておいてください。知恵を絞った結果であることが、ステークホルダーが納得する条件だと考えます。

このようなスケジュール遅延が多発するようだと、プロジェクトマネージャの手腕を問われる事態になってきますので、権限が届く範囲で、小さな芽のうちにつぶしておくことが大切です。

そのためにも、小さなトラブルの予兆も見逃さないセンサーが必要です。

それは他記事もで書いてきていますが、「リスク管理を重視すること」です。先を見通す目がプロジェクト、ひいてはプロジェクトマネージャである自分を救うことにもなります。

まとめ

スケジュール遅延は、プロジェクトマネジメントをしていると、ごく当たり前に発生します。PMBOKでも当然のこととして説明しています。

管理人も数限りないスケジュール遅延に悩まされてきています。原因はさまざまですが、一番多いのは何かというと、品質問題でした。(品質問題に関しては別記事で書いていきます)

スケジュール遅延の問題は、プロジェクト計画時に織り込み済みの状態で開始できるようにマネジメントしましょう。月並みですが、自分の身を守るためでもありますので。

 

PM

Posted by wpmaster