プロジェクトの遅延を取り戻す

プロジェクトの遅延を取り戻す方法としては、一般的に次の2つの方法があると言われています。

• ファストトラッキング（Fast Tracking）
• クラッシング（Crashing）

ファストトラッキング

ファストトラッキングとは、一つの行程が完了する前に次の工程を開始することです。

前工程の完了を待たずに次工程を開始し、既に作業が済んだ成果物を利用して次工程の作業を進めます。
コストを増やさずにスケジュールを短縮できるメリットがありますが、タスクの相関・依存関係が複雑で、同時に行う作業量が増え、リソースコントロールが複雑化します。

また、前工程で変更が入ってしまうと、後工程で手戻るリスクがあります。
各工程間でのファストトラッキングは、一般的に行われていると思います。

例えば設計フェーズと開発フェーズのファストトラッキングです。
設計ができるメンバーとプログラミングができるメンバーが異なる場合、設計書が完成したところから順番に、プログラミングを開始する場合があります。
ただし、ファストトラッキングで重ねることができる工程は2つまでにしてください。
なぜなら、戻り作業が生じた場合に損害が大きくなるからです。
以下はNGのケースです。（3つの工程が重なっている）

各行程の中には複数のタスクが存在します。
各タスクのリソースの割り当ては、理論値上100％の稼働（または若干余裕がある程度）になるよう割り当てるのは良いと思います。なぜなら、計画上100%を超える稼働を割り当てた場合、リスクが生じるとリカバリーがしづらくなるからです。
残業ありきの計画を作成するのは良くないです。なぜなら、同様にリスクが生じるとリカバリーがしづらくなるからです。

各タスクは難易度によってあらかじめ、予定工数が計算されています。
予定工数の中にはある程度のバッファが含まれているかと思います。
割り当てるメンバーのスキルによって生産性は異なります。バッファ分とメンバーの力量を加味して、多少タスクをファストトラッキングしても良いと思います。
ただし、計画上は特に後半のスケジュールに余裕を持てるようにして、それぞれの力量や進捗を見ながら、都度スケジュールの微調整を行っていきましょう。

メンバーによっては、何回もスケジュール調整を余儀なくされるケースがあります。
その場合は、何らかの問題を抱えています。問題が何なのかを見極める必要があります。
もしも1人が精神的に追い詰められて休んでしまえば遅延はさらに拡大します。しっかりとケアしていきましょう。

基本的にメンバーには実力より少し高めの目標を与えた方がパフォーマンスを発揮します。（高すぎるのは駄目です）
ただし、計画上余裕が無いのは危険です。スケジュールの前半に早めの進捗をコントロールし、後半に余裕ができるようコントロールする方が安心です。

クラッシング

クラッシングとは、「人的コスト」「ハード・ソフトのコスト」を追加することでスケジュールを短縮させる方法です。
簡単に言うと、新しい要員を増やしたり、残業をしてもらい、作業できる工数を増やしてスケジュールを短縮させる方法です。

クラッシングを採用すると、一般的にコストが増加します。
また、人数を増やすと要員のコントロールが難しくなります。
また、新しい要員が作業環境に慣れるまで時間がかかったり、スキル不足だったりして、すぐには効果が出なかったりします。

要員を増やす場合は、なるべく即戦力になる人を追加した方が安全です。
また、単純作業が大量にある場合は、手順書を作成してオフシュアにお願いするのも良いかもしれません。ただし、オフシュアは文化や言語の違いから手順書や成果物をしっかりと決めていないと、思った通りの成果が出ない可能性があります。またオフシュアは、短期間ではなかなか成果が出にくいので、リスクをある程度予測して、早めに作業をお願いできるのであれば有効だと思います。

スケジュールが遅延する理由

スケジュールが遅延する理由には次の様なものがあると思います。

• スコープクリープが発生した
• 品質が悪かった
• 要員のスキル不足
• 予想工数の見積もりが間違っていた
• スケジュールの段取りが間違っていた
• 要員が不足していた
• 納期が短すぎた
• 予期せぬリスクが発生してしまった

スコープクリープが発生した

プロジェクトの途中で要件が変更になったり、追加になってしまうと、追加作業が増え、戻り作業が発生し、要員が不足し、品質が劣化します。
客先の要因で要件変更・要件追加が発生した場合、次フェーズに先送りするか、スケジュールを変更するなどの調整が必要です。

品質が悪かった

完了した前工程の品質が悪かった場合、後行程に影響します。
例えば、設計の品質が悪かった場合、開発フェーズの途中や後で、設計ミスが発覚した場合、設計書修正後にプログラムを修正しなければなりません。

それぞれのタスクが完了したら、必ず作業した本人とは違うメンバーでレビューやチェックを実施しましょう。
また、前工程と後工程のタスクの要員の割り当てにおいては、必ず違うメンバーを割り当てるようにしてください。例えば設計者とプログラマーで違うメンバーを割り当てます。
そうすると、違った視点で設計ミスを発見できるのでクロスチェックになります。

要員のスキル不足

それぞれのメンバーのスキルはまちまちです。経験が少ないメンバーもいれば、豊富なメンバーもいます。
スキルの浅いメンバーに作業を任せっきりにしてはいけません。
かならず経験豊富なメンバーとペアにするようにしてください。

スキルの浅いメンバーも育てていかなければ、経験豊富になりません。教育にかかる時間をスケジュールに加味するようにしましょう。

外部からの要員がスキル不足だった場合、なるべく早い段階で退室していただいた方が無難だと思います。

予想工数の見積もりが間違っていた

工数見積もりを行う場合は、過去の実績や機能ごとの難易度から見積もりを作成します。
一人で見積もりを作成すると見積もりの精度に不安になることがあると思います。
大きなプロジェクトでは、二人以上で別々に見積もりを計算し、後で答え合わせを行うのも良いかと思います。

スケジュールの段取りが間違っていた

大きなプロジェクトの場合、プロジェクト全体の詳細を最初から正確に作成することはできません。
まずは、マスタースケジュールを作成して、それぞれの工程で段階的に詳細化していく必要があります。

また、プロジェクトは、はじめに決めたスケジュール通りに進むことはまずありません。
常に進捗をチェックし、タスクの順番や、要員の割り当てや、スケジュールの見直しを常に行う必要があります。

要員が不足していた

進捗の遅れや残業の増加が継続していた場合、そもそも工数見積もりや要員計画が間違っていた可能性があります。早めに悪い傾向を検知し、スケジュールの調整や体制強化を図る必要があります。

納期が短すぎた

提案時に、お客様からの強い要望により短納期で受注してしまうことがあります。
短納期は色々なリスクを発生させます。

リスクに備えて、コストを高めに見積もったり、途中でのスコープクリープが発生しないように前提条件・制限事項を厳しめに記載して契約したり、作業手順は省略できませんが、納品物の体裁を簡素なものにさせていただくなど、事前にリスクヘッジしておくべきです。

できれば、品質に影響しない適切な納期で契約を行えれば良いと思います。

予期せぬリスクが発生してしまった

予期せぬリスクは発生するものです。ある程度余裕を持ったスケジュールを作成しましょう。また事前に予知できるリスクには早めに対処していく必要があります。

プロジェクトは基本的には当初の予定通りには進みません。
常に進捗をチェックし、早期に問題を検出し、タスクの割り当て変更や、スケジュールの微調整が必要です。
またどうしても遅延が解消されない場合は、ファストトラッキングやクラッシングが必要です。

スケジュールをうまくコントロールするためには、戻り作業を少なくするために、早い工程の品質を高くする必要があります。（特に要件定義・設計フェーズ）

また、ある程度余裕のあるスケジュールを作成する必要があります
（前半の要員の山積みを高めにして、後半のスケジュールに余裕を持たせる）
そして、残業をはじめから見込まない、無理の無いスケジュールを立ててください。