納期が延びる要因を指標化する - スケジュールのDRAGとはどんな尺度か

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

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

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

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

e0058447_2364470.gif


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

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

左上:Early Start (ES=最早着手日)
右上:Early Finish (EF=最早完了日)
左下:Latest Start (LS=最遅着手日)
右下:Latest Finish (LF=最遅完了日)

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

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

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

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

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

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

e0058447_23142952.gif


(図2 最早着手日と最早完了日)

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

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

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

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

e0058447_2393173.gif


(図3 全体の日程とクリティカル・パス)

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

ルール3:「最遅着手日-最早着手日」の値がFloat(余裕日数)を表す

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

スケジューリングの世界で一番特徴的なことは、このように「大事な作業」と「大事でない作業」がくっきり分かれることである。これは、コスト管理の世界と全く異なる。コストはすべて足し算の世界で成り立っている。だから、どこかの作業項目で1円でも安くすれば、全体が1円安くなる。しかし、スケジューリングの世界では、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=それ自体の所要期間

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

e0058447_23114944.gif

(図4 DRAGの値)

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

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

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

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

さらにいうと、DRAG指標はさらにコストを加味すると、さらにぐっと使い勝手を増す。しかし、いつものように長くなりすぎた。それについては項をあらためてまた書こう。
by Tomoichi_Sato | 2013-03-25 23:18 | 時間管理術 | Comments(0)
<< 「リスク確率に基づくプロジェク... ガバナンスの最適設計を考える >>