こんにちは。
最近プログラムをあまり書いていないプログラマの吉田です。

プログラムを書く時間が減った代わりに、プロジェクトを管理する時間が多くなってきた今日この頃。
せっかくなので、プロジェクト管理についての記事も少しずつ綴っていってみようかと思います。


さて、システム開発のプロジェクトを滞りなく進めるのって、なかなか難しいものですよね。

「QCDが達成できればプロジェクトは成功である」という考え方は、昔から良くあると思います。
　※QCD： Quality（品質）、Cost（予算）、Delivery（納期）

何もかもが計画通りに進めば、プロジェクトは上手く進みますが、
残念なことに、ほとんどのプロジェクトは、計画通りには進みません。

計画通りに進まなくなった時、どうするか？
というのは、プロジェクトマネジメントのお仕事の1つです。

そんなわけで、今回は、スケジュールが遅延した場合の処方箋である
「クラッシング」と「ファスト・トラッキング」の2つについて、紹介したいと思います。

クラッシングとは？（Crashing）

クラッシングとは、開発のスコープを保ったまま、スケジュールを短縮するための技法の１つで、
コストを追加することでスケジュールを短縮させる方法です。

例えば、3ヵ月のスケジュールを2ヶ月に短縮したい場合、単純に考えると、1人月分の
追加コストを投入することで、1か月のスケジュールを短縮させることになります。

追加コストを投入するというのは、要するに、人を追加したり、残業をしたり、という感じですね。。。
　※もちろん、残業を選択する場合は、労働基準法に抵触しないことが大前提。

ちなみに、この方法は、クリティカルパス上にあるタスクに対して実施しなければ意味がありません。

個人的な所感では、人を追加したり、残業をしたりしても、追加コスト分の生産性が出るかというと、
そんなわけないので、あくまでも考え方の一つとして知っておく程度で良いのかと。

実際、プロジェクトの状況によってクラッシングが有効かどうかは変わってきますから。


ちなみに、PMBOK第3版だと、P145、P360に説明が書いてあるです。
（PMBOKの内容をそのまま複製したり発信することが禁じられているようなので、引用できませんが。。。）

ファスト・トラッキングとは？（Fast Tracking）

ファスト・トラッキングとは、開発スコープを保ったまま、スケジュールを短縮させる方法の１つで、
本来は順番に進めていくべきタスクを、先行タスクが完了する前に後続タスクを進めることで、
スケジュールを短縮させる方法です。

例えば、システム開発のプロジェクトであれば、設計が完了する前に実装を始めたり、実装が
完了する前にテストを始めたり、といった感じです。

もちろん、設計に変更が入ってしまうと、実装作業に手戻る可能性があるので、その辺のリスクが
発生するということを、念頭に置かねければなりません。

結局、手戻りまくっちゃって、スケジュールが短縮できなくなる可能性もあったりします。


ちなみに、PMBOK第3版だと、P146、P399に説明が書いてあるです。

まとめ

今回は、スケジュールの短縮技法を2つ紹介してみました。
実際のところ、「技法」というほど凄いものでもなく、スケジュールが遅延した場合、普通に考えることかと思います。

スコープを変更しない前提条件だと上記の2つの手段がありますが、スコープを狭くするという考え方や、
そもそもスケジュールを伸ばすという考え方もあるので、スケジュール遅延への対策はケースバイケースです。

というわけで、プロジェクトが遅延する兆候がある時は、遅延する前の早めの対策を心がけたいものですね。


デワデワ。