アジャイル vs ウォーターフォール：真のソフトウェア品質向上戦略とは？海外文献と最新動向徹底解説

2025 5/21

2025年5月21日 2025年5月21日

序論

ソフトウェア開発手法選択の重要性と本記事の目的

ソフトウェア開発プロジェクトの成功は、採用される開発手法の選択に大きく左右されます。特に、最終的な成果物である「ソフトウェア品質」という観点から、どの手法がより優れているのか、あるいは特定の状況において最適なのかという問題は、長年にわたり業界内外で活発に議論されてきました。この選択は、プロジェクトのタイムライン、コスト効率、リスク管理、そして何よりも顧客満足度と直結するため、極めて重要な意思決定となります ¹。

本記事では、ソフトウェア開発における二大潮流であるアジャイル開発手法とウォーターフォール開発手法を多角的に比較検討します。その際、主に国外の学術文献、業界レポート、専門家の知見を広範に参照し、それぞれの基本的な技術内容から、ソフトウェア品質への具体的な影響、さらには現代のソフトウェア開発を取り巻く最新の動向や将来の展望に至るまでを、分かりやすい日本語で徹底的に解説することを目的とします。

序論の段階で触れておきたいのは、アジャイルとウォーターフォールのどちらか一方が絶対的に優れているという単純な二元論は、現代の複雑なソフトウェア開発環境においては必ずしも適切ではないという点です。むしろ、プロジェクトの特性、チームの成熟度、組織文化、市場の要求といった多様な文脈に応じて、最適なアプローチは変化します。近年では、両者の利点を組み合わせたハイブリッドモデルや、DevOpsのような新しいプラクティスとの融合も進んでおり、ソフトウェア品質向上のための戦略はより洗練され、多岐にわたるようになっています。本記事を通じて、読者がこれらの複雑な要素を理解し、自身の状況に最適な品質向上戦略を見出すための一助となることを目指します。

SEOキーワード: ソフトウェア開発手法, アジャイル, ウォーターフォール, ソフトウェア品質, プロジェクト成功

アジャイルとウォーターフォールの概要と論争点

ウォーターフォール開発は、その名の通り水が上から下に流れるように、各開発フェーズを直線的かつ逐次的に進める伝統的なアプローチです。この手法は、事前の徹底した計画と包括的な文書化を重視し、各フェーズの完了をもって次のフェーズへと移行します ²。安定性と予測可能性を強みとする一方で、開発途中の仕様変更への対応が難しいという課題も指摘されてきました。

対照的に、アジャイル開発は、変化への適応性を核とする反復的かつ漸進的なアプローチです。プロジェクトを短期間のサイクル（イテレーションやスプリントと呼ばれる）に分割し、各サイクルで計画、設計、実装、テストを行い、動作するソフトウェアを少しずつ構築していきます ³。顧客との継続的な協調やチーム内のコミュニケーションを重視し、柔軟性を確保することで、不確実性の高いプロジェクトや要求が変化しやすい状況に対応することを目指します。

これら二つの手法は、ソフトウェア品質に対する考え方、変更管理のプロセス、顧客やステークホルダーとの関与の度合い、リスクへの対処法など、開発プロセスの多くの側面で根本的に異なる思想に基づいています ¹。そのため、どちらの手法が特定のプロジェクトや組織にとってより高いソフトウェア品質をもたらすかという点は、長年にわたる論争の中心であり続けています。本記事では、これらの論点を深掘りし、客観的なデータと専門家の分析に基づいて考察を進めていきます。

第1部：ソフトウェア開発手法の基礎知識

1.1. ウォーターフォール開発モデル詳解

定義、基本原則

ウォーターフォール開発モデルは、ソフトウェア開発プロジェクトを管理するための古典的かつ基本的なアプローチの一つです。その名称は、開発プロセスが滝の水が上から下へと一方向に流れるように、明確に区切られたフェーズを順番に、かつ後戻りすることなく進めていく様子に由来しています ²。各フェーズは、前のフェーズが完全に完了した後に開始されるのが原則であり、この直線的・逐次的（シーケンシャル）な進行が最大の特徴です ²。

このモデルの根底にあるのは、「二度測り、一度切る (measure twice, cut once)」という格言に象徴される思想です ²。つまり、プロジェクトの初期段階で要件を徹底的に洗い出し、詳細な計画を策定し、それらを包括的な文書として記録することに非常に大きな重点を置きます。この厳格な計画と文書化を通じて、プロジェクト全体のスコープ、コスト、スケジュールを早期に確定し、後続のフェーズでの誤解や手戻りを最小限に抑え、予測可能な形でプロジェクトを遂行することを目指します。このアプローチは、特に要件が安定しており、変更の可能性が低いプロジェクトにおいて、その構造的な明確さから有効性を発揮すると考えられてきました ⁹。

開発プロセスフロー (各フェーズの説明)

ウォーターフォールモデルの典型的な開発プロセスは、以下の連続したフェーズで構成されます。

要求定義 (Requirements):
この最初のフェーズでは、開発するソフトウェアに対する顧客やステークホルダーのニーズと期待を収集し、分析し、明確に定義します。機能要件（ソフトウェアが何をすべきか）と非機能要件（性能、セキュリティ、ユーザビリティなど）が詳細に洗い出され、プロジェクトのスコープ、目標、制約条件などが特定されます。このフェーズの成果物は、通常、「要求仕様書」として文書化され、後続の全フェーズの基礎となります。コスト、前提条件、リスク、依存関係、成功の測定基準、タイムラインなどもこの段階で検討され、文書に含められることが一般的です 2。
設計 (Design):
要求定義フェーズで作成された要求仕様書に基づき、ソフトウェアのアーキテクチャ（全体構造）、モジュール構成、データベース構造、ユーザーインターフェース（UI）、アルゴリズムなど、ソフトウェアの具体的な設計を行います。設計は通常、システム全体の大まかな構造を示す「基本設計（または外部設計）」と、各モジュールの詳細な内部構造や処理ロジックを定義する「詳細設計（または内部設計）」の二段階に分けて行われます 2。このフェーズの成果物は「設計仕様書」として文書化され、次の実装フェーズの入力となります。
実装 (Implementation):
設計フェーズで作成された設計仕様書に従って、プログラマーが実際のコーディング作業を行います。各モジュールが個別に開発され、単体テスト（ユニットテスト）によって個々の機能が正しく動作するかどうかが検証されることもあります。事前の詳細な調査と設計が完了しているため、このフェーズは比較的スムーズに進行することが期待されますが、設計の曖昧さや不備が発見された場合には、設計フェーズへの手戻りが発生することもあります 2。
テスト (Verification/Testing):
実装されたソフトウェア全体を結合し、システムとして正しく機能するか、また要求仕様書で定義された全ての要件を満たしているかを検証するフェーズです。テストチームは、設計文書やユースケースシナリオを基にテスト計画を策定し、様々なテストケースを実行します。これには、機能テスト、性能テスト、負荷テスト、セキュリティテストなどが含まれます。このフェーズで発見されたバグや不具合は修正され、再テストが行われます。最終的に、ソフトウェアがリリース可能な品質であることを保証することが目的です 2。
導入・保守 (Deployment and Maintenance):
テストフェーズで品質が確認されたソフトウェアは、顧客の運用環境に展開（デプロイ）され、実際の利用が開始されます。導入後もソフトウェアのライフサイクルは続き、保守フェーズへと移行します。保守フェーズでは、運用中に新たに発見された欠陥の修正、環境変化への対応（OSのバージョンアップなど）、ユーザーからの改善要望や新たな機能追加要求に応じたエンハンスメント（機能強化）などが行われます 2。

これらのフェーズは厳密に区切られ、通常、一つのフェーズが完了するまで次のフェーズに進むことはありません。

メリット・デメリット

ウォーターフォール開発モデルには、その構造的な特徴から生じる明確なメリットとデメリットが存在します。

メリット:

明確な構造と進捗管理の容易さ: 各フェーズの開始と終了が明確であり、タスクと成果物が事前に定義されるため、プロジェクトの進捗状況を把握しやすく、管理が比較的容易です ²。マイルストーンが明確であるため、計画に対する実績の追跡がしやすいです。
初期段階での全体像の把握: プロジェクトの初期に全体のスコープ、目標、成果物が定義されるため、関係者全員がプロジェクトの全体像を共有しやすいです ⁸。
文書化の重視による情報共有の円滑化: 各フェーズで詳細なドキュメント（要求仕様書、設計書など）が作成されるため、チームメンバー間の情報共有が促進され、プロジェクトの途中で新しいメンバーが参加した場合でも、ドキュメントを通じて迅速に状況を理解できます ²。
コストとスケジュールの見積もり精度: 要件が初期に固定されることを前提としているため、プロジェクト全体のコストや完了までのスケジュールを比較的正確に見積もることが可能です ²。
品質管理のしやすさ（理論上）: 各フェーズで厳格なレビューと承認プロセスを経ることで、品質を段階的に確保していくことが期待されます。

デメリット:

柔軟性の欠如と変更対応の困難さ: 一度フェーズが完了すると、前のフェーズに戻って変更を加えることが非常に困難であり、コストも時間もかかります。特に開発後半での仕様変更や要求追加への対応は極めて難しいです ²。
顧客・エンドユーザーのフィードバック反映の遅れ: 顧客やエンドユーザーの関与は主に要求定義フェーズに限られ、開発途中で実際に動作するソフトウェアを見てフィードバックする機会が少ないため、最終成果物が真のニーズと乖離するリスクがあります ²。
テストフェーズの遅延によるリスク: テストが開発プロセスの最終段階に集中するため、そこで重大な欠陥や設計上の問題が発見された場合、手戻りが非常に大きくなり、プロジェクトの遅延やコストの大幅な増加、最悪の場合はプロジェクト失敗に繋がる可能性があります ⁸。
「動くソフトウェア」の提供遅延: プロジェクトの最終段階まで、実際に動作するソフトウェアが提供されないため、顧客は長期間、成果物を確認できません。
変化の激しい環境への不適合: 市場の動向が急速に変化したり、技術革新が早かったり、あるいはプロジェクト開始時点で要件が不明確または変動しやすい場合には、このモデルの硬直性が大きな足かせとなります ⁵。

ウォーターフォールモデルの品質に対する考え方は、初期計画の正確性に大きく依存します。計画段階で全ての要件が正確に把握され、変更がないという理想的な状況下では、各フェーズでの厳格な検証を通じて高品質な成果物を生み出す可能性があります。しかし、現実のソフトウェア開発、特に新規性が高いプロジェクトや市場の変化が速い分野では、この前提が崩れやすく、その結果として品質問題が発生するリスクを内包しています。初期の要求や設計に誤りがあった場合、その影響は後続の全フェーズに波及し、最終段階で発覚した際には修正が極めて困難になるか、あるいは時間的・コスト的制約から不完全な形での妥協を強いられることになりかねません。この点が、ウォーターフォールモデルにおける品質確保の大きな課題と言えます。

適したプロジェクトタイプ

ウォーターフォール開発モデルは、その特性から、以下のような特徴を持つプロジェクトに適しているとされています。

要件が明確で安定しているプロジェクト: プロジェクト開始時点で、開発すべきソフトウェアの機能や仕様が具体的かつ詳細に定義されており、開発途中で大きな変更が発生する可能性が極めて低い場合 ²。例えば、既存システムのマイナーバージョンアップや、法的要件に基づく変更が主である場合などが該当します。
大規模で複雑、かつ安全性が厳格に求められるプロジェクト: 建設業（例：高層ビル建設 ¹¹）、航空宇宙産業（例：航空機開発 ¹²）、医療機器開発など、フェーズごとの厳密な検証と承認が不可欠であり、逐次的な進行が自然な分野。これらの分野では、初期計画の精度とプロセスの厳格性が、最終的な品質と安全性を担保する上で重要となります ⁶。
過去の類似プロジェクト経験が豊富な場合: 開発チームが過去に同様のプロジェクトを多数手がけており、作業内容、潜在的なリスク、必要な工数などについて高い予測精度を持っている場合。
厳格な契約条件や規制遵守が求められるプロジェクト: 成果物の仕様や納期、コストが契約で厳密に定められている場合や、特定の業界標準や法的規制を遵守する必要がある場合。ウォーターフォールモデルの文書化重視の姿勢と計画性は、これらの要求に応える上で有利に働くことがあります。

しかし、現代のビジネス環境は変化が速く、ソフトウェアに対する要求も流動的であることが多いため、ウォーターフォールモデルが最適となるケースは以前に比べて限定的になっているとも言われています ¹³。

SEOキーワード: ウォーターフォール開発, プロセスフロー, メリット, デメリット, 要求定義, 設計, 実装, テスト, プロジェクトタイプ, ソフトウェア品質.

1.2. アジャイル開発モデル詳解

定義、基本原則（アジャイルマニフェスト）、プロセスフロー

アジャイル開発モデルは、固定された計画に固執するのではなく、変化への適応を重視するソフトウェア開発アプローチの総称です。その核心は、プロジェクトを「スプリント」または「イテレーション」と呼ばれる短期間（通常1週間から4週間程度）の反復的なサイクルに分割し、各サイクルで計画、設計、実装、テストを行い、実際に動作するソフトウェアの小さな塊（インクリメント）を少しずつ、かつ継続的に構築していく点にあります ³。この反復的なプロセスを通じて、顧客やステークホルダーからのフィードバックを早期かつ頻繁に収集し、それを次のサイクルに反映させることで、不確実性に対応し、最終的により価値の高い製品を生み出すことを目指します。チーム内の密接なコラボレーション、自己組織化、そして継続的な改善が、アジャイル開発を支える重要な要素です ³。

アジャイルマニフェストの4つの価値 (The Four Values of the Agile Manifesto):

アジャイル開発の思想的背景と基本原則は、2001年に17名のソフトウェア開発者たちによって提唱された「アジャイルソフトウェア開発宣言（Agile Manifesto）」に集約されています。この宣言は、従来の重厚な開発プロセスに対するアンチテーゼとして生まれ、以下の4つの中心的な価値を掲げています。

プロセスやツールよりも個人と対話 (Individuals and interactions over processes and tools):
厳格に定められたプロセスや特定のツールに従うことよりも、開発チームのメンバー間の自律的なコミュニケーションや協調、そして個々の能力を最大限に活かすことを重視します。優れた個人が集まり、効果的に対話することで、より良い解決策が生まれるという考え方です 6。
包括的なドキュメントよりも動くソフトウェア (Working software over comprehensive documentation):
詳細で膨大な量のドキュメントを作成することに時間を費やすよりも、実際に動作し、顧客に価値を提供するソフトウェアを早期かつ頻繁に提供することに重点を置きます。ドキュメントが不要というわけではなく、価値を生むために必要十分な量に留めるべきだという思想です 6。
契約交渉よりも顧客との協調 (Customer collaboration over contract negotiation):
プロジェクト開始時に固定された契約条件に基づいて厳密に作業を進めるよりも、開発プロセス全体を通じて顧客と継続的に対話し、協調し、変化するニーズや優先順位を共に理解しながら製品を開発していくことを重視します。顧客は開発チームの一員として積極的に関与することが期待されます 6。
計画に従うことよりも変化への対応 (Responding to change over following a plan):
初期に立てた計画に固執するのではなく、開発の途中で発生する要求の変化、市場の変動、新たな技術的発見などに対して、柔軟かつ迅速に対応することを価値とします。変化は避けるべきものではなく、より良い製品を作るための機会として捉えられます 3。

これらの価値は、アジャイル開発の様々なフレームワークやプラクティスに共通する指導原理となっています。

プロセスフローの概要 (Overview of the Process Flow):

アジャイル開発の具体的なプロセスフローは採用するフレームワークによって異なりますが、一般的には以下のような反復的なサイクルで進行します 3。

要求の収集と優先順位付け: プロダクトオーナー（またはそれに類する役割）が、顧客やステークホルダーから要求を収集し、ビジネス価値や緊急度に基づいて優先順位を付けたリスト（プロダクトバックログなど）を作成・維持します。
イテレーション計画: 各イテレーションの開始時に、チームはプロダクトバックログの上位から、そのイテレーションで取り組むタスクを選択し、具体的な作業計画を立てます。
設計・開発・テスト: 選択されたタスクについて、チームは設計、コーディング、単体テスト、結合テストなどを並行して、あるいは密接に連携しながら進めます。テストは開発の初期段階から継続的に行われます。
イテレーションレビューと成果物の提示: イテレーションの終わりには、完成した「動くソフトウェア」のインクリメントを顧客やステークホルダーにデモンストレーションし、フィードバックを収集します。
ふりかえり（レトロスペクティブ）: チーム自身がそのイテレーションの進め方（プロセス、ツール、コミュニケーションなど）を振り返り、良かった点、問題点、改善点を洗い出し、次のイテレーションに活かします。
次のイテレーションへ: 上記のサイクルを繰り返し、プロダクトバックログのアイテムがなくなるか、あるいは顧客が満足する製品が完成するまで開発を続けます。

このサイクルを通じて、ソフトウェアは段階的に成長し、品質は継続的に検証され、顧客のニーズへの適合度が高められていきます ³。

主要なアジャイルフレームワーク紹介

アジャイル開発の原則と価値を実現するための具体的な手法やプラクティスを集めたものが「アジャイルフレームワーク」です。多種多様なフレームワークが存在し、それぞれに特徴や得意とする領域があります。以下に主要なものを紹介します。

スクラム (Scrum):
アジャイル開発フレームワークの中で最も広く採用されているものの一つです 16。スクラムは、複雑な問題に対応し、創造的かつ生産的に最高価値の製品を提供するためのフレームワークと定義されています。開発は「スプリント」と呼ばれる固定期間（通常2～4週間）の反復サイクルで行われます 3。
スクラムには明確な3つの役割が存在します 3:

プロダクトオーナー: 開発する製品のビジョンを持ち、要求（プロダクトバックログアイテム）を定義し、その優先順位を決定する責任者。
スクラムマスター: スクラムの原則とプラクティスが正しく理解・実践されるようチームを支援し、チームが直面する障害物を除去するファシリテーター。
開発チーム: プロダクトバックログアイテムを実際に「動くソフトウェア」のインクリメントに変換する、自己組織的で多能工的な専門家集団。また、スクラムには以下の主要なイベント（セレモニー）があります ³:
スプリントプランニング: スプリントで何を行うかを計画する。
デイリースクラム: 毎日行われる短時間の進捗確認と計画調整のミーティング。
スプリントレビュー: スプリントの成果物をステークホルダーにデモンストレーションし、フィードバックを得る。
スプリントレトロスペクティブ: スプリントのプロセスを振り返り、改善点を見つけ出す。スクラムは、透明性、検査、適応という3つの柱に基づいており、経験的プロセス制御を通じてプロジェクトを進行させます。
カンバン (Kanban):
カンバンは、日本のトヨタ生産方式から着想を得た、作業の流れ（ワークフロー）を視覚化し、進行中の作業量（WIP: Work In Progress）を制限することで、プロセス全体の効率を改善することを目指す手法です 16。
主な特徴は以下の通りです 3:

ワークフローの視覚化: 「カンバンボード」と呼ばれる物理的または電子的なボードを使用し、タスク（カードで表現）が「未着手(To Do)」「作業中(Doing)」「完了(Done)」といった各工程（列で表現）をどのように流れていくかを視覚的に示します。
WIP制限: 各工程で同時に進行できるタスクの数に上限（WIP制限）を設けます。これにより、チームの過負荷を防ぎ、ボトルネックを明確にし、作業の流れをスムーズにします。
フローの管理: タスクがボード上を円滑に流れるように、リードタイム（タスクの開始から完了までの時間）やサイクルタイム（特定の工程にかかる時間）を計測・改善します。
明示的なプロセスポリシー: 作業ルールや完了基準などを明確に定義し、チームで共有します。
フィードバックループの実装: 定期的なミーティングなどを通じて、プロセスの改善を図ります。
実験と進化を通じた改善: 科学的アプローチを用いて、継続的にプロセスを改善していきます。カンバンは、スクラムのような固定長のイテレーションや特定の役割（プロダクトオーナー、スクラムマスターなど）を必須としないため、既存のプロセスに導入しやすいという特徴があります ¹⁶。主に、継続的なフローが求められる作業（例：サポート業務、保守業務）や、作業の優先順位が頻繁に変わる環境に適しています。
エクストリームプログラミング (XP – Extreme Programming):
XPは、高品質なソフトウェアを効率的かつ継続的に開発するための、一連の具体的な技術的プラクティス（実践方法）を重視するアジャイル手法です 3。XPの価値は、コミュニケーション、シンプルさ、フィードバック、勇気、尊重です 16。
XPの主要なプラクティスには以下のようなものがあります 4:

ペアプログラミング: 2人の開発者が1台のコンピュータを共有し、共同で設計、コーディング、テストを行います。これにより、コード品質の向上、知識共有、リアルタイムのコードレビューが促進されます。
テスト駆動開発 (TDD): プロダクションコードを書く前に、そのコードが満たすべき振る舞いを定義する自動テストコードを先に書きます。そして、そのテストが通るようにプロダクションコードを実装し、リファクタリング（コードの改善）を行います。
継続的インテグレーション (CI): 開発者が行ったコード変更を、頻繁に（理想的には1日に何度も）共有リポジトリに統合し、自動ビルドと自動テストを実行します。これにより、統合時の問題を早期に発見し、修正できます。
リファクタリング: ソフトウェアの外部的な振る舞いを変えずに、内部構造を改善し続けることで、コードの可読性、保守性、拡張性を高めます。
顧客オンサイト（Whole Team）: 顧客（またはその代理人）が開発チームの一員として常にプロジェクトに参加し、要求の明確化や優先順位付け、テストの受け入れなどを迅速に行います。
短期リリース: 動作するソフトウェアを非常に短い間隔（数週間から数ヶ月）で頻繁にリリースし、顧客からのフィードバックを早期に得ます。
コーディング標準: チーム全体で一貫したコーディング規約を定め、遵守します。
集団的コード所有: チームの誰もがシステムのどの部分のコードでも変更できる権利と責任を持ちます。 XPは、特に技術的な卓越性と変化への迅速な対応が求められるプロジェクトに適しており、高品質なコードを継続的に提供することを目指します。
その他のフレームワーク:
上記以外にも、特定の目的や状況に合わせて様々なアジャイルフレームワークが提案され、活用されています。

リーン開発 (Lean Development): 製造業におけるリーン生産方式の7つの原則（ムダの排除、品質の組み込み、知識の創造、決定の遅延、迅速な提供、人の尊重、全体最適化）をソフトウェア開発に適用し、価値を最大化し、効率を追求します ⁴。
クリスタル (Crystal) ファミリー: プロジェクトの規模、重要度、チームの特性に応じて、手法の「重さ」を調整する一連の軽量なアジャイル手法群です。人間中心のアプローチと効果的なコミュニケーションを重視します ⁴。
動的システム開発手法 (DSDM – Dynamic Systems Development Method): ビジネスニーズへの適合、固定された納期内での機能提供、ユーザーの積極的な関与を基本原則とする、比較的構造化されたアジャイルアプローチです。MoSCoW法（Must have, Should have, Could have, Won’t have）による優先順位付けが特徴的です ³。
フィーチャー駆動開発 (FDD – Feature-Driven Development): 顧客にとって価値のある小さな機能（フィーチャー）単位で、短期間（通常2週間以内）の反復開発を行います。ドメインオブジェクトモデリングとフィーチャーリストに基づく計画・進捗管理を特徴とします ³。
アジャイル統一プロセス (AUP – Agile Unified Process): IBM Rational社が提唱した反復型開発プロセスであるRational Unified Process (RUP) を、アジャイルの原則に基づいて簡略化したものです ⁴。
SAFe (Scaled Agile Framework): 大規模な組織やエンタープライズレベルで、複数のアジャイルチームを連携させ、アジャイルプラクティスを組織全体に展開（スケーリング）するための包括的なフレームワークです。ポートフォリオ管理、プログラム管理、チームレベルのアジャイルを統合します ⁴。

これらのフレームワークは、アジャイルの基本的な価値と原則を共有しつつも、それぞれ異なるプラクティスや構造、重点領域を持っています。プロジェクトの特性やチームの状況に応じて、最適なフレームワークを選択したり、複数のフレームワークの要素を組み合わせたりすることが一般的です。

メリット・デメリット

アジャイル開発モデルは、その柔軟性と適応性から多くの利点をもたらしますが、同時にいくつかの課題や注意点も存在します。

メリット:

変化への高い柔軟性と適応性: アジャイル開発の最大の強みは、プロジェクト途中の要求変更や市場の変化に迅速かつ柔軟に対応できる点です。短いイテレーションサイクルと継続的なフィードバックにより、計画を適宜見直し、軌道修正することが可能です ³。
迅速な提供と早期の価値実現: 各イテレーションの終わりに「動くソフトウェア」のインクリメントをリリースするため、顧客は早期に製品の価値を享受でき、開発チームは市場からのフィードバックを迅速に得ることができます。これにより、Time to Marketの短縮が期待できます ³。
継続的なフィードバックによる品質向上: 顧客やステークホルダーが開発プロセスに深く関与し、イテレーションごとに成果物を確認してフィードバックを提供するため、要求の誤解や期待とのズレを早期に発見・修正できます。これにより、手戻りが減少し、最終的な製品品質が向上します ³。
顧客満足度の向上: 顧客との密接なコラボレーションを通じて、真のニーズや優先順位を正確に把握し、それに応じた製品を開発できるため、顧客満足度が高まる傾向にあります ³。
リスクの早期発見と軽減: プロジェクト初期から小さな単位で開発とテストを繰り返すため、技術的な課題や市場の反応に関するリスクを早期に特定し、対処することが可能です。これにより、プロジェクト全体の失敗リスクを低減できます ⁶。
チームのモチベーションと生産性の向上: 自己組織的なチーム運営、透明性の高いコミュニケーション、達成感のある短いサイクルなどが、チームメンバーのモチベーションを高め、生産性の向上に繋がることが期待されます ³。

デメリット:

スコープクリープのリスク: 変化への対応を重視するあまり、プロジェクトの途中で次々と新しい要求が追加され、当初の目的や範囲から逸脱してしまう「スコープクリープ」が発生しやすい傾向があります。これを防ぐためには、プロダクトオーナーによる厳格な優先順位付けとスコープ管理が不可欠です ⁵。
初期段階での正確な見積もりの困難さ: プロジェクト開始時点では全体の要件が確定していないことが多いため、総期間や総コストを正確に見積もることが難しい場合があります。これは、予算やリソース計画を重視する組織にとっては課題となり得ます ³。
詳細な文書の不足の可能性: 「動くソフトウェア」を優先する文化から、ウォーターフォールモデルほど詳細なドキュメントが作成されない傾向があります。これにより、後々の保守作業やチームメンバーの入れ替わり時の知識移転で問題が生じる可能性があります。ただし、アジャイルはドキュメントを全く作らないわけではなく、「必要十分な」ドキュメントを作成することが推奨されます ³。
大規模プロジェクトへの適用には工夫が必要: チームの規模が大きくなったり、複数のチームが関与したりする大規模プロジェクトでは、チーム間の調整、依存関係の管理、全体整合性の確保などが複雑になり、アジャイルの原則をそのまま適用するのが難しくなることがあります。SAFeのようなスケーリングフレームワークの導入が検討されることもあります ⁴。
ステークホルダーの積極的かつ継続的な関与が不可欠: アジャイル開発の成功は、プロダクトオーナーを含む顧客やステークホルダーが、開発プロセス全体を通じて積極的にフィードバックを提供し、意思決定に関与することが前提となります。この関与が得られない場合、プロジェクトの方向性が定まらず、進行が遅延する可能性があります ³。
経験豊富なチームメンバーや特定スキルの必要性: 自己組織的なチーム運営や、スクラムマスター、プロダクトオーナーといった特定の役割を効果的にこなすためには、経験豊富でスキルの高い人材が必要となる場合があります ⁴。

アジャイル開発がもたらす品質面での利点は、その反復的な性質と迅速なフィードバックループに起因します。短いサイクルで「動くソフトウェア」を構築し、それをテストし、ステークホルダーからのフィードバックを得て適応するというプロセスは、一種の「学習サイクル」を形成します。この学習サイクルを通じて、要求の誤解は早期に修正され、市場のニーズとのズレは最小限に抑えられ、技術的な問題点は初期段階で発見・対処されます。XPにおけるテスト駆動開発（TDD）のようなプラクティスは、品質を開発の初期段階から組み込むことを目指しており、これもアジャイルの品質向上に寄与する要素です。

しかし、この学習サイクルが効果的に機能するためには、アジャイルマニフェストで謳われている「個人と対話」や「顧客との協調」といった価値観が、チームや組織に根付いていることが不可欠です。ステークホルダーの関与が薄かったり、チーム内のコミュニケーションが不足していたりすると、フィードバックの質と量が低下し、学習サイクルはうまく回りません。その結果、アジャイルが本来持つ品質向上のポテンシャルを十分に発揮できなくなる可能性があります。したがって、アジャイル開発における品質は、手法そのものだけでなく、それを実践する人々のスキル、マインドセット、そして組織文化に大きく左右されると言えるでしょう。

適したプロジェクトタイプ

アジャイル開発モデルは、その柔軟性と適応性から、特に以下のような特徴を持つプロジェクトに適していると考えられています。

要件が不確実または変動しやすいプロジェクト: プロジェクト開始時点で全ての要件が明確に定まっていない、あるいは開発の途中で市場のニーズやビジネス環境の変化に応じて要件が変更される可能性が高いプロジェクト。アジャイルは、このような不確実性を受け入れ、変化に柔軟に対応することを前提としています ⁵。
迅速な市場投入（Time to Market）が求められるプロジェクト: 新しい製品やサービスをいち早く市場に投入し、競合他社に先んじたい場合や、早期にユーザーからのフィードバックを得て製品を改善していきたい場合。アジャイルの短いイテレーションとインクリメンタルなリリースは、これを可能にします ⁵。
革新的な製品・サービスの開発やスタートアップ企業: 未知の領域に挑戦するプロジェクトや、試行錯誤を繰り返しながら最適な解決策を見つけ出していく必要がある場合。アジャイルの実験的なアプローチと学習サイクルが有効に機能します ⁵。
顧客との密接な連携が可能なプロジェクト: 顧客やエンドユーザーが開発プロセスに積極的に参加し、継続的にフィードバックを提供できる環境がある場合。これにより、顧客満足度の高い製品を開発できる可能性が高まります。
複雑で解決策が自明でない問題に取り組むプロジェクト: 既存の解決策がない、あるいは複数の要素が複雑に絡み合っている問題に対して、反復的なアプローチで少しずつ理解を深めながら解決策を構築していく場合に適しています。

ソフトウェア開発全般、特に現代のウェブサービスやモバイルアプリケーション開発など、変化の速い分野ではアジャイルが主流となりつつあります ⁶。広告・マーケティング分野でも、キャンペーンの成果を見ながら迅速に戦略を調整するためにアジャイル的なアプローチが採用されることがあります ⁶。

SEOキーワード: アジャイル開発, アジャイルマニフェスト, スクラム, カンバン, XP, リーン開発, メリット, デメリット, プロジェクトタイプ, ソフトウェア品質.

第2部：ソフトウェア品質の多角的視点

2.1. ソフトウェア品質とは何か？ (ISO/IEC 25010に基づく定義)

ソフトウェアの「品質」という言葉は日常的に使われますが、その意味するところは多岐にわたります。単に「バグが少ないこと」や「仕様書通りに動作すること」だけが品質の全てではありません。より包括的かつ客観的にソフトウェア品質を捉えるために、国際標準化機構（ISO）と国際電気標準会議（IEC）は、ISO/IEC 25010という国際規格を策定しています。この規格は、ソフトウェア製品の品質を評価するためのモデルを提供し、開発者、利用者、評価者が共通の理解のもとに品質について議論し、測定するための基盤となります ²⁴。

ISO/IEC 25010では、ソフトウェア製品の品質を以下の8つの主要な「品質特性（Quality Characteristics）」によって定義し、それぞれがさらに具体的な「副特性（Sub-characteristics）」に細分化されています。これらの特性を理解することは、アジャイル開発とウォーターフォール開発がそれぞれソフトウェア品質のどの側面に、どのように影響を与えるのかを深く考察する上で不可欠です。

機能適合性 (Functional Suitability):
ソフトウェアが、明示されたニーズおよび暗黙のうちに期待されるニーズを満たすために、特定の条件下で使用された場合に、どの程度適切な機能を提供するかを示す特性です。

機能網羅性 (Functional completeness): 指定されたタスクとユーザーの目標を達成するために必要な機能が、すべて提供されている度合い ²⁴。
機能正確性 (Functional correctness): 提供される機能が、正確な結果または合意された効果をもたらす度合い ²⁴。
機能適切性 (Functional appropriateness): 提供される機能が、ユーザーの特定のタスクおよび目標の達成をどの程度促進し、支援するかという度合い ²⁴。

性能効率性 (Performance Efficiency):
特定の条件下で使用されるリソース（時間、計算資源、メモリなど）の量に関連して、どの程度の性能（応答速度、処理能力など）が達成されるかを示す特性です。

時間効率性 (Time behavior): ソフトウェアがタスクを実行する際の応答時間、処理時間、スループット率などが、規定された要件を満たしている度合い ²⁴。
資源効率性 (Resource utilization): ソフトウェアが機能を実行する際に使用するCPU、メモリ、ディスク容量、ネットワーク帯域などのリソースの種類と量が、規定された要件に対して妥当である度合い ²⁴。
容量適合性 (Capacity): 同時ユーザー数、データ量、トランザクション処理量などの最大限界値が、規定された要件を満たしている度合い ²⁴。

互換性 (Compatibility):
あるソフトウェア製品が、同じハードウェア環境またはソフトウェア環境を共有しながら、他の製品、システム、またはコンポーネントと情報を交換したり、共存したりできる度合いを示す特性です。

共存性 (Co-existence): 他の独立したソフトウェア製品と、共通の環境およびリソース（メモリ、CPUなど）を共有しながら、自身の機能に悪影響を与えることなく、また他の製品にも悪影響を与えることなく、要求される機能を効率的に実行できる度合い ²⁴。
相互運用性 (Interoperability): 二つ以上のシステム、製品またはコンポーネントが、明確に定義されたインターフェースを通じて情報を交換し、その交換された情報を正しく解釈して使用できる度合い ²⁴。

使用性 (Usability):
特定の利用状況において、特定の利用者が、有効性（目標達成度）、効率性（目標達成に要する資源）、満足性（利用時の快適さや肯定的な態度）をもって、特定の目標を達成できる度合いを示す特性です。

適切度認識性 (Appropriateness recognizability): ユーザーが、そのソフトウェア製品またはシステムが自身のニーズや目的に適しているかどうかを容易に認識できる度合い ²⁴。
習得性 (Learnability): ユーザーが、そのソフトウェア製品またはシステムの使い方を容易に学習し、効率的に利用開始できる度合い ²⁴。
操作性 (Operability): ユーザーが、そのソフトウェア製品またはシステムを容易に操作し、制御できる度合い。明確な指示、直感的なナビゲーションなどが含まれます ²⁴。
ユーザーエラー防止性 (User error protection): ソフトウェア製品またはシステムが、ユーザーが誤った操作をすることを防いだり、誤操作から回復したりするのを助ける度合い ²⁴。
ユーザーインターフェース快感度 (User interface aesthetics): ユーザーインターフェースのデザイン（レイアウト、配色、フォントなど）が、ユーザーにとって魅力的で、心地よい利用体験を提供する度合い ²⁴。
アクセシビリティ (Accessibility): 年齢、経験、知識、言語、身体的・知的な能力の違いに関わらず、できるだけ多くの人々がソフトウェア製品またはシステムを利用できる度合い。障害を持つユーザーへの配慮も含まれます ²⁴。

信頼性 (Reliability):
システム、製品またはコンポーネントが、特定の条件下で特定の期間、指定された機能を障害なく実行できる度合いを示す特性です。

成熟性 (Maturity): 通常の運用条件下で、ソフトウェア製品またはシステムが、障害発生頻度の低さという点で信頼性のニーズを満たす度合い。安定して動作し続ける能力を指します ²⁴。
可用性 (Availability): ユーザーが必要とするときに、ソフトウェア製品またはシステムが操作可能であり、アクセス可能である度合い。システムがダウンしている時間が短いことを意味します ²⁴。
障害許容性 (Fault tolerance): ハードウェアの故障やソフトウェアの欠陥、予期せぬ入力などが発生した場合でも、ソフトウェア製品またはシステムが、規定された機能を継続して実行したり、安全な状態に移行したりする度合い ²⁴。
回復性 (Recoverability): 障害やシステム停止が発生した場合に、影響を受けたデータを回復し、システムを正常な状態に復旧させることができる度合い。復旧にかかる時間やデータの損失量が評価指標となります ²⁴。

セキュリティ (Security):
ソフトウェア製品またはシステムが、情報やデータを保護し、人や他の製品・システムが持つべきアクセス権限に応じて、それらの情報やデータへのアクセスを保証する度合いを示す特性です。

機密性 (Confidentiality): 情報が、認可されていない個人、エンティティ、またはプロセスに対して開示されないように保護されている度合い ²⁴。
完全性 (Integrity): データやプログラムが、認可されていないアクセスや改ざんから保護されている度合い。情報の正確性と完全性を維持する能力を指します ²⁴。
否認防止性 (Non-repudiation): ある活動やイベントが発生したという事実、またはその活動を行ったエンティティを後から否認できないように証明できる度合い ²⁴。
責任追跡性 (Accountability): あるエンティティの活動が、そのエンティティに対して一意に追跡できる度合い。誰が何を行ったかを特定できる能力です ²⁴。
真正性 (Authenticity): ある主体（ユーザーやシステム）またはリソースの身元が、主張通りであることを確認できる度合い ²⁴。

保守性 (Maintainability):
ソフトウェア製品またはシステムが、意図した保守者（開発者、運用者など）によって、効果的かつ効率的に修正、改善、または環境の変化（新しいOS、ハードウェアなど）に適応させることができる度合いを示す特性です。

モジュール性 (Modularity): ソフトウェアが、変更が他のコンポーネントに与える影響が最小限になるように、独立したコンポーネントで構成されている度合い [²⁴²⁴, ²⁴]。
再利用性 (Reusability): 既存の資産（コード、コンポーネント、ドキュメントなど）を、複数のシステムで、または他の資産を構築するために再利用できる度合い [²⁴²⁴, ²⁴]。
解析性 (Analyzability): ソフトウェアの欠陥や故障の原因を診断したり、修正が必要な部分を特定したり、あるいは変更の影響を予測したりすることが、どの程度容易であるかの度合い [²⁴²⁴, ²⁴]。
修正性 (Modifiability): ソフトウェア製品またはシステムを、欠陥を導入したり既存の品質を損なったりすることなく、効果的かつ効率的に修正できる度合い [²⁴²⁴, ²⁴]。
試験性 (Testability): 修正後などに、ソフトウェア製品またはシステムに対してテスト基準を確立し、テストを実行して、それらの基準が満たされているかどうかを判断することが、どの程度効果的かつ効率的に行えるかの度合い。自動テストの容易さも含まれます [²⁴²⁴, ²⁴]。

移植性 (Portability):
ソフトウェア製品またはシステムが、あるハードウェア、ソフトウェア、運用、または利用環境から別の環境へ、効果的かつ効率的に移すことができる度合いを示す特性です。

適応性 (Adaptability): ソフトウェアが、異なるまたは進化するハードウェア、ソフトウェア、その他の運用環境または利用環境に、効果的かつ効率的に適応できる度合い ²⁴。
設置性 (Installability): 指定された環境において、ソフトウェア製品またはシステムを効果的かつ効率的にインストールおよびアンインストールできる度合い ²⁴。
置換性 (Replaceability): 同じ環境で同じ目的のために、別の指定されたソフトウェア製品の代わりに、このソフトウェア製品を使用できる度合い ²⁴。

このISO/IEC 25010の品質モデルは、ソフトウェア品質に関する議論を深める上で極めて重要な枠組みとなります。なぜなら、ユーザーが求める「真のソフトウェア品質向上」とは何かを具体的に定義し、それに基づいて各開発手法がどの品質特性に強みを持ち、どの特性に課題を抱えやすいのかを分析する土台を提供するからです。例えば、アジャイル開発は「使用性」や「機能適合性（特に機能適切性）」において、顧客フィードバックを頻繁に取り入れることで高いレベルを達成しやすいかもしれません。一方、ウォーターフォール開発は、初期の厳密な設計を通じて「信頼性」や「性能効率性」を計画的に確保しようと試みるかもしれません。この後の比較分析では、これらの品質特性を念頭に置きながら、各手法の影響を考察していきます。

SEOキーワード: ソフトウェア品質, ISO/IEC 25010, 品質特性, 機能適合性, 性能効率性, 互換性, 使用性, 信頼性, セキュリティ, 保守性, 移植性, 品質モデル.

2.2. 主要なソフトウェア品質メトリクス

ISO/IEC 25010で定義された品質特性は、ソフトウェア品質の「何を」評価するかを示しますが、それを「どのように」具体的に測定・評価するかについては、品質メトリクス（品質指標）が用いられます ²⁶。品質メトリクスは、ソフトウェアの様々な側面を定量的に把握し、品質の状態を客観的に評価し、改善活動の方向性を定めるための重要なツールです。以下に、ソフトウェア開発の現場でよく用いられる主要な品質メトリクスをいくつか紹介します。

欠陥密度 (Defect Density):
ソフトウェアのコード量（通常はキロラインオブコード、KLOC：Thousand Lines of Code）あたりに発見された欠陥（バグ）の数を示す指標です 26。計算式は「総欠陥数 ÷ コードサイズ(KLOC)」となります。一般的に、欠陥密度が低いほどコードの品質が高いと見なされます。業界やプロジェクトの性質によって目標値は異なりますが、例えば1 KLOCあたり1～25件の欠陥が一つの目安とされることもあります 26。このメトリクスを時系列で追跡することで、開発プロセスの改善効果を測定したり、特定のモジュールの品質問題を特定したりするのに役立ちます。
コードカバレッジ (Code Coverage):
作成された自動テストスイートによって、ソフトウェアのソースコードのどれだけの割合が実行されたかを示す指標です 26。具体的には、テスト実行時に通過した行数、分岐（ブランチ）、パスなどを基に計算されます。コードカバレッジが高いほど、テストが広範囲に行き届いていることを意味しますが、カバレッジ率の高さ自体が必ずしもテストの質を保証するわけではありません。意味のあるテストケースを作成することが重要であり、重要なコンポーネントでは80%程度のカバレッジを目指すことが一つの目標とされることがあります 26。
サイクロマティック複雑度 (Cyclomatic Complexity):
プログラムの構造的な複雑さ、具体的にはコード内の独立した実行パスの数を測定する指標です 26。この値が高いほど、コードは理解しにくく、テストも難しく、修正時に新たなバグを混入させるリスクも高まるとされています。一般的に、メソッド（関数）ごとのサイクロマティック複雑度は10以下に抑えることが保守性の観点から推奨されます 26。SonarQubeのような静的解析ツールで自動的に計測できます。
顧客満足度スコア (Customer Satisfaction Scores):
ソフトウェアの最終的な利用者である顧客が、その製品やサービスに対してどの程度満足しているかを示す直接的な指標です 26。アンケート調査（例：CSAT、NPS）、サポートへの問い合わせ件数や内容の分析、アプリストアのレビューや評価、ユーザーの利用行動データの分析など、様々な方法で測定されます。高い顧客満足度は、機能性だけでなく、ユーザビリティや信頼性など、総合的な品質の高さを反映していると考えられます。
平均故障間隔 (MTBF – Mean Time Between Failures):
修復可能なシステムが、ある故障から次の故障までの間に正常に稼働している平均時間を示す指標です 26。計算式は「総稼働時間 ÷ 故障回数」となります。MTBFの値が大きいほど、システムの信頼性が高いことを意味します。特に、ミッションクリティカルなシステムや、常時稼働が求められるサービスにおいて重要なメトリクスとなります。
平均修復時間 (MTTR – Mean Time To Recover/Repair):
システムに障害が発生してから、それが修復されて正常な状態に復旧するまでにかかる平均時間を示す指標です 26。検出時間、診断時間、修正作業時間、デプロイ時間などが含まれます。MTTRの値が小さいほど、障害からの回復が迅速であり、システムの保守性や可用性が高いことを意味します。サービスレベルアグリーメント（SLA）で目標値が設定されることもあります。

これらの品質メトリクスは、ISO/IEC 25010で定義された品質特性と密接に関連しています。例えば、MTBFは「信頼性」の成熟性や可用性を、MTTRは「信頼性」の回復性や「保守性」の修正性を具体的に測定するのに役立ちます。欠陥密度は「機能適合性」の機能正確性や「信頼性」の成熟性に関わります。コードカバレッジやサイクロマティック複雑度は、「保守性」の試験性や解析性、修正性と関連が深いです。

このように、抽象的な品質特性を具体的なメトリクスに落とし込むことで、開発チームは品質目標を明確に設定し、進捗を監視し、問題点を特定して改善策を講じることが可能になります ²⁶。第3部でアジャイルとウォーターフォールの品質への影響を比較する際には、これらのメトリクスがどのように変動するのか、あるいは各手法がどのメトリクスの改善に注力しやすいのか、といった観点も重要になります。

SEOキーワード: 品質メトリクス, 欠陥密度, コードカバレッジ, サイクロマティック複雑度, 顧客満足度, MTBF, MTTR, ソフトウェア品質測定.

第3部：アジャイル vs ウォーターフォール：ソフトウェア品質への影響比較

アジャイル開発とウォーターフォール開発は、ソフトウェア品質を達成するためのアプローチにおいて根本的な違いを持っています。このセクションでは、それぞれの品質向上の戦略、実際の研究データに基づく比較、リスク管理と品質保証の観点からの考察、そして日本国内における品質重視の考え方について掘り下げていきます。

3.1. 品質向上のアプローチの違い

アジャイル開発のアプローチ

アジャイル開発における品質向上のアプローチは、継続的なフィードバック、統合されたテスト戦略、柔軟な変更管理、そして「動くソフトウェア」を重視する姿勢に特徴づけられます。

フィードバックループの活用: アジャイル開発の核心は、短いイテレーション（スプリント）と頻繁なリリースを通じて、継続的なフィードバックループを確立することにあります ¹。各イテレーションの終わりに、実際に動作するソフトウェアのインクリメントを顧客やステークホルダーに提示し、レビューを受けます。このプロセスにより、要求の誤解、期待とのズレ、潜在的な問題点を早期に特定し、迅速に修正することが可能になります。この早期発見・早期修正のサイクルが、手戻りのコストを削減し、最終的な製品品質を高める上で極めて重要です。
統合されたテスト戦略: アジャイルでは、テストは開発プロセスの最終段階で行われる独立したフェーズではなく、開発ライフサイクル全体にわたって統合された活動と見なされます ⁹。品質保証（QA）チームはプロジェクトの初期段階から関与し、開発者と密接に協力して品質を確保します ²⁸。テスト駆動開発（TDD）やビヘイビア駆動開発（BDD）のようなプラクティスは、テストを設計の一部として捉え、コードが書かれる前、あるいは同時にテストが作成されることを奨励します ¹⁷。継続的インテグレーション（CI）環境では、コード変更のたびに自動テストが実行され、品質が常にチェックされます。
柔軟な変更管理: アジャイルマニフェストが示すように、アジャイルは「計画に従うことよりも変化への対応」を重視します ³。市場の要求や顧客のニーズは開発途中で変化しうるという現実を受け入れ、それらの変更を柔軟に取り込みながらも品質を維持・向上させることを目指します。優先順位の高い機能から開発し、各イテレーションで価値を提供することで、変更の影響を局所化しやすくなります。
ドキュメンテーションの考え方: アジャイルは「包括的なドキュメントよりも動くソフトウェア」を優先しますが、これはドキュメントを全く作成しないという意味ではありません ⁶。むしろ、価値を提供するために必要十分なドキュメントを作成し、過剰な文書化作業による無駄を省くことを目指します。知識や情報は、チームメンバー間の頻繁なコミュニケーションやペアプログラミングなどを通じて、より動的に共有されることが奨励されます。

ウォーターフォール開発のアプローチ

ウォーターフォール開発における品質向上のアプローチは、厳格な計画、フェーズごとの明確な成果物、詳細な文書化、そして最終段階での集中的なテストに特徴づけられます。

フィードバックループの構造: ウォーターフォールモデルにおけるフィードバックループは、主に各フェーズの完了時点で行われるレビューや承認プロセスを通じて形成されます ²。しかし、開発の後半段階、特にテストフェーズに至るまで、顧客やエンドユーザーからの実質的なフィードバックが得られにくいという構造的な課題があります ⁹。これにより、初期の要求解釈の誤りや潜在的なユーザビリティの問題が、プロジェクトの終盤まで発見されないリスクが生じます。
独立したテスト戦略: ウォーターフォールでは、テストは通常、実装フェーズが完全に完了した後に実施される、独立した集中的なフェーズとして位置づけられます ²。このテストフェーズで、要求仕様書や設計書に基づいてソフトウェア全体の品質が検証されます。計画段階でテスト計画が詳細に策定され、それに従ってテストが実行されます。
厳格な変更管理: ウォーターフォールモデルでは、プロジェクト開始時に要件を確定させ、その後の変更は極力避けるという前提に立っています ²。途中で変更が発生した場合、それは正式な変更管理プロセスを経て評価され、承認された場合にのみ反映されますが、多くの場合、手戻りコストが非常に高くなるため、変更は敬遠される傾向にあります ⁵。
ドキュメンテーションの重視: ウォーターフォールでは、各フェーズの成果物として詳細なドキュメント（要求仕様書、設計仕様書、テスト計画書、テスト報告書など）を作成することが不可欠とされます ¹。これらのドキュメントは、プロジェクトの進捗管理、品質保証、後続フェーズへの情報伝達、そして将来の保守作業のための重要な基盤となります。

このように、両手法は品質を確保するための哲学と具体的な手段において大きく異なります。アジャイルはプロセスを通じた継続的な検証と適応によって品質を練り上げていくのに対し、ウォーターフォールは初期計画の精度と各フェーズの厳格な実行によって品質を構築しようとします。

3.2. 海外研究に基づく品質比較データ

アジャイル開発とウォーターフォール開発のどちらがソフトウェア品質の向上に寄与するかという問いに対して、多くの研究機関や実務家が比較分析を行っています。以下に、海外の文献から得られた具体的なデータや事例を紹介します。

Microsoftの事例研究:

ある研究では、Microsoft社内でのプロジェクトを対象に、ウォーターフォール型からアジャイル型（特にScrumやKanban）への移行がもたらした影響を分析しています 20。この研究によると、アジャイル手法を導入したプロジェクト（250件）は、ウォーターフォール手法を用いたプロジェクト（100件）と比較して、以下の点で顕著な改善が見られました。

平均開発期間: ウォーターフォールで24ヶ月だったものが、アジャイルでは15ヶ月に短縮。
平均欠陥率: ウォーターフォールで15%だったものが、アジャイルでは10%に低減。
コスト超過: ウォーターフォールで20%だったものが、アジャイルでは12%に削減。
顧客満足度スコア: ウォーターフォールで70%だったものが、アジャイルでは85%に向上。

このデータは、アジャイル開発が開発効率の向上だけでなく、ソフトウェア品質（欠陥率の低減）および顧客満足度の向上にも大きく貢献しうることを示唆しています ²⁰。

International Journal of Project PReMS (IJPREMS) の研究:

2023年12月にIJPREMSに掲載された研究では、それぞれ50件のアジャイルプロジェクトとウォーターフォールプロジェクトを対象とした比較分析が行われています 21。この研究結果は以下の通りです。

品質メトリクス（1000行あたりの欠陥数）: アジャイルプロジェクトの平均が4件であったのに対し、ウォーターフォールプロジェクトの平均は7件でした。
ステークホルダー満足度スコア（1-10点満点）: アジャイルプロジェクトの平均が8.5点であったのに対し、ウォーターフォールプロジェクトの平均は7.0点でした。
平均提供時間（週）: アジャイルプロジェクトは平均10週間、ウォーターフォールプロジェクトは平均14週間。
平均予算差異（%）: アジャイルプロジェクトは5%、ウォーターフォールプロジェクトは10%。

これらの差異はいずれも統計的に有意であり（p < 0.001 または p < 0.01）、アジャイル開発が品質（欠陥数の少なさ）とステークホルダー満足度の両面でウォーターフォール開発よりも優位性を持つ可能性を示しています ²¹。この研究では、アジャイルの効果的なテストとフィードバックメカニズムが品質向上に寄与していると考察されています。

SAVIOM Softwareによる分析:

SAVIOM Softwareのブログ記事では、アジャイルは継続的な改善と高品質を保証すると述べられています。頻繁なテストとスプリントレビューが、問題が深刻化する前に早期に発見し対処することを促進するためです。一方、ウォーターフォールは開発完了後に構造化されたテストを行うことで品質基準の遵守を目指しますが、初期段階での要求の誤解や見落としが開発後半で発覚した場合、大規模な手戻りが発生するリスクが高いと指摘されています 9。

Designveloperによる調査引用:

Designveloperのブログ記事では、ある調査結果として、アジャイルプロジェクトの成功率が88.2%であるのに対し、ウォーターフォールプロジェクトの成功率は47%であったと報告されています 11。プロジェクトの成功には多くの要因が絡みますが、一般的に成功率の高さは、提供されるソフトウェアの品質や顧客満足度と相関があると考えられ、間接的にアジャイルの品質への貢献を示唆している可能性があります。

これらのデータをまとめた比較表を以下に示します。

表1: アジャイルとウォーターフォールの品質関連メトリクス比較

メトリクス名	ウォーターフォール	アジャイル	出典
平均欠陥率	15%	10%	²⁰
1000行あたりの欠陥数 (件)	7	4	²¹
顧客満足度スコア / ステークホルダー満足度スコア	70% / 7.0点	85% / 8.5点	²⁰
プロジェクト成功率	47%	88.2%	¹¹
平均開発期間 (ヶ月/週)	24ヶ月 / 14週	15ヶ月 / 10週	²⁰
コスト超過	20%	12%	²⁰
平均予算差異 (%)	10%	5%	²¹

注: 異なる研究からのデータを統合しているため、直接比較には注意が必要です。しかし、全体的な傾向としてアジャイルが有利であることを示唆しています。

これらの研究結果から、アジャイル開発が示す品質面での優位性は、そのプロセスに内在するメカニズムに起因すると考えられます。短いイテレーションによる反復的な開発とテスト ³ は、欠陥が作り込まれてから発見されるまでの時間を短縮し、修正コストを低減します。これにより、欠陥密度が直接的に影響を受けます。また、顧客との継続的な協調と頻繁なフィードバック ⁶ は、開発されるソフトウェアが真のユーザーニーズに合致することを保証し、機能的な適切性やユーザビリティを高め、結果として顧客満足度の向上に繋がります。

ただし、これらのアジャイルの利点は、手法が適切に実践された場合にのみ最大限に発揮されることを忘れてはなりません。例えば、ステークホルダーの関与が不十分であったり、プロダクトバックログの管理が杜撰であったりすると（³⁰で指摘される課題）、アジャイルの利点は損なわれてしまいます。一方で、ウォーターフォール開発も、要件が真に安定的で明確に定義されている場合には、その厳格なプロセスを通じて高品質なソフトウェアを生み出すことが可能です ²。

したがって、データはアジャイルの優位性を示唆していますが、その背景にあるのはアジャイル固有の品質向上メカニズム（早期フィードバック、反復的テスト、顧客協調など）であり、これらのメカニズムが効果的に機能することが重要です。

3.3. リスク管理と品質保証

ソフトウェア開発プロジェクトには常にリスクが伴います。これらのリスクをいかに効果的に管理し、品質を保証していくかは、開発手法を選択する上で重要な考慮事項です。

アジャイルにおけるリスク管理と品質保証:

アジャイル開発では、リスク管理はプロジェクト全体を通じて継続的に行われる活動と位置づけられています 1。短いイテレーションごとに実際に動作するソフトウェアを開発し、ステークホルダーからのフィードバックを得ることで、市場のニーズとの不一致リスク、技術的な実現可能性に関するリスク、ユーザビリティに関するリスクなどを早期に特定し、迅速に対応することが可能です 1。もしある機能が期待通りに受け入れられない、あるいは技術的に困難であることが判明した場合でも、早期に方向転換（ピボット）することで、大きな損失を避けることができます。

品質保証（QA）に関しても、アジャイルでは特定のフェーズに限定されるのではなく、開発プロセス全体に組み込まれます。QA担当者はプロジェクトの初期段階からチームの一員として参加し、要求の明確化、受け入れ基準の定義、テスト戦略の策定などに貢献します ²⁸。テストは開発と並行して継続的に行われ、自動化が積極的に活用されます。チーム全体が品質に対する責任を共有し、「品質は作り込むもの」という意識が醸成されやすい環境です。

ウォーターフォールにおけるリスク管理と品質保証:

ウォーターフォール開発では、リスクの特定とそれに対する軽減策の計画は、主にプロジェクトの初期フェーズ（要求定義、設計）で行われます 1。詳細な計画と文書化を通じて、潜在的なリスクを洗い出し、それらが発生した場合の対応策を事前に準備しておくことが重視されます。

品質保証は、通常、開発フェーズが完了した後の独立したテストフェーズで集中的に実施されます ²⁹。この段階で、作成されたテスト計画に基づいて厳格なテストが行われ、仕様書に対する適合性が検証されます。文書化された明確な基準に基づいて品質を評価するため、客観性は保たれやすいですが、問題が発見された時点では既に多くの開発作業が完了しており、修正には大きなコストと時間がかかる可能性があります。

アジャイルの継続的かつ適応的なリスク管理は、特に変化の激しい環境や不確実性の高いプロジェクトにおいて、品質を維持・向上させる上で有利に働きます。リスクが顕在化した場合でも、その影響を最小限に抑え、迅速に軌道修正できるため、結果として品質の高い成果物につながる可能性が高まります。一方、ウォーターフォールの初期段階でのリスク評価は重要ですが、予期せぬリスクが開発後半で発生した場合、その硬直的な構造ゆえに対応が難しく、品質を犠牲にして納期を守るか、大幅な遅延とコスト増を受け入れて品質を確保するかの厳しい選択を迫られることがあります ⁵。

3.4. 品質を重視する場合の日本国内での見解

国外の研究や事例ではアジャイル開発が品質面で優位性を示すデータが多い一方で、日本国内では異なる見解も存在します。特に、伝統的に品質に対する意識が高いとされる日本の製造業やシステム開発の現場では、ウォーターフォール開発の特性が品質確保に適していると捉えられることがあります。

ある国内の専門家は、「仕様変更がないシステムであれば、ウォーターフォールが向いている場合もある」としつつ、「仕様変更が考えられるシステムであれば、アジャイルが向いている」と、プロジェクトの特性に応じた使い分けの重要性を指摘しています ²³。これは、ウォーターフォールの計画性と、アジャイルの柔軟性をそれぞれ評価する見方です。

また、別の国内情報源では、「品質を特に重視する場合にもウォーターフォール型開発はおすすめ」とされています。その理由として、「ウォーターフォール型開発は各工程で細かくチェックを行うので、ミスなども発生しづらく障害発生率も大幅に抑えることができる」と説明されています ³¹。この見解は、ウォーターフォールの厳格なフェーズ管理と各段階でのレビュープロセスが、欠陥の作り込みを防ぎ、結果として高い品質（特に障害の少なさ）に繋がるという期待に基づいています。

これらの日本国内での見解と、先に示した国外の研究データ（アジャイルの方が欠陥率が低い傾向）との間には、一見すると矛盾があるように感じられるかもしれません。この違いは、いくつかの要因によって説明できる可能性があります。

一つは、「品質」という言葉の解釈の違いです。ウォーターフォールで重視される「品質」は、初期に定義された仕様に対する厳密な準拠性や、安定稼働（障害の少なさ）である可能性があります。一方、アジャイルで追求される「品質」は、変化するユーザーニーズへの適合性（機能適切性）や、高い顧客満足度を含む、より広範な概念であるかもしれません。

また、日本の組織文化やプロジェクト管理の慣行が影響している可能性も考えられます。計画通りに進めることや、詳細なドキュメントによる責任範囲の明確化を重視する文化では、ウォーターフォールの構造的なアプローチが好まれる傾向があるかもしれません。

さらに、日本でウォーターフォールが適用されるプロジェクトのタイプ（例：大規模な基幹システム刷新など、安定性が極めて重視されるもの）と、アジャイルが適用されるプロジェクトのタイプ（例：新規サービス開発など、変化への対応が重視されるもの）が異なるため、単純比較が難しいという側面もあるでしょう。

重要なのは、ウォーターフォールで言及される「各工程での細かいチェック」というプラクティスは、アジャイル開発においても適用可能であるという点です。アジャイルのスプリント内での徹底したテスト、受け入れ基準（Definition of Done）の厳格な運用、継続的インテグレーションによる頻繁な検証などは、まさに「細かいチェック」を反復的に行うことに他なりません。

したがって、日本国内の見解を尊重しつつも、それを国際的なデータやアジャイルの進化と照らし合わせて理解することが、真の品質向上戦略を考える上で重要となります。

SEOキーワード: ソフトウェア品質比較, アジャイル品質, ウォーターフォール品質, リスク管理, 品質保証, 日本品質観.

第4部：現代のソフトウェア開発トレンドと品質

ソフトウェア開発の世界は常に進化しており、アジャイルやウォーターフォールといった基本的な方法論も、新しい技術やプラクティスと融合しながら変化を続けています。このセクションでは、現代の主要なトレンドであるハイブリッドモデル、DevOpsとCI/CD、そしてアジャイルQAのベストプラクティスが、ソフトウェア品質にどのような影響を与えているかを探ります。

4.1. ハイブリッドモデルの台頭とその品質への影響

純粋なアジャイル開発または純粋なウォーターフォール開発だけでは、現代の多様かつ複雑なプロジェクトの要求に完全に応えきれないケースが増えています。その結果、両者の長所を組み合わせ、短所を補い合うことを目的とした「ハイブリッドモデル」が広く採用されるようになってきました ¹。

ハイブリッドモデルの具体的な形態は様々ですが、一般的な例としては、プロジェクトの初期段階（要求定義、基本設計、全体計画など）ではウォーターフォール的なアプローチで構造化と予測可能性を重視し、その後の開発・実装フェーズではアジャイル（特にスクラムなど）を適用して柔軟性と迅速なフィードバックを確保するというものです ¹。これにより、大規模で複雑なプロジェクトにおいても、初期の方向性を固めつつ、変化への対応力を維持することが期待されます。

品質への影響:

ハイブリッドモデルがソフトウェア品質に与える影響は、その設計と運用次第で大きく変わりますが、理想的には以下のような肯定的な効果が期待できます。

構造化された計画と適応的な実行のバランス: ウォーターフォールの強みである初期計画の網羅性と、アジャイルの強みである反復的な開発とフィードバックによる軌道修正能力を組み合わせることで、より現実的で質の高い成果物を目指せます ²¹。例えば、基幹システムのような安定性が求められる部分の設計はウォーターフォール的に行い、ユーザーインターフェースのような変化が予想される部分はアジャイル的に開発するといった使い分けが考えられます。
ステークホルダーの関与向上とリスク管理改善: プロジェクトのフェーズに応じて適切な関与の仕方を設計することで、ステークホルダーの満足度を高めつつ、リスクを効果的に管理できる可能性があります ³²。
協力体制の強化: 異なるアプローチを組み合わせる過程で、チーム内外のコミュニケーションと協力体制がより重要となり、結果として品質向上に繋がることもあります。

課題:

一方で、ハイブリッドモデルの導入と運用には以下のような課題も伴います。

コミュニケーションの障壁と統合の複雑性: 異なるマインドセットやプロセスを持つアプローチを効果的に統合するには、高度なコミュニケーション能力と調整スキルが求められます。各アプローチの境界や連携方法が不明確だと、混乱や非効率が生じる可能性があります ²²。
変化への抵抗: 従来の手法に慣れたチームや組織が、新しいハイブリッドなやり方に適応するには時間と努力が必要であり、変化への抵抗が生じることもあります ³²。
「名ばかりハイブリッド」のリスク: 単に両手法の用語を使っているだけで、本質的な利点を活かせていない、あるいは両者の欠点を引き継いでしまうような運用になるリスクもあります。

事例:

実際にハイブリッドモデルを導入して成果を上げている企業も存在します。例えば、TeslaやZaraは、製品開発においてアジャイルな反復開発とウォーターフォール的な構造化計画を組み合わせて活用しているとされています 12。IBMは「Agile with Discipline」というアプローチで、伝統的な手法の詳細な文書化とアジャイルの柔軟なタイムラインやスプリントを融合させています 11。また、米国のベーカリーチェーンPanera Breadは、Disciplined Agile Delivery (DAD) というハイブリッド的なフレームワークを導入し、迅速なソフトウェア開発と品質向上を実現しました 19。

これらの事例からわかるように、ハイブリッドモデルは画一的な解決策ではなく、プロジェクトの特性や組織の状況に合わせて慎重に設計・調整されるべきアプローチです。純粋なウォーターフォールが硬直的すぎると感じる一方、純粋なアジャイルでは統制が取りにくいと感じるような場合に、ハイブリッドモデルは現実的な選択肢となり得ます。その結果として得られる品質は、ウォーターフォールの計画性によって初期のアーキテクチャの堅牢性を確保しつつ、アジャイルの適応性によって最終的なユーザーニーズへの適合性を高めるという、「両方の世界の良いとこ取り」を目指すものと言えるでしょう。しかし、その成功は、異なるプロセスの「接着剤」となるコミュニケーションとプロセスの統合をいかに巧みに行うかにかかっています ²²。

4.2. DevOpsとCI/CDの役割と品質向上への貢献

現代のソフトウェア開発において、品質とスピードの両立を追求する上で不可欠なトレンドとなっているのが、DevOps（デブオプス）とCI/CD（継続的インテグレーション/継続的デリバリーまたはデプロイメント）です。これらは特定の手法というよりも、文化、プラクティス、ツールの組み合わせであり、アジャイル開発の原則をさらに推し進め、ソフトウェア開発ライフサイクル全体の効率化と品質向上に大きく貢献します。

DevOpsとは:

DevOpsは、開発（Development）チームと運用（Operations）チームが密接に連携し、協力し合うことで、ソフトウェアの計画、開発、テスト、リリース、運用、監視といった一連のプロセスを迅速かつ効率的に、そして高い信頼性をもって行うための考え方や文化、実践方法の総称です 34。伝統的に存在しがちだった開発チームと運用チームの間の「サイロ（縦割り構造）」を取り払い、共通の目標（高品質なソフトウェアを迅速に顧客に届ける）に向かって協力することを重視します。自動化、継続的なフィードバック、共有された責任がDevOpsの重要な要素です 34。

CI/CDとは:

CI/CDは、DevOpsの思想を実現するための具体的な技術的プラクティスの中核をなすものです。

CI (継続的インテグレーション – Continuous Integration):
開発者が書いたコードの変更を、頻繁に（理想的には1日に何度も）中央の共有リポジトリに統合（マージ）し、その都度、自動的にビルド（実行可能な形式への変換）とテスト（単体テスト、結合テストなど）を実行するプラクティスです 15。これにより、コードの統合時に発生する問題を早期に発見し、迅速に修正することができます。また、常に動作する状態のコードベースを維持することが容易になります。
CD (継続的デリバリー/デプロイメント – Continuous Delivery/Deployment):

継続的デリバリー (Continuous Delivery): CIでビルドとテストが成功したソフトウェアを、いつでも手動の承認一つで本番環境にリリースできる状態に保つプラクティスです。リリース候補となるソフトウェアは、ステージング環境などで追加のテスト（受け入れテスト、パフォーマンステストなど）を経ていることが一般的です。
継続的デプロイメント (Continuous Deployment): CI/CDのパイプラインをさらに進め、CIで全てのテストをパスしたコード変更を、人手を介さずに自動的に本番環境にまでデプロイするプラクティスです。これにより、非常に迅速なリリースサイクルが実現されます ¹⁵。

品質への貢献:

DevOpsとCI/CDは、ソフトウェア品質の向上に多大な貢献をします。

欠陥の早期発見と修正の促進: CI/CDパイプラインに組み込まれた自動テスト（単体テスト、結合テスト、リグレッションテストなど）が、コード変更のたびに実行されるため、バグや不具合を開発サイクルの非常に早い段階で発見し、修正することが可能になります ¹⁵。問題が小さいうちに対処できるため、修正コストも低く抑えられます。
リリースの信頼性向上とリスク低減: 変更を小さな単位で頻繁に統合し、デプロイすることで、一度にリリースされる変更量が少なくなり、大規模なシステム障害を引き起こすリスクが低減されます ¹⁵。また、デプロイプロセス自体が自動化・標準化されるため、人為的ミスによる問題も起こりにくくなります。
迅速なフィードバックループの確立: 開発者がコードを変更してから、その変更が品質に与える影響（テスト結果など）が数分から数時間以内にフィードバックされるため、問題の特定と対応が迅速に行えます。これは、開発→テスト→運用というライフサイクル全体にわたるフィードバックループを強化します ³⁴。
品質に対する共同責任の醸成: DevOps文化は、開発チームと運用チーム、さらにはQAチーム間のサイロを解消し、ソフトウェアの品質は全員の共同責任であるという意識を育みます ¹⁵。
アジャイル開発との高い親和性: DevOpsとCI/CDは、アジャイル開発の価値である「動くソフトウェアの迅速な提供」や「変化への対応」を技術的に支え、さらに強化します ¹⁵。アジャイルのスプリントで開発された機能は、CI/CDパイプラインを通じてスムーズにテストされ、リリースへと繋げられます。
ウォーターフォールプロジェクトへの適用可能性: DevOpsのプラクティス、特にテスト自動化やデプロイ自動化などは、厳密なウォーターフォールプロジェクトにおいても、テストフェーズの効率化やリリース作業の信頼性向上といった形で品質向上に貢献する可能性があります ³⁶。

DevOpsとCI/CDは、アジャイル開発が目指す品質向上の原則（例：「動くソフトウェア」、「変化への対応」、「継続的フィードバック」）を、自動化と効率的なプロセスを通じて具体的に実現する強力な手段と言えます。アジャイルQAのベストプラクティスである「テスト自動化」や「CI/CD連携」²⁸ は、まさにDevOpsの中核的な要素です。このように、DevOpsとCI/CDは単なる独立したトレンドではなく、アジャイルの品質向上ポテンシャルを最大限に引き出し、それを拡張するための不可欠なイネーブラー（実現手段）として機能しています。

4.3. アジャイルにおける品質保証（Agile QA）のベストプラクティス

アジャイル開発の普及に伴い、品質保証（QA: Quality Assurance）のあり方も変化しています。伝統的なウォーターフォールモデルにおけるQAが、開発プロセスの最終段階で「ゲートキーパー」として機能するのに対し、アジャイルQAは開発ライフサイクル全体にわたって品質を「組み込む」活動へとシフトしています ²⁸。以下に、現代のアジャイル開発におけるQAのベストプラクティスを挙げます。

QAチームの早期関与 (Early QA Involvement):
アジャイルプロジェクトでは、QA担当者やQAチームは、プロジェクトの構想段階やスプリントの計画段階といった非常に早い時期から積極的に関与します 28。彼らは、ユーザーストーリーの明確化、受け入れ基準（Acceptance Criteria）の定義、テスト可能性の評価、リスク分析などに貢献し、開発初期から品質を意識した活動を推進します。
テスト自動化の積極的活用 (Test Automation for Faster Cycles):
アジャイルの短いイテレーションと頻繁なリリースサイクルに対応するためには、テストの自動化が不可欠です 28。特に、リグレッションテスト（既存機能が壊れていないかを確認するテスト）、APIテスト、パフォーマンステスト、ロードテストなどは自動化の主要な対象となります。ユニットテスト（単体テスト）も開発者自身によって自動化されることが一般的です。これにより、迅速なフィードバックと継続的な品質検証が可能になります。
シフトレフトテスティング (Shift-Left Testing):
「シフトレフト」とは、開発ライフサイクルのより早い段階（左側）でテスト活動を開始し、品質問題を早期に発見・修正することを目指す考え方です 28。具体的には、ユーザーストーリーが作成された直後からテストケースの作成やレビューを開始したり、開発者がコーディングと並行してユニットテストを実装したり、静的コード解析ツールを早期から導入したりといった活動が含まれます。欠陥は、発見が遅れるほど修正コストが増大するため、シフトレフトは品質向上とコスト削減の両面に貢献します。
アジャイルテスト計画・実行 (Agile Test Planning & Execution):
アジャイルにおけるテスト計画は、ウォーターフォールのような詳細で固定的なものではなく、軽量で適応可能なものとなります 28。各スプリントの開始時に、そのスプリントで開発される機能に対するテスト戦略が立てられ、リスクやビジネス価値に基づいてテストケースの優先順位が決定されます。ビヘイビア駆動開発（BDD）のようなフレームワーク（例：Cucumber）を活用し、開発者、QA、プロダクトオーナーが共通言語で振る舞いを定義し、それをテストに結びつけることも効果的です。テスト実行はスプリント期間中、継続的に行われます。
CI/CDパイプラインとの連携 (Leverage Continuous Integration & Deployment – CI/CD):
アジャイルQAは、CI/CDパイプラインと密接に連携します 28。コードがコミットされるたびに自動ビルドと自動テスト（ユニットテスト、統合テストなど）が実行され、問題があれば即座に開発者にフィードバックされます。これにより、統合時の問題を早期に発見し、常にデプロイ可能な状態のソフトウェアを維持することができます。リグレッションテストもCI/CDパイプラインに組み込まれ、全てのコード変更に対して自動的に実行されることが理想です。
アジャイルメトリクスによる品質追跡 (Use Agile Metrics to Track Quality):
アジャイルプロジェクトにおける品質の状態を客観的に把握し、継続的な改善を促すためには、適切なメトリクスを追跡することが重要です 28。主なメトリクスには以下のようなものがあります。

欠陥密度 (Defect Density): 特定のモジュールや機能あたりの欠陥数。
テスト実行率 (Test Execution Rate): 各スプリントで計画されたテストのうち、実際に実行されたテストの割合。
コードカバレッジ (Code Coverage): 自動テストによってカバーされているソースコードの割合。
平均検出時間 (MTTD – Mean Time to Detect): 欠陥が発生してから検出されるまでの平均時間。
平均修復時間 (MTTR – Mean Time to Repair): 欠陥が検出されてから修正されるまでの平均時間。これらのメトリクスは、チームのパフォーマンスを評価し、品質に関するボトルネックや改善機会を特定するのに役立ちます。
チーム全体の品質責任 (Whole Team Approach to Quality):
アジャイルでは、品質はQAチームだけの責任ではなく、開発チーム全体の共同責任であるという考え方が基本です 28。開発者は自身のコードに対するユニットテストを作成・実行し、プロダクトオーナーは受け入れ基準を明確にし、QA担当者はテスト戦略の策定や高度なテスト（探索的テスト、ユーザビリティテストなど）に注力します。チーム全員が品質に対する当事者意識を持つことが、アジャイルQAの成功の鍵となります。

これらのベストプラクティスを実践することで、アジャイルチームは、変化の速い環境下でも、迅速かつ継続的に高品質なソフトウェアを提供することが可能になります。アジャイルQAは、単なるテスト実施部門から、品質を開発プロセス全体にわたって積極的に推進し、支援する役割へと進化しているのです。

SEOキーワード: ハイブリッド開発, DevOps, CI/CD, アジャイルQA, 品質保証, シフトレフト, テスト自動化.

第5部：ソフトウェア開発の未来と品質の進化

ソフトウェア開発の世界は、技術革新とともに絶え間なく進化しています。特に人工知能（AI）の急速な発展は、開発手法そのものや品質保証のあり方に大きな変革をもたらしつつあります。このセクションでは、AI駆動開発、AIとソフトウェアテスト、そしてその他の注目すべきトレンドが、未来のソフトウェア品質にどのような影響を与えるのかを展望します。

5.1. AI駆動開発：ソフトウェアエンジニアリングの変革

人工知能（AI）、特に大規模言語モデル（LLM）やエージェントAI（Agentic AI）の進化は、ソフトウェア開発の各プロセスを根本から変えようとしています ³⁸。これにより、開発の効率性、速度、そして潜在的には品質も新たな次元へと引き上げられる可能性が期待されています。

コード生成・補完の高度化:
GitHub CopilotやAmazon CodeWhispererといったAI搭載ツールは、開発者が記述するコードの文脈を理解し、適切なコードスニペットを提案したり、関数全体を生成したりすることができます 39。これにより、定型的なコーディング作業の時間が大幅に削減され、開発者はより複雑な問題解決や創造的な作業に集中できるようになります。AIはアルゴリズムの最適化や、特定のパターンに基づくコードのリファクタリング提案なども行うようになっています。
プロトタイピングと反復開発の加速:
自然言語による指示（プロンプト）を通じて、アプリケーションの基本的な構造や機能をAIに構築させることが可能になりつつあります 39。これにより、アイデアの具現化やプロトタイプの作成が迅速に行えるようになり、反復開発のサイクルも短縮されます。エージェントAIは、より自律的にタスクを分解し、必要なファイルを生成し、依存関係を管理するといった、より高度な開発支援を行うことが期待されています 40。
バグ発見・修正支援の自動化:
AIは、既存のコードベースを解析し、潜在的なバグや脆弱性を特定する能力を高めています。また、発見されたバグに対して、修正案を提示したり、場合によっては自動的に修正コードを生成したりすることも研究されています 39。これにより、デバッグ作業の効率化と、ヒューマンエラーによる見落としの削減が期待されます。
設計支援とドキュメンテーションの効率化:
AIは、要件に基づいて初期の設計案を提案したり、UML図のような視覚的な設計成果物を生成したりするのに役立ちます 40。また、コードから自動的にドキュメントを生成したり、既存のドキュメントを最新の状態に保ったりといった作業もAIによって効率化される可能性があります。
人間のソフトウェアエンジニアの役割変化:
AIによる開発作業の自動化が進むにつれて、人間のソフトウェアエンジニアの役割は変化していくと考えられます 39。単純なコーディング作業はAIに任せ、人間は以下のような、より高度な判断や創造性が求められるタスクに注力するようになるでしょう。

ソリューションの設計とアーキテクチャ構築: システム全体の構造やコンポーネント間の連携など、大局的な設計。
要件定義とステークホルダーとのコミュニケーション: ビジネスニーズやユーザーの真の要求を理解し、それを技術仕様に落とし込む。
AIが生成した成果物の評価と検証: AIが生成したコードや設計が、品質基準（正確性、効率性、保守性、セキュリティなど）を満たしているかどうかの評価。
複雑なシステム連携と問題解決: 複数のシステムやサービスが絡み合う複雑な環境における問題の特定と解決。
倫理的配慮と社会的影響の評価: AIを利用したシステムが社会に与える影響を考慮し、倫理的な問題を回避するための設計。

AI駆動開発が進化するにつれて、品質保証のあり方も新たな局面を迎えます。AIが生成したコードや設計、ドキュメントといった成果物に対する品質保証戦略が必要になります。AI生成物の検証は、単に機能的な正しさを確認するだけでなく、AI特有のバイアス、セキュリティ脆弱性、説明可能性の欠如といった新たな課題にも対応しなければなりません。例えば、LLMが生成したコードが、訓練データに含まれていた潜在的な脆弱性を引き継いでいないか、あるいは特定の条件下で予期せぬ振る舞いをしないか、といった点を検証する必要が出てくるでしょう ⁴⁰。これは、従来のQAとは異なるスキルセットやツール、メトリクスを要求する可能性があります。

5.2. AIとソフトウェアテスト・品質保証

AIは、ソフトウェアテストと品質保証（QA）の分野においても、その能力を急速に拡大させています。AIを活用することで、テストプロセスの効率化、テストカバレッジの向上、そしてより高度な欠陥予測などが可能になり、ソフトウェア品質のさらなる向上に貢献すると期待されています ³⁸。

予測的欠陥分析 (Predictive Defect Analysis):
機械学習アルゴリズムを用いて、過去のプロジェクトデータ（コードの変更履歴、欠陥報告、テスト結果、開発者のスキルなど）を分析し、ソフトウェアのどの部分（モジュールやコンポーネント）に欠陥が発生しやすいかを予測します 42。これにより、QAチームは限られたリソースを、リスクの高い領域に重点的に投入することができ、テストの効率と効果を高めることができます。
テストケース生成・最適化の自動化 (AI-driven Test Case Generation and Optimization):
AIは、ソフトウェアの仕様書や既存のコード、あるいはユーザーの利用パターンなどから、テストケースを自動的に生成することができます 44。また、既存の膨大なテストスイートの中から、冗長なテストケースを特定して削減したり、リグレッションテストで実行すべき最適なテストケースのサブセットを選択したりといった、テストスイートの最適化も支援します。
テスト自動化の強化と高度化 (Enhanced Test Automation):
従来から行われてきたリグレッションテストやパフォーマンステストなどの自動化を、AIがさらに高度なレベルで実行できるようになります 38。例えば、AIはアプリケーションのUIの変更を自動的に検知し、テストスクリプトを適応させたり、テスト実行結果を分析して失敗の原因を推定したりすることができます。
視覚的テスト・UIテストの自動化 (Visual Testing and UI Testing Automation):
AI（特に画像認識技術）を活用することで、アプリケーションのGUI（グラフィカルユーザーインターフェース）が正しく表示されているか、レイアウト崩れや要素の欠落がないかといった視覚的な不具合を自動的に検出することができます。これにより、手動での目視確認にかかる時間と労力を大幅に削減できます。
ログ分析と異常検知 (Log Analysis and Anomaly Detection):
AIは、システムが生成する大量のログデータをリアルタイムで分析し、通常とは異なるパターン（異常）を検知することができます 42。これにより、システム障害の予兆を早期に捉えたり、障害発生時の原因究明を迅速化したりするのに役立ちます。

品質への影響:

AIをソフトウェアテストとQAに導入することによる品質への影響は多岐にわたります。

テスト効率と効果の大幅な向上: 自動化と最適化により、より少ない時間とコストで、より広範囲かつ深いテストが可能になります ⁴²。
手戻りの削減: 欠陥の早期発見と予測により、開発サイクルの後半での手戻りが減少し、開発全体の生産性が向上します。
リリースサイクルの短縮: 効率的なテストプロセスは、ソフトウェアのリリースサイクルを短縮し、市場への迅速な価値提供を可能にします。
より信頼性の高いソフトウェア製品の実現: より網羅的かつ効果的なテストを通じて、最終製品の信頼性と安定性が向上します。

AIによるQAの進化は、品質向上のための好循環を生み出す可能性があります。AIによる予測的欠陥分析 ⁴³ は、チームがリスクの高い領域に事前に対処することを可能にし、欠陥の発生そのものを抑制します。AIによるスマートなテストケース生成と最適化 ⁴⁴ は、より効果的なテストとカバレッジ向上につながります。反復的なテストの高度な自動化 ³⁸ は、人間のテスターをより複雑で探索的なテストに集中させ、全体的な欠陥検出能力を向上させます。そして、AI駆動テストからの迅速なフィードバックは、より迅速な修正を可能にします。このような予防、より良い検出、そして迅速な解決という継続的なサイクルは、AIによって駆動または増強され、ソフトウェア製品の基本的な品質とQAプロセスの効率を大幅に向上させることが期待されます。

5.3. その他の注目トレンド（ローコード/ノーコード、クラウドネイティブ等）と品質への示唆

AI以外にも、ソフトウェア開発の未来を形作るいくつかの重要なトレンドが存在し、それぞれがソフトウェア品質のあり方に新たな示唆を与えています。

ローコード/ノーコードプラットフォーム (Low-Code/No-Code Platforms):
ローコード/ノーコードプラットフォームは、従来のプログラミング知識が少ない、あるいは全くない「市民開発者（Citizen Developer）」でも、グラフィカルなインターフェースや事前定義されたコンポーネントを使ってアプリケーションを迅速に構築できるツールです 38。これにより、ビジネス部門が必要とするアプリケーションの開発速度が飛躍的に向上し、IT部門の負担軽減にも繋がると期待されています。
品質への示唆: 開発の民主化は、一方でガバナンスの欠如や「シャドーIT」のリスクも生み出します。市民開発者が作成したアプリケーションの品質（セキュリティ、スケーラビリティ、保守性、データ整合性など）をいかに担保するかが新たな課題となります。専門のソフトウェアエンジニアやQAチームの役割は、プラットフォーム自体の選定・管理、開発標準やテンプレートの提供、市民開発者への教育、そして重要なアプリケーションや複雑な連携部分の品質保証へとシフトしていく可能性があります 41。
クラウドネイティブ開発 (Cloud-Native Development):
クラウドネイティブとは、アプリケーションをクラウド環境（パブリッククラウド、プライベートクラウド、ハイブリッドクラウド）の利点を最大限に活用するように設計・構築するアプローチです。マイクロサービスアーキテクチャ、コンテナ技術（Docker、Kubernetesなど）、サーバーレスコンピューティングといった技術要素が中心となります 38。これにより、アプリケーションのスケーラビリティ（拡張性）、レジリエンス（障害耐性）、アジリティ（俊敏性）が大幅に向上します。
品質への示唆: クラウドネイティブアプリケーションは、多数の独立したマイクロサービスが連携して動作する分散システムとなるため、従来のモノリシックなアプリケーションとは異なる品質課題が生じます。サービス間の通信障害、一部サービスの遅延や停止がシステム全体に与える影響、分散環境でのデータ一貫性の担保、複雑な依存関係のテスト、セキュリティ確保などが新たな焦点となります。カオスエンジニアリング（意図的に障害を発生させてシステムの挙動を検証する手法）や、高度な監視・オブザーバビリティ（可観測性）の確立が、クラウドネイティブ環境における品質保証の重要な要素となります。
DevSecOps (セキュリティバイデザイン – Security by Design):
DevSecOpsは、DevOpsの考え方にセキュリティ（Security）を統合し、開発ライフサイクルの初期段階からセキュリティを組み込むアプローチです 38。セキュリティは、開発の最終段階で追加されるものではなく、設計、実装、テスト、運用の全てのフェーズで考慮されるべき「品質の一側面」として扱われます。
品質への示唆: 「品質＝セキュアなソフトウェア」という認識がますます強まっています。静的/動的アプリケーションセキュリティテスト（SAST/DAST）、脆弱性スキャン、脅威モデリングといったセキュリティプラクティスが、CI/CDパイプラインに自動的に組み込まれるようになります。これにより、セキュリティ問題の早期発見と修正が促進され、より安全で信頼性の高いソフトウェアが提供されることが期待されます。
エッジコンピューティング (Edge Computing):
エッジコンピューティングは、データ処理をデータが生成される場所（エッジデバイス、センサー、ローカルサーバーなど）の近くで行うことで、中央集権的なクラウドへのデータ送信量を減らし、低遅延と高性能を実現する技術です 38。IoTデバイス、自動運転車、AR/VRアプリケーションなど、リアルタイム性が極めて重要な分野で活用が進んでいます。
品質への示唆: エッジ環境で動作するソフトウェアには、非常に高いリアルタイム性、信頼性、そしてオフラインでも動作する能力などが求められます。ネットワーク接続が不安定な状況や、リソースが限られたデバイス上での動作を保証するためのテスト戦略や品質基準が必要となります。また、多数のエッジデバイスの管理やセキュリティ確保も新たな品質課題となります。

これらの新しい開発パラダイムは、品質保証の対象と方法を大きく変化させます。ローコード/ノーコードは、開発の敷居を下げる一方で、品質管理の分散化という課題を生みます。クラウドネイティブは、個々のアプリケーションのコード品質だけでなく、サービス間の連携や運用特性を含むエコシステム全体の品質を問います。DevSecOpsは、セキュリティを品質の中核に据え、開発プロセス全体での実践を求めます。これらのトレンドは、QA戦略が静的なコード検証から、動的なシステム挙動、運用特性、そしてエコシステム全体の健全性を保証するものへと進化する必要性を示唆しています。

SEOキーワード: AI駆動開発, LLM, ソフトウェアテスト AI, ローコード開発品質, クラウドネイティブ品質, DevSecOps, エッジコンピューティング品質.

結論：真にソフトウェア品質を高める開発手法とは

本記事では、アジャイル開発とウォーターフォール開発という二大ソフトウェア開発手法を、主にソフトウェア品質という観点から、国外の文献や最新のトレンドを交えながら比較検討してきました。最終的に「どちらの手法が真にソフトウェア品質を高めるのか」という問いに対する答えは、単純な二者択一では導き出せないことが明らかになりました。

アジャイルとウォーターフォールの本質的な強みと弱みの再確認

ウォーターフォール開発は、その直線的かつ逐次的なアプローチにより、プロジェクト初期に要件が明確で変更の可能性が低い、安定した環境において強みを発揮します ¹。厳格な計画、詳細な文書化、フェーズごとの明確な成果物は、予測可能性と管理のしやすさをもたらします。しかし、その硬直性ゆえに、開発途中の変化への対応力に乏しく、フィードバックの反映が遅れがちであるという本質的な弱点を抱えています。これが、最終的なソフトウェアが真のユーザーニーズから乖離したり、後半で発見された問題の修正が困難になったりするリスクに繋がります。
アジャイル開発は、反復的なサイクル、継続的なフィードバック、そして変化への適応力を特徴とし、特に要求が不確実であったり、市場の変化が速かったりする環境でその真価を発揮します ¹。顧客との密接な協調を通じて、ユーザーにとって価値の高いソフトウェアを迅速に提供し、顧客満足度を高めることに優れています。一方で、初期段階での全体像の把握や正確な見積もりが難しかったり、スコープクリープのリスクがあったり、大規模プロジェクトへの適用には工夫が必要だったりといった課題も指摘されています。

プロジェクト特性に応じた最適な手法選択の指針

「万能な開発手法」というものは存在しません。ソフトウェア品質を最大限に高めるためには、プロジェクトの具体的な特性（規模、複雑性、要件の安定性、技術的新規性など）、チームのスキルと経験、組織の文化や成熟度、そして市場の動向や顧客の期待といった多様な要因を総合的に考慮し、最適な手法を選択または組み合わせることが不可欠です ⁵。

要件が固定的で明確、かつ変更リスクが低い場合: ウォーターフォールが依然として有効な選択肢となり得ます。特に、厳格な規制遵守や安全性が最優先される分野では、その計画性と文書化が強みとなります。
要件が不確実で変化が多く、迅速な市場投入が求められる場合: アジャイルが適しています。イノベーションを追求するプロジェクトや、ユーザーからのフィードバックを継続的に取り入れて改善していく製品開発には最適です。
両者の特性が必要とされる複雑なプロジェクトの場合: ハイブリッドモデルの検討が有効です。例えば、全体のアーキテクチャ設計はウォーターフォール的に行い、個々の機能開発はアジャイルで進めるといったアプローチが考えられます ¹。

品質向上のための普遍的原則と今後の展望

特定の開発手法に固執する以上に、ソフトウェア品質を真に高めるためには、手法の選択を超えた普遍的な原則とプラクティスの実践が重要です。

明確なコミュニケーションとコラボレーション: チーム内、そして顧客やステークホルダーとの間で、オープンかつ継続的なコミュニケーションを図り、共通理解を醸成することが不可欠です ³。
継続的なフィードバックの重視: 開発のあらゆる段階でフィードバックを積極的に求め、それを製品改善に活かす文化を育むことが重要です ⁹。
早期からのテストと品質の作り込み: テストを開発プロセスの初期段階から組み込み（シフトレフト）、品質は後から検証するものではなく、最初から作り込むものという意識を持つことが求められます ²⁸。
顧客中心主義の徹底: 常に顧客の視点に立ち、真のニーズと価値を理解し、それに応える製品を提供することを目指すべきです ⁷。
チームのスキル向上とモチベーション維持: 高品質なソフトウェアは、高いスキルとモチベーションを持ったチームによって生み出されます。継続的な学習と成長の機会を提供し、チームが自律的に活動できる環境を整えることが重要です ³⁰。
品質文化の醸成: 組織全体として品質を最優先事項と捉え、品質向上のための努力を支援し評価する文化を築くことが、持続的な品質改善の鍵となります。

DevOps、CI/CD、そしてAIといった最新の技術トレンドは、これらの普遍的原則の実践を強力に支援し、アジャイルであれウォーターフォールであれ、あるいはハイブリッドであれ、あらゆる開発プロセスにおける品質向上を加速させるツールとなり得ます ¹⁵。

最終的に、ソフトウェア品質は、選択された特定の手法のみに依存するわけではありません。むしろ、その手法をいかに効果的に実践するか、そして何よりも、開発に関わる人々と組織全体が品質に対してどれだけ真摯にコミットしているかによって大きく左右されます。開発手法はあくまで高品質なソフトウェアを通じて顧客に価値を提供するための「手段」であり、その目的を見失わないことが肝要です。真のソフトウェア品質向上戦略とは、固定的な方法論に頼るのではなく、プロジェクトの文脈を深く理解し、品質中心の原則を柔軟に適用し、最新の技術とプラクティスを賢明に取り入れ、そして何よりも品質に対する組織的なコミットメントを育むことにあると言えるでしょう。

SEOキーワード: ソフトウェア品質向上, 開発手法選択, 今後の展望, アジャイル原則, 品質文化.

参考文献

Adobe Communications Team. (2022, March 18). Waterfall Methodology: A Complete Guide. Adobe Experience Cloud Blog. ²
Agile Alliance. (n.d.). Manifesto for Agile Software Development. ⁶
BestOutcome. (2025, January 21). Agile Vs Waterfall: Proven Strategies To Supercharge Your Project Management. ¹²
Designveloper. (n.d.). Agile vs Waterfall Project Management: What to Pick in 2025. ¹¹
Florac, W. A. (1992, September). Software Quality Measurement: A Framework for Counting Problems and Defects (Technical Report CMU/SEI-92-TR-022, ESC-TR-92-022). Software Engineering Institute, Carnegie Mellon University. ²⁷
Forecast.app Blog. (2025, February 10). The real difference between Agile and Waterfall. ⁵
Gandomani, T. J., Zulzalil, H., Ghani, A. A. A., Sultan, A. B. M., & Nafis, T. M. (2013). Obstacles in moving to agile software development methods in Malaysia. International Journal of e-Education, e-Business, e-Management and e-Learning, 3(3), 253. ³⁰
Ganesh, N., & Thangasamy, S. (2012). A survey on challenges in the agile software development. International Journal of Computer Science Issues (IJCSI), 9(2), 271. ³⁰
Global App Testing. (2024, February). 6 QA Testing Methodologies and Techniques in 2025. ²⁹
Gregory, P., Barroca, L., Sharp, H., Deshpande, A., & Taylor, K. (2015). The challenges of enterprise agile transformation: A public sector case study. In Agile Processes in Software Engineering and Extreme Programming: 16th International Conference, XP 2015, Helsinki, Finland, May 25-29, 2015, Proceedings 16 (pp. 3-17). Springer International Publishing. ³⁰
Hamid, N. A., Sahibuddin, S., & Ahmad, A. (2015). Hindering factors for adopting agile practices in software industry. Journal of Theoretical and Applied Information Technology, 73(1), 1. ³⁰
Hexadecimal Software. (2025, January 11). Case Studies in Project Management: Agile vs. Waterfall Success Stories. DEV Community. ¹⁹
International Journal of Advanced Scientific Research (IJASR). (2024, November). Comparative Analysis of Waterfall and Agile Methodologies in Microsoft. IJAISR, 24(1102). ²⁰
International Journal of Scientific Research (IJSR). (2024, January). Comparative Analysis of Waterfall and Agile Software Development Models: A Comprehensive Review. IJSR, 13(1), SR24105103239. ¹
International Journal of Project PReMS (IJPREMS). (2023, December). EVALUATING THE IMPACT OF AGILE AND WATERFALL METHODOLOGIES IN LARGE SCALE IT PROJECTS. ²¹
ITEA Journal. (2024). Agile and Waterfall Perceptions of Project Management Methodologies in a Department of Defense Organization. 45(4). ³⁰
Kanban Zone. (2024). Agile Frameworks Compared: Scrum vs. Kanban vs. Lean vs. XP. ¹⁷
Lucidchart Content Team. (n.d.). Pros and cons of the Waterfall methodology. Lucidchart Blog. ⁸
Monterail. (n.d.). Software QA Standards: What is ISO 25010 and Why Should You Care? Monterail Blog. ²⁴
Palmquist, M., Lapham, M. A., Miller, S., Chick, T., & Ozkaya, I. (2013). Parallel worlds: Agile and waterfall differences and similarities. Carnegie-Mellon Univ Pittsburgh Pa Software Engineering Inst. ³⁰
Product School. (2024, December 11). 13 Types of Agile Methodology To Optimize Your Workflow. Product School Blog. ⁴
ProjectManagement.com. (2016, October 7). Scrum vs. Kanban vs. XP. ¹⁶
ProjectManagement.com. (2024, November 25). Agile vs Waterfall: Which Project Management Methodology to Use? ⁶
Punnam, P. (2025, March 23). QA in Agile Methodology: Best Practices & Implementation for 2025. ACCELQ Blog. ²⁸
ResearchGate. (2024, February). (PDF) Waterfall to DevOps transition Successful DevOps Driven Digital Transformation. ³⁶
ResearchGate. (2024, December 8). AI in Testing Automation: Enabling Predictive Analysis and Test Coverage Enhancement for Robust Software Quality Assurance. ⁴³
ResearchGate. (2024, December 27). (PDF) A STUDY ON IMPACT OF AGILE AND DEVOPS PRACTICES ON SOFTWARE PROJECT MANAGEMENT SUCCESS. ³⁵
ResearchGate. (2025, January 5). Improving Software Development with Continuous Integration and Deployment for Agile DevOps in Engineering Practices. ³⁷
Saviom Software. (n.d.). Agile vs. Waterfall Project Management: Comparative Analysis. ⁹
Simplilearn. (n.d.). What is Agile Methodology and How Does it Work? Simplilearn. ³
Six Sigma. (2024, November 14). Software Quality: Metrics, Measurement & Best Practices. The Council for Six Sigma Certification. ²⁶
Su, D. (2025). The Future of AI-Driven Software Engineering. arXiv preprint arXiv:xxxx.xxxxx. ⁴⁰
Tech Helpware. (2025, January 13). ISO 25010: Enhancing Our Software Quality Management Process. Tech Helpware Blog. ²⁵
The International Conference on Software Engineering (ICSE). (2025). Panel 1: The Future of Software Engineering Beyond the Hype of AI. ³⁹
Valverde, R., Toleubay, A., & Tursynbay, N. (2024). The use of artificial intelligence for automatic analysis and reporting of software defects. Heliyon, 10(23), e33092. ⁴²
Various Authors. (2025, May 13). Best Practices Evidenced for Software Development Based on DevOps and Scrum: A Literature Review. Applied Sciences, 15(10), 5421. MDPI. ³⁴