アジャイル開発で品質をどうやって確保する?~「アジャイルテストの四象限」を読み解く~

  • テクノロジー
  • ビジネススキル

皆さんこんにちは!富士通ラーニングメディア ナレッジサービス事業本部の佐藤です。今回はアジャイル開発のコラム第9弾をお送りします 。

ご参考:前回までのコラム(注1)

本コラムでは、アジャイル開発の中でもわかるようでわからない「品質」について解説します。皆さまがアジャイル開発へ取り組むヒントになれば幸いです。

利用者の品質 VS プロダクト品質

本コラムでは、アジャイル開発で考慮すべき品質特性について、「利用時の品質」、「プロダクト品質」、「プロセス品質」の3つに分けて紹介したいと思います(図1)。

20241107_02 .jpg

図1:アジャイル開発で考慮すべき品質特性

利用時の品質には、利用者にとって魅力的な要素(魅力的品質)が含まれます。プロダクト品質では、仕様(とくに機能要件)に沿ってプロダクトを作り、欠陥がない状態を目指します。最後のプロセス品質は、作業工程などの進め方を改善し続けます(様々な品質の向上を下支えします)。

3つのうち、プロダクト品質は、プロセス品質とともに日本のソフトウェア開発者がたいへん注力してきた品質ではないかと思います。例えば、私たちが所属する情報システム開発の世界では、できるだけ沢山の機能を実装し、バグを潰してリリースすることが「当たり前」に求められることが多いと思います。

しかしながら昨今は、時代の変化とともに、利用者から見た利用時の品質が注目されています。利用時の品質は、ソフトウェアの品質を測定するための国際規格 SQuaRE(Software Quality Requirements and Evaluation)シリーズのうち ISO/IEC 25010 にて定義されています。品質の力点は、国際的にも利用者視点へシフトしつつあるのが現状です。そこで、利用時の品質を考慮しつつ進めるソフトウェア開発手法として、アジャイル開発が注目されています。

アジャイルテストの四象限

もちろん私たちは、利用時の品質について、これまで何もしてこなかったわけではありません。例えば、ウォーターフォール開発であれば、要件定義で妥当性確認を行い、設計段階で魅力的品質を作り込むことも可能です。しかしアジャイル開発では、もうすこし柔軟に動くことができるようです。アジャイル開発で品質をどのように確保しているのか、「アジャイルテストの四象限」を読み解いていきたいと思います(図2)。

20241107_03.jpg

図 2:アジャイルテストの四象限

アジャイルテストの四象限は、テストの大枠を把握し、どのテストが必要なのかを検討する手助けになるものです。2003年にブライアン・マリック(Brian Marick)が定義したモデルが元となり、アジャイル開発では広く利用されています。テスト活動を2つの軸で分類し、縦軸に「ビジネス面」と「技術面」を取り、横軸に「チームを支援」と「製品を批評」を取ります。4つの象限は、左下をQ1(Quadrant 1, 第一象限)として、そこから時計回りに各順に、Q2, Q3, Q4と呼ぶことが多いです。 

※ 象限に付けられた数字は、あくまで便宜的なものです(テストを実施する順序とは関係がありません)。
  • 第一象限(Q1):単体テスト
    主に開発者が、プロダクトが意図したとおりに動作することを確認します。
  • 第二象限(Q2):機能テスト
    PO(または利用者)の意図したとおりに機能が動作するかをテストします。
  • 第三象限(Q3):ユーザビリティーテスト
    プロダクト全体の動作がユーザビリティーと機能の要件を満たしていることを検証します。
  • 第四象限(Q4):非機能テスト
    プロダクトが非機能要件を満たしていることを確認します。

それでは、それぞれの象限の概要を見ていきたいと思います。

プロダクト品質に関わるもの

●第一象限(Q1):単体テスト

単体テストは、アプリケーション全体の中から1つのモジュール(単一のクラスや関数など)を完全に取り出して実行するテストです。 開発担当者が開発環境で行うことが多く、各モジュールが正しく動作するかを確認します。

アジャイル開発では、開発者がコーディングの際に単体テストを行うことになります。テスト駆動開発(注2) を採用している場合は、コーディングの前にテストを書きます。

※ 単体テストは、コンポーネントテスト、ユニットテストとも呼ばれます。
※ アジャイル開発には、「結合テストをいつ行うか」という明確な基準はありません。チームによっては、シンプルな結合テストであれば単体テストの象限(Q1)に分類することもあります。

●第二象限(Q2):機能テスト

機能テストは、プロダクトが実行する機能を評価するテストです。機能完全性、機能正確性、および機能適切性などをチェックします。

アジャイル開発では、作ったものの動作をテストし、要求(仕様レベル)に沿うものを作ることができたかを、ビジネス側と一緒に検証します。受け入れテスト駆動開発(注3) が採用される場合もあります。単体テストの象限(Q1)と部分的に重複することもありますが、Q1よりもプロダクト全体の動作を確認することになります。

利用時の品質に関わるもの

●第三象限(Q3):ユーザビリティーテスト

ユーザビリティーテストは、利用者が求めているものへの仮説を検証するテストです。利用者が特定の状況でプロダクトを使用する際の有効性、効率性、満足度の度合いを評価します。

アジャイル開発では、利用者が求めているプロダクトになっているか、ビジネスゴールを達成できるかなどを、ビジネス側と一緒に確認します。機能テストの象限(Q2)よりも利用者志向であり、妥当性確認に重点を置いています。例えば、ユーザビリティーテストの結果、「要求(仕様レベル)どおりに作ってもらっているが、欲しいものと違う」と、利用者からフィードバックを受けた場合には、プロダクトを修正し、必要に応じてQ1・Q2・Q3を行き来しながら、利用者にとって欲しいものへ近づけていくことになります。

どちらにも関わるもの

●第四象限(Q4):非機能テスト

非機能テストは、プロダクトが実行する機能特性以外の属性をテストし、非機能要件を満たしていることを確認します。

アジャイル開発では、プロダクトの反応スピードやパフォーマンス、セキュリティなど、利用者が実際に使用する機能とは直接関係ない部分をテストし、快適に使用できるか、安全に使用できるか、などの観点での品質を高めます。ユーザビリティーテストの象限(Q3)では使用性を検証しますが、Q4は使用性以外の「~性」をテストします。

※「~性」には、性能効率性、互換性、信頼性、セキュリティ、保守性、移植性などがあります。

このようにアジャイルテストの四象限は、おおむねQ1~Q2でプロダクト品質に関わるものが多く、Q3は利用時の品質に関わるものが多いと把握すると、初めて学ぶ方にはわかりやすいでしょう(Q4はどちらにも関わります)。

大きな特徴として、ウォーターフォール開発であれば、決められた工程順にテストが進んで完了しますが、アジャイル開発では、それぞれの象限を行き来します。品質に関する目標・メトリクスは、関係者があらかじめ認識を共有するようにはしますが、ユーザビリティーテストの結果を踏まえて、必要性が高ければ変更も受け入れます。そのような進め方で、利用時の品質を実現していきます。

まとめ ~利用時の品質を確保しよう~

本コラムでは、アジャイル開発の中でもわかるようでわからない「品質」を説明しました。当社はアジャイル開発の教育研修を提供していますが、受講される方々の傾向として、どなたもプロダクト品質に強い関心があり、それゆえに利用時の品質を見落としがちです。例えば 「仕様に沿って忠実に作り、バグをしっかり潰せば、お客様に価値を提供できる」 と考える方々は、Q3で行うべき妥当性確認を怠り、結果、利用者にとって欲しいものを作れずに終わる傾向にあります。このようなご自身の傾向に、非常に多くの方がほぼ無意識です。そのため、ご自身がいまどの品質について考えて動いているか、今一度、ご確認しつつ向き合っていただければと思います。

また、ウォーターフォール開発とアジャイル開発は、似て非なる開発手法ではありますが、そうは言っても同じソフトウェア開発です。品質の定義やテスト手法は、案外、共通するところがあります。皆さんがこれまで培ってきた品質に関するノウハウには、転用可能なものもあることでしょう。詳細な進め方を検討する際には、スクラムやプラクティスが役立ちますので、いずれそのような学習も進めていただき、新しい作業の進め方を検討いただければと思います。

富士通ラーニングメディアでは、アジャイル開発に関する研修サービスを多数ご用意しています。ぜひ、この機会に研修受講をご検討ください。今後もアジャイル開発のコラムを発信していきますので、どうぞよろしくお願いいたします。

関連コース紹介

【eラーニング】アジャイル開発における品質活動(UEL87B)

本コラムは、本コースの内容の一部をもとに執筆しました。アジャイル開発の品質について、どのような品質特性に配慮し、どのように活動したらよいか、ポイントを押さえて学習できるコースです。アジャイルテストの四象限、テスト駆動開発などについても紹介しています。

【ライブ】JSTQB認定テスト技術者 FLトレーニング(UZS33R)

国際的に普及しているISTQBのシラバスに基づいて、ソフトウェアテストの基本的な手法や技法について学習するコースです。JSTQBテスト技術者資格のFoundation Levelに取り組まれている方にもお勧めの内容です。

※ 各コースの詳細は、当社ウェブサイトをご覧ください。

執筆者紹介

ナレッジサービス事業本部 マネジメントPJ 研修講師
佐藤 幸呼(さとう さちこ)

富士通グループにて、SI工程前の顧客向けビジョン策定ワークショップなどに従事。FLMへ転社後、教育研修講師としてプロジェクトマネジメント、ITサービスマネジメント、アジャイル開発などのカテゴリを担当。米国にて富士通JAIMS “The East-West Knowledge Leaders Program” 修了。教育研修サービスの企画開発・教材執筆から、サービスデリバリ・継続的改善に至るサイクルを回すべく、FLM社内で「品質会議」の運営に携わる。

(注1)前回までのコラムはこちらからご覧ください。

(注2)テスト駆動開発

最初にテストを書き、そのテストが動作する必要最低限な実装を行った後、コードを洗練させる、という短い工程を繰り返す手法です。 ケント・ベック(Kent Beck)の『テスト駆動開発』には、「動作するきれいなコード」という記述があり、以下のような特徴があるとされています。

  • 読みやすい
  • 何がしたいのか意図がつかめる
  • 修正がしやすい、修正にかかるコストが少ない
  • 再利用しやすい

(注3)受け入れテスト駆動開発

開発に先立って受け入れテストを書き、開発したコードをその受け入れテストで検証するアプローチです。ユーザーストーリーを実装する前に、テストケースを作成します。必須のテストということはありませんが、広く知られている概念です。

(2024/11/07)

関連記事