タスクのスケジューリング (CCPM)

タスクとWBSの定義

タスクを定義する目的は、プロジェクトの完了に必要なすべてのタスクあるいはフェーズを識別することです。

明確なスコープの説明、WBSあるいは充分なスコープ定義がない場合、ワークショップを開いて要件を収集し、プロジェクトスケジュールを展開する必要があります。

この段階では、プロジェクトのすべての詳細はまだ不明です。

タスクの属性:

  • 1人のオーナー – 各タスクの責任者が誰かを明確にします。

  • 中間結果なし – タスク内にサブタスクは必要ありません。

  • 期間 – これを管理します。

プロジェクトのアウトラインを明確にするため、タスクを細かく分割するプロセスを、WBS(ワークブレークダウンストラクチャ)と言います。

プロジェクトマネージャは通常、プロジェクトの実行を単純化するためにWBSを使用します。WBSでは、大きなタスクを管理可能な小作業に分割します。分割された小作業は予測しやすく、管理も簡単です。

WBSの適用には、特定の制約はありません。この手法は、どんなタイプのプロジェクトマネジメントにも使用できます。WBSの作成は、プロジェクトの主要な成果物を識別することから始めます。

この重要なステップは通常、プロジェクトマネージャとプロジェクトに関わるチームメンバーの専門家が行います。このステップが完了すると、チームメンバーの専門家が上位レベルのタスクをより小さな作業単位に分割していきます。

タスクを分割するプロセスでは、様々な細分化のレベルが考えられます。高位レベルのタスクを10のサブタスクに分割する人もいれば、同じタスクを20のサブタスクに分割する人も居ます。

WBSでは、タスクを分割する際に適用するような規則は特にありません。プロジェクトのタイプと使用する管理手法によって、細分化のレベルが決まると言えます。

WBSの効率こそが、プロジェクト成功の鍵となります。WBSは、計画、コスト予測、工数予測、リソース配置、スケジューリングを含む、すべてのプロジェクト管理作業の基盤を提供します。

従ってWBSを作成することは、プロジェクト管理プロセスの重要なステップです。

注記

プロジェクトの完了を意味するマイルストンタスクでプロジェクトを終了するのは良い考えです。

入力したタスクは、デフォルトではすべて同じレベルに作成されます。インデント(IndentGrey)とアウトデント(OutdentGrey)ボタンで、自由にタスクレベルを作成することができます。WBSでのタスク間の相互関係は、親タスクがすべての子タスクと下位レベルタスクの集約タスクとなる、親子関係です。

Sciformaでは、10レベルまでのWBS構造をサポートしています。レベル0が最上位でプロジェクトを表し、レベル10が最下位となります。レベル自体はいくらでも作成できますが、アウトラインコードとスプレッドシートのフォーマットはレベル10までをサポートしています。最下位レベルのタスクは実際の作業が実行されるレベルです。最上位のレベル0はプロジェクトの作成時にプロジェクト名称を入力するレベルとして確保されます。

タスク期間の予測

プロジェクトを管理可能なタスクに細分化した後は、それぞれのタスクの実行に必要な期間を予測します。タスクの期間はWBSの最下位レベルのタスク(基本タスクあるいは子タスク)にのみ設定します。

WBSでは、最下位レベルのタスクだけが実際に行う作業となり、上位レベルのタスク(親タスク)は実作業のグループをまとめたものになります。

各タスクの完了に必要な時間を判断する方法は、数多くあります。それまでのデータから推測、担当部門からの見積時間、PERT分析の結果などが一般的です。

プロジェクトの計画と実行は、ソフトウェアや機械ではなく人間が行うものです。プロジェクトマネージャは人的要因の影響を忘れてはいけません。エリヤフ・ゴールドラット博士が開発したCCPM(クリティカルチェーン法)では、さまざまなポイントを挙げています。

期間予測

プロジェクトマネージャからタスク期間の予測を尋ねられた場合を想定してみましょう。

最初に、担当する作業の期間を5日間と予測しました。しかし、よく考えてみると難しい部分も含まれているかもしれず、問題が発生する恐れもあります。そこで、8日間としたほうが妥当だと思われました。最終的には、楽観的な予測をするよりは確実な方が良いと判断し、プロジェクトマネージャにタスクには10日間が必要だと答えました。

この予測では、タスク期間の10日間には、5日間の安全バッファが含まれていることになります。実質5日間の作業に対し、10日間の期間を予測し、タスクリスクのバッファが5日間あるので、このタスクのリスクは低いと言えます。

タスク期間の予測にこういった安全バッファを織り込むことは間違いではありません。すべての要素とプロジェクトのコンテキストを考慮することは、完全に道理にかなっています。プロジェクト期間に影響を与えたくないと考えるのは、当たり前です。

学生症候群

学生症候群とは、大多数の学生(人間)は期限が迫ってからでないと本格的に宿題(仕事)に取り組まないという現象のことです。これにより、安全余裕期間はなくなり、ストレスとプレッシャーがかかることになります。

こういった先延ばしとマーフィの法則は固く結びついています。

マーフィの法則とは、"およそ失敗の可能性のある事柄は,かならず失敗する"あるいは"失敗する余地があるなら、失敗する"という格言です。

パーキンソンの法則

パーキンソンの法則:“仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する。”

つまり、2時間の作業を1週間以内に完了しなければならない時、その作業は(心理的に)複雑で困難なものになっていき、まるまる1週間を費やすことになる、と言うことです。実際に作業量が増えたり、追加作業が必要になるわけではなく、期日までに完了しなければならないというプレッシャーとストレスが進捗を遅らせます。タスクに的確な期間を見積もることで、合理的な時間制約内で作業し、タスクの複雑さを拡大させる(期間を延長させる)ことがなくなります。

マルチタスク

ほとんどの場合、同時に複数のプロジェクトを管理するのがビジネスルールです。

優先順位の高いプロジェクトのタスクを実行するため、別のプロジェクトのタスクを休止しなければならないという状況に遭遇していないプロジェクトマネージャはいないでしょう。

プロジェクトマネージャが同時に複数のプロジェクトを管理し、成果物と期限に責任を持つという状況では、こういったマルチタスクも理解できます。

顧客が内部の場合も、外部の場合でも、彼らは自分たちのプロジェクトは最優先されると思っており、順調に進捗するよう多くの要求を出します。

マルチタスクをやめ、タスクを順番に開始/完了するとしたら、プロジェクトの質は改善し、リソースの効率も上がり、ストレスも軽減されるでしょう。

タスクの関連性の定義

ラフスケジュールの立案の最後のステップは、タスクの順番と依存関係を識別することです。どんなプロジェクトにも、一連のタスクを実行する順番があります。

多くのタスクは並行して実行できますが、他のタスクが終了しないと開始できないタスクもあります。

タスクの関連性を定義する際、タスクに関する次の3つの質問に答える必要があります。

  1. そのタスクを開始する前に終了していなければならないタスクはどれか。

  2. そのタスクを開始する前に開始していなければならないタスクはどれか。

  3. そのタスクを終了する前に終了していなければならないタスクはどれか。

次の2つの定義があります。

  • 先行タスクは、別のタスクの条件となるタスクです。

  • 後続タスクは、別のタスクに依存するタスクです。

Sciformaでは、タスクの関連を定義するリンクが4種類あります。

タスクの関連性

定義/例

FS_link.png

FS (終了-開始):先行タスクが終了するまで、後続タスクを開始できません。

例:穴を開け終えるまで、木を植えられない。

SS_link.png

SS (開始-開始):先行タスクが開始するまで、後続タスクを開始できません。

例:ソフトウェア設計を開始したら、プログラミングを開始できる。

FF_link.png

FF (終了-終了):先行タスクが終了するまで、後続タスクを終了できません。

例:テストを終了したら、ドキュメント作成を終了できる。

SF_link.png

SF (開始-終了):先行タスクが開始するまで、後続タスクを終了できません。

リードとラグ

  • リード:後続タスクが先行タスクのイベントを待たずに作業をオーバーラップできる日数です。

  • ラグ:後続タスクが先行タスクのイベントから数える待機日数です。ラグはプラスの値で表示されます。例:1回目の塗装終了後、2日あけないと2回目の塗装を開始できない。

タスクの関連性

ラグ

リード

FS

FS_lag.png
FS_lead.png

SS

SS_lag.png
SS_lead.png

FF

FF_lag.png
FF_lead.png

SF

SF_lag.png
SF_lead.png
注記

リードとラグのないFS (終了-開始)リンクがSciformaでタスクを作成する際のデフォルトの関連性になります。

警告

タスクのリンクは、子タスク同士だけに作成することを強く推奨します。親タスクをリンクすることは避けてください。

期間制約について

プロジェクト内のタスクのシーケンスは、基本的に先行/後続関係で決まりますが、スケジュール上の制約が優先され、タスクの順番に影響をあたえることがあります。

プロジェクトマネージャは最短開始日フィールドに、その日より前にタスクを開始できない日にちを入力することができます。先行タスクの終了予定に関係なく、最短開始日フィールドで指定した日以前にタスクを開始することはできません。

例:タスクを請け負った業者の作業開始日が決まっており、その日以前にはタスクを開始することができない。

プロジェクトマネージャは強制開始日フィールドに、その日にタスクを開始しなければならない日にちを入力することができます。強制開始日が指定されると、実開始日を除く他のすべての制約は無視され、指定日にタスクが開始します。

例えば、参加者が多く、調整に時間のかかるワークショップなどに強制開始日を設定することが考えられます。また、すでに講師を予約済みの研修や、利用期間が限られる特殊な機械が必要な作業などにも設定します。

プロジェクトマネージャは終了期限フィールドに、タスクの完了目標日を入力することができます。タスクの終了予定日あるいはキーとなるマイルストンが終了期限を超えた場合、マイナスのフロート値(ネガティブフロート)が表示されます。

スケジュールタイプについて

Sciformaに入力されるすべてのタスクは、定義された依存関係に従い、デフォルトでできるだけ早く(ASAP)でスケジュールされます。タイプは、スケジュールタイプフィールドで決まります。

その他のスケジュールタイプは次の通りです。

できるだけ遅く(ALAP)がもう何時のオプションで、できる限りプロジェクトの終了日を重視してスケジュールする際に使用します。このタイプは通常、フロートのあるタスクに適用します。フロートのあるタスクをALAPでスケジュールすると、タスクはフロートの最後にスケジュールされます。

バッファ - バッファタスクを作成することができます。多くのプロジェクトでは、プロジェクトの終了予定日のようなクリティカルなマイルストンや保護すべきタスクを先行タスクとする、戦略的なバッファタスクをいくつか設定しています。通常だとマイルストンの先行タスクとなるタスクは、バッファタスクの先行タスクとなります。バッファタスクの期間は手動で設定します。

ハンモックタスクは、先行タスクの開始日と後続タスクの終了日を基にスケジュールされます。ハンモックタスクは、先行タスクの開始日と後続タスクの終了日の間にぶら下がり、タスク期間は2つのタスクの間の期間として動的に計算されます。ハンモックタスクの期間は、関連するタスクの開始日や終了日が変更されるとそれに伴い変更されます。ハンモックタスクを実行するには、先行タスクと後続タスクがそれぞれ1つだけである必要があります。プロジェクト全体にわたって継続するタスク、例えばプロジェクト管理業務などはハンモックタスクの典型的なものです。先行タスクあるいは後続タスクを指定しないと、親タスクの開始日と終了日によって期間が決定されます。

注記

合流バッファとプロジェクトバッファのスケジュールタイプは、CCPMで使用します。

共有安全期間

CCPMのキーポイントは、作業者は安全余裕なしにタスク期間を見積るということです。安全のための余裕としてこれまで追加していた期間は統合され、プロジェクトスケジュールの要所要所にバッファとして追加されます。タスクの終了に予定以上の時間がかかった場合、その超過分はバッファから消費されます。

この方法でプロジェクトをスケジュールのに必要な協力を得るには、個人と企業の両方の考え方を変える必要があります。これまでの隠された安全余裕は決して削除されたり、放棄されるわけではないことを全員が理解する必要があります。隠された安全余裕は、タスクレベルの隠されたリソースではなく、プロジェクトリソースとしてプールされ、露出されます。プロジェクトマネージャもプロジェクトチームも、時間の見積り技術を高めることで不確実性に打ち勝つのではなく、不確実性を包括することを納得する必要があります。タスクから安全余裕を外すことで、タスクは予測時間を超えて終了する可能性が高いことを関係者が受け入れることが必要です。これは悪いことではなく、普通のことです。タスクの実績は、予測ベースラインと比較し、差異を発見して問題とするためのものではなくなります。そうすると、チームメンバーは見積り方法を調整し、次の作業時間予測では再び隠された安全余裕を折り込み、クリティカルチェーンによる管理全体を台無しにすることになります。

見積り通りに作業を終了できないことを失敗とする作業環境を作ってはいけません。イノベーションは乱雑なものです。抑制を強く進め、内在する乱雑さをなくそうとする環境は、知らないうちにイノベーションを抑制することに繋がります。

目標は、成功確率が50%のタスク期間の見積りを得ることです。これは、50%の確率でタスクが見積り通りに終わらないことも意味します。また、タスクが見積時間より早く終る可能性もあります。

ただし、チームメンバーには、50%の成功確率で作業時間を見積もるよう依頼する代わりに、次の想定で作業時間を見積もるよう依頼します。

  • タスクに必要なすべての情報と資材は揃っている。

  • 中断なしにタスクに集中して作業できる。

  • 追加作業が必要となる突発的な事態は考慮しない。

もちろん、プロジェクト全体にわたってこれらの想定すべてが当てはまることは滅多にありません。これらの想定を使うことで、作業者に統計数理を紹介しなくとも、彼らは50%の成功確率に近い見積りを出すことができます。

SciformaのCCPMでは、2つの期間を入力し、追跡することができます。期間フィールドには、50%の成功確率の期間を入力します。Sciformaには、成功確率90%の安全余裕期間を計算するためのパラメータが用意されています。安全余裕期間は外部に公開する期間であり、期間は内部でプロジェクトの管理に使用する期間となります。

ALAPスケジューリング/逆方向スケジューリング

CCPMの重要な特徴は、タスクをできるだけ遅く開始するようスケジュールすることです。このようにスケジュールすることで、クリティカルパスのスケジュールとは反対に、タスクはプロジェクトの終了にできるだけ近くスケジュールされます。

プロジェクトの作業をできるだけ遅らせることには、いくつかの利点と1つの欠点があります。

  • 生産用語を使うと、ALAPでのスケジューリングはプロセス中作業(WIP)を最小化し、実際に必要となる前のコスト発生を避けることができます。プロジェクトマネージャの観点から言うと、開始予定のタスク数が少ないため、プロジェクトの重要な開始時期に焦点を絞ることができます。また、複雑な知識が要求されるプロジェクトでは、作業が進むに連れ発見がなされ、作業者の知識も増加します。タスクをできるだけ遅く(ALAP)でスケジュールすることで、こうして得た知識を活用することができるため、やり直しの必要性も最小化されます。

  • ALAPスケジュールの唯一の欠点は、伝統的なクリティカルパス法の用語で言うと、プロジェクトを追跡モードに切り替えるとすべてのタスクがクリティカルとなる点です。どのタスクでも、期間が延長されるとプロジェクトの終了日がその分だけ延長されます。この問題に対する解決策は、プロジェクト計画の要所に期間バッファを挿入することです。これらのバッファは緩衝材として働き、プロジェクトの終了日をタスクの期間延長から守ります。バッファのサイズは、プロジェクトの不確実性に対する適切な保護を提供できるよう決定する必要があります。

  • 希望するプロジェクトの終了日から逆方向にタスクをスケジュールする必要があるため、SciformaではCCPM用に逆方向スケジュール機能を提供しています。これは最後のタスクから入力し、プロジェクト全体を逆向けにスケジュールするということではありません。タスクを入力し、リンクを設定し、期間を指定したら、プロジェクトの終了日を固定して、タスクの開始日を計算するということです。タスクは、どんな順番で入力しても構いません。