概スケジュールを作成する

　最終成果物、あるいは途中成果物としてに納入が求められているものがイメージできたところで、それを実現するための大まかな段取り、則ち「概スケジュール」を策定します。

　スケジュールというのは、要求されているものをどのようにして納めるかというときの“段取”りであるということも出来ます。また、オリエンテーリングのように、ゴールや途中のチェックポイントに対して、最短のコースを見付けるという問題でもあります。

　求められているものが見えた段階で、

　　１）それを達成するには、どのような成果物を繋いで行けばいいのか
　　２）その「量」をこなすためには、どれだけの要員を投入すればいいのか
　　３）そのためには何を何時までに仕上げなければならないか

といった観点から「概スケジュール」を作り上げていきます。

　注意しなければならないのは、作業が求められているのではなく、成果物が求められているということです。したがって、もし求められている成果物が、すでに出来上がっているのなら、これ以降の作業は存在しません。

　この観点に立たなければ「コストに見合う作業」が導き出せなくなります。この世界では、最終的に要求が満たせない限り、途中の努力は評価されないことを知るべきです。

　１）は言い換えれば「要求の分析」に相当します。必要なら、ここで、「ファンクション・ポイント法」などの見積もり手法を使うことも考えられます。また、一般の「分析手法」の一一部を使って、作業の「総量」を見積もることも有効です。

　いずれにしろ、ここで、作業の種類（設計作業、インプリメント作業、テスト作業などの種類）別にどれだけの作業量が必要なのかを割り出します。例えば設計作業にどれだけの「量」が必要か、インプリメントやテストの作業にどれだけの「量」が必要かということに目星を付けます。これは、求められている機能の“質量”や品質の種類などから、「設計書」自身の量やテストケースの量が推測されます。もちろん、この段階では概算です。

　ただ気をつけなければならないことは、作業の「量」は、成果物をイメージすることで見えてくるものです。「作業」を見ていては「量」は見えてきません。

　しかしながら、ここで求められた「作業量」もそのままでは要求されている「期日」に間に合いません（多分、ず〜とオーバーします）。そこで２）のステップとして、一体どれだけの要員を、どの段階で投入するか検討します。このとき、大まかな「分担」がイメージされます。

　「分析」手法をつかっての分析が効果を発揮するのはこのときです。要求の内容に対して、その難易度などが分析によって把握されるはずです。逆にいえば、それが把握できるところで分析を止めるのです。こうすることによって、作業と担当者のミスマッチを防ぐことが出来ます。もちろん、そのためには、見積もり迄の時間が少し多めに必要になりますが。

　そのプジロジェクトに投入できるコストを考慮して投入するスタッフを決めた後は、３）のステップであるマイルストーンを設定します。「この段階で、何と何が出来ていること」「どのような成果物が出来上がっていること」といった途中の目標が設定されます。これは最終成果物、および納入することが求められている途中成果物を無理なく生成するための裏付けでもあります。

　もちろん、この設定には「暫定」の要素を含んでいます。「この段階で、これが出来て居れば・・」という安全弁の正確を帯びていることは否定できません。それでも、何らかの「基準」があったほうが、この後の詳細スケジューリングはやり易くなります。　

　したがって、この後、担当者毎の詳細スケジューリングに入って、その時点で、ここで設定されたマイルストーンが合理的ではないと判断されれば、この設定を変更することになりますが、それまでは、一定の役割を果たすことになります。

　こうして「概スケジュール」が出来上がります。もちろん、これには「権威」が与えられます。簡単に崩して良いわけではありません。ただ、個別のスケジュールが策定されるまでは、この「権威」も少し“ゆるめ”の状態にあります。

　なお、この段階の「概スケジュール」は、その裏付けが取れていないという意味で、「ネバナラナイ・スケジュール」の性格を帯びています。したがって、このままではトピックに書いてあるような罠にはまってしまいます。