久しぶりにスケジューリングの話を書こう。スケジュールがなぜ長くなってしまうのか、どこを攻めたら短くできるのか、それを数字で指標化できる手法についてである。

いま、あるシステム製品をおさめる仕事を考える。単純化のために、この仕事は以下の６つの作業項目（アクティビティ）のみからなると考える。

1.　基本設計　　（推定所要期間＝20日）
2.1 ハード調達　（推定所要期間＝35日） 先行作業：基本設計
2.2 設置調整　　（推定所要期間＝ 5日） 先行作業：ハード調達
3.1 詳細設計　　（推定所要期間＝10日） 先行作業：基本設計
3.2 ソフト開発　（推定所要期間＝20日） 先行作業：詳細設計
4.　総合テスト　（推定所要期間＝15日） 先行作業：設置調整、ソフト開発

さて、このお仕事の納期は何日かかるだろうか。これは、作業項目とその順序関係を図に書いてみると分かりやすい。仕事の全体像をネットワーク・ダイアグラムで表す流儀にはいくつかあるが、ここでは一番広く用いられている図法を使う。Precedence Diagramなどと呼ばれているもので、作業項目を四角形で表し、その順序関係を矢印で示す。



（図１　作業項目の順序を示すネットワーク・ダイアグラム）

ただし、ここでちょっとした約束事がある。四角形の中心に作業項目の名前を書き、その下に所要期間の値を書く。それ以外に、左上・左下・右上・右下に、それぞれ小さな欄を置いておく。ここに、あとで数値を計算して記入するのである。記入するのは、以下のような項目だ。

左上：Early Start （ES＝最早着手日）
右上：Early Finish （EF＝最早完了日）
左下：Latest Start （LS＝最遅着手日）
右下：Latest Finish （LF＝最遅完了日）

これらはそれぞれ、「最も早く着手できる日」、「最も早く完了できる日」、「最も遅く着手できる日」「最も遅く完了できる日」、の意味だ。この４つは、スケジューリングにおける最も基本的な概念であるから、覚えておいてほしい。

さて、頭のいい人なら、図１をちょっとにらんだだけで、全体の納期がいつになるか計算できてしまうだろう。しかし、ここでは一応説明のために、愚直に手順を追っていくことにする（それに、どんな頭がいい人でも、作業要素が50個も100個も並んでいたら、やはりすぐには答えが出るまい）。

まず、最初の作業（｢基本計画」）からはじめて、順に後ろの作業の日程を考えていく。基本設計の最早着手日を、0日とする。最早完了日は20日だ。後続するハード調達の最早着手日も20日になる。その最早完了日は20+35 = 55日、という具合に、前から後ろに順に計算していく。このような手順を、「フォワード・スケジューリング」という。

ところで、最後の「総合テスト」には、設置調整とソフト開発の二つの先行作業があり、異なった最早完了日がある。どちらをとるべきか？　－－いうまでもない。「総合テスト」は両方がそろわなければ着手できないのだから、遅い方（数字の大きい方）の最早完了日を，自分の最早着手日として記入する。

ルール1：複数の先行作業がある場合は、その最早完了日の大きい（遅い）方をとって、自分の最早着手日とする

こうして、全作業項目のESとEFが計算できた。これが図２だ。これを見ると、総合テストは最も早くても75日たたないと完了しないことが分かる。これが全体の納期だ。ただし、話はまだつづきがある。



（図２　最早着手日と最早完了日）

次に、最後の作業項目から逆順に、最遅完了日と最遅着手日をさかのぼって計算していく。これをバックワード・スケジューリングとよぶ。後続の最遅着手日を、自分の最遅完了日に記入し、そこから所要期間を引き算して、自分の最遅着手日を求める。

ここでまた、「基本設計」のように複数の後続作業のあるものがでてくる。ハード調達の最遅着手日＝20日、詳細設計の最遅着手日＝30日だ。この場合、ハード調達は遅くても20日にはスタートしなければ間に合わないのだから、基本設計の最遅完了日は20日になっていなくてはならないことがわかる。

ルール２：複数の後続作業がある場合は、その最遅着手日の小さい（早い）方をとって、自分の最遅完了日とする

この結果、すべての作業項目の４つの箱がうまった。さて、ここで、左上＝左下、となっている作業項目を拾い出す。これは、“最も早く着手できる日＝遅くてもその日にスタートしないと間に合わない日”になっている、まったく日程的余裕のない作業だ。このような作業のならびを、『クリティカル・パス』と呼ぶ。日本語では、隘路という。図３では、そのクリティカル・パスを赤い矢印でマークした。



（図３　全体の日程とクリティカル・パス）

ちなみに、左上＜左下、となっている作業項目は、着手に日程上の余裕があるわけだ。たとえば詳細設計は、20日に着手可能だが、30日に着手しても間に合う。この余裕を、英語で"Float"と呼ぶ。

ルール３：「最遅着手日－最早着手日」の値がFloat（余裕日数）を表す

クリティカル・パスとはすなわち、Float＝0日となっている作業項目の系列のことだ。そして、お仕事の全体納期は、クリティカル・パスの長さに等しい。これを短くしない限り、納期は早まらない。逆にいえば、Floatのある作業項目は、それ自体をどんなに頑張って早く仕上げても、全体の納期には何も貢献しないことになる。だから、プロマネは、かならず何がクリティカル・パスかをしっかり把握して、管理を底に集中させなければならない。

スケジューリングの世界で一番特徴的なことは、このように「大事な作業」と「大事でない作業」がくっきり分かれることである。これは、コスト管理の世界と全く異なる。コストはすべて足し算の世界で成り立っている。だから、どこかの作業項目で１円でも安くすれば、全体が１円安くなる。しかし、スケジューリングの世界では、Floatをもつ作業項目をいくら頑張ったって、何の足しにもならないのである。

さて、ここまではある意味、基礎だ。ところで、では、「大事な作業」は、“どれくらい大事”なのだろうか？　ここで、DRAGという指標が出てくるのだ。

DRAGとは、ある作業項目が、全体の納期をどれだけ後ろに押し下げているかを示す尺度である。たとえば、Floatをもつ作業項目は、DRAGはゼロになる。上の例では、詳細設計やソフト開発はDRAG＝0になる。他方、クリティカル・パスに乗っていて、しかも並行する作業のないもの、たとえば基本設計や総合テストは、その所要期間全部がDRAGになる。その所要期間分、納期を押し下げているからだ。そして、これらの要素は、その所要期間を短くすればするほど、納期は早くなる。

問題は、クリティカルだが、他にも並行する作業のある項目だ。たとえばハード調達や設置調整である。これらに並行する詳細設計→ソフト開発の系列は、10日のFloat日数を持っている。そこで、たとえばハード調達を5日短縮すれば、5日だけ、10日短縮すれば、10日だけ、全体納期が短くなるが、それ以上短縮すると、逆に並行する系列の方にクリティカル・パスが移ってしまうため、もはや納期には貢献しなくなる。その限界が10日なのである。そこで、ハード調達のDRAG＝10日になる。

設置調整の方は、そもそもが5日の所要期間しかない。並行する系列のFloat：10日よりも短い。だから、5日まで減らせば、その分は納期が前に倒れる。設置調整のDRAG＝5日だ。

整理すると、以下のようなルールになる：
(1) Float日数を持つ項目は、DRAG＝0日
(2) クリティカル・パス上にあり、かつ他に平行作業がない項目は、DRAG＝それ自体の所要期間
(3) クリティカル・パス上にあり、平行作業がある項目は、DRAG＝その並行作業系列のFloat日数
(4) ただし、その所要期間自体が平行作業のFloat日数要理小さいときには、DRAG＝それ自体の所要期間

この結果を図示したものが図４だ。


（図４　DRAGの値）

DRAGの値が分かると、何か得るところがあるのか？　あるのだ。DRAGは、その作業項目が、どれだけ納期を押しているかを直接表す。逆に、納期を早めたかったら、DRAG値の大きな作業項目をまっ先に攻めるべきである。その重要度が、一目瞭然になる。

DRAG値はある意味、その仕事全体が、どれだけ並列性から外れているかの尺度でもある。仕事を早めたかったら、独立した部分に分けて並列にすすめるしかない。これはどんな仕事でも（ピラミッドの建設でも、コンピュータ内部の計算プロセスでも）適用できる真理である。DRAGは、どこに並列性から外れた部分があるかを明確に示す。

まあ、この例はたった6個かそこらの作業項目だから、DRAGなど計算しなくてもじっと考えれば、攻めるべき箇所は分かる。しかし、これが60個だったら、あるいは600個だったら、もう目では分かるまい（ちなみに、わたしの勤務先で扱うスケジュールでは、Activity数＝600個は少ない方である）。

むろん、DRAGにせよ、クリティカル・パス法にせよ、批判しようと思えばいろいろと限界はある。静的な分析にすぎないとか、作業項目の所要期間がそんな1点見積で正確に見積られるか、とか、リソースの負荷上限が考慮されていない、などなど。ただ、忘れてはいけないことがある。それは、スケジューリングとは元々、様々な仮定をおいて作成した近似モデルに過ぎないということだ。モデルとはつねに単純化を伴うものである。だが、単純化することで、見えやすくなる事もあるのだ。シンプルな道具は、使い所を知った上で、シンプルに使えばきちんと威力を発揮する。スケジューリング手法も同じで、いつ、どう使うかが知恵なのである。

さらにいうと、DRAG指標はさらにコストを加味すると、さらにぐっと使い勝手を増す。しかし、いつものように長くなりすぎた。それについては項をあらためてまた書こう。