ソフトのモジュール作成（プログラム作成）は機能セット単位にスケジュールするのが基本となります。そして、機能セットごとのモジュール作成は、詳細設計、コーディング、単体テストが一体となった作業と考えます。実際、ソフト開発の現場では、詳細設計、コーディング、単体テストが流れ作業として実施されることは稀です。コーディングをしたときに詳細設計のミスに気づくことや、単体テストの結果で関連するモジュールの機能を見直すことなど、何らかの手戻りは必ずあるものです。そもそも、製品開発はチャレンジの要素や不確実な要因を含んでいるものであり、そのソフト開発も単純な流れ作業で進むわけがないのです。手戻りが全くないことを前提とした開発スケジュールを作っても実情にあわず、使えないのは当然です。
前回の繰り返しになりますが、しっかりと進捗管理をやること、イコール、進捗確認を毎週ではなく毎日やることと考え、そのために、図35のようなモジュールの一つひとつの機能ごとに、詳細設計、コーディング、単体テストという一連の作業を日単位で計画しても、開発はこのような流れ作業通りには進みません。このような実際の開発作業と大きく乖離した計画を使って進捗管理をやること自体がムダなのです。
ソフト開発で重要なのは、手戻りを完全になくすことではなく、手戻りのフィードバック・ループをできるだけ小さくすることです。大きな手戻りとなる可能性をなくすことです。今回紹介している方法は、プログラム作成を、結合テストセット（機能セット）という、実際に動かして動作確認できる単位に分解し、その単位では詳細設計、コーディング、単体テストを手戻りのある一体化された作業にすることで、手戻りのフィードバック・ループを小さなものにしています。ソフト開発スケジュールはこのような考え方で計画する必要があります。
この方法であれば、ソフト開発の経験がないプロジェクトリーダーであってもハード屋さんであっても、ソフト開発スケジュールの内容確認はもちろん、進捗管理もできるはずです。それでは、今回紹介している方法で作成したソフトの開発スケジュールがどのような形になるのかを紹介しておきましょう。図39 をご覧ください。
図39. 理想的なソフト開発スケジュール
機能セットはＡとＢしか書いていませんが、実際の開発はもっと多くの機能セットになります。ただ、機能セットは、関連するモジュール機能の作成（プログラム作成）が詳細設計、コーディング、単体テストをひとつの作業（タスク）としてスケジュールされていることに変わりありません。また、モジュールの機能作成は同時並行に行うスケジュールにしていますが、担当者の状況によってシーケンシャルにせざるをえないこともありますし、その他様々な事情により調整が必要になることもあります。ただ、基本的な考え方、理想的なスケジュールを共通認識として持った上で調整することが大切です。
図39 ではシステムテストについてもスケジュールしています。ポイントは、システムテストのテスト分類に応じたスケジュールにすることです。単体テストや結合テストは、機能を中心としたテストですが、システムテストは製品としての総合的なテストですから、単体テストや結合...
テストとは全く違う観点でテストを実施することになります。したがって、どのようなテスト分類があり、それをどのような日程で実施するのかを明らかにする必要があります。
システムテストのスケジュールが、単純に線（タスク）が１本あるだけだったり、モジュールや機能で線（タスク）を引いていたりするケースをよく見かけますが、製品として、ソフトウェアに対してどのようなテストを行うのかをタスクとして記述してください。そのためには、システムテストのテスト分類を整理しておくことが前提となります。
次回は、進捗の見える化について、解説します。