V＆Vで考えるアジャイル開発の本質とウォーターフォールモデルの改善アプローチ
はじめに
こんにちは。SHIFTアジャイルQAリードの清水です。
ソフトウェア開発において、品質はプロジェクトの成功やその後の継続的なデリバリーの実現を左右する重要な要素であることは言うまでもありません。日本の大企業では、長年にわたりウォーターフォールモデルが主流の開発手法として採用されてきました。このモデルは、計画と管理がしやすいという利点があり、大規模プロジェクトでは特に重宝されてきました。しかし、お客様（顧客）の要求が絶えず変化する現代において、ウォーターフォールモデルでは柔軟な対応が難しく、開発の終盤に問題が発見されるリスクが高まることが課題となり、時にはプロジェクトの「炎上」に繋がる原因ともなります。
一方、アジャイル開発はその柔軟性と迅速なフィードバックが可能であるため、品質保証を高める手法として、日本企業でも近年広く認知されるようになりました。しかし、大企業、特に長年ウォーターフォールモデルに慣れ親しんだ組織やその開発チームが一気にアジャイル開発にシフトすることは現実的ではありません。このように断言できるのは、私が前職でそのような環境に身を置き、何度もこの状況に直面した経験があるからです。したがって、このような状況下では、一気にアジャイル開発に移行するのではなく、既存のウォーターフォールモデルをベースにし、その中にアジャイル開発の考え方を取り入れていくなど、徐々に変化させていく方法を取るべきだと考えます。
本ブログでは、アジャイル開発における品質保証の方法をV&V（Verification and Validation）の観点から解説し、ウォーターフォールモデルにおける品質保証の課題を述べ、その改善策を提案します。そして、段階的かつ実践的なアプローチを通じて、品質向上を目指すための具体的な方法を探ります。ご参考になれば幸いです。
アジャイル開発の本質
アジャイル開発は、ソフトウェア開発プロセスを迅速かつ柔軟に進めるための手法です。主な特性として、イテレーティブ（反復的）かつインクリメンタル（漸進的）なアプローチにより、開発期間を短いイテレーションに分割して、小さな機能単位での開発とリリースを繰り返します。これにより、チームは動作するソフトウェアを短い周期で顧客に提供し、迅速なフィードバックを得ることができます。
V&Vとは
V&Vは、「Verification and Validation」の略で、日本語では「検証と妥当性確認」と呼びます。 V&Vは、ソフトウェア開発における品質保証の肝となる考え方です。以下、それぞれの用語について説明します。なおV&Vは、いくつかの定義があるので、ここでは B.Boem氏によるものをベースとして説明します。
Verification（検証）
検証は、ソフトウェアが設計や仕様に基づいて正しく作られているかどうかを確認するプロセスです。具体的には、ソフトウェアの設計やコードが、あらかじめ定められた要件や設計ドキュメントに対して正しく実装されているかを確認します。つまり、検証は「正しく成果物を作っているか？」という問いに対する答えを提供します。これには、ドキュメントレビュー、コードレビュー、ユニットテスト、静的解析などが含まれます。
Validation（妥当性確認）
妥当性確認は、ソフトウェアがユーザーのニーズや要求を正しく満たしているかどうかを確認するプロセスです。これは、実際の運用環境においてソフトウェアが期待された通りに動作するかを確認することで行われます。妥当性確認は、「正しい成果物を作っているか？」という問いに対する答えを提供します。これには、ユーザーテスト、システムテスト、受け入れテストなどが含まれます。
妥当性確認の重要性
数年前、某モバイル決済サービスがリリースされました。しかし、サービス開始直後にセキュリティの脆弱性が露呈し、多数の顧客アカウントが不正に利用される事態となりました。この問題により、顧客からの信頼を失い、わずか数ヶ月でサービスは終了することになりました。 この事例では、妥当性確認が不足していたことが大きな要因とされています。
具体的には、二要素認証が導入されていなかったり、パスワード変更手順が容易すぎるという非常に危険な状態でサービスを開始し、実際の使用環境での問題が顕在化しました。サービス開始前に十分なセキュリティテストや脆弱性診断が行われていなかったため、システムの弱点が見逃され、顧客情報が危険にさらされる結果となりました。 おそらく、設計どおりに動いているかといった「検証」は行われていたのでしょう。
しかし、ユーザー目線での「妥当性確認」が不足していたために問題が発生したと言えます。このサービスの撤退は、妥当性確認の重要性を強く示す事例です。この経験から、製品やサービスを市場に投入する前に、ユーザーのニーズや期待をしっかりと確認し、セキュリティや機能性に関する妥当性確認を徹底することが不可欠であると言えます。
アジャイル開発の品質保証をV＆Vの観点で考えてみる
アジャイル開発の品質保証をV＆Vの観点から考えてみます。アジャイル開発において、イテレーションごとに成果物として出力されるものをインクリメントと呼びます。インクリメントは動作するソフトウェアであり、これを積み重ねたものを「最終成果物」と呼びます。 ですので、インクリメントは最終成果物の一部であると言えます。
また、イテレーションの中では必要最小限のドキュメントやソースコードなども成果物となりますが、これらは実際に動作するものではないため「中間成果物」と呼ばれます。
イテレーションの中では、中間成果物の検証（レビューなど）を通じて、ドキュメントやソースコードの品質を高めることも重要ですが、アジャイル開発における品質保証の肝となるのはインクリメントによる妥当性確認（要求に合致しているか？）です。
アジャイル開発では「常にリリース可能な状態を維持する」ことが求められます。この確認方法として、イテレーションごとにインクリメントが正しいことを確認しながら開発を継続することができます。言い換えれば、ソフトウェアが要求と合致していないことをイテレーション単位で早期に検出できる（問題の早期発見が可能）のです。これが、アジャイル開発における品質保証の大きなメリットと言えます。
ウォーターフォールモデルにおける品質保証の課題
ウォーターフォールモデルは、ソフトウェア開発を計画通りに進めるために設計された直線的なアプローチです。プロジェクトの各フェーズ（要件定義、設計、実装、テスト、リリース）が順番に行われるため、全体像を把握しやすく、進捗管理がしやすいという利点があります。しかし、このモデルには大きな課題も存在します。
ウォーターフォールモデルの各工程の成果物には設計書やソースコードが含まれますが、これらは中間成果物であり、各工程のインプットをプロセスに沿って変換しアウトプットしているもので、最終成果物（動くソフトウェア）ではありません。したがって、前半から中盤の工程では中間成果物による検証が品質保証の中心であり、妥当性確認はできません。妥当性確認によって確認できるユーザ価値は終盤のテストフェーズになって初めて明らかになります。
特に、開発の後期に行われるテストフェーズで初めて発見される問題がプロジェクト全体に影響を及ぼすことが多く、修正が遅れることで品質が低下するリスクが高い点が指摘されています。また、要件変更に柔軟に対応するのが難しく、開発中に顧客のニーズが変わった場合に適応が遅れることがあります。
ウォーターフォールモデルでの早期妥当性確認の重要性
ウォーターフォールモデルにおいても、早期に妥当性確認を行うことが品質保証の鍵となります。例えば、要件定義フェーズでユーザーインタビューやプロトタイピングを実施することで、開発初期段階から顧客のニーズに合ったソフトウェアを設計することができます。また、開発の各フェーズでインクリメンタルな動作確認を行うことで、問題を早期に発見し、修正することが可能になります。
ウォーターフォールモデルの改善策
ウォーターフォールモデルを改善するための有効な手段の一つが、「インクリメンタルな動作確認のアプローチ」です。このアプローチでは、ソフトウェアを段階的に開発し、それぞれの段階ごとに動作確認を行います。具体的には、開発された一部の機能やモジュールが完成するたびに、その部分を動作させてみて、要件や設計に対して正しい動作をしているかを確認します。これにより、全体の開発が完了する前に問題を早期に発見し、修正することが可能となります。
私が前職でプロジェクトマネージャーを担当していた組み込みソフトウェアの開発プロジェクトにおいても、一部の機能を実装してソフトウェアが動く状態になった時点で「簡易動作確認」と称した確認作業を段階的に実施していました。これにより、終盤のテストに入る前に設計や実装上の問題を見つけることができるため、後戻りを防ぐための手段として定着していました。
ただし、このアプローチではある程度まとまった機能単位・モジュール単位で実施していたので、設計→実装→簡易動作確認のサイクルの期間は固定的でなく、開発対象によりバラツキがありましたのでイテレーションにはなっていません。あくまでもウォーターフォールモデルの改善策になります。それでも動くソフトウェアによる動作確認を前倒しできる効果は大きく、開発終盤のテストで大きな後戻りの発生を抑止できていました。
このように、インクリメンタルな動作確認は、ウォーターフォールモデルのような一括開発においても、開発後期に集中するテスト作業の負担を軽減し、品質リスクを低減するための効果的な手法です。結果として、品質向上とリリースの迅速化が図られ、ユーザーに対して安定したソフトウェアを提供することができます。
とはいえ、この改善策で万全かというとそうではありません。上図を見てわかるとおり、最初に要件定義、最後にテストを行う、基本はウォーターフォールモデルです。したがって、不要なものやユーザーニーズに合わないものを作ってしまう、また簡易動作確認では検出できない問題が最後のテストで見つかる可能性はないとは言えず、ウォーターフォールモデルの問題点は強く残っています。ですので、さらなる変革として、要件定義や最後のテストをイテレーションの中に組み入れる、などといった改善を続け、アジャイル開発に進化していくことが望ましい姿と言えるでしょう。
まとめ
ウォーターフォールモデルを用いた開発プロジェクトにおいても、品質保証のアプローチを見直すことが重要です。アジャイル開発の要素を段階的に取り入れることで、ウォーターフォールモデルの持つ課題を克服し、より高品質なソフトウェアを開発することが可能になります。特に、インクリメンタルな動作確認アプローチを導入することで、プロジェクト全体のリスクを低減し、顧客の期待に応える製品を提供できるようになるでしょう。
企業としては、急激な変革を求めるのではなく、現実的かつ効果的な改善策を採用することで、競争力を維持しながら開発プロセスを進化させていくことが肝要と考えます。
◆参考文献
居駒 幹夫・梯 雅人「アジャイル開発のプロジェクトマネジメントと品質マネジメント -58のQ&Aで学ぶ-」2020年3月
執筆者プロフィール：清水 政幸（しみず まさゆき）
2023年11月にSHIFT入社。
前職では組み込みソフトウェア開発のプロジェクトマネージャーを行うかたわら、組織を横断したアジャイル開発の推進活動に8年間取り組んでいた。 SHIFTでは、顧客のアジャイル開発チームやQAチームに伴走しながら、品質とスピードを改善する「アジャイルQAリード」として、日々、顧客のソフトウェア開発の変革に取り組んでいる。
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/