アジャイル＆ウォーターフォール⑤ ～「手法として共に良い」の間違い～

はじめに

ソフトウェア開発の現場では「状況に応じてウォーターフォールとアジャイルのプラクティスを使い分ける」という考え方が広く見られます。しかし、この考え方はアジャイルのプラクティスが持つ本質的な意図を見落としています。本稿では、ウォーターフォール開発で発生する様々な問題のうち代表的な例を取り上げ、それらに対するアジャイルプラクティスの解決策を検証することで、両者の関係性について考察します。

ウォーターフォールプラクティスの課題

ウォーターフォール開発では、多くの実務的な課題が指摘されています。その中から本稿では特に顕著な例として、以下の問題を取り上げます。
まず、計画段階での想定と実態の乖離により、開発中にスコープの変更が必要となることが一般的です。しかし、スコープ変更の都度、変更管理帳票の作成や承認プロセス、場合によっては契約の再締結が必要となるのがウォーターフォールの特徴です。この煩雑な手続きを避けるため、現場担当者が非公式に作業を追加してしまう事態が頻発し、これがスコープクリープの主要な原因となっています。
また、同じく重要な課題として、上流工程と下流工程の分離により、作業者から作業依頼者への情報共有が限定的になりがちな点が挙げられます。作業者は問題が発生しても、契約上の責任を問われることを恐れて情報を隠蔽する傾向があり、結果として作業依頼者が開発の実態を正確に把握できない事態が発生します。これにより、品質上の問題が後工程まで発見されず、手戻りのコストが増大するケースも少なくありません。
さらに、要件定義から設計、実装、テストまでが順次進行するため、ユーザーが実際のシステムに触れられるのは開発の終盤になってからです。その時点で重大な使い勝手の問題が発見されても、予算や納期の制約から十分な改善が困難となり、結果的に現場での運用回避や追加開発の必要性につながることがあります。

アジャイルプラクティスによる解決

アジャイルのプラクティスは、ウォーターフォール開発における多岐にわたる課題に対する解決策として設計されています。ここでは先に挙げた2つの代表的な問題に対する解決アプローチを見ていきましょう。
例えば、開発チームが新たな要件や課題を発見した場合、プロダクトバックログに記録するだけでよく、その優先順位付けは定期的なリファインメントの中で権限者により実施されます。この仕組みにより、スコープの変更を正式なプロセスとして管理でき、スコープクリープを防ぐことができます。
また、デイリースクラムや定期的なスプリントレビューを通じて、作業依頼者と作業者が頻繁にコミュニケーションを取る機会が設けられています。問題の早期発見と共有が推奨される文化により、作業者が情報を隠すインセンティブが低減され、作業依頼者は開発の実態をリアルタイムに把握できるようになります。
さらに、短いイテレーションサイクルで動作するソフトウェアを提供し、ユーザーからのフィードバックを得ることで、開発の早い段階から使い勝手の問題を発見し改善することができます。これにより、完成間際になって重大な問題が発見されるリスクを大幅に低減できます。

両プラクティスの本質的な違い

本稿で取り上げたスコープクリープの防止や作業者と作業依頼者間のコミュニケーション促進は、アジャイルが解決を図った数多くの課題のほんの一例です。プロダクトバックログやリファインメントをはじめとする様々な仕組みは、ウォーターフォール開発で発生する多様な問題への対応として設計されています。したがって、ウォーターフォールとアジャイルを、単なる「異なるアプローチ」として扱うことは、アジャイルプラクティスが持つ問題解決としての本質を見落としていることになります。

まとめ

本稿では、アジャイルのプラクティスがウォーターフォール開発で生じる様々な実務上の問題への解決策として設計された点について、スコープクリープと作業者・作業依頼者間のコミュニケーション不全という2つの代表的な例を通じて検証しました。これらは数ある改善点のほんの一部ですが、アジャイルのプラクティスがウォーターフォール開発の課題に対する具体的な解決策として機能することを示す好例と言えます。
したがって、これらを「状況に応じて使い分ける別々の手法」として評価することは、アジャイルプラクティスの本質的な意図を正しく理解していないものだと言えます。ウォーターフォールの様々な具体的な問題を解決するために生まれたアジャイルの価値を、単なる選択肢の一つとして扱うような評価は、本質を見誤った見方であり、アジャルのプラクティスを考案した人々にとって失礼にも当たります。