システム開発でよく使われる開発手法としてウォーターフォールモデルがあります。
細かい差はありますが、よくある流れは要件定義→基本設計→詳細設計→製造…と進みます。
ウォーターフォールモデルにおいて、品質面で重要となるのが要件定義・基本設計にあたる「上流工程」と呼ばれる部分です。
そして、「品質の作り込み」は上流工程で行うべき、といわれています。
なぜ上流工程が重要なのか？
上流工程で潰せなかった潜在不具合が中流工程・下流工程で検出されると、対応に手間がものすごくかかるためです。
以下は要件定義で不具合を1件潰した場合に、手間を仮に1とした場合の例です。
同じ不具合を要件定義工程で潰せずに後工程で検出された場合、システムテスト時点で数十倍、リリース後では100倍以上とも言われています。
なぜそこまで手間がかかるのか？
要件定義工程の場合、要件定義書などの該当ドキュメントの修正と確認のみで済みます。
システムテストで不具合が流出した場合、要件に関わる不具合であれば、ドキュメント修正など発生する作業が要件定義の時よりも多岐にわたります。
- ドキュメント（要件定義書、基本設計書、詳細設計書、各テスト仕様書）修正
- ソースコード修正
- 各ドキュメント、ソースコードのレビュー
- 単体テスト、結合テスト、システムテストの再実施
運用後の場合、不具合の指摘が市場からのものであれば発生する作業が更に増えます。
- コールセンターの窓口業務
- システム運用担当が一次受けして開発担当者に繋ぐ対応
- ドキュメント（要件定義書、基本設計書、詳細設計書、各テスト仕様書）修正
- ソースコード修正
- 各ドキュメント、ソースコードのレビュー
- 単体テスト、結合テスト、システムテストの再実施
- 修正後の報告書作成
- リリースに向けた承認会の開催
また、もし市場インパクトが非常に大きいシステムでの障害に繋がるような内容であった場合、関係省庁への報告というのも発生することがあります。
上記を考えると、後ろの工程になればなるほど手間が増えていきます。
対応の手間が膨らむことでスケジュールへのインパクトが大きくなり、かつ期間的な余裕も少なくなります。
上流工程だけで100％品質を確保できるか？
これはNOです。
実物が何もない要件定義工程・基本設計工程では検討しきれない部分がありますし、外部システムと繋ぐことで初めて見えるような不具合もあります。
また、中流工程以降で混入する不具合もあります。
そのため、複数のテスト工程で問題ないことを確認することに力を入れますし、より確実な品質担保をするために第三者視点でのテスト部隊も入ります。
最終的には上流から下流まで、全体で品質を担保できるように進めていきますが、それでも「品質を上流工程で作り込む」という取り組みは大前提になります。
