製品機能に対するソフトウェアの各モジュールが実装すべき処理（内部機能）が、前回までで明確になりましたが、現在のソフト開発は既存ソフトウェアの流用がほとんどですので、その対応も考えておく必要があります。一連の分析でモジュールが実装すべき内部機能（処理）が明らかになっているので、流用が主な開発であっても既存モジュールに対してどのような修正を行う必要があるのかは明らかです。この方法をとっていれば、流用中心であっても、新規作成の場合であっても、同じ仕組みで対応することができます。
そして、モジュールごとの必要な処理が明確になるということは、具体的な開発作業が明確になることを意味します。つまり、製品開発に必要な 作業(WBS) を作成することができ、また、作業見積もりも可能になるということです。これが、下記に再掲載した図33「スケジュールが作成される過程」のように、外部仕様、ソフト内部構造（モジュール）、必要作業（WBS）と逐次明確になっていき、見積もりができるようになるということです。全体の流れを理解していただけたでしょうか。
図33. スケジュールが作成される過程
スケジュールが作成される過程でも示しているように、進捗管理に適した開発スケジュールを作成することがゴールなのですが、ソフトウェア開発の場合、スケジュールにするにはさらに工夫が必要です。よく見かけるソフトウェアの開発スケジュールにおける問題を確認して、それからどのような工夫が必要なのかを解説したいと思います。
図35. よくあるソフトウェア開発スケジュール
図35は、よく見かけるソフトウェア開発スケジュールの例です。このスケジュールでは、次のような問題を抱えています。
a. 機能ごとに開発工程別に作業（タスク）をブレークダウンしている
b. 機能によっては結合テストを実施するまでに待ちが発生している
c. システムテストも個別機能の開発作業の一部となっている
問題の本質は、スケジュールと実際のソフト開発作業とが一致していないことです。そのために、このようなスケジュールではソフト開発の進捗を確認することができません。良く聞く、「ソフト開発の進捗がわからない」「ソフト開発は突然遅れが発生する」などの原因のひとつになっています。
問題 (a) は実際の開発作業とスケジュールが一致していない代表的な現象です。実際の開発現場では、基本設計、詳細設計、コーディング、単体テスト、結合テスト、システムテストという、いわゆるウォーターフォール・スタイルでソフト開発が進むことは、ほとんどないはずです。現実のソフト開発は、コーディングをしているときに設計の不備に気づき設計を変更したり、単体テスト実施中ににロジック誤りに気づいて詳細設計とコーディングを修正したり、結合テストの結果で必要な機能が抜けていることがわかり基本設計からやり直したり、ということが起きています。
もし、図35 のようなスケジュールに沿って機能ごとにウォーターフォール・スタイルでソフト開発を進めたとしても、機能１の単体テストを終了して、機能２の詳細設計を行っているときに機能１の詳細設計ミスに気づいたり、機能３のコーディング中に機能１とのインタフェースの不備がわかり機能１の基本設計からやり直しが必要になったり、というようなことが起きてしまいます。機能ごとに完全な設計を行うことは非常に困難なのです。
つまり、図35 のようなスケジュールを立てても、ソフトウェアは機能ごとに完成品を作れるわけでもなく、機能ごとにウォーターフォール型の開発ができるわけでもなく、進捗管理のための作業計画になっていないのです。ソフト開発メンバー全員に毎日進捗をヒアリングしてスケジュール通りに進んでいること確認しているのに、ある日突然、スケジュールにない作業が発生したり、何日も遅れていること...
が発覚したりするのはなぜなんだというプロジェクトリーダーの嘆きは、そもそもスケジュールが開発作業の実態と合っていないため、進捗管理の基準として機能しないことが原因のひとつなのです。
次回は、上記の問題b：機能によっては結合テストを実施するまでに待ちが発生しているを考察します。