アプリケーションを開発する際に、通常、複数の工程に分けてプロジェクトを推進・管理します。
なぜ工程を分けるのかというと、期間が長かったり、主体者が変わったりすることで、区切りをつけるためです。
自分のためだけのアプリケーションを一人で開発をする場合には、工程など分けません。設計書も作らず、いきなりアプリケーションを作りはじめ、作った部分を動かしながら動作確認をして完成させていきます。
これが仕事を請け負い、設計書等の成果物を納期までに納める必要がある場合、一連の作業を複数の工程に分けて、発注者に進捗報告をしていく必要があります。発注者も管理責任があるので、きちんと開発が進んでいるか把握しなければならないからです。
さらに開発を複数の会社で分担する場合、責任の所在をはっきりさせるためにも工程を分けます。上流工程は元請けベンダー、下流工程は下請けベンダーといった分け方をする場合、元請けベンダーの担当範囲を要件定義、基本設計、総合テスト、下請けベンダーの担当範囲を詳細設計、製造、単体テスト、結合テスト、といった形で分けます。それによって、テストでバグが見つかった場合、どちらの工程で埋め込まれたバグなのかを評価し、元請けベンダーと下請けベンダーのどちらが修正するかを決めていきます。
開発の工程には、ある程度はIT業界共通の工程の境界がありますが、その境界はグレーゾーンが多いのが実情で、プロジェクトを進めるとしばしばこの境界で意見が対立することがあります。
元請けベンダーと下請けベンダーであれば、「このバグは基本設計の記載が曖昧だからいけない」、「いやいやこれは詳細設計で決めていくレベルの内容だ」といった意見のぶつかり合い（責任の押し付け合い）、発注者とベンダーであれば、「これは要件を出さないユーザー側の責任」、「こんなものは基本設計でベンダーが対応箇所として洗い出すべきもの」といった意見のぶつかり合い（責任の押し付け合い）が、しばしばあります。
また工程の分け方自体にも複数あるから厄介です。設計工程を基本設計、詳細設計という呼び方で分けたり、外部設計、内部設計という呼び方で分けたり、ベンダー独自の呼び方があったり。単体テストという同じ呼び方でも、範囲が異なっていたり。
その辺りの実情も踏まえながら、企画含めた開発の一連の作業を、以下の各工程ごとに説明していきたいと思います。
①戦略・企画
②要求定義
③要件定義
④基本設計
⑤詳細設計
⑥製造
⑦単体テスト
⑧結合テスト
⑨総合テスト
⑩受入テスト
