ファスト・トラッキングとは何か？短納期プロジェクトのためのスケジュール短縮方法
ファスト・トラッキングとは
ファスト・トラッキング（Fast Tracking）とは、通常は順番に実施されているアクティビティを並行して実施し、スケジュールを短縮するという技法です。
なぜファスト・トラッキングは必要なのか？
もしソフトウェアの稼働開始日が予め決まっていたら
はじめに、なんでファスト・トラッキングが必要なのかをお話ししていきます。
プロジェクトの完了日やプロジェクトの成果物をいつから稼働させるかというのは、プロジェクト開始後にタスクを洗い出しながらプロジェクトマネジメント計画書の作成の中で決定できるのがベストです。
しかし、クライアントワークで行うプロジェクトの多くは最初に納期や稼働時期が定められていることが往々にしてあります。その場合、予定されている期日を最優先にしてプロジェクトを進めなければなりません。
やっかいなのは、その納期があまりにも短かったり、プロジェクトの途中でその期日にあわせてほしいとスケジュールの短縮を依頼された時です。
このように、プロジェクトで開発するソフトウェアの稼働開始時期が決まっているなど、納期や完了予定日、成果物の稼働開始日が決まっており、なおかつタイトなスケジュールのプロジェクトの対処法の１つがファスト・トラッキングなのです。
なぜ予め納期や完了予定日が決まっているのか
そもそも、なぜ納期や完了予定日が予め決まっているプロジェクトが発生してしまうのでしょうか。
１つの理由としては、当年の予算を使い切りたいという発注側の思惑があります。
「予算が余っているけど、次年度には持ち越せないし、使わないと次年度の予算を減らされてしまいそうだ」、「年度内に終わらないとこの年の予算消化として認められない」という状況から、年度内に完了することが決められたプロジェクトが発生します。
予め納期が決まるもう１つの理由としては、クライアント側のイベントにあわせるケースが挙げられます。
例えば「会社の創業XX年記念にあわせたい」とか、「新規店舗のオープンにあわせたい」というようなことから、納期や完了予定日、稼働時期が決定されていることはよくあります（とくにデザイン系のクリエイティブ物でよくある話です）。
この他にも様々な理由で完了予定日ありきのプロジェクトが生まれますが、ほとんどの場合はこれまで見てきた「予算消化の都合」、「イベントの都合」で説明がつくでしょう。
主な対応方法
短納期のプロジェクトやスケジュールの短縮を依頼された時の対処法は多くはありません。
採るべき対処法としては、タスクの内容や構成、実施順序を調整してスケジュールを組む（組み直す）か、一部の機能を期日の後にリリースするかです。
後者については、クライアントとプロジェクト・マネジャーの交渉によって実現されます。例えば「今回のプロジェクトはWebサイト更新システムとそれに連動したWebマーケティングシステムの開発だったが、更新システムだけは期日内に完了させて、マーケティングシステムは翌々月の提供にする」というように、一部の機能だけを後日提供する方法です。
契約上問題がなければ、このように期日をずらすとプロジェクトの負担が減ります。しかし、こうした手法がとれない場合は、ファスト・トラッキングを用いてタスクを並行実施し、スケジュールを調整していく必要があります。
ファスト・トラッキングを実施していく方法
ファスト・トラッキングの大まかな流れ
ここからはファスト・トラッキングの方法をまとめていきます。
ファスト・トラッキングを実施するときの流れは以下の通りです。
- タスクの整理
- タスクを細分化する
- 並行実施できるタスクとできないタスクを見きわめる
- スケジュールの調整
まずはタスクを整理し、その中で細分化できるものは細分化してサブタスクを作ります。ここまで整理したら、並行実施できるタスクとできないタスクを見きわめていきます。
並行実施できるタスクが決まったら、最後にスケジュールに落とし込んでいきます。
Webサイトリニューアルを事例としてファスト・トラッキングの方法を紹介
ここからはWebサイトのリニューアルプロジェクトを例として、ファスト・トラッキングの方法を見ていきます。
このプロジェクトはWebデザイン会社が学習塾からWebサイトリニューアルの依頼を受けたと仮定して進めていきます。この他の設定は以下の通りとします。
- クライアント：従業員100人ほどの学習塾
- プロジェクトの内容：
Webサイトのデザインの刷新とともに、Webサイトをクライアント側でも簡単に更新できるようにCMSを導入する。
Webサイトのページ数は30ページで新規コンテンツはない。 - プロジェクト期間：４ヶ月（12月１日からスタートし、翌年の３月31日まで）
- プロジェクトの経緯：
本プロジェクトはクライアント側の創業30年を記念したものであり、翌年４月１日の公開を予定している。創業30年記念の告知にあわせて、Webサイトのリニューアルも大々的に告知する予定である。
記念としてWebサイトをリニューアルするということはクライアント側で当年の10月に決定し、急いで担当者が業者を選定し、12月頭からプロジェクトをスタートさせた。
タスクを整理する
タスクを並行実施するときだけでなく、プロジェクトはタスクの整理からはじまります。
例として挙げたケースでも、プロジェクトメンバー間で話し合った結果、タスクは以下の通りであるという結論に至りました[1]実際のプロジェクトではデザインの戻しやCMSの研修など、もっと多くのタスクがあるが、話の都合上簡略化した。。
- 要件定義（0.5ヶ月）
- 画面設計 （0.5ヶ月）
- デザイン作成（１ヶ月）
- システム設計 （0.5ヶ月）
- CMSの開発（２ヶ月）
- テスト（１ヶ月）
- ページの作成（１ヶ月）
（ ）内は各タスクの作業時間を表しています。これらのタスクを上から順番に処理していくと、6.5ヶ月かかってしまい、12月頭からプロジェクトを開始すると、４月１日に公開することはできません。
そのため、一部のタスクを並行実施して、なんとか翌年の４月１日の公開を実現させるようにします。
タスクの細分化
並行して実施させることができるタスクを確認する前に、さらにタスクを詳細化していきます。
再度プロジェクトメンバー間で話し合った結果、以下のように「CMSの開発」、「ページの作成」、「テスト」が細分化できることが分かりました。
- 要件定義（0.5ヶ月）
- 画面設計 （0.5ヶ月）
- デザイン作成（１ヶ月）
- システム設計 （0.5ヶ月）
- CMSの開発
- ページ投稿機能の開発（0.5ヶ月）
- お知らせ投稿機能の開発（0.5ヶ月）
- カレンダー機能の開発（１ヶ月）
- テスト
- ページ投稿機能のテスト（0.25ヶ月）
- お知らせ投稿機能のテスト（ 0.25ヶ月 ）
- カレンダー機能のテスト（0.5ヶ月）
- ページの作成 （１ページにつき１日）
「CMSの開発」についてはそれぞれ「ページ投稿機能」、「お知らせ投稿機能」、「カレンダー機能」の３つの機能の開発に分かれており、 各機能の開発期間はそれぞれ0.5ヶ月、0.5ヶ月、１ヶ月でした。そして、この機能のテストも機能にあわせて３つに分けることができました。
また、ページ投稿は１ページにつき１日必要であり、30ページの投稿が必要であることから１ヶ月の作業時間が見込まれていました。
ここからは、これらのタスクを並行実施する流れを見ていきます。
タスクの並行実施を計画する
何が並行実施できて、何ができないか
タスクが細分化できたら、何が並行処理できて、何ができないかを確認していきます。
ここで確認すべきなのは、それぞれのタスクは何を前工程として必要としているかです。つまり、何かの作業を完了させなければ進められないタスクはどこかを見つけていきます。
今回のケースでは基本的にすべて一連の工程となっていたとします。つまり、要件定義を完了させなければ画面設計ができず、画面設計が終わらなければデザイン作成とシステム設計ができず、デザイン作成とシステム設計が完了していなければCMSの開発ができず、CMSが完了していなければテストができず、テストまで完了していなければページの作成ができないという状況でした。
しかし、デザイン作成とシステム設計は画面設計が完了していれば着手できるので、並行実施することにしました。
その結果、作業の流れは下の図のように改善することができました。
デザイン作成とシステム設計を同時に実施したとしても、システム設計のための作業時間（0.5ヶ月）しか短縮できません。まだまだすべての作業を完了させるまで６ヶ月かかってしまう計算となり、予定日の公開には間に合わなさそうです。
そのため、細分化したタスクの中で並行実施が可能なタスクがないかを検討していきます。
細分化したタスクの中で並行実施できないか
上述の通り、「CMSの開発」、「ページの作成」、「テスト」 についてはさらに細分化することが可能でした。
「CMSの開発」についてはそれぞれ「ページ投稿機能」、「お知らせ投稿機能」、「カレンダー機能」の３つの機能の開発に分かれており、それぞれの機能の開発は並行実施できるとします。ここではプログラマーを２人プロジェクトに参画してもらうようにし、１人には１ヶ月かかるカレンダー機能を担当してもらい、もう１人にはページの投稿機能とお知らせ投稿機能を開発してもうようにしました。また、これらの機能のテストも、テスターを２人にして、１人はカレンダー機能のテストを行い、もう１人はページ投稿機能とお知らせ投稿機能のテストをすることとしました。
また、ページ作成についても、全30ページのWebサイトを、アシスタント２人が15ページずつ担当して作成することとしました。
このように細分化タスクを並行実施するようにした結果、下の図のような流れで作業を行うこととしました。
CMSの開発、テスト、ページの作成のタスクが短縮された結果、すべての作業を完了させても４ヶ月の作業時間で済むようになり、４月１日の公開の目途がたちました。
（もちろん、このスケジュール通りにプロジェクトが進められるかどうかはまた別の話ではありますが……）
ファスト・トラッキング以外のスケジュール短縮法
ファスト・トラッキングはPMBOKでも紹介されるくらいポピュラーなスケジュール短縮技法の１つです。
このファスト・トラッキングと双璧をなしているのが、「クラッシング」です。
ファスト・トラッキングが作業やアクティビティを並行実施することに着目している一方で、クラッシングはネックとなっている作業に充てる人数を増やすことによってスケジュール短縮を行おうとします。
このクラッシングについては、以下のページもご参照ください。
ファスト・トラッキングはコストとリスクが増える
今回は短納期のプロジェクトやスケジュールの短縮が必要になった時に、ファスト・トラッキングを用いてタスクを並行実施する方法を見ていきました。
最後にタスクを並行実施するときの注意点を紹介していきます。
タスクを並行実施する場合は、多くの場合コストとリスクの増加を引き起こします。
例えば先ほど見てきたプロジェクトの例ですと、プログラマーやテスター、アシスタントを２人体制にしたため、２人分の時間を拘束する料金が必要になります。
Webデザイン会社のリソースに十分な余裕があれば問題ないのですが、外部のパートナー企業やフリーランスに声をかける場合は追加の料金が発生してしまいます。
また、プロジェクトのメンバーが増えるということはコミュニケーションコストが増加することも考えられます。
例えばテスト作業や投稿作業を複数人で行っていくと、お互いの作業の進捗などがお互いに影響する場合もあり、１人で作業をするときには必要なかったコミュニケーションの時間を増やしてしまうかもしれません。
さらに、作業員が複数人になると、それらの作業の整合性を保つことができないと、作業のミスを引き起こすリスクも発生します。そのため、増加した作業員を統括する人員も必要になることもありますが、そうなるとさらにコストは増加します。
このように、作業の並行実施はコストの増加をもたらすことが多いため、プロジェクト中にスケジュールの短縮を求められたときはもちろんのこと、短納期であるプロジェクトの依頼を受けた場合には、それらの内容を見積書に含めておいたほうがよいでしょう。
注
| ↑1 | 実際のプロジェクトではデザインの戻しやCMSの研修など、もっと多くのタスクがあるが、話の都合上簡略化した。 |
|---|