ソフトウェア開発スケジュールでは次のような問題を抱えています。
a. 機能ごとに開発工程別に作業（タスク）をブレークダウンしている
b. 機能によっては結合テストを実施するまでに待ちが発生している
c. システムテストも個別機能の開発作業の一部となっている
前回に続いて、今回は上記の問題 (b) として挙げた、結合テスト実施までに待ちが発生していることを考察します。実際のソフト開発は機能ごとにウォータフォール型の流れるような開発作業になっているわけではないので、現実にはこのような待ちが発生しているわけではありませんが、ここで考えるべきポイントは結合テストの計画の立て方です。結合テストとは、いくつかの機能を合わせて動作確認をすることが目的です。そして、いくつかの機能ごとに段階的に動作確認を行うことで完成度を逐次確認する方法をとります。したがって、結合テストで重要なのは、どの機能とどの機能を合わせて、どのくらいの回数をかけて、どのような順番で、どのような日程で実施するのかということです。
このような方法をとる理由は、組込型ソフトウェア開発のリスクを減らすための効果的な方法のひとつが、ハードウェアと組み合わせ、段階的に動作確認をしながら完成度を見える化して進捗を確認することだからです。実際の開発現場では意識しているかどうかにかかわらず、何度も結合テストを繰り返して、その度に完成度を確認しているはずです。これを計画の際に明示的にすることが重要です。つまり、結合テストの範囲（どのような組み合わせで結合するのか）とその実施日程（いつ動作確認ができるのか）が明示されているスケジュールにするということです。
図35. よくあるソフトウェア開発スケジュール
振り返って図35 を見てみると、結合テストという作業（タスク）が機能ごとに組み込まれており、結合テストの全体像を把握するには、スケジュールを全部見てその中から結合テストが同じ日程になっている機能をリストアップするというような変換作業が必要です。このようなスケジュールになっているということは、少々極端な言い方になりますが、結合テストの重要性がわかっておらず、完成度の確認も不十分なソフト開発になっているといえます。
結合テストの重要性がわかっている適切なスケジュールというのは、図36 のように結合テストは大項目として別出しになっており、小項目で段階的にどのような範囲の結合テストが実施されるのかがわかるようになっています。そして、どのような範囲で結合が行われるのかは別資料（「結合テスト範囲プラン」）で説明されています。
図36. 結合テストの実施スケジュール例
結合範囲（図36 では「結合テスト範囲プラン」）は、動作確認をしたい外部仕様の優先順位と、モジュールの新規性や処理の複雑性などのソフト内部仕様の優先順位の両方から決める必要があります。したがって、結合テストのスケジュールはソフト屋さんだけで決めるものではなく、製品全体の開発進捗をどのような段取りで確認するのか、プロジェクトリーダーやハード屋さん含めて検討す...