(2013/03/26)久しぶりにスケジューリングの話を書こう。スケジュールがなぜ長くなってしまうのか、どこを攻めたら短くできるのか、それを数字で指標化できる手法についてである。いま、あるシステム製品をおさめる仕事を考える。単純化のために、この仕事は以下の6つの作業項目(アクティビティ)のみからなると考える。先行作業:設置調整、ソフト開発さて、このお仕事の納期は何日かかるだろうか。これは、作業項目とその順序関係を図に書いてみると分かりやすい。仕事の全体像をネットワーク・ダイアグラムで表す流儀にはいくつかあるが、ここでは一番広く用いられている図法を使う。Diagramなどと呼ばれているもので、作業項目を四角形で表し、その順序関係を矢印で示す。作業項目の順序を示すネットワーク・ダイアグラム)ただし、ここでちょっとした約束事がある。四角形の中心に作業項目の名前を書き、その下に所要期間の値を書く。それぞれ小さな欄を置いておく。ここに、あとで数値を計算して記入するのである。記入するのは、以下のような項目だ。(LF=最遅完了日)これらはそれぞれ、「最も早く着手できる日」、「最も早く完了できる日」、「最も遅く着手できる日」「最も遅く完了できる日」、の意味だ。この4つは、スケジューリングにおける最も基本的な概念であるから、覚えておいてほしい。頭のいい人なら、図1をちょっとにらんだだけで、全体の納期がいつになるか計算できてしまうだろう。ここでは一応説明のために、愚直に手順を追っていくことにする(それに、どんな頭がいい人でも、作業要素が50個も100個も並んでいたら、やはりすぐには答えが出るまい)。最初の作業(「基本計画」)からはじめて、順に後ろの作業の日程を考えていく。基本設計の最早着手日を、0日とする。後続するハード調達の最早着手日も20日になる。55日、という具合に、前から後ろに順に計算していく。このような手順を、「フォワード・スケジューリング」という。ところで、最後の「総合テスト」には、設置調整とソフト開発の二つの先行作業があり、異なった最早完了日がある。「総合テスト」は両方がそろわなければ着手できないのだから、遅い方(数字の大きい方)の最早完了日を,自分の最早着手日として記入する。ルール1:複数の先行作業がある場合は、その最早完了日の大きい(遅い)方をとって、自分の最早着手日とするこうして、全作業項目のESとEFが計算できた。これを見ると、総合テストは最も早くても75日たたないと完了しないことが分かる。話はまだつづきがある。着手日と最早完了日)次に、最後の作業項目から逆順に、最遅完了日と最遅着手日をさかのぼって計算していく。これをバックワード・スケジューリングとよぶ。後続の最遅着手日を、自分の最遅完了日に記入し、そこから所要期間を引き算して、自分の最遅着手日を求める。ここでまた、「基本設計」のように複数の後続作業のあるものがでてくる。ハード調達の最遅着手日=20日、詳細設計の最遅着手日=30日だ。この場合、ハード調達は遅くても20日にはスタートしなければ間に合わないのだから、基本設計の最遅完了日は20日になっていなくてはならないことがわかる。ルール2:複数の後続作業がある場合は、その最遅着手日の小さい(早い)方をとって、自分の最遅完了日とするこの結果、すべての作業項目の4つの箱がうまった。ここで、左上=左下、となっている作業項目を拾い出す。これは、“最も早く着手できる日=遅くてもその日にスタートしないと間に合わない日”になっている、まったく日程的余裕のない作業だ。このような作業のならびを、『クリティカル・パス』と呼ぶ。日本語では、隘路という。図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日だ。その所要期間自体が平行作業のFloat日数要理小さいときには、DRAG=それ自体の所要期間この結果を図示したものが図4だ。DRAGは、その作業項目が、どれだけ納期を押しているかを直接表す。逆に、納期を早めたかったら、DRAG値の大きな作業項目をまっ先に攻めるべきである。その重要度が、一目瞭然になる。DRAG値はある意味、その仕事全体が、どれだけ並列性から外れているかの尺度でもある。仕事を早めたかったら、独立した部分に分けて並列にすすめるしかない。これはどんな仕事でも(ピラミッドの建設でも、コンピュータ内部の計算プロセスでも)適用できる真理である。DRAGは、どこに並列性から外れた部分があるかを明確に示す。この例はたった6個かそこらの作業項目だから、DRAGなど計算しなくてもじっと考えれば、攻めるべき箇所は分かる。これが60個だったら、あるいは800個だったら、もう目では分かるまい(ちなみに、わたしの勤務先で扱うスケジュールでは、Activity数=600個は少ない方である)。DRAGにせよ、クリティカル・パス法にせよ、批判しようと思えばいろいろと限界はある。静的な分析にすぎないとか、作業項目の所要期間がそんな1点見積で正確に見積られるか、とか、リソースの負荷上限が考慮されていない、などなど。忘れてはいけないことがある。それは、スケジューリングとは元々、様々な仮定をおいて作成した近似モデルに過ぎないということだ。モデルとはつねに単純化を伴うものである。単純化することで、見えやすくなる事もあるのだ。シンプルな道具は、使い所を知った上で、シンプルに使えばきちんと威力を発揮する。スケジューリング手法も同じで、いつ、どう使うかが知恵なのである。いうと、DRAG指標はさらにコストを加味すると、さらにぐっと使い勝手を増す。いつものように長くなりすぎた。それについては項をあらためてまた書こう。technology.。