1．アジャイル開発における品質管理の考え方
2020年2月に書いた「アジャイル開発での品質保証～成功の鍵～」という記事で、アジャイル開発における品質管理の難しさと、それを解決するための考え方について紹介しました。
ソフトウェア開発における品質管理では、従来「プロセス品質」と「プロダクト品質」という2つの視点から捉える手法がとられてきました。しかしながら、ウォーターフォール開発でこれらの品質を評価するために使われていた「テスト密度」や「バグ密度」といったメトリクスを、アジャイル開発では適切に測定できないことがあります。そのため、アジャイル開発では従来の手法に従った品質管理や品質評価ができないという問題が起きます。
そこで、アジャイル開発で適切に品質を管理・評価するために、「プロセス品質」と「プロダクト品質」に影響を及ぼす「要求品質」と「リソース品質」という2つの視点が重要であることを、前述の記事で解説しました（図1）。今回は、このうちの「リソース品質」についてより詳しく解説します。
図1：ソフトウェア品質向上の着眼点（※1）
経済産業省「システム及びソフトウェア品質の見える化、確保及び向上のためのガイド」の図を一部改変
2．リソース品質とは
リソース品質について、JIS X 25010:2013には「資源の品質」という名称で、『資源の品質（例えば、プロセスで使用される、人的資源、ソフトウェアツール、ソフトウェア技術）は、プロセス品質に影響を及ぼし、その結果として、製品品質に影響を及ぼす。』との記述があります（※2）。この記述にある通り、リソース品質には様々な要素が含まれます。しかし、これらの要素をすべて適切に評価するのは難しいため、まずは対象を絞ることにします。ここでは、スクラムをはじめとする多くのアジャイル開発方法論で重要視されている「チームの能力」をリソース品質の主要な要素とみなし、管理・評価の対象としました。リソース品質が高い、すなわち能力が高いチームの特徴としては、例えば以下のようなものが挙げられます。
- 多くの成果をあげる。
- 計画を順守する。
- 変化に対応する。
- 失敗を繰り返さない。
- 常に改善し続ける。
これらの特徴のうちの一部を定量的に測るために、いわゆる進捗や生産性を測るためのメトリクスやグラフを用いることができます。具体例としては、以下のようなものがあります（図2）。
- スプリントバーンダウンチャート
- リリースバーンダウンチャート
- ベロシティ
- 累積フロー図
図2：リソース品質の管理・評価に使用できるメトリクス・グラフ
もちろん、グラフや数値だけでは分からない部分もありますので、定性的な評価とあわせて総合的に評価する点は従来の品質評価と同様です。
JIS X 25010:2013 システム及びソフトウェア製品の品質要求及び評価（SQuaRE）−システム及びソフトウェア品質モデル
3．リソース品質の管理
先ほど紹介したリソース品質に関するメトリクスは、JIRAなどのプロジェクト管理ツールではグラフ・レポート機能を使って確認できることが多いでしょう。また、独自の観点での評価や様々な観点の総合的な評価を行いたい場合は、プロジェクト管理ツールからデータを抽出してダッシュボードを作成することもできます。図3は、当社で使用しているダッシュボードの一例です。
図3：品質ダッシュボードの例
これらのグラフは、イテレーション（スプリント）が完了した時に、そのイテレーションの結果を確認するときに使用するだけでなく、日々モニタリングすることで、チーム状況の変化にいち早く気づくことができます。そして、グラフや数値を確認して終わりではなく、問題やその兆候があった場合には改善のための対策を打たなければなりません。
リソース品質の管理に関わる作業は、スクラムマスターや開発チームのリーダーが担うことが多いですが、開発チームのメンバーも関与できるようになると、より成熟したチームになったと言えるでしょう。
4．リソース品質管理の実例
ここでは、リソース品質とプロダクト品質の関係を、実際のプロジェクトの事例を使って紹介します。リソース品質として「1ストーリーポイントにかかる時間」、プロダクト品質として「累積バグ数」というメトリクスを用いて評価しました。「1ストーリーポイントにかかる時間」は、値が大きいほどリソース品質（生産性）が低く、値が小さいほどリソース品質（生産性）が高いと言えます。また、累積バグ数は、これだけで一概にプロダクト品質を判断できるものではありませんが、ここではバグが多く見つかるほどプロダクト品質が低く、バグが見つからないとプロダクト品質が高いとして評価しました。
図4に示した期間では、リソース品質が安定した少し後にプロダクト品質が安定し、リソース品質が低下したり不安定になった後にプロダクト品質が不安定になったりするというように、リソース品質の影響が少し遅れてプロダクト品質に表れるという傾向が見られました。
図4：リソース品質とプロダクト品質の関係（1）
また、図5ではやや長期的な期間を示していますが、リソース品質が高すぎるときにも、その後にプロダクト品質が低下するという傾向が見られました。「1ストーリーポイントにかかる時間」が小さすぎるということは、時間を十分にかけずに作業しているために、成果物の質が落ちたのではないかと考えられます。
図5：リソース品質とプロダクト品質の関係（2）
もちろん、これらの例だけでリソース品質とプロダクト品質には関係性があると結論づけられるものではありませんが、リソース品質をモニタリングすることで開発チームの状況の変化を的確に捉えることができ、プロダクト品質への影響を最小限に食い止められる可能性があると言えるでしょう。
5．まとめ
アジャイル開発では、従来の品質の概念にとらわれず、より広い視点を持つことが重要です。はじめから成熟したチームであることは少ないと思いますが、適切な管理をしてチームの成熟度を高めることで、作成する成果物の品質も高くなります。
NTTデータでは、従来のウォーターフォール開発で培った品質管理のノウハウを基にしながら、アジャイル開発のような新しい開発プロセスにも対応した品質管理の手法を用いて、お客さまが求める価値をもたらすシステムの開発を行っています。
