近年、これまでのウォーターフォール開発に代わってアジャイル開発を採用するプロジェクトが日本でも増えています。ウォーターフォール開発に慣れた人がアジャイル開発をするとき、「ウォーターフォール開発のときのような品質管理（※1）ができない」と戸惑う人が多いようです。しかし、この戸惑いは、ウォーターフォール開発での品質管理に対する誤解から生じていることが多いと思われます。よくある誤解を下図に示します。

図1：品質管理に対する誤解

この図の「正解」に書かれていることは、アジャイル開発の特徴として挙げられることもありますが（※2）、実際にはウォーターフォール開発でも必要なことです。つまり、品質管理の正しい考え方が身についている人であれば、アジャイル開発に変わってもそれほど戸惑うことはありません。

ウォーターフォール開発とアジャイル開発で品質管理に対する基本的な考え方は同じですが、具体的なやり方には違いがあります。この違いは、開発期間、要求の変化への対応、作成する成果物といった両者の開発スタイルの違いから生じるものです。ウォーターフォール開発をしていた人が戸惑うのはこの点ではないかと思います。

ウォーターフォール開発をしていた人が特に戸惑う点として、今まで使っていたテスト密度（※3）やバグ密度（※4）といったメトリクスを使った評価が難しい点が挙げられます。アジャイル開発では実施する作業や作成する成果物が変わるため、今までどおりにメトリクスが取得できなかったり、今までどおりの品質評価では意味をなさなくなったりすることがあるからです。

アジャイル開発でも定量的品質管理は必要ですが、今までと同じやり方が通じないところが難しい点です。

では、アジャイル開発ではどのように品質管理をすればよいのでしょうか。ここでは、2つの方法を紹介します。

1つ目は、要求を満たしていることを示すことです。品質は「要求事項を満たす程度」と定義される（※5）ことから考えると、これは当然の方法と言えます。アジャイル開発では、要求は「バックログ」として表されます。バックログには、要求に相当する「ユーザーストーリー」と、そのユーザーストーリーが完成するための必要条件である「受け入れ基準」が書かれます。つまり、受け入れ基準を満たせば、それに対応するユーザーストーリー、すなわち要求を満たしたと言えます（※6）。

受け入れ基準を設けることは、アジャイル開発では一般的に行われます（※7）ので、この方法は一見簡単そうに見えます。しかし、受け入れ基準を適切に書くこと、書かれた受け入れ基準を正しく理解することが求められる上に、全体的な品質を保証するためにはバックログの網羅性も必要になります。そのため、単に「受け入れ基準を満たした」だけでは、品質が十分と言えない場合もあります。

そこで、別の視点からの品質管理として、開発したプロダクトそのものの品質ではなく、それに代わる情報（代用特性）を用いる方法が採られます。たとえば、「正しいプロセスで開発すれば、正しいプロダクトができる」という仮説に基づいて、「プロセス品質」を測ることは、従来からよく行われています。それに加えて、アジャイル開発では、開発者のスキルやチームの成熟度といった「リソース品質」がプロダクトの品質に影響するという考えから、リソース品質も代用特性として使われます。リソース品質には、バーンダウンチャートやベロシティなど、進捗や生産性に関するメトリクスが含まれます。つまり、開発者やチームが計画通りに作業ができて、高い能力を発揮できていれば、開発されるプロダクトの品質も高いという仮説です。

紹介した2つの方法をまとめると下図のようになります。このように、品質を多角的に捉え、総合的に分析・判断することが必要となります。

図2：品質管理対象と品質管理方法の関係（※8）

ここまで、アジャイル開発での品質管理の考え方、方法を紹介してきました。アジャイル開発における品質管理については、まだ最適解はなく、過去の開発ノウハウをベースにしつつ、アジャイル開発に合った品質管理方法を探っている状態と言えます。今までのやり方にとらわれない新たな方法が見つかる可能性もあるかもしれません。

NTTデータのデジタル技術部では、社内のアジャイル開発プロジェクトにおける検証や、NTTグループの各社との協業などを通して、アジャイル開発において品質が保証できていることを論理的に説明できる方法の確立を目指しています。