国際規格（ISO25000）でアジャイル開発の品質保証の仕組みを理解する

本稿ではまずソフトウェア開発における品質とは何かを国際規格（ISO）に基づいて説明し、その上でアジャイル開発に備わっている品質向上の仕組みについて説明します。

品質とは

ソフトウェアの品質は、「テストで不具合がでないこと」や「製品が想定どおりに動くこと」のように様々な意味合いで解釈されています。これらの定義は誤りではありませんが、十分ではありません。そもそも品質とは何かについて、システムおよびソフトウェア品質を定義する国際規格のISO/IEC 25000シリーズ（SQuaRE）をもとに説明します。

品質の定義

ソフトウェアの品質とは、後述するソフトウェアの特性の１つであり、「特定の条件で利用する場合の、明示的ニーズまたは暗黙的ニーズを満たすためのソフトウェア製品の能力」と定義されます。端的に言うと、「ソフトウェアが要求を満たしている度合い」です。

ソフトウェアの特性と品質

ソフトウェアの特性とは、図１に示すように、ソフトウェア固有の特性（元々備わっている特性）と、付与された特性（価格、出荷日といった管理面の特性）で構成されます。そして、ソフトウェア固有の特性は、「ソフトウェアが何をできるか」という機能特性と、「ソフトウェアがどれくらいうまく実行できるか」という品質特性に分類できます。この品質特性がソフトウェア製品の品質にあたります。

図１ ソフトウェアの特性

品質の分類

ソフトウェア製品の品質、つまり品質特性は、「利用時の品質」と「製品品質」の２つに分類できます。「製品品質」はさらに、「外部品質」、「内部品質」に分類できます。各品質の定義を以下に述べます。

• 利用時の品質
  • 利用者がニーズを満たすためにソフトウェア製品を使用することができる度合いです。これは、顧客満足とも言い換えることができます。利用者（利害関係者）は、ソフトウェア製品を直接利用する人だけではなく、保守や運用管理を行う人、ソフトウェア製品から出力されたものを受け取る人など様々で、利用者によってニーズは異なります。
• 製品品質
  • 開発するソフトウェア製品の出来映えそのものです。利用者のニーズを満たすためのソフトウェア製品の能力であり、製品の挙動（実行時のふるまい）の能力が外部品質で、開発中の中間製品（設計書やソースコードなど）の能力が内部品質です。

製品品質は、製品を開発するための一連の活動がどれだけうまく実施できているかという「プロセス品質」により大きく左右されます。図２は、プロセス品質を含めた各品質の関係性を示す図です。各品質は、互いに影響し、依存します。

図2 品質の分類と関係性

品質と要求

品質は「要求を満たしている度合い」と説明した通り、品質と要求は密接に関係していて、品質を理解するためには要求について理解する必要があります。そもそも要求とは何か、その定義について説明します。

要求の定義

要求とは「何かを達成してほしい、または何かを実現してほしい、というはっきりしたニーズの表現」と定義され、「期待やニーズを仕様化したもの」です。

ソフトウェアの品質要求

ソフトウェア製品に対する要求（ソフトウェア要求）について、図３に示します。ソフトウェア要求は、図１で示したソフトウェアの各特性に対する要求であり、品質特性に対する要求が品質要求です。そして、ソフトウェアの品質は「品質要求を満たしている度合い」です。

図3 ソフトウェア要求

品質要求の分類

品質要求は、「利用時の品質要求」、「外部品質要求」、「内部品質要求」の３つに分類できます。各品質要求の定義を以下に述べます。

• 利用時の品質要求
  • 「利用者がソフトウェア製品を利用する際の要求」です。主に、ビジネス要求、機能要求、既存製品や利用者が現在使用するシステム特有の要求といった利害関係者の要求から導出されます。
• 外部品質要求
  • 「ソフトウェア製品のふるまいに対する要求」です。主に機能要求、既存製品や利用者が使用しているシステムに特有の要求、法的な要求や制約、セキュリティ要求、企業の開発標準や指針といった利害関係者の要求や、利用時の品質要求など、多数の情報から導出されます。
• 内部品質要求
  • 「ソフトウェア製品内部の要素に対する要求」です。企業方針、開発方針や制約といった利害関係者の要求や、外部品質要求から導出されます。

品質のライフサイクル

これまでに述べた品質と品質要求の関係性は、図４に示す「品質ライフサイクル」のとおりです。

図4 品質ライフサイクル

まず、利用中のシステムや既存製品など、すでにある製品の利用によって、利害関係者（あらゆる利用者）にニーズが生まれます。そして、利害関係者のニーズから、利害関係者の要求が定義されます。利害関係者の要求を分析して製品に対する品質要求（利用時の品質要求、外部品質要求、内部品質要求）を導出します。導出された品質要求は製品へ実装され、各品質要求をに製品の品質が確認・承認されて利害関係者へ受け入れされます。そして製品の利用によって新たな利害関係者のニーズが生まれる、といった反復型のサイクルを繰り返します。
このことから高品質、つまり利害関係者のニーズを満たす能力が高い製品を開発するには、いかに利害関係者のニーズを効果的に引き出して、品質要求を仕様化できるかが重要です。

アジャイル型開発ライフサイクルについて

アジャイル開発の品質向上の仕組みを説明する前に、アジャイル開発の全体像とその特徴について説明します。
##全体像
一般的なアジャイル型の開発ライフサイクルの全体像を図５に示します。特定のアジャイル方法論に依存しないように、用語についてはPMBOKを参照しています。

図５ アジャイル型の開発ライフサイクルの全体像

アジャイル開発は、スクラムやXPといった方法論によらず、おおむね以下のようなプロセスを繰り返し実行します。

1. バックログの準備と洗練
   1. 利害関係者のニーズに基づく要求をバックログ（プロダクトバックログ）に格納する
2. イテレーションの計画
   1. 次のイテレーション（通常は２〜4週間の期間）で実現する要求（イテレーションバックログ）をプロダクトバックログから選定する。
3. イテレーションの実行
   1. イテレーションバックログをもとに「動く製品」を開発・実装する
   2. デイリースタンドアップを行い、日々のプロセスの課題や問題点を洗い出す
4. イテレーションのレビュー
   1. 利害関係者に向けて製品のデモンストレーションとレビューを行なって利害関係者からフィードバックをうける。このフィードバックをもとにプロダクトバックログの見直しを行う。
5. レトロスペクティブ
   1. イテレーション中の気付きや問題点についてふりかえり、教訓や学びを得て次のイテレーションに生かす。
6. （１から５を繰り返す）

特徴

アジャイル型の開発ライフサイクルには、大きな特徴が２つあります。

１つは、イテレーションのレビューにおける「動く製品のデモンストレーション」です。動作確認可能な製品（プロトタイプやモックアップなども含む開発中の製品）をイテレーション中に作りあげ、デモンストレーションを行なって利害関係者から製品に対するフィードバックを効果的に引出すことができます。

もう１つは、イテレーションをとおして行う継続的なプロセス改善活動です。開発チームは、イテレーションの実行中にデイリースタンドアップによって開発状況や課題、問題など日々共有し、利害関係者を含めたレトロスペクティブ（ふりかえり）によってイテレーション中に得た教訓や学びを形式知化する、といった改善活動を継続して行ます。

アジャイル開発における品質向上の仕組み

図６は、アジャイル開発の一般的なライフサイクルと、品質ライフサイクルを縦に並べたものです。アジャイル開発のライフサイクルは、品質のライフサイクルとうまく適合していることがわかります。

図６　アジャイル型開発ライフサイクルと品質ライフサイクルの比較

アジャイル開発は、動く製品をつくり、利害関係者へのデモンストレーションを行なってニーズを効果的に引き出すことで利害関係者の要求を定義して明示化します。利害関係者の要求は、短時間で開発できる単位に分解されて、分析により品質要求が導出されます。導出された品質要求は製品へ実装され、利害関係者へのデモンストレーションによって品質（主に利用時の品質と外部品質）が確認されます。さらに、デイリースタンドアップやレトロスペクティブによって、日々の作業の改善活動を定期的に行なってプロセス品質も向上します。

このように、アジャイル型の開発プロセスは、そのライフサイクル自体が品質改善のサイクルになっており、高品質、つまり顧客満足度の高い製品を開発することができます。

おわりに

本稿では、アジャイル型の開発ライフサイクルに備わっている品質向上の仕組みについて、国際規格に基づく工学的な観点から説明しました。
アジャイル開発は、脱ウォーターフォールのための手法として広まっていますが、その工学的な仕組みについてはあまり理解されていないように見受けられます。例えば、ステークホルダーの関与が見込めず開発チームにほぼ丸投げの状態でアジャイル開発をしても、利用時の品質は向上しません。また、ステークホルダーやPOは製品の機能面に注目する傾向があり、開発チームが品質保証に日々取り組まなければ内部品質は向上せず、プロジェクトは失敗するでしょう。
筆者は、プロジェクトの目的・特性をもとに開発プロセスをテーラリングすることが重要だと考えます。もしアジャイルを実践し、意義がわからず惰性で続けているようなプラクティスなどあれば、その意義や必要性について見直してみてください。

参考情報

• ISO/IEC 25010:2011, Systems and Software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models
• ISO/IEC 25030:2007, Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Quality requirements
• Joseph W. Yoder, Rebecca Wirfs-Brock, Ademar Aguilar (2014). "Quality Assurance to Agile Quality"