 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| 遅延を取り戻す対処方法 | ||||||||||||
|
アラームがあがった場合の対処方法について考えてみよう。代表的な手法として「クラッシング」と「ファストトラッキング」があり、PMBOKではタイム・マネジメントの章にて取り上げられている。この2つの手法は例え言葉自体を知らなかったとしても、実践している人は多いのではないだろうか。 |
||||||||||||
| 要員を追加するクラッシング | ||||||||||||
|
「クラッシング」とは、主に要員を追加することで期間短縮をはかる方法である。プロジェクトのクリティカル・パス上にあるアクティビティに対して要員を投入するのである。 一口に要員投入といっても、可能であるならば既存要員の配置換えで対応したい。待ち状態になっている要員を該当するアクティビティに投入すれば、コストを増加させずに済ませることも可能だからである。 そうはいっても、プロジェクトにおいては、そんなに都合よく空き人員が発生するような割り当て方はしていないだろう。まだ残業が膨らんでいないのであれば、次の対策として既存要員に残業を頼んだ方がよい。 残業により勤務状況が厳しくなる場合は、プロジェクトの目標を皆で達成するために頑張っていることを改めて共有するなど、モチベーションを保つための対策も忘れないで欲しい。そのためであれば、短時間の飲み会などももちろん有効だろう。 空き要員もなく、すでに残業も多いとなると、新規要員の投入を検討することになる。新規要員を追加すればコスト増に直結する影響も大きく、またこれまでの経緯を知らない新規要員は、エンジンがかかるまでに時間を要する。場合によっては、追加要員のスキルが低いか適していないため、コストが増加するだけで進捗が改善されないこともあり得る。そもそも進捗が遅れているということは、困難に直面していることが想定される。 こういう時こそ、単価が高いとしても高スキルな要員を投入した方が、最終的なコスト増が低く抑えられる場合が多いことも十分考慮すべきであろう。
表2：クラッシングのポイント |
||||||||||||
| アクティビティを並列にするファストトラッキング | ||||||||||||
|
「ファストトラッキング」とは直列に並んでいるアクティビティを並列にして期間短縮をはかる方法である。通常、スケジュールはすでに並列化してあると思われるが、これをさらに並列化するのである。リスクヘッジとして意図して直列化してあったアクティビティが存在すれば、並列化することは可能である。 また十分検討してこれ以上ない程並列化してあったとしても、プロジェクトが進めば状況も変わる。例えば、当初一括して設計すべきだと考えていた機能群がプロジェクトが進んだ段階では、一部分割して設計しても問題ない（独立性が高い）ことがわかる場合もある（図1）。  図1：作業の分割例 （画像をクリックすると別ウィンドウに拡大図を表示します） 「ファストトラッキング」は「クラッシング」ほど単純ではない。リスクヘッジのために直列化していたアクティビティを並列化したのであれば、そのリスクを背負うことになる。アクティビティを分割して並列化したのであれば、アクティビティの順序や前後関係がより複雑になり、要員の割り当ても複雑化する。特にキーマンの作業割り当てには考慮が必要である。 図2では品質を落とさないために、設計内容をよく知るキーマンが開発ではなくテスト（単体テストではない）に参画できるように配慮している。また安易に並行化したのでは手戻りのリスクが発生するが、図2では「機能群A,B,C」と「機能群D」に関するタスクはそれぞれ直列にしており、手戻りリスクを軽減している。  図2：ファストトラッキングによる作業の平行化 （画像をクリックすると別ウィンドウに拡大図を表示します） 「ファストトラッキング」では、作業を並行化して期間短縮をはかっており、開発のボリュームが減るわけではないので、要員の追加投入が必要になってくることも忘れてはいけない。この点に関しては、「クラッシング」と同様に既存要員で対応した方がよい。
表3：ファストトラッキングのポイント |
||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
