作業の成果物をイメージする

　概スケジュールを受けて、今度は各分担の担当者レベルでのスケジューリングになります。各担当者レベルの「概スケジュール」は、大元の概スケジュールから、比較的容易に引き出せます。そこには自分の分担部分が書かれているはずです。したがって、此処からは各自の詳細スケジュールを作り上げる作業になります。

　既に述べたように、スケジュールを考えるということは、適切な成果物をイメージすることです。あるいは、適切な成果物の連鎖をさかのぼる形で考えることです。もしその前に「作業」をイメージしてしまうと、最短距離から外れてしまう危険があります。

　「作業」は、それがイメージされた時点では、殆ど例外なく「必要な作業」なのです。そこでは全く関係ない作業などイメージされることはなく、必ず、「必要性」に対して何らかの“接点”を持っているはずです。そのため、一度「作業が設定」されたら、その作業は次の瞬間から「存在」を主張することになります。

　実際にコンサルティングの場で、気になる作業に対して「この作業は必要ですか？」と質問すると、一生懸命にその必要性、正当性を並べてきます。まるで、公益法人つぶしに対する役所の反応のように。

　だから、不用意に作業が設定されることを避けるために、どのような成果物が必要なのか、あるいは有効なのか、その成果物を産み出すには、前提として（＝入力データとして）どのようなことが書かれた成果物が必要なのか、というところから入っていくことを勧めます。

　通常、それぞれの担当者には、入ってくるもの（誰かの成果物か、要求内容）と、最終的に出ていくもの（担当者レベルの最終成果物）が明らかにされています。これは、プロジェクト全体のレベルでも同じ構図を見ることが出来ます。

　そして極端に言えば、各担当者は、この「間」をどうやってもいいのです。もちろん、その途中の生成物の納入が指定されているときは、それを実現しなければなりませんが、それ以外は、もっとも効果的な方法を考えればいいのです。

　最終的に納めるのは成果物です。それがプロジェクトの最終製品であろうと、各担当者の途中成果物であろうと、納めるのは「作業」ではありません。

　一般に、プロセス・レベルが「１」の組織や、ここで述べているようなことを注意しない組織では、ほとんど例外なく「作業」を並べる形でスケジュールが作られています。その結果、ゴールまでのルートが遠くなったり、不必要な中間生成物を作ってしまいます。いわゆる、「作業の捏造」です。

　それでも、そこに設定された個々の作業は、どれ一つとして「余分」な作業は見当たらないのです。それらの作業はお互いに連携しており、依存しあっているため、その中の一つをつまみ出して捨て去ることは出来ません。言い換えれば、「作業」は一旦設定された時点で、お互いにバランスしあうのです。こうなると、まとめて崩すしかなくなります。

　また、このような場合、後の方でチーム単位でチューニングが必要になったとき、彼のスケジュールは、それが不可能であることを真っ先に主張するでしょう。どの作業も「必要」なのですから。