StartとEnd — タスク間の依存関係

StartとEnd — タスク間の依存関係



生産スケジューリングやプロジェクト・スケジューリングの世界では、仕事を細かなタスクにわけて、そのタスク間の前後関係について制約条件を定義することが多い。たとえば、先行タスクＡが終わらないと、後続タスクＢを始めることができない、などのように。こうした定義付けを、「タスクの依存関係」という。



タスクの依存関係の定義においては、ふつう、各タスクの開始（Start）時点および終了（End）時点での関連性に注目する。そして、たとえば、先行タスクのEndが後続タスクのStartにつながるのであれば、これをEnd-Startの関係（略称“E-S”）の依存関係と呼んだりする。



もっとも、ときどき、タスクの途中で他のタスクに分岐したり合流したりする図を見かけることがあるが、これはあまり良いやり方とは言えない。タスクというのは、それ自体が完結した作業単位であるべきで、もし途中で分岐したり合流したりするのであれば、本当はその点の前後でタスクを分割して定義すべきだったのだ（こうした例は、工順をうまく整理できていない生産スケジューリングでよく見かける）。



タスクの依存関係は、基本的には S-S、E-S、E-E、S-Eの４種類である。この中でもっともよく使われるのは、上述したE-SすなわちEnd-Start関係であろう。また、Start-Startも、比較的よく使われる。たとえば、建物の壁材を張るタスクと、壁の下塗りをするタスクを考えればいい。壁材を張り始めたら、その作業が建物全体に完了するのを待たずとも、すぐに下塗りにとりかかることができる。これがS-S関係である。逆に、最終引き渡しのタスクと、プロジェクト・マネジメントのタスクなどは、前者が終わると後者も（ほぼ）自動的に完了となるので、End-End関係になる。



ところで、一番分かりにくいのは、Start-End関係だろう。これが使えるようになると、スケジューリングのモデリング入門編は済んだ、と言ってもいいほどだ。



Start-End関係は、単純に考えると、先行のタスクが開始すると後続のタスクが終了する、という、ひどく変てこな依存関係のように見える。むろん、こんな馬鹿な話はない。「先行・後続」というタスクの順序を、考えなしに適用するから誤解を生むのだ。これを、タスクＡの開始とタスクＢの終了が関係づけられていると理解すれば、もっと明快だろう。



もっとも、“タスクＢが終わってタスクＡが開始するのならば、通常のEnd-Start関係とどこが違うのだ”という疑問も出るかもしれない。そうではないのだ。これは、“タスクＡが開始しなければ、タスクＢが終わることができない”と読むべきなのである。言いかえれば、後続が開始することが先行の完了の条件なのである。



具体例を挙げよう。たとえば、既存システムを運用しながら、新システムを導入するプロジェクトを考えよう。新システムが開発され、実運用がはじまって、はじめて旧システムは運用を終了することができる。決して、この逆の順序ではないことに注意してもらいたい。後続がはじまる前に、先行タスクを勝手に終わることはできないのだ。



生産スケジューリングの場面ならば、たとえばこうだ：後続の工程（機械）が利用可能になるまでは、前工程に仕掛品をずっと保管しておかなければならない。これもStart-Endだ。あるいは、夜シフトがはじまらない限り、昼シフトは終わることができない、など。隙間を空けずに何かを運用しなければならない系では、しばしばStart-End関係のお世話になることになる。



タスクの依存関係については、E-SやS-Sに付随して、タイム・ラグを規定したりすることもある（たとえば8時間以上たたないと後続が開始できない、など）。あるいは、S-SとE-Eを同時に満たす必要があったり、いろいろとバリエーションが存在する。



高機能のAPSになればなるほど、タスクの依存関係については柔軟なモデル化が可能になる。とはいえ、高機能なAPSがいつでも良いわけではない。高機能なものは、それなりにマスタデータの完全性を要求されるし、運用やチューニングの手間もふえるし、なにより高価である。「問題の身の丈」にあったツールを選べるよう、モデル化の工夫を凝らす方が経済的に引き合うことが多いのである。いつでも「ツールは使いよう」なのだから。

Follow me!